Estruturação de Código

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?

Oi Israel,

esta é uma organização bacana pro seu código, claro: existem milhares de maneiras de se organizar os nossos projetos, mas costumo adotar sempre aquela que considero mais simples, porque normalmente pensar em flexibilidade demais no início do trabalho costuma gerar verdadeiros monstrinhos em complexidade conforme o tempo passa.

Lembre-se do seguinte:
* Se for sempre usar um SGBD para armazenar os seus dados, é possível escrever um único DAO, alterando apenas a configuração do Hibernate depois (nestas horas arquivos XML mostram o seu valor em comparação às anotações).
* Caso contrário, ou seja, se seus dados podem estar em fontes diferentes, como por exemplo webservices, etc, neste caso a arquitetura convencional de DAOs é a mais aplicada.

Com relação a este intermediário entre a classe de entidade e o DAO, normalmente o que vejo é o pessoal criar esta classe só para selecionar qual a implementação correta de uma interface de DAO. Mas este intermediário também se torna intermediário se você usar um container de inversão de controle como o Spring por exemplo.

Caso não tenha experiência com containers de IoC, sugiro que dê uma olhada em um que implementei justamente para casos como o seu, ou seja, de gente que ainda está aprendendo o que vêm a ser este conceito. Se chama miocc, e pode ser baixado gratuitamente em http://miocc.itexto.com.br

Bom carnaval!

Bom carnaval pra c bm, logo mais a gente conversa!

Boa tarde Henrique.   Mas porque utilizar um framework de ioc? Seria somente para promover desacoplamento? Não é mais facil instanciar objetos diretamente nas classes que o utilizarão os daos e os beans?    

Um container de IoC traz como vantagem os seguintes pontos: * maior desacoplamento * possibilidade de externalização de configurações. O que ocorre: esta classe intermediária que você citou no seu post faz basicamente o trabalho de um container de IoC, ou seja, ela seleciona qual implementação instanciar para cada caso. Dado que esta decisão é normalmente feita uma única vez durante o ciclo de vida de uma aplicação (inicialização, execução, finalização), ao invés de você ter de criar uma classe intermediária para cada DAO, você basicamente precisa de apenas uma: a do seu container de IoC, e um único arquivo de configuração, que depois você pode alterar à sua vontade conforme a necessidade. Este é o grande lance com o padrão IoC. Sinceramente, acredito que uma arquitetura baseada em Sprint (IoC) + Hiberante (ORM) simplifica em 90% o trabalho do desenvolvedor.

Boa noite Henrique! Peço desculpas pela demora. Estou fazendo a portabilidade de meu telefone para outra operadora e por enquanto estou sem internet, peço que aguarde mais um pouco pois logo este problema sera resolvido. Pela atenção muito obrigado. 

Sem problema Israel.
Estamos à sua disposição.

Boa noite Henrique Henrique, pense em um programador iniciante perdido !!! Vou tentar explicar as coisas por partes: Dentro do pacote model eu terei os pacotes beans, services e DAOs, que conterão respectivamente os objetos de negócio da aplicação,
as classes de serviços que servem como um façade para os DAOs, e os DAOs certo? Observação: vou utilizar as classes services por enquanto, ao invés do miocc para incurtar a curva de aprendizado. A principal duvida aqui é a construção correta da classe SubCategoriaService e PedidoService, vc acha que esta certo fazer mais ou menos como segue abaixo: Observe que a classe subCategoriaService contém uma instancia da classe CategoriaDAO e uma lista de categorias que servira para alimentar um combobox que sera exibido no formulário de subCategorias
e neste mesmo formulário ao lado deste combobox havera um botão de atalho que chamara o editor de categorias para inserção de uma nova categoria caso necessário, por isto alem do método que lista todas categorias (obterTodasCategorias()) existe o método salvaCategoria(Categoria categoria) . Esta certo desta forma ou cometi um equívoco?
Se estiver certo, a classe de PedidoService deve seguir o mesmo estilo não é ?
Tem jeito de vc me guiar para quais métodos devo escrever nesta classe?
Outra questão é a classe PedidoDAO, ela será um DAOZÃO
que gerenciará os pedidos e seus itens ou devo criar dois DAOs distintos
um para gerenciar os pedidos e outro para os itensPedido ? package br.com.order.model.service; import java.util.ArrayList;
import java.util.List; import br.com.order.model.beans.Categoria;
import br.com.order.model.beans.SubCategoria;
import br.com.order.model.dao.CategoriaDAO;
import br.com.order.model.dao.SubCategoriaDAO; public final class SubCategoriaService {   
    private List<SubCategoria> subCategorias;
    private List<Categoria> categorias;
    private SubCategoriaDAO subCategoriaDAO;
    private CategoriaDAO categoriaDAO;     // Metodo Construtor ******************************************************
   
    public SubCategoriaService() {
     subCategoriaDAO = new SubCategoriaDAO();
     categoriaDAO = new CategoriaDAO();
     subCategorias = new ArrayList<SubCategoria>();
     subCategorias.addAll(subCategoriaDAO.obterTodasSubCategorias());
     categorias.addAll(categoriaDAO.obterTodasCategorias());
    }
   
  
    // Expondo a Lista de SubCategorias *****************************************     public List<SubCategoria> obterTodasSubCategorias() {
        return subCategorias;
    }
   
    // Expondo a Lista de Categorias *******************************************
   
    public List<Categoria> obterTodasCategorias(){
     return categorias;
    }     // Gerenciando SubCategorias *************************************************     public void salvaSubCategoria(SubCategoria subCategoria){
     subCategoriaDAO.salvarSubCategoria(subCategoria);
    }
   
    public void removeSubCategoria(SubCategoria subCategoria){
     subCategoriaDAO.removerSubCategoria(subCategoria);
    }
   
    // Gerenciando Categorias ***************************************************
   
    public void salvaCategoria(Categoria categoria){
     categoriaDAO.salvaCategoria(categoria);
    }
   
    // Obtendo SubCategorias ****************************************************
   
    public SubCategoria obterSubCategoriaPorId(Integer id){
     return subCategorias.get(0);
    }
   
    public List<SubCategoria> obterSubCategoriaPorDescricao(String descricao){
     return subCategorias;
    }
   
    }
           

Oi Israel, vamos lá:

> Dentro do pacote model eu terei os pacotes beans, services e DAOs, que conterão respectivamente os > objetos de negócio da aplicação,
> as classes de serviços que servem como um façade para os DAOs, e os DAOs certo?

Com relação a "classes de serviços". Já vi algumas definições para este conceito (inclusive o seu). No entanto, sou mais próximo do seguinte (parafraseando): "são classes que encapsulam lógica de negócio que possa ser reaproveitada em mais de uma parte do seu sistema".

Exemplos: uma classe de encriptação ou de ordenação por exemplo. No entanto, acaba que o significado REAL do termo varia de projeto pra projeto. Acontece demais isto. Acho que o melhor mesmo Israel, é você seguir o seguinte princípio: adote a nomenclatura que seja mais fácil para que você entenda o seu código e consiga explicá-lo. Se achar que a sua está beleza, use-a, se achar a que expus melhor, adote-a.

Acho importante também que nos lembremos do que é o padrão de projeto fachada ok?
"Fachada é um objeto que provê uma interface simplificada para um conjunto maior de código, como uma biblioteca de classes por exemplo"

Acho importante que reflitamos um pouco sobre este conceito: quando você implementa o padrão fachada? Normalmente em situações em que uma mesma sequência de ações é repetida em mais de um local dentro do seu código. Um exemplo clássico disto seria uma classe de fachada para manipulação de um sistema de arquivos. Imagine que em diversos locais no seu código você precise compactar um conjunto de arquivos. Então, uma solução é você criar uma classe de fachada com um método com a assinatura similar à abaixo:

public void zipar(List<File> arquivos, File arquivoDestino);

Vamos agora supor que você acaba precisando também descompactar alguns arquivos de tempos em tempos, e este código se repita no seu código: você incluiria um outro método, cahmado "dezipar" que seria incluido na sua classe de fachada, e por ai vai.

Reparou algo interessante aqui? o conceito de classe de serviço e fachada se mostraram práticamente o mesmo! Voltamos então ao que te propus inicialmente: use a nomenclatura que melhor lhe convier. O interessante de se adotar algo que é padrão na industria (usar por exemplo o padrão facade) é que torna mais fácil a sua comunicação com o mundo externo ao seu projeto. Porém, isto de nada irá lhe valer se for mais difícil pra você, concorda?

> Observe que a classe subCategoriaService contém uma instancia da classe CategoriaDAO e uma lista de
> categorias que servira para alimentar um combobox que sera exibido no formulário de subCategorias
> e neste mesmo formulário ao lado deste combobox havera um botão de atalho que chamara o editor de
> categorias para inserção de uma nova categoria caso necessário, por isto alem do método que lista todas > categorias (obterTodasCategorias()) existe o método salvaCategoria(Categoria categoria) .

Repare no que grifei no seu texto. Há um perigo aqui. Você está implementando a sua camada de modelo pensando já no formulário. Isto é uma armadilha a médio e longo prazo. Quando estiver trabalhando no seu modelo, finja que não exista interface gráfica. Ignore-a completamente.

Por que isto: reaproveitamento de código. Hoje você está pensando em desktop. E se amanhã quiser trabalhar com web ou computação móvel?


Agora, com relação ao seu código, uma pergunta: porque você declarou a sua classe como final? Por qual razão você quer evitar que no futuro sejam criadas classes que herdem desta? Lembre-se: você só declara uma classe como final quando não quer em hipótese alguma que sejam criadas classes derivadas. Exemplo? a classe String do Java. Seria uma bagunça se todos pudessem criar as suas próprias implementações de algo tão básico. Então a solução adotada pelos projetistas foi implementá-la como final. Pense nisto.

Outra: reparou que esta sua classe SubCategoriaService tá mais pra DAO do que um encapsulador de lógica de negócio? Sugestão: mova estes métodos que obtém dados para o seu DAO. Assim você centraliza o acesso ao banco de dados em um só lugar, não?

Então neste caso é besteira implementar a classe no estilo SubCategoriaService? Eu coloquei final por engano, nem havia reparado.   Sugestão: mova estes métodos que obtém dados para o seu DAO.     Ate mesmo o que obtem as subCategorias ou devo tira-lo daqui?   Então no meu SubCategoriaDAO deve cuidar somente das subCategorias?

Oi Israel,

sim, minha sugestão é a de que você mova estes métodos que fazem pesquisa para o DAO, visto que tem na realidade mais a ver com esta classe do que a de serviço.

A idéia é que o seu SubCategorias só cuide das SubCategorias mesmo. É como havia te dito: inclua na sua classe Service apenas a lógica de negócio mesmo da sua aplicação, mas nada diretamente relacionado a buscas no banco de dados.

Fazendo isto você gera menos classes e, consequentemente, torna seu código mais simples de ser mantido também.

Bao tarde Henrique   E com relação ao DAO de pedidos vc recomenda eu embutir nele as operações necessarias para os itensPedido dentro dele ou criar um DAO separado para cuidar somente dos itensPedido?   No caso estou utilizando JPA vc acha terei problemas com esse negocio da JPA não saber deletar um objeto orfão?

Oi Israel,

recomendo incluir tudo dentro do próprio DAO, pois assim serão menos classes para você dar manutenção, além de ficar melhor divididas as tarefas.

Pode fechar este chamado.