Como evitar o modelo anemico no jsf?

Programação Arquitetura
#1

Bom dia.

Estou lendo o livro de arquitetura da Caelum, e estou com uma dúvida, como eu evitaria o modelo anemico usando jsf, já que eu necessito de gets e sets nos managed beans, que por sua vez muitas vezes tem os values mapeados para a os gets e sets que são chamadados na composição existente nos managed beans, exemplo

tem alguma referência do tipo “Managed beans e os modelos anemicos”???

Abraço e obrigado.

#2

O “modelo anêmico” não diz que você não pode ter setters and getters. Mas sim evitar o uso indiscriminado deles.

Exemplo: por que ter um setId se o JPA gera o ID para você? Então remova-o.

#3

Esse negócio de DDD é polêmico. Lia bastante sobre isso uns 5 anos atras. Acho que a maior parte das “medidas” pregadas pelo DDD simplesmente não funciona. Na prática, em uma aplicação java comum como as conhecemos hoje, simplesmente não dá.

Nunca li essas apostilas da Caelum para saber o que exatamente é dito lá, mas um ponto que é “pregado” pelo DDD e que eu acho completamente não viável é a ideia de entidades cogitarem usar DAOs (ou Repositories na semantica do DDD) ou qualquer outro serviço externo.

Dá pra colocar alguma inteligência em objetos de domínio? Claro que dá. Mas algo bem mais restrito do que o DDD sonha em ter. Os modelos sempre ficam muito mais “anêmicos” do que “inteligentes”. :slight_smile:

#4

Maior criador de modelos anemicos: Fabricas de Softwares e seus frameworks “super ágeis”.

#5

Ao colega rodrigo.uchoa:
DDD é viável sim, tenho excelentes experiencias com desenvolvimento utilizando este paradigma, a questão é maturidade da equipe, isso sim é um ponto que custa caro mudar, mas vale cada centavo.

Quanto a pergunta do colega ribclauport:
JSF, ou melhor a EL, que é a linguagem utilizada nas páginas JSF, não te obriga a violar os principios do DDD.
Conceitualmente falando, se determinado dado:

  • não deve ser visto, ele não deve ter get nem set logo não é acessível via EL;
  • não deve ser alterado, ele tem somente get, portanto é uma propriedade somente leitura via EL;
  • pode ser visto e alterado, deve ter get e set e portanto é acessível e editável pela EL;

Vale lembrar que #{venda.valorTotal} não precisa ter um atributo com este nome, um método com nome getValorTotal que itere sobre os itens da venda e retorne o valor total é conceitualmente mais correto e plenamente viável pelo JSF.

Portanto, ao meu ver, a EL no JSF são aliados do domínio rico e não o contrário.

#6

[quote]Ao colega rodrigo.uchoa:
DDD é viável sim, tenho excelentes experiencias com desenvolvimento utilizando este paradigma, a questão é maturidade da equipe, isso sim é um ponto que custa caro mudar, mas vale cada centavo. [/quote]

Ainda continuo cético :slight_smile:

Na maioria esmagadora dos casos, a única coisa que vale a pena fazer é colocar uma logicazinha simples dentro de alguma entidade, quando a lógica depende só dos atributos da própria entidade. Usar DDD na sua plenitude acho que só vai valer a pena em 1% dos sistemas que se ve por ai. Eu ainda não tive oportunidade de participar de um.

Grande abraço!

#7