Estou querendo criar uma arquitetura completa para o JBoss Seam usando JSF, EJB3, JPA, XHTML, FACELETS, JAX-WS.
Estudei vários livros do Seam (Beginning JBoss Seam, Seam Simplicity and Power Beyond Java EE, Pratical JBoss Seam Projects) e o Seam Reference, mas não encontrei nenhuma proposta de estrutura de pacotes seguindo os padrões de projeto.
Gostaria de saber se alguem já trabalhou com o Seam em produção com essas tecnologias.
Seguindo uma estrutura como proposta no livro Core J2EE (figura a baixo).
Vc não encontrou em livros do Seam pq não existe uma resposta para isso.
O Seam é um framework de integração entre tecnologias JavaEE, ele não dita patterns que o desenvolvedor deve seguir, isso depende de qual modelo de arquitetura que vc quer adotar (por isso vc nao vai achar em livros do Seam). Note que um modelo de arquitetura não é simplesmente utilizar JPA, JSF, EJB3 etc, mas sim como organizar tudo isso. Se vc já estudou o Seam, sabe que ele facilita muito a vida em como obter estes recursos, mas como organizar é com vc mesmo.
É um crime vc tentar seguir padrões CoreJ2EE com tecnologias JavaEE5+ feito JPA e EJB3… as motivações de muito dos antigos patterns não fazem mais sentido algum.
Você acha os novos modelos como o DDD mais indicados para esse caso?
Qual uma sugestão sua para uma boa arquitetura usando esses componentes?
Vale lembrar que DDD não é um nova forma de desenvolver ou moldar aplicações Sivio. Evans menciona em seu livro que sua motivação para escrever o mesmo, foi que as praticas eram utilizadas a mais de 20 anos, mas não se encontrava muita literatura sobre a mesma.
Domain-Driven Design, o livro, é uma ótima literatura para trabalhar com construção do código de domínio e outros de gerência do ciclo de vida destes objetos. A base é um MDD (Model-Driven Development), de onde o modelo é obtido e trabalhado de maneira que o “conhecimento” do negócio não se perca através de abstrações da tecnologia.
Neste ponto, os recursos tecnológicos que vc citou ajuda no sentido de diminuir a necessidades destas abstações, uma vez que a maior parte de escrita de código para integração entre os recursos é provida pelas mesmas APIs utilizadas, deixando que vc foque mais tempo em resolver problemas no domínio, o qual DDD ajuda e muito.
Uma sugestão que lhe dou, em vista de arquitetura, é usar a tecnologia correta para seu problema e não catalogar uma única solução arquitetural para seus projetos. Para alguns casos, vc vai notar que utilizar a FrameworkApi do Seam (EntityHome, EntityQuery) … pode ser mais negócio que usar Repositórios e Daos (e mesmo isso mantendo seu domínio intacto). Em outros casos, utilizar a gerência transacional do Spring em Services de domínio para acessar repositórios pode ser melhor e mais flexível/entendível para um código mais “Ubiquitous”.
Faça Pet Project com a tecnologia que vc quer utilizar e neste mesmo projeto veja a necessidade de Patterns GoF , PoEAA e idéias DDD de Evans. Flexibilidade e clareza em arquitetura vc vai tendo com experiência, portanto abuse de pequenos laboratórios de projetos e leia bastante.
Obrigado pelas dicas!!!
Vou começar com os testes com esse novo pensamento.
Mais voltado para o modelo rico e deixar de lado os modelos anêmicos.
Valeu!!!
Procurei na documentação do JBoss Seam sobre o EntityHome e o EntityQuery.
Surgiu uma dúvida!!!
Quando devo usar o EntityQuery?
Se o EntityHome eu posso chamar o entityManager.
Qual seria a diferença entre um e outro?
EntityHome é uma alternativa para CRUDs programáticos (usual para cadastros simples). EntityQuery executa queries, apenas invocando pelo nome.
Ex:
<!--Declaração no component.xml-->
<framework:entity-home name="usuarioHome"
entity-class="Usuario"
entity-manager="#{entityManager}"/>na página:
<h:inputText value="#{usuarioHome.instance.nome}"/>
<h:commandButton value="Salvar" action="#{usuarioHome.persist}">EntityQuery:
<!--Declaração no component.xml-->
<framework:entity-query name="todosUsuarios"
ejbql="from Usuario usr" />
na página:
<h:dataTable value="#{todosUsuarios.resultList}" var="usuario">
...Mas a idéia de usar essas classes em uma aplicação de grande porte, seria uma boa idéia ou não?
Ou o certo seria criar as minhas próprias do zero e usar repositórios para acessar os dados???
Não vejo diferença em utilizar este recurso em aplicações de pequeno ou grande porte, mas sim de baixa ou grande complexidade.
Sistemas grandes tbm são recheados de CRUDs tediosos que não fazem nada além de extender um estado de um objeto (persistencia); para estes casos não vejo mal algum em utilizar recursos que facilitem isso (já que nenhuma linha de codificação será necessária). Porém se determinada história do usuário mudar e for necessário que alguma atividade do domínio seja mais efetiva para aquela entidade, então a modelagem evolui junto.
Concordo com você devemos tratar os casos de uso com arquiteturas diferentes.
Ou estou errado?
Por exemplo se é um caso de uso de manter Estado sem nenhuma regra de negócio, não vejo a necessidade de uma arquitetura com várias camadas.
Mas para um caso de complexidade maior ou em regras ou em quantidade de entidades, eu usaria o que fosse preciso para delegar as responsabilidades certas para as classes certas.
Me corrijam se eu estiver errado!!!
Sim, cada caso um caso.
Se possível, considere os princípios abaixo:
[KISS] http://en.wikipedia.org/wiki/KISS_principle
[YAGNI] http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It
Gostei das citações, esses links couberam como uma luva no caso.
Adorei o dialogo dos 2 … Obrigado !