Interação entre Patterns: DAO, Business Object e Appliction Services

Pessoal, tudo bem?

Seguinte, estudando alguns patterns fiquei na dúvida sobre como DAO, Business Object(BO) e Application Service(AS) realmente interagem entre si.

Então, um BO enxerga somente outros BOs e a camada DAO, enquanto que um AS vê somente outras ASs e os BOs.
Isto é, um AS nunca acessa diretamente a camada DAO?
A camada DAO nunca deve ser "acessivel" diretamente, a não ser através de um BO?

Resumindo, qual o relacionamento mais correto entre DAO, Business Object(BO) e Application Service(AS)?

Vlw d+

Abraço a todos

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

O relacionamento correto é este mesmo Application Controller(AC) -> BO -> DAO . A recomendação de não acessar um DAO de um AC é por que neste caso você estaria "misturando ou pulando camadas". Se você precisar acessar um DAO diretamente da sua Action é indício que está colocando lógica de negócio nela.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

viniciushmol wrote:Pessoal, tudo bem?

Seguinte, estudando alguns patterns fiquei na dúvida sobre como DAO, Business Object(BO) e Application Service(AS) realmente interagem entre si.

Então, um BO enxerga somente outros BOs e a camada DAO, enquanto que um AS vê somente outras ASs e os BOs.
Isto é, um AS nunca acessa diretamente a camada DAO?
A camada DAO nunca deve ser "acessivel" diretamente, a não ser através de um BO?

Resumindo, qual o relacionamento mais correto entre DAO, Business Object(BO) e Application Service(AS)?

não é por nada mas essa arquitetura é velha pra caramba... hoje ninguem mais usa isso( a menos em sistema legado, claro está)
Dedique seu tempo a aprender padrões modernos.

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

Essa arquitetura foi concebida na época do EJB2. Por isso alguns a consideram antiga e pesada. A estratégia POJO tem sido mais recomendada quando o escopo da aplicacao esta em uma unica JVM e a aplicação não é distribuída.

Do contrario um SLSB (Stateless Session Bean) implementando o padrão Session Façade ainda é a solução ideal.

Essa arquitetura é apresentada nos exemplos oficiais do Spring PetClinic quando no J2EE/EJB PetStore

Neste link há uma descrição bem amigável sobre como ela funciona: http://javaboutique.internet.com/tutorials/businessObject/

Um comentário a parte. Me parece que quem nunca trabalhou com esse tipo de sistema distribuído e não tem muita experiência com EJB-Spring tem dificuldade de entender a importância desse padrão de organização.

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

FrancoC wrote:Essa arquitetura foi concebida na época do EJB2. Por isso alguns a consideram antiga e pesada. A estratégia POJO tem sido mais recomendada quando o escopo da aplicacao esta em uma unica JVM e a aplicação não é distribuída.

Diga-se de passagem, acho que boa parte dos JEE Patterns tem de ser revista, a maioria deles foram criados para contornar falhas da linguagem que já não existem.

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

deniswsrosa wrote:

FrancoC wrote:Essa arquitetura foi concebida na época do EJB2. Por isso alguns a consideram antiga e pesada. A estratégia POJO tem sido mais recomendada quando o escopo da aplicacao esta em uma unica JVM e a aplicação não é distribuída.

Diga-se de passagem, acho que boa parte dos JEE Patterns tem de ser revista, a maioria deles foram criados para contornar falhas da linguagem que já não existem.

Primeiro que isso nao deve ser dito assim "de passagem". Denúnicas sem provas é um problema sério nesse país. O que voce chama de "falhas da linguagem", na verdade seria uma critica enderecada a especificacao EJB que como qualquer outra especificacao é lenta para acompanhar as inovacoes do mercado. Se puder ser mais específico e detalhar pattern por pattern justificando pq a maioria está obsoleta, voce realmente enriqueceria essa discussão.

GUJ Ranger Membro desde: 21/07/2005 08:51:27 Mensagens: 807 Offline

Service Locator;
Value List Handler
Transfer Object - pq agora com JPA se usa diretamente um pojo.
Acredito que com o JPA o Domain Store ( que eu numca entendi muito bem) tb não seja necessário.

sergiotaborda wrote:
não é por nada mas essa arquitetura é velha pra caramba... hoje ninguem mais usa isso( a menos em sistema legado, claro está)
Dedique seu tempo a aprender padrões modernos.

Por que o pessoal de tecnologia acha que tudo que é velho é ruim e tudo que é novo é bom....um dia eu realmente pretendo entender isso...

No projeto onde estou trabalhando usamos esta arquitetura e o que menos atrapalha é a arquitetura. E sabe o que mais atrapalha ? As pessoas que não entendem um caso de uso simples, quem dirás os complexos.

obs.; O sistema não é legado, mas vem de um projeto longo e vai durar um bom tempo ainda.

Giulliano wrote:

sergiotaborda wrote:
não é por nada mas essa arquitetura é velha pra caramba... hoje ninguem mais usa isso( a menos em sistema legado, claro está)
Dedique seu tempo a aprender padrões modernos.

Por que o pessoal de tecnologia acha que tudo que é velho é ruim e tudo que é novo é bom....um dia eu realmente pretendo entender isso...

No projeto onde estou trabalhando usamos esta arquitetura e o que menos atrapalha é a arquitetura. E sabe o que mais atrapalha ? As pessoas que não entendem um caso de uso simples, quem dirás os complexos.

obs.; O sistema não é legado, mas vem de um projeto longo e vai durar um bom tempo ainda.

pois é... as vejo solução robusta sendo aplicada para problemas pequenos (e que inclusive dificilmente vão crescer)... as vejo inclusive gente inserindo camada/código desnecessário por que aprendeu que aquilo é bom, tomando como exemplo de por que aquilo é bom um problema enorme e usa aquilo num negocio simples... (de vez em quando chega-se a ver isso em cruds...)

sergiotaborda wrote:não é por nada mas essa arquitetura é velha pra caramba... hoje ninguem mais usa isso( a menos em sistema legado, claro está)
Dedique seu tempo a aprender padrões modernos.

Tirando o fato de ter um "Application Service" não vejo o porque de ser uma arquitetura antiga. Hoje os projetos na qual eu tenho planejado são baseados em Controller > Business (com session beans), DAO caso necessário e repositórios.

Há algum tempo a Sun publicou o que eu penso ser um rascunho de uns design patterns. Dentro do JEE5 tem diretório bpcatalog-ee5-ea-0.8/docs que tem alguma coisa.

JavaTeenager Membro desde: 12/12/2009 14:07:01 Mensagens: 150 Offline

maior_abandonado wrote:...pois é... as vejo solução robusta sendo aplicada para problemas pequenos (e que inclusive dificilmente vão crescer)... as vejo inclusive gente inserindo camada/código desnecessário por que aprendeu que aquilo é bom, tomando como exemplo de por que aquilo é bom um problema enorme e usa aquilo num negocio simples...

@viniciushmol,
O relacionamento(interação) entre as "camadas" da Aplicação vai depender da (grau de) Complexidade do Sistema e, por conseguinte, a Arquitetura de Software adotada. Vja, vc poderia expor a Lógica de Negócio como Serviços através de 1 interface (não me refiro à Interface do Java) através de 1 Fachada: ServiceFacade. Persistindo os objetos do DomainModel em/via arquivo lógico de dados (Repository / DAO) Se entre essas camadas não houver 1 camada Gerenciador/Manager (caso esta camada não seja necessária), seus ServiceFaçades invariavelmente vão ter q fazer uso dos DAOs.
Obs.: o 'Application Controller' mencionado p/ deniswsrosa consta do famigerado catálogo da Sun: J2EE Core-Patterns.

maior_abandonado wrote:(de vez em quando chega-se a ver isso em cruds...)

@maior_abandonado,
Gostaria de abrir apenas um parêntese: a questão não é só de ser CRUD, ou não. Até pq os 'Casos de Uso' Arquiteturalmente Siginificativos tem q ser levados em conta na definição da Arquitetura. O q eu quero dizer é q quando for implementar o seu Sistema, todos os Casos de Uso vão ter q seguir o mesmo padrão (camadas lógicas, se for o caso).
Então, talvez fosse o caso de ser adotada Arquitetura Evolucionária/Emergente.

This message was edited 1 time. Last update was at 30/06/2010 08:11:54

pois é, temos camadas como um façade por exemplo, que além de facilitar ainda ajuda a desacoplar um controler de um modelo por exemplo, vamos pegar um exemplo relativamente básico assim... o problema é que as vezes se encontra software relativamente simples onde o cara poe la várias camadas que acabam por unicamente uma chamar a outra, pensa numa view chamando o controller, chamando um façade, chamando bo, chamando um dao que da um "return Session.createQuery("hql em questão").list()"...

tem casos muito menos desnecessários, claro, mais por ai se encontra uns casos assim e me arrisco a dizer píores...

eu pelo menos acho bestera parte das chamadas ai...

JavaTeenager Membro desde: 15/10/2009 13:11:25 Mensagens: 193 Offline

maior_abandonado wrote:pois é, temos camadas como um façade por exemplo, que além de facilitar ainda ajuda a desacoplar um controler de um modelo por exemplo, vamos pegar um exemplo relativamente básico assim... o problema é que as vezes se encontra software relativamente simples onde o cara poe la várias camadas que acabam por unicamente uma chamar a outra, pensa numa view chamando o controller, chamando um façade, chamando bo, chamando um dao que da um "return Session.createQuery("hql em questão").list()"...

tem casos muito menos desnecessários, claro, mais por ai se encontra uns casos assim e me arrisco a dizer píores...

eu pelo menos acho bestera parte das chamadas ai...

Basicamente vocês estão dizendo que aplicações em camadas é desperdicio de recurso e produtividade. FAIL!

JavaBaby Membro desde: 01/09/2004 15:25:57 Mensagens: 75 Offline

não, eles estão dizendo que tem gente usando bala de canhão para matar mosca. ou seja usando padrões/arquiteturas pensadas para sistemas bem complexos em sistemas simples como um crudzinho...

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