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

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.

viniciushmol:

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.

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.

FrancoC:

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.

deniswsrosa:

FrancoC:

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.

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:

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:

sergiotaborda:

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:

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.

maior_abandonado:

…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…

maior_abandonado:

(de vez em quando chega-se a ver isso em cruds…)

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…

maior_abandonado:

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!

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…