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)?
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.
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)?
[/quote]
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
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.
[quote=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.
[/quote]
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.
[quote=deniswsrosa][quote=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.
[/quote]
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.[/quote]
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.
[quote=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.[/quote]
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.
[quote=Giulliano][quote=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.[/quote]
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.[/quote]
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…)
[quote=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.[/quote]
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.
[quote=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… [/quote]@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.
[quote=maior_abandonado](de vez em quando chega-se a ver isso em cruds…)[/quote]@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.
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…
[quote=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…[/quote]
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…