Estrutura, nomes de classes e pacotes

21 respostas
F

Em primeiro lugar, se aki não vou o local adequado, me perdoem.

Gostaria da opinião de vcs como seria interessante organizar o projeto, com relação à estrutura, nomes de classes e pacotes.
No momento tenho o seguinte cenário.

Projeto utilizando arquitetura maven:

  • Sistema:
    • controllers

    • dao

    • domain

    • services

    • webapp: somente jsp

Onde:

  • controllers: somente os controllers
    SistemaController.java

  • dao:
    Dao.java - Interface
    GenericDao.java - classe abstrata
    SistemaDaoImpl.java - implementação

  • domain:
    Entidade.java - entidade
    EntidadeType.java - enum

  • services: somente a implementação
    SistemaService.java

Como podem notar, no pacote dao, tenho implementação misturado com interface e classe abstrata.
No domain, tenho entidades e enums.
Os services, a princípio eu não devo utilizar interfaces.

Está bom dessa forma ou sugerem algo melhor ?
Por exemplo, criar um pacote entidade e outro enum, dentro de domain ?

Obrigado

21 Respostas

CristianPalmaSola10

Criar o pacote para a entidade para o enum, eu acho melhor

e tambem fazer um projeto separado para o dao

ai voce adiciona esse outro projeto aqui nesse e seus dao extendem um dao generico que esta nesse projeto novo

eu acho melhor dessa maneira

ate mais

j0nny

CristianPalmaSola10:
Criar o pacote para a entidade para o enum, eu acho melhor

e tambem fazer um projeto separado para o dao

ai voce adiciona esse outro projeto aqui nesse e seus dao extendem um dao generico que esta nesse projeto novo

eu acho melhor dessa maneira

ate mais

E pq complicar dessa forma para ter um projeto apenas com Daos?

CristianPalmaSola10

Quebrando dessa forma e implementando um dao generico que os outros dao’s herdem, ao meu ver fica melhor, pois qualquer projeto que eu queira implementar vou ter apenas que adicionar o jar do projeto do dao no novo projeto, uma reutilização de codigo, mais elegante que crtl+c e crtl+v todas vez

naum acha ?

j0nny

CristianPalmaSola10:
Quebrando dessa forma e implementando um dao generico que os outros dao’s herdem, ao meu ver fica melhor, pois qualquer projeto que eu queira implementar vou ter apenas que adicionar o jar do projeto do dao no novo projeto, uma reutilização de codigo, mais elegante que crtl+c e crtl+v todas vez

naum acha ?

Não compensa a criação de um projeto apenas para um DAO genérico. Lembre-se, descomplicar quando der, faça o necessário, não tente matar uma formiga com um canhão.

CristianPalmaSola10

Cada um tem uma opiniao e faço assim, porque acho assim melhor, e naum é isso que vai deixar o codigo tao mais complicado, no meu ponto de vista naum deixa complicado, que tem mania de fazer um dao para cada classe do banco o que eu disse naum serve

mas como eu implementei um dao generico, e meus dao herdam esse cara, os fica melhor assim

prefiro isso do crtl + c e crtl + v toda vez

j0nny

CristianPalmaSola10:
Cada um tem uma opiniao e faço assim, porque acho assim melhor, e naum é isso que vai deixar o codigo tao mais complicado, no meu ponto de vista naum deixa complicado, que tem mania de fazer um dao para cada classe do banco o que eu disse naum serve

mas como eu implementei um dao generico, e meus dao herdam esse cara, os fica melhor assim

prefiro isso do crtl + c e crtl + v toda vez

Bom, então vc não tem mais nada a aprender, e eu nada mais a acrescentar.

F

CristianPalmaSola10:
Criar o pacote para a entidade para o enum, eu acho melhor

e tambem fazer um projeto separado para o dao

ai voce adiciona esse outro projeto aqui nesse e seus dao extendem um dao generico que esta nesse projeto novo

eu acho melhor dessa maneira

ate mais

Tb acho q criar os pacotes entidade e enum ficaria mais organizado.
Mas acho q iria aumentar a complexidade criando um projeto separado só pra dao.
Obrigado pela sugestão.

j0nny:

E pq complicar dessa forma para ter um projeto apenas com Daos?

Tb acho desnecessário, neste caso.
O que me sugere ?

j0nny

fdiaz2011:
CristianPalmaSola10:
Criar o pacote para a entidade para o enum, eu acho melhor

e tambem fazer um projeto separado para o dao

ai voce adiciona esse outro projeto aqui nesse e seus dao extendem um dao generico que esta nesse projeto novo

eu acho melhor dessa maneira

ate mais

Tb acho q criar os pacotes entidade e enum ficaria mais organizado.
Mas acho q iria aumentar a complexidade criando um projeto separado só pra dao.
Obrigado pela sugestão.

j0nny:

E pq complicar dessa forma para ter um projeto apenas com Daos?

Tb acho desnecessário, neste caso.
O que me sugere ?

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

F

j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

Obrigado pela ajuda !

F

[quote=fdiaz2011]

j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

No caso de interface pra dao, acha valido criar um pacote só pras interfaces ?

Obrigado pela ajuda !

j0nny

fdiaz2011:
fdiaz2011:
j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

No caso de interface pra dao, acha valido criar um pacote só pras interfaces ?

Obrigado pela ajuda !

Não. Caso REALMENTE tenha necessidade de criar interfaces, colocaria no mesmo pacote dos DAOs.

F

j0nny:
fdiaz2011:
fdiaz2011:
j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

No caso de interface pra dao, acha valido criar um pacote só pras interfaces ?

Obrigado pela ajuda !

Não. Caso REALMENTE tenha necessidade de criar interfaces, colocaria no mesmo pacote dos DAOs.

Uma última opinião hehe
Pra interface, acredito q precise usar sim mais pra frente, acha q devo colocar algum sufixo ou prefixo pra identifica-las como interface ?

Eu sempre tenho curiosidade como o pessoal faz e quando acho melhor eu mudo a minha maneira de fazer. :smiley:

Fui editar o post anterior, mas o forum duplicou e colocou quote e ficou esquisito…
:frowning:

j0nny

fdiaz2011:
j0nny:
fdiaz2011:
fdiaz2011:
j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

No caso de interface pra dao, acha valido criar um pacote só pras interfaces ?

Obrigado pela ajuda !

Não. Caso REALMENTE tenha necessidade de criar interfaces, colocaria no mesmo pacote dos DAOs.

Uma última opinião hehe
Pra interface, acredito q precise usar sim mais pra frente, acha q devo colocar algum sufixo ou prefixo pra identifica-las como interface ?

Fui editar o post anterior, mas o forum duplicou e colocou quote e ficou esquisito…
:(

Eu sou da opinião que sua arquitetura deve evoluir com o tempo. Não se prenda em fazer malabarismos agora. Faça a coisa mais coesa possível.
Muito dos programadores (o que mais vejo é em Java), gosta de complicar muito a coisa só pra ter uma ‘arquitetura bem definida’, quando na verdade só complicou a coisa que não precisava.

Quanto a nomenclatura, a interface vai existir pra ‘esconder’ sua implementação. Então não colocaria algo como ‘IContatoDao’. Apenas ‘ContatoDao’.

F

j0nny:
fdiaz2011:
j0nny:
fdiaz2011:
fdiaz2011:
j0nny:

Tudo que faz parte do seu domínio, ou seja, da sua lógica, colocaria dentro de domain (ou model). Ou seja, entidades, enums, etc.
Services coloco quando há necessidade de uma certa operação do sistema trabalhar com mais de uma entidade. Nada impede de vc colocar isso dentro do seu domain, afinal, é domínio.
Vc poderia muito bem ter a seguinte estrutura: domain -> services, domain -> entities, domain -> types
No caso aos DAOs, colocaria apenas um DAO genérico, classe mesmo, com as operações básicas, e criaria DAO específico para cada operação, quando necessário (consulta específica, etc).

Uma opção seria fazer a seguinte estrutura:
controllers -> MeuController.java
dao -> MeuDao.java
domain -> services -> MeuService.java
domain -> entities -> MinhaEntidade.java
domain -> types -> MeuEnum.java
weapp -> meus_jsps.jsp

Entendi, e achei muito bom.
Tb fica bem organizado.

No caso de interface pra dao, acha valido criar um pacote só pras interfaces ?

Obrigado pela ajuda !

Não. Caso REALMENTE tenha necessidade de criar interfaces, colocaria no mesmo pacote dos DAOs.

Uma última opinião hehe
Pra interface, acredito q precise usar sim mais pra frente, acha q devo colocar algum sufixo ou prefixo pra identifica-las como interface ?

Fui editar o post anterior, mas o forum duplicou e colocou quote e ficou esquisito…
:(

Eu sou da opinião que sua arquitetura deve evoluir com o tempo. Não se prenda em fazer malabarismos agora. Faça a coisa mais coesa possível.
Muito dos programadores (o que mais vejo é em Java), gosta de complicar muito a coisa só pra ter uma ‘arquitetura bem definida’, quando na verdade só complicou a coisa que não precisava.

Quanto a nomenclatura, a interface vai existir pra ‘esconder’ sua implementação. Então não colocaria algo como ‘IContatoDao’. Apenas ‘ContatoDao’.

Está certo, obrigado pelas dicas e sugestões.

Abraços !

sergiotaborda

fdiaz2011:
Em primeiro lugar, se aki não vou o local adequado, me perdoem.

Gostaria da opinião de vcs como seria interessante organizar o projeto, com relação à estrutura, nomes de classes e pacotes.
No momento tenho o seguinte cenário.

Projeto utilizando arquitetura maven:

  • Sistema:
    • controllers

    • dao

    • domain

    • services

    • webapp: somente jsp

Onde:

  • controllers: somente os controllers
    SistemaController.java

  • dao:
    Dao.java - Interface
    GenericDao.java - classe abstrata
    SistemaDaoImpl.java - implementação

  • domain:
    Entidade.java - entidade
    EntidadeType.java - enum

  • services: somente a implementação
    SistemaService.java

Como podem notar, no pacote dao, tenho implementação misturado com interface e classe abstrata.
No domain, tenho entidades e enums.
Os services, a princípio eu não devo utilizar interfaces.

Está bom dessa forma ou sugerem algo melhor ?
Por exemplo, criar um pacote entidade e outro enum, dentro de domain ?

Obrigado

Se vc quer usar o nome das camadas (andares) então seria

cliente
apresentacao ( o seu controllers)
dominio ( o seu dominio e seu services, se os services são de dominio)
integracao ( o seu dao e os seus services quandos os services são de estrutrua - por exemplo, enviar email, ou chamadas a outros sistemas)
recursos

Eu não usaria DAO se estiver usando hibernate ou JPA apenas DomainStore (camada integração) - que é o proprio jpa/hibernate e Repository. Os repository ficam no andar do dominio.

Os services têm que ter interface. Faz parte do contrato do design pattern e é toda a graça da coisa. Se os serviços forem remotos, por exemplo, vai ser difícil funcionar ser interfaces. Injetar aspetos também será mais complicado. Por outro lado vc está usando interfaces no DAO, então a bem da coerencia do projeto ou usa interfaces sempre, ou nunca. Misturar assim é meio sem sentido.

Dentro do dominio não ha muita necessidade de separar as coisas com subpacotes, mas ai é mais do gosto. Nunca crie um pacote apenas para exceções em nenhuma das camadas. Deixe as exceções perto da raiz e/ou perto das classes que as usam. mas nunca isoladas num pacote especifico.

webapp não é um pacote. normalmente é a pasta base do maven para a raiz do war. É especialmente util se dividir o projeto maven entre o war e as libs do projeto

F

Oi Sergio.
Obrigado por responder e aproveito pra parabenizar pelo seu blog, já li bastante coisa lá.

Para persistir os objetos eu estou usando jpa/hibernate e anotando a classe com @Repository, porém o nome chamei de SistemaDao apenas para ajudar na identificação e por repository ser um nome meio grande hehe
Pra falar a verdade eu ainda confundo dao e repository. Já aprendi um pouco sobre, mas ainda falta algo. :oops:
Eu tenho algo assim:

public interface Dao = contrato com os metodos utilizados por todos os dao´s ou classes de persistencia jpa.

public abstract class GenericDao implements Dao = implementação dos metodos comuns as dao´s.

public interface EntidadeDao = contrato com os métodos específicos da entidade

@Repository
public class EntidadeDaoImpl extends GenericDao implements EntidadeDao
= implementação com herança dos metodos comuns a todo dao e o contrato especifico da entidade

Com relação aos services eu estou usando @Autowired para injeção.
Vc acha q devemos utilizar os metodos dos services atraves da interface (polimorfismo) ou não tem necessidade ?

Oq eu qro é fazer da melhor forma, então fiquem a vontade pra falar oq tem de errado.

F

duplicado novamente

:?

wagnerfrancisco

Se a tua classe é um repositório, você não precisa colocar repositório no nome. Se é um repositório de usuários, pode chamar de AllUsers ou TodosOsUsuarios. Fica melhor de usar, inclusive. Imagine um repositório de usuários com um método que busca todos os cadastrados antes de uma determinada data… você iria usar assim:

allUsers.registeredBefore(theDate);

ou

todosOsUsuarios.registradosAntesDe(aData);

Veja:

F

wagnerfrancisco:
Se a tua classe é um repositório, você não precisa colocar repositório no nome. Se é um repositório de usuários, pode chamar de AllUsers ou TodosOsUsuarios. Fica melhor de usar, inclusive. Imagine um repositório de usuários com um método que busca todos os cadastrados antes de uma determinada data… você iria usar assim:

allUsers.registeredBefore(theDate);

ou

todosOsUsuarios.registradosAntesDe(aData);

Veja:

http://blog.aspercom.com.br/2009/08/11/repositorios-ddd/

Então qd é q uso Dao ?
Qd é pra acesso a mais de um tipo de objeto ?

Desculpe, ainda não li a referencia q me passou, mas vou ler !

wagnerfrancisco

Você usa a nomenclatura DAO, quando está criando um objeto DAO. :smiley:

DAO e Repository são padrões diferentes. O DAO é um padrão que abstrai o mecanismo de persistência e provê acesso aos dados, estejam eles num banco de dados, arquivo txt ou numa rede, por exemplo.

O Repository é um conceito de domínio. É uma coleção dos seus objetos, só que mais evoluída, com consultas mais específicas relativas ao domínio da aplicação. É um conceito de domínio, não de infra. O Repository não conhece banco de dados e coisas do gênero.

A implementação do Repository pode ser um DAO - não é uma necessidade, é uma possibilidade.

Por isso eu disse. Se você está usando um repositório, não é obrigatório colocar Repository no nome.

sergiotaborda

Não entendi como chamar de XYZDAO ajuda a identificar que é um repositorio.

Chame de repositorio e pronto.

A diferença principal é que o DAO é um serviço do andar (camada) de integração (alguns chamam de camada de persistencia) e o repositorio é um objeto (não é um serviço) do andar de dominio.

Repositorios não têm interfaces de definição porque só é possivel uma implementação. No máximo vc tem uma herança basead em classes abstratas. Por exemplo AbstratRepository e ClienteRepository. No repositorio vc injeta o DomainStore. No DAO vc injeta o DataSource ou algum tipo de provedor de conexões.
O DAO provê dados, o Repositorio provê entidades. O Repositório de especializa em executar queries ( o spring tem até um padrão para ajudar nisto, mas o que o Spring de @Repository é na realidade um DAO e não um repositorio verdadeiro, pois está na cada de integração).
O Repositorio usa um mecanismo que o DomainStore entende para defenir as queries, mas elas não especificam como fisicamente a querie é feita. Isto significa que um bom domainstore tanto procura em SQL como em NoSQL sem diferença. Para isto são usados os padrões QueryObject e Interpreter. Tem um artigo no javabuilding especialmente sobre isto

Se vc quiser isolar a tecnologia de persistencia o fluxo seria ssim

Repositorio – cria querie object POJO --> envia para DomainStore — interpreta para querie objet nativo , por exemplo criteria api do hibernate --> exeecuta no domain store real —> devolve o resultado.

Se não quiser isolar, pode fazer o repositorio simplesmente utiliza a api de criterio e chamar diretamente a api nativa do domainstore

A interface não serve para definir polimorfismo – isso é uma consequencia – serve para definir um contrato independente da implementação.
Para serviços , especialmente se publicos às outras camadas é bom ter um contrato separado. Para objetos internos ao dominio podem ser implementados sem o padrão service. O padrão service, e especialmente o service façade têm que ter interfaces. Tento explicar isso em um artigo do meu blog

A questão aqui não é DAO VS Repositorio, mas sim usar a correta numenclatura. Não vale chamar de ControladorDeCliente e dizer que um DAO, então também não vale usar ClienteDAO e dizer que é um repositorio. Não apenas pelos que os padrões representam em si mesmos, mas sobre os andares onde pertencem. O uso de nomes padrão e camadas padrão ajuda a auto-documentar o código e ajuda também a organizar as responsabilidades de cada objeto em cada andar.

Criado 30 de julho de 2012
Ultima resposta 31 de jul. de 2012
Respostas 21
Participantes 5