Fórum Estruturação de Código #13884

Moderação: Direcionar este chamado para Henrique A pedidos do cliente.

Dyego se vc quiser dar continuidade neste post, pode prosseguir. Pedi para que fosse direcionado ao Henrique porque outro dia vc disse pra mim que Jgoodies não era muito sua praia. 

Oi Israel, bom: com relação à organização do seu código, o que costumo dizer é o seguinte: MVC deve ser a sua religião. Na minha opinião, o ideal sempre é que você organize seu código, se possível, em dois projetos distintos: um apenas para lidar com a sua camada de negócios, persistência, integração com plataforma baixa (sistema operacional, web, sgbd, etc) e uma outra, bem menos complexa, para que você trabalhe apenas com a interface gráfica. Em teoria, poderia até ser possível criar 3 projetos: um para o modelo, outro para a visualização e um para o controle, mas na prática o que observo é que o controlador sempre acaba ficando muito dependente do toolkit de visualização que você optou, razão pela qual opto sempre por 2 projetos distintos. Esta abordagem é ótima porque sua camada de negócios será obrigatóriamente independente de um tipo específico de interface gráfica, como desktop, web ou mobile. Além disto, já facilita a integração no futuro do seu projeto com outros sistemas. Sendo assim, o ideal é iniciarmos pelo seu projeto que será o responsável por lidar com o modelo. Trataremos do modo como você está acessando o SGBD, assim como da organização do seu código e o que deverá ser exposto à camada de visualização (ou qualquer outro sistema com o qual seja necessário interagir). Em seguida, poderemos nos focar no JGoodies. Não tenho experiência alguma com esta biblioteca, porém farei o possível para aprender o máximo que puder para que possamos trabalhar juntos. O que me diz?

A idéia é otima. No entanto utilizando a utilização de mvc dificulta os testes unitarios sobre a interface. E o jgoodies é focado no padrão presentation model por isto disponibilizei os exemplos com documentação. Para web mvc pode ser mais indicado. No entanto pelo que tenho lido presentation model e o mais indicado para desktop O que vc acha?

Oi Israel, na minha opinião, em ambos os casos (Presentation Model) ou MVC, testes unitários não são de fato a coisa mais fácil de se fazer. Hà muita discussão a respeito de qual a melhor alternativa de se executar os testes unitários, razão pela qual, neste ponto realmente não sei te responder. Mas em ambos os casos temos o modelo, certo? Se partirmos dele, podemos já começar alguma coisa. O que me diz?

Blz, Propuz à vc o padrão presentationModel pelo fato de jgoodies ser projetado para aplicação deste padrão, pelo menos a api de binding, e tambem porque ja estou mais familiarizado com este padrão.   E tambem disponibilizei os fontes e javaDocs de um exemplo que acompanha o Zip de distribuição da api de binding que exemplifica de forma clara como dividir responsabilidades entre as classes e a utilização do padrão PresentationModel, aplicado a um cadastro de Albums, o qual ja estudei e conheço bem. No entanto o exempo é simples e quando a complexidade do sistema a ser desenvolvido começar a aumentar com certeza ficarei perdido por este motivo preciso de ajuda. Então sujiro que vc de um olhada no exemplo, ele pode servir como um bom ponto de partida. O que vc me diz? link para o exemplo:
http://video.devmedia.com.br/discovirtual/200152/AlbumManager/AlbumManager.zip

Oi Israel, já estou com o seu código aqui. Sendo assim, mande-me suas dúvidas para que possamos começar o nosso bate bola ok?

Vou começar a construir o digrama de classes que representa a arquitetura do sistema logo mais te envio, blz.

Olá Henrique Montei um diagrama que de uma forma simplificada representa
a arquitetura da aplicação de exemplo. Uma de minhas duvidas
é a seguinte:
Repare na classe em amarelo, ela representa um formulário para edição
dos dados de um compositor. Vc acha que vou encontrar problemas
com esta arquitetura na hora de acrescentar novos formulários a aplicaçao
visto que todas as ações devem ficar na classe PresentationModel Um dos problemas que vejo é com relação ao owner do dialogo
que ficará nulo, pois a classe presentationModel não possui referencia
para um JFrame que sera o owner do dialogo. Vc vê algum outro problema com esta arquitetura quando formos
aumentar a quantidade de classes ? Vc Propõe alguma alteração nesta
arquitetura?

Oi Israel,

bom: vou começar pelos detalhes ok?

no seu diagrama, você diz que classe AlbumPresentationModel recebe uma instância de Album como parâmetro em seu construtor, certo?
Dica: sempre tenha um construtor padrão implementado, a não ser que seja uma situação muito (mas muito mesmo) singular. Lhe digo isto por experiência própria: 99,9999% das vezes em que adotei um raciocínio similar a este passado algum tempo acabei incluindo algum construtor default posteriormente, fosse para que funcionasse com algum outro framework/biblioteca fosse por alguma outra razão.

Outro questionamento deve ser incluído nesta linha de raciocínio: na sua classe AlbumPresentationModel, por exemplo: você tem certeza ABSOLUTA de que no decorrer da vida desta classe ela deverá receber apenas uma vez uma instância de Album? Lembre-se: objetos são caros. Quanto menos instâncias você possuir de suas classes, melhor.

Agora, à sua pergunta principal: "Repare na classe em amarelo, ela representa um formulário para edição
dos dados de um compositor. Vc acha que vou encontrar problemas
com esta arquitetura na hora de acrescentar novos formulários a aplicaçao
visto que todas as ações devem ficar na classe PresentationModel"

Não terá problema na medida em que manter a sua classe PresentationModel o mais independente possível de qualquer formulário. Este é o ponto. Vou fazer uma tradução livre de uma frase de Martin Fowler a respeito deste assunto: "a essência do padrão Presentation Model consiste em se ter uma classe auto contida que represnete todas as informações do modelo da interface gráfica, mas que seja completamente independente dos componentes usados no formulário para representar estas informações".

Acho que talvez você conheça este texto, visto que seu exemplo é basicamente o contido nele (http://martinfowler.com/eaaDev/PresentationModel.html). Se não leu, está ai uma leitura muito interessante sobre o assunto.

Agora, à pergunta seguinte: "Um dos problemas que vejo é com relação ao owner do dialogo
que ficará nulo, pois a classe presentationModel não possui referencia
para um JFrame que sera o owner do dialogo."

Neste ponto, a responsabilidade pelo formulário pai da sua caixa de diálogo deve ser a sua instância do formulário, e não o presentation model.

E, finalmente, a pergunta final: "Vc vê algum outro problema com esta arquitetura quando formos
aumentar a quantidade de classes ? Vc Propõe alguma alteração nesta
arquitetura?"

Olha, sei que você quer usar o JGoodies e por isto se interessou pelo Presentation Model. No entanto, acho qeu ele complica demais o que pode ser fácilmente obtido pelo padrão MVC (que já é adotado como fundamento do Swing). O que pude observar no seu diagrama de classes é que não há uma distinção nítida entre modelo e visualização. O ideal seria se você primeiro os separasse em pacotes. Um para sua lógica de negócios, entidades, etc e outro apenas para a sua interface gráfica.

Neste ponto, sou inclusive radical. Costumo criar projetos distintos para estes dois pontos. Assim fica mais fácil de se garantir a independència de suas clásses de domínio a respeito de qualquer visualização.

Precisnado, já sabe: estamos ai para lhe ajudar neste caminho.

Estou vendo o funcionamento do mvc logo, peço um tempo para que eu analize este padrão logo mais te retorno,ok?

Ok Israel, estamos à sua disposição ok?

Oi, Desculpe a demora. Henrique, decidi que quero aprender das duas formas
tanto utilizando o padrão Presentation Model quanto
utilizando o padrão MVC. Como vc disse em ambos os
casos teremos o modelo, então podemos começar por ele.
  Pelo que eu entendi o modelo contém as classes de negócio como categoria sub Categoria
produto, usuário e seus respectivos DAOs para acesso ao banco além de integração com plataforma baixa e outras coisas. Não é? Porem estava pensando no seguinte: Criar implementações diferentes para os DAOs,
uma implementação que acessa os dados via JDBC e outra
que utiliza um framework ORM como Hibernate, tudo
isto utilizando o padrão Abstract Factory. Qual sua opinião? Como vc disse é aconselhavel que se crie dois projetos um para o modelo e outro para visão e o controlador. Como será feita a comunicação entre os dois projetos?
Será através de um façade?
Se a resposta for sim em qual dos dois projetos este façade ficará? Vc acha que devo começar criando as classes de negócio (pojos) logo em seguida criando um
dao generico e depois para cada classe de negócio criar um DAO especifico. Ou seja quais os passos que devo seguir? Segue abaixo o diagrama de Entidade Relacionamento que cotém o modelo de dados a ser programado.    

Oi Israel,

bom: vamos por partes ok?

> Pelo que eu entendi o modelo contém as classes de negócio como categoria sub Categoria
> produto, usuário e seus respectivos DAOs para acesso ao banco além de integração com plataforma baixa e > outras coisas. > Não é?
Exatamente. Toda a sua lógica de negócio fica na camada de modelo.
> Porem estava pensando no seguinte: Criar implementações diferentes para os DAOs,
> uma implementação que acessa os dados via JDBC e outra
> que utiliza um framework ORM como Hibernate, tudo
> isto utilizando o padrão Abstract Factory.
> Qual sua opinião?
Bem Israel, neste caso, cada caso é um caso é a melhor resposta em um primeiro momento. No entanto, o que costumo observar é o seguinte: na ânsia de se criar uma arquitetura capaz de obter/persistir dados na maior variedade de fontes possível (bancos de dados, web services, arquivos texto, etc) complica-se algo que poderia ser simples.Por exemplo: banco de dados. Já vi demais ser usado ao extremo o padrão DAO no qual cria-se interfaces para cada DAO de cada classe de domínio e, em seguida, uma implementação para cada tipo de banco de dados. Parece lindo num primeiro momento, porém passado algum tempo observa-se os seguintes pontos:* Em 99,9999999999% dos casos durante toda a vida da aplicação será usada apenas uma base de dados
* Com uma ferramenta ORM como o Hibernate ou TopLink por exemplo consegue-se com uma única classe acessar práticamente qualquer tipo de BD (bastando alterar os arquivos de configuração).Sinceramente, após a popularização das ferramentas ORM não vejo mais esta necessidade em se ficar implementando interfaces e logo em seguida implementações que serão escolhidas em tempo de execução ou por um container de inversão de controle ou arquivos de configuração.
Resumindo: na teoria, é lindo. Na prática, nem um pouco.
> Como vc disse é aconselhavel que se crie dois projetos um para o modelo e outro para visão e o > controlador. > Como será feita a comunicação entre os dois projetos?
> Será através de um façade?
> Se a resposta for sim em qual dos dois projetos este façade ficará?
Eis algo que parece complexo num primeiro ponto, porém com o estudo se mostra banal. Basta disponibilizar para o seu projeto responsável pela camada de controle/visualização os arquivos jar (incluindo dependências) da sua camada de controle.Se estiver usando o Netbeans ou o Eclipse, basta que você referencie o projeto que contém a sua camada de modelo no projeto responsável pela visualização/controle.
Lembre-se do porquê de uma fachada: nela você inclui métodos que encapsulam procedimentos mais complexos que são executados com frequência. (dê uma lida no capítulo sobre facades no "Padrões de Projeto" da GoF).Lembre-se também do grande problema com fachadas: elas crescem! E com o tempo, você vai acabar tendo uma fachada com dezenas de centenas de métodos, lhe forçando a adotar uma abordagem procedural ao invés de orientada a objetos, que seria o ideal.

Qualquer coisa, já sabe: estamos aqui para auxiliá-lo ok?

Boa tarde Henrique. Pelo que eu entendi a estrutura do modelo seria mais ou menos
como segue abaixo?
Vejo muito por ai o pessoal utilizar uma classe chamada de
por exemplo CategoriaService, ProdutoService... que simplesmente que serve como intermediaria entre o DAO
e a classe que o utiliza, então na sua opnião isto é algo desnecessário? Tem algo mais que devo fazer para incrementar o modelo?