Qual seria a arquitetura indica para um sistema J2EE, que utiliza os seguintes Frameworks .
Struts
Spring
Hibernate
Hoje utilizamos as seguintes camadas :
Pojo
Dao
Service
Facade
Sendo que as Actions do struts acessam o facade , o Facade acessa o Service , e o Service acessa o Dao , que acessa o Hibernate que acessa o Banco de Dados.
So que depois de 6 meses de projeto , estamos no deparando com alguns problemas como demora no desenvolvimento de novas funcionalidades.
Se você quer aprender qual seria a melhor solução comece por elndo o POEAA, do Fowler, depois passe por page-Jones e Eric Evans.
Se quer apenas aplicar a melhor solução no seu trabalho contrate um consultor, me parece que faltam alguns conceitos a vocês (POJO não é camada, por exemplo).
Cada projeto pode pedir um tipo de arquitetura diferente.
Aqui na empresa temos alguns aplicativos Web que usam a seguinte arquitetura:
JSP -> Struts Action -> Business Class (Pojos singleton) -> DAO/Hibernate ou em alguns casos Web Services
As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.
Essa arquitetura pode parecer bem simples e propositalmente ela é!
A ‘manutenabilidade’ era um requisito não funcional muito forte, pois as aplicações iriam sofrer constante evolução.
Hoje vemos que foi a escolha certa, os novos requisitos funcionais são implementados rapidamente. A performance é excelente.
Nesses aplicativos, a adoção da arquitetura mais simples, porém compacta mostrou-se ideal.
Mas como falei no ínicio, cada projeto é diferente, por isso temos também sistemas com arquiteturas bem complexas: Integração com sistemas legados, EJB´s, etc…
O legal é que os nossos aplicativos ‘light’ conversam numa boa com esses sistemas usando webservices. Assim conseguimos dividir e estruturar bem os aplicativos, temos por exemplo um aplicativo de vendas da area administrativa se comunicando um um sistema ‘barra pesada’ de engenharia da area de produção.
Cara utilize uma camada Business Delegate para descoplar o seu Controll do Model
As actions chama o business delegate que apenas delega para o facade, e não tem necessidade de utilizar service, use a inteligência no facade, e dele passe para o DAO
[quote=leandroqbs]
E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE[/quote]
agora fiquei curioso.
poderia dar exemplos ou argumentos que justifiquem sua opinião.
não acredito que vc consiga usar a mesma arquiteura em qualquer projeto, isso funciona em projeitnho CRUD que é a mioria dos projetos hj em dia e ach oque é o que vc tem exepriencia.
quanto ao Spring, se vc souber utiliza-lo, com certeza não vai quere tira-lo de seu projeto.
[quote=leandroqbs]Para diversos projetos da empresa na qual trabalhamos, utilizamos a mesma arquitetura… e isso atende muito bem…
é apenas a maior empresa de seguros do país, acha que são projetos CRUD?
Como disse, uma arquitetura bem definida atende a qualquer projeto J2EE.[/quote]
ok. Ma se são projetos parecidos(mesma area), então vc não pode dizer que atende a “qualquer” projeto. sempre vai depender do problema. qunato ao que é ser CRUD, se vc mostra dados, faz alguma logica com eles, persiste, consulta, altera, na minha visão é CRUD. o que muda vai so a logica de negocio.
mas vc ão respondeu sobre o Spring. então vou te oerguntar: como vcs fazem controle de transação? na mão? usam um container EJB 2.1?
ou deixam o Spring fazer de forma transparente ao desenvolvedor?
isso so p/ citar uma funcionalidade do Spring.
[quote=leandroqbs]
E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE[/quote]
Cada projeto não exige uma arquitetura diferente mas não há arquitetura que atenda qualquer projeto. Você está tirando essa conclusão a partir de uma empresa que lida com um tipo de aplicação e em um dominio?
Se tudo que você faz são aplicações web que lidam com XYZ para N usuarios com acesso a internet certamente você consegue reaproveitar muitos dos componentes arquiteturais, mas será que isso é “qualquer projeto J2EE”?
Sua arquitetura suporta SOA? LDAP? CBD? Cluster? RPC? Replicação de Sessão? Uso de scripts? Um milhão de requisições por dia? Segurança configurável? Interface desktop, web e celular? Multiplos bancos de dados usados ao mesmo tempo? Messaging?
Não existe arquitetura que suporte “qualquer projeto J2EE”.
Quanto ao Spring eu realmente estou curioso para que você embase sua afirmação em alguma coisa.
Cara, a melhor arquitetura sem dúvida é… “Make it Simple, Make it Better”
Não sai enchendo seu projeto de patterns e frameworks não senão você vai literalmente dar mais corda pra sua forca.
Struts é um framework simples e funcional, spring é muito bom e funciona integrado a qualquer coisa (falo isso pq se ele funciona com vignette, realmente funciona com qualquer coisa ), mas no caso do hibernate e dos patterns, isso que varia muito do contexto do sistema.
Caso uma arquitetura simples não atenda á necessidade, vá alterando sob demanda, até chegar em uma que seja eficiênte e ao mesmo tempo eficaz.
[quote=pcalcado][quote=Raven] JSP -> Struts Action -> Business Class (Pojos singleton) -> DAO/Hibernate ou em alguns casos Web Services
As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.
[/quote]
Duvidas:
1 - Pra que Singleton?
2 - Pra que TO?[/quote]
Ok Vamos Lá!
1 - Pra que Singleton?
O padrão singleton nos pareceu mais adequando aos objetos de negócios pois realmente eles não precisam ser instanciados várias vezes a cada requisição do mesmo cliente. Poderíamos ter feito inclusive métodos estáticos. Vamos ter apenas um objeto dessas classes em uma interação.
2 - Pra que TO?
Os objetos TO são os objetos de domínio, gerados pelos DAO´s ou também chamados de Transfer Objects ou Value Objects…como queira.
Esses objetos são manipulados pelos business para atender a requisito do negócio.
O Business então devolte ‘Java Beans’ especificos para a View, esses java beans possuem coleções da TO´s, com os dados relevantes.
E claro, existe o processo inverso tb, quando um usuário esta criando ou alterando um objeto do sistema (uma NF, um novo usuário, um item de material), nesse caso os dados são encapsulados em TO´s, (NotaFiscalDTO por exemplo) e esse objeto é persistido, isso claro, após passar a validação.
Entendeu?
Se quiser entrar em mais detalhes fique a vontade!
[quote=leandroqbs]
Cara utilize uma camada Business Delegate para descoplar o seu Controll do Model
As actions chama o business delegate que apenas delega para o facade, e não tem necessidade de utilizar service, use a inteligência no facade, e dele passe para o DAO[/quote]
Leandro,
sim, consideramos essa hipotese, mas no nosso caso especifico, não foi necessário chegar a esse nível de detalhe. Como falei.
O Action chama direto o obejto de Negocio mesmo.Isso foi uma questão de muita discussão. O Bussines Delegate é sim muito interessante, mas veja só, o acoplamento que existe é só a chamada de um método de negiocio.
De fato que se quisermos, podemos ‘rancar fora o struts’ e tacar ali um Swing ou JSF. O Impacto na camada de negócios é zero.
Concordo plenamente com vc nos dois ultimos topicos.
aqui usamos o seu DTO (nosso VO) como um JavaBean, o form popula ele no action…
também não via muita necessidade no Business Delegate antigamente… mas depois de umas sitações que nos deu trabalho sem ele, passei a adotar haahahahahaha
[quote=Raven][quote=pcalcado][quote=Raven] JSP -> Struts Action -> Business Class (Pojos singleton) -> DAO/Hibernate ou em alguns casos Web Services
As camadas se comunicam através de TO, e alguns JavaBeans especificos.
No caso dos JSP´s, usamos somente JSTL.
[/quote]
Duvidas:
1 - Pra que Singleton?
2 - Pra que TO?[/quote]
Ok Vamos Lá!
1 - Pra que Singleton?
O padrão singleton nos pareceu mais adequando aos objetos de negócios pois realmente eles não precisam ser instanciados várias vezes a cada requisição do mesmo cliente. Poderíamos ter feito inclusive métodos estáticos. Vamos ter apenas um objeto dessas classes em uma interação.
2 - Pra que TO?
Os objetos TO são os objetos de domínio, gerados pelos DAO´s ou também chamados de Transfer Objects ou Value Objects…como queira.
Esses objetos são manipulados pelos business para atender a requisito do negócio.
O Business então devolte ‘Java Beans’ especificos para a View, esses java beans possuem coleções da TO´s, com os dados relevantes.
E claro, existe o processo inverso tb, quando um usuário esta criando ou alterando um objeto do sistema (uma NF, um novo usuário, um item de material), nesse caso os dados são encapsulados em TO´s, (NotaFiscalDTO por exemplo) e esse objeto é persistido, isso claro, após passar a validação.
Entendeu?
Se quiser entrar em mais detalhes fique a vontade!
[ ]´s
[/quote]
Mas por que você precisa de TO se você vai mandar mensagens entre objetos que residem dentro de uma mesma JVM? Se prestarem atenção à descrição do padrão Transfer Object no J2EE Design Patterns Catalog (http://java.sun.com/blueprints/patterns/TransferObject.html), vocês vão ler isso:
A menos que você esteja fazendo chamadas a EJBs remotos ou Web Services, não existe necessidade de você ter TOs. Antes que o shoes faça, leia as discussões sobre amenic domain model do GUJ e aos artigos:
[quote=leandroqbs]
E esse papo de que cada projeto exije uma arquitetura diferente é balela… uma arquitetura bem definida atende a qualquer projeto J2EE[/quote]
Tenho que discordar…
Se um modelo de arquitetura bem definida serve pra qualquer projeto J2EE, então ele usa TODOS os padrões de projetos? Usa TODAS as APIs do J2EE?
Lógico que não, é por isso que existem várias APIs , que foram criadas para contemplar requisitos diferentes.
Assim como os design patterns.
E os projetos de arquitetura de hardware também serão diferentes em função dos requisitos.
Depende de cada cenário, de cada empresa…
Na empresa onde trabalho, existem sistemas que precisam se comunicar com mainframes, outros que precisam fazer leituras de hardwares específicos…E ainda os sistemas administrativos, aplicações Web ‘comuns’…
Portanto, afirmo que sim, cada sistema exije uma arquitetura diferente! Mas isso não quer dizer que você pode (e até deve) usar a mesma arquitetura em vários projetos, desde que os projetos sejam semelhantes (requisitos semelhantes)
), mas no caso do hibernate e dos patterns, isso que varia muito do contexto do sistema.