Ola,
Estamos iniciando nosso primeiro projeto em J2EE. Utilizamos Rational Rose para fazer a modelagem das classes. Estamos usando tambem o Jakarta Struts (MVC) e estamos estudando a possibilidade de usar o Hibernate para persistencia de objetos no banco de dados ao inves de usar o CMP.
Gostaria que vcs partilhassem suas experiencias de projeto usando J2EE relatando a arquitetura que vcs utilizam e ferrametas/frameworks
Obrigado
Fala Amigo,
para vc que esta comecando com struts, qual versao vcs estao adotando? Porque a ultima versao considerada estavel a (1.0.2) tem mmmuuiitta diferenca se comparada com a versao do release candidate Struts 1.1 , logo talvez seja interessante adotar o relese ja que deve entrar em vigor logo, nós optamos por isso em um projeto aqui e por acaso esse projeto eh muito semelhante ao seu com Rational Rose para fazer a modelagem das classes e Jakarta Struts a unica difierenca eh que usamos cmp/bmp aqui.
Abraco,
Adotamos aqui na empresa o para o padrão MVC o framwork Jakarta STRUTS.
As views em jsp + taglibs(As tags do Struts e a JSTL).
Para o modelo uma arquitetura de camadas que foi idealizada na UFPE e é adotada por várias empreas do Recife.
Tentarei explicar de maneira simplificada nossa arquitetura.
As camadas são divididas em:
±-----------------+
| Fachada |
|---|
| controlador |
| ------------------- |
| Cadastro |
| ------------------- |
| Repositório |
±-----------------+
Essa arquitetura pode ser aplicada para qualquer tipo de modelo de negócio não estando preso ao uso do EJB.
Resumindo as camadas:
Implementa o padrão Facade ou no caso de trabalhar com EJB o SessionFacade, seria o ponto de entrada para o sistema(em sistemas pequenos usamos uma única fachada) ou para cada módulo do mesmo.
O acesso do cliente se limita a Fachada do sistema, no caso do STRUTS, o acesso ficaria por conta das Actions. A fachada deve ser acessada mediante uma Fábrica de fachadas (Usando o padrão AbstractFactory) para que exista a independência das camadas. A fachada repassa as solicitações para os Controladores que mais uma vez são acessados por uma fábrica de controladores.
O controlador implementa a regra de negócio referênte ao caso de uso, ele gerencia os Cadastros para repassar solicitações de regra de negócio mais específica da entidades. Aqui não acessamos os cadastros por uma fábrica tornando essa camada acoplada ao controlador. Nossa regra de negócio esta ligada aos Controladores + Cadastros. Os Controladores também são responsáveis pelo gerenciamento das transações.
As classes de cadastro são responsáveis pela regra de negócio específica da entidade. As classes de Cadastro fazem acesso aos repositórios de dados por uma fábrica de repositórios.
O Repositório implementa o padrão DataAccessObject, ele é responsável pelo acesso aos dados de qualquer natureza. Seja um SGDB, um arquivo xml, um txt … nele serão implementadas as funções de inserir, deletar, excluir e localizar, nenhuma regra pode existir nos repositórios e nele o acesso a dados pode ser implementado com JDO, EntityBean, JDBC … ficando transparente para as outras camadas.
Estamos usando o JBuilder8 para o STRUTS e o Together para modelar as camadas e Patterns.
Caso você trabalhe com EJB coloque um BussinessDelegate em conjunto com um ServiceLocator entre a Action do STRUTS e o SessionFacade. Isso faz com que seu cliente possua uma abstração local das camadas remotas e isola todo o mecanismo de lookup da Fachada remota.
No final nossa arquitetura de camadas fica da seguinte maneira.
±-----------------+
| GUI |
|---|
| Fachada |
| ------------------- |
| controlador |
| ------------------- |
| Cadastro |
| ------------------- |
| Repositório |
±-----------------+
Onde a GUI pode ser uma interface web(com Struts,Velocity etc), Swing ou outra alternativa. E como cada camada fica independente da outra podemos fazer uma troca na camada que as outras não percebem. Um exemplo podemos ter um sistema funcionando com uma GUI web e um repositório em JDO e depois trocar a GUI por uma interface Swing e o repositório por um Entity Bean e o sistema continua numa boa.
Ola,
Vc tem algum exemplo de codigo bem simples dessa arquitetura. Pode ser um cadastro bem simples que implemente toda essa arquitetura explicada por vc. Ou algum template? Vcs usam algum gerador de codigo?
Obrigado,
Luiz Fernando
dizem que Beans são muito pesados e estão revendo seu verdadeiro propósito. Não seria melhor usar seus próprios pacotes de classes? Há uma alternativa para isso?
Amigo EddiE, realmente não entendi sua pergunta, que tipo de Beans vc se refere? EJB, JavaBeans?
Nessa arquitetura que mostrei vc pode optar pelo uso de EJB ou não nas camadas de Fachada e Repositório, nas outras camadas vc vai usar classes java “normais” para resolver o problema.
A idéia de isolar cada camada é justamente para que vc possa trocar uma camada sem que isso cause impacto nas outras.
Exemplo:
Na camada de Fachada do seu sistema, vc estava usando um Session Bean, mais agora não quer mais e prefere colocar uma classe fazendo esse trabalho pois não vai mais distribuir sua aplicação. Isso será tranquilo pois será só modificar essa camada e o BussinessDelegate e pronto.
Richardson,
onde posso encontrar uma documentacao dessa arquitetura? A UFPE disponibiliza?
Da maneira que estamos usando pode ser até que não, mais da uma olhada nesse link.