Assunto polemico quantas e quais camadas vcs dividem suas aplicações Web/SE

This message was edited 2 times. Last update was at 13/01/2011 14:35:33

Boa tarde galera seguindo a ideia do topicohttp://www.guj.com.br/java/229983-duvida-programar-em-camadas
e para trocar uma ideia sobre camadas e packages como vcs dividem suas aplicações tanto web tanto desktop?

divisão dos package:

bean

exceptions

dao

daoimpl

entity

service

view

e camadas

Visão: Tela + Bean
Controller: Framework+Service
Model: Entity+DAO

GUJ Master Membro desde: 21/06/2007 23:27:21 Mensagens: 1850 Offline

Costumo dividir assim:

entity (entidades ligadas ao hibernate)
dao
service
controller
view (JSPs)

Basicamente assim... as vezes eu dou uma roubada e faço os controllers acessarem diretamente o dao

As vezes preciso de outras classes.. e outros pacotes.. mas basicamente.. uso dessa forma

Para aplicação desktop (stand-alone) talvez você não precise de tudo isso. Recomendaria isso:
entity
dao
service ou domain model (repository)
view (swing)

Você pode usar algum framework para desenvolvimento desktop pra te ajudar entre o a view e o service, como SwingBean, Genesis, Spring RCP ou Swing Application Framework. Se For uma aplicação mais simples pode até deixar de usar isso.

boa essa

divisão dos package:

bean
exceptions
dao
daoimpl
entity
service
view

Ai você está separando os pacotes pelo que eles represantam para o sofware e não para o dominio! O Ideal separar eles conforme eles se relacionam digamos

dominio.financeiro

dominio.cadastro

Digamos que em financeiro entram todas a classes relacionadas a contas a pagar, receber etc.

e camadas

Visão: Tela + Bean
Controller: Framework+Service
Model: Entity+DAO

eu utilizaria:

Infraestrutura (Banco de dados, envio de e-mails, etc) - DAOs e outros.

dominio e serviços do domínio - Entity, Objeto Valor, etc

Serviços do aplicativo - Beans e outros serviços relacionados a aplicação

visualização

Uma ótima fonte para saber como separar é o livro Domain Driven Design do Evans

This message was edited 1 time. Last update was at 13/01/2011 17:25:35

amhfilho wrote:Para aplicação desktop (stand-alone) talvez você não precise de tudo isso. Recomendaria isso:
entity
dao
service ou domain model (repository)
view (swing)

entity -> Entitidade separada do dominio? Entidade sem repositório? Não entendi?
service ou domain model (repository) Também não entendi. Dentro do dominio pode haver vários classes que se enquadram como serviço. O dominio sempre vai existir e os serviços de aplicativo (que são separados do dominio) também de modo que se possa acessar o dominio, senão vai haver uma acoplamento alto ai. O que pode é juntar o serviços de aplicativo com a visualização, ai o acoplamento só entre esses dois pelo menos salva o dominio.

Virtual Machine Man Membro desde: 10/08/2006 16:22:17 Mensagens: 530 Offline

x@ndy wrote:Ai você está separando os pacotes pelo que eles represantam para o sofware e não para o dominio! O Ideal separar eles conforme eles se relacionam digamos

dominio.financeiro
dominio.cadastro
Digamos que em financeiro entram todas a classes relacionadas a contas a pagar, receber etc.

dentro dos pacotes por exemplo DAO ai que eu sub-divido no dominio tipo DAO.financeiro o q vc acha

JavaEvangelist Membro desde: 19/07/2006 09:04:42 Mensagens: 402 Offline

O ideal é quebrar primeiro por conceito de negócio (aggregate root se você usar DDD) e depois por conceito técnico. Dessa forma, você agrupa todas as classes referentes a um mesmo conceito de negócio sob um único pacote e pode implantar apenas esse pacote, caso uma alteração não afete classes de outro pacote.

Classes que mudam juntas, devem ser empacotadas juntas.

esmiralha wrote:Classes que mudam juntas, devem ser empacotadas juntas.

Perfeito! Resumiu tudo o que eu queria dizer.

leonardobhbr wrote:dentro dos pacotes por exemplo DAO ai que eu sub-divido no dominio tipo DAO.financeiro o q vc acha

Utilizando o repositório nas entidades do domino você pode criar um pacote de infraestrutura assim para seu DAO perfeitamente, assim você espelha o dominio para sua camada de infraestrutura!
Abstraindo mais eu faria Infraestrutura.Financeiro.DAO.DAOJPA.,
Sendo que dentro de Infraestrutura.Financeiro eu poderia ter outros pacotes relacionados ao dominio não somente a persistência

Tomem cuidado com o excesso de encapsulamentos e abstrações! Comece do mais simples e use REFATORAÇÃO sempre. Lembre-se do conceito mestre em desenvolvimento de software: Inspeção e Adaptação

amhfilho wrote:Tomem cuidado com o excesso de encapsulamentos e abstrações! Comece do mais simples e use REFATORAÇÃO sempre. Lembre-se do conceito mestre em desenvolvimento de software: Inspeção e Adaptação

Concordo!

Notícias, artigos e o maior fórum brasileiro sobre Java