Arquitetura 2010 – Parte II 

Apr/10
25

O primeiro post desta s√©rie levantou muito burburinho pelas raz√Ķes erradas. A culpa foi minha porque ao tentar explicar que aplica√ß√Ķes EE e sites s√£o coisas diferentes e que para fazer sites n√£o precisamos de EJB acabei citando coisas que n√£o precisava…

Felizmente algumas pessoas entenderam o objetivo do texto: descrever uma arquitetura mais adquada para sites sem usar EJB e aumentando as capacidades de teste e robustez das aplica√ß√Ķes. Algumas pessoas pediram um exemplo mais concreto desta arquitura. Porque isto implicariam em escrever muito codigo e seria extenso demorei um pouco. Mas j√° que tinha que o fazer, resolvi colocar esta arquitetura na nova se√ß√£o de configura√ß√Ķes de arquitetura. Quem estiver interessado pode ler o artigo completo. Quem ler tenha em mente que √© um “work in progress” e sugest√Ķes s√£o bem vindas. A parte com CriteriaBuilder tive que pular pois ia ocupar muito espa√ßo e n√£o √© o foco do artigo. Cada um poder√° implementar como quiser. S√≥ uso esse objeto porque ele torna muito facil criar criterios de busca.

Espero que fique claro  desta vez porque esta arquitetura é vantajosa face às tradicionais arquiteturas acopladas ao hibernate e/ou entity manager.

2 comentários para “Arquitetura 2010 – Parte II”

  1. Sem d√ļvida um bom c√≥digo, mas consigo ver pouca diferen√ßa de usar seu pr√≥prio sistema de Criteria/Query/CriteriaBuilder em vez de usar a JPA2. Vi que no outro artigo voc√™ n√£o conhecia do lan√ßamento da JPA2, mas agora j√° poderia ter visto que ela faz exatamente o que voc√™ colocou l√°, e de forma padronizada (nomes dos m√©todos parecidos at√©). N√£o devemos rejeitar o Java EE a ferro e fogo, mas entendo que “o passado o condena”.

    Sobre ter um DAO abstrato na classe m√£e, h√° muito tempo fui adepto, mas hoje em dia enxergo as grandes desvantagens da heranca at√© num exemplo simples assim. Escrevi sobre esse mesmo tipo de DAO abstrato em 2006, e hoje em dia n√£o usaria (como comentei l√° em 2008, n√£o vale a pena para economizar meia d√ļzia de linhas que s√£o s√≥ delega√ß√Ķes):
    http://blog.caelum.com.br/2006/10/29/brincando-com-generics-o-bizarregenericdao/

    Mas como você deixou tudo bem interfaceado, usar o dao abstrato certamente é opcional.

    A prop√≥sito, a erasure sempre ocorre. O seu m√©todo resolveGenericClass descobre o par√Ęmetro atrav√©s da assinatura da classe, diferentemente do que est√° escrito. N√£o √© por causa de ser heran√ßa ou por “erasure n√£o se aplicar”. Funcionaria perfeitamente com interface/implementa√ß√£o se usado o mesmo exemplo. Mas, tamb√©m diferente do que est√° falado, a heran√ßa n√£o obriga nada, j√° que voc√™ poderia ter dando extends em AbstractRepository sem especificar o tipo, o que √© uma falha no c√≥digo: o repository abstrato n√£o checa se esse parametrized type est√° bem definido.
    http://blog.caelum.com.br/2008/04/28/nao-posso-descobrir-nem-instanciar-tipos-genericos-porque/

  2. A arquitetura que propus parece fazer o mesmo que o JPA2. E de facto assim √©. Ela faz exactamente o mesmo ( ok, n√£o exactamente, mas isso √© detalhe). O ponto aqui √© que o JPA2 n√£o faz o mesmo que esta arquitetura. √Č isso que √© importante entender. Com esta arquitetura eu posso mudar a estrat√©gia de persistencia quando e como quiser. No JPA isso √© simplesmente demasiado complexo (n√£o √© impossivel, mas teria muito, muito, muito, muito trabalho pois teria que implementar a especifica√ß√£o toda … )

    Agora alguem vai dizer que esse tipo de flexibilidade é inutil, que nunca mudamos de banco, blá, blá, blá. Se a pessoa faz testes unitários e tem experiencia com moking, sabe muito bem que é preciso fazer mock da camada de persistencia e que isso é impossivel usando JPA ou Hibernate directamente. Sempre temos que ter alguem no meio. Ora, esse alguem é a estratégia de persistencia.

    Esta arquitetura √© desacoplada. Mesmo que nunca precisa usufruir dessa qualidade ( o que eu duvido muito) ela √© sem duvida melhor. At√© porque, basta colocar o hibernate/jpa por baixo da estrat√©gia de persistencia e voil√°, teremos o que todo o mundo est√° usando por ai… algum tipo de objeto que encapsula o acesso a esses caras. O ponto , aqui √© que, o encapsulamento n√£o √© completo/correto sem um mecanismo de Query Object, o qual n√£o √© vi√°vel sem Repositorios. Uma coisa leva a outra…

    N√£o ha nenhum DAO nesta arquitetura . ent√£o n√£o entendi do que est√° falando.

    O erasure nem sempre ocorre.

    “For instance, erasure doesn’t apply to subclasses of generified classes” fonte

    √Č sim porque ha heran√ßa – n√£o funcionaria sem isso , n√£o funciona para interfaces – e √© sim porque erasure n√£o se aplica neste caso.
    Não é uma falha no código, é uma simplificação. Desta forma não precisa passar a classe no construtor ou em qq outro lugar.
    O AbstractRepository não checa porque não precisa. A construção da classe e o proprio java garantem que a tipagem é compativel. Veja que na realidade quem irá definir o tipo é o critério e quem a carrega é a estratégia de persistencia, portanto as assinaturas genéricas do repositorio servem apenas para manter a tipagem forte e com isso simplificar a escrita.

    Ao contr√°rio do que pode parecer dos variados exemplos de “DAO Gen√©ricos” vinculados por ai onde o programador precisa passar explicitamente o literal da classe no contrutor das implementa√ß√Ķes, isso n√£o √© uma necessidade. Ali√°s, √© uma m√° pr√°tica por criar um c√≥digo que n√£o √© DRY.

    Todas as implementa√ß√Ķes do artigo s√£o exemplos, e cada pessoa pode modificar como entender. O objetivo √© mostrar os componentes e suas responsabilidades, n√£o uma implementa√ß√£o “ultima”. Contudo, n√£o pude deixar passar a oportunidade de mostrar que ainda ha alguns mitos a serem quebrados. Sendo um deles a cren√ßa que a erasure sempre acontece.

    Nem sempre acontece. E podemos tirar vantagem disso para deixar o código mais elegante.

Comente

Artigos