A anos acompanho esse forúm e tenho o prazer de dizer que nunca precisei postar nada. Sempre encontrei a solução para minhas dúvidas. Mas, desta vez precisarei da ajuda das companheiros.
Estou para começar a desenvolver um projeto usando o que chamam de “modelo anêmico”. Percorri o GUJ e vi várias discussões sobre o assunto, são muitas opiniões que na maioria das vezes colidem umas com as outras.
Gostaria de uma resposta objetiva para o seguinte:
Dentro da lógica usarei os patterns DAO e Abstract Factory. Em resumo, as classes serão dos classificadas em DAO, DTO (VO, TO, Entidade, por favor sem brigas…) e BO. Entre essas classes os objetos DTO serão sempre passados como parâmetro dando conhecimento às outras classes sobre sua estrutura (acoplamento). Fora dessa logistica haverá uma aplicação web que usará as classes BO para acessar toda a logica. A minha dúvida é se seria incorreto usar as classes DTO na apresentação de dados, além do BO.
Procurei essa resposta mas não achei. É prejudicial? incorreto?
Desde já agradeço!
Acho que não fica errado (dentro do seu contexto) pois se está separado BO - Lógica, DTO - Estado, DAO - Persistência… Se você vai exibir o estado, então o mais lógico é utilizar o DTO mesmo (apesar de eu não gostar muito de tanta separação…)
A separação se fez necessária por causa de alguns “desgostos”.
Mas nessa questão de separação. O que sugeriria para deixar menos complexo? Usar objetos ricos ao invés de DTOs?
Isso, deixando da forma clássica Objeto = Estado + Comportamento = Estado + Lógica 
A parte de persistência realmente deve ficar separada, bem como a parte de visualização e controle, mas se tratando do modelo, acho que separar a lógica dos dados é aumentar a complexidade sem necessidade, geralmente essas duas camadas ainda ficam muito dependentes…
Mas eu só disse que não gosto muito, não estou falando que é errado (muito pelo contrário) é só uma abordagem diferente do meu ‘estilo’ rsrsrsrs
Entendo. Gostaria de desenvolver justamente dessa forma. Na verdade o grande ponto aqui é a facilidade de implementação.
O modelo de objetos ricos é muito bom mais exige certo “bom senso” para modelar a classe. Se não souber fazer embana tudo…
A grande vantagem de mapear um projeto no modelo anêmico é que não tem como errar. Os DTOs são praticamente reflexos das tabelas no banco.
Andrews.fb87, da minha parte só posso dar lhe parabéns. Concordo com sua decisão de adotar um design baseado em modelo anêmico e com as suas argumentações. É bom tomar certos cuidados mas, pela sua argumentação, estou confiante de que vc saberá tomá-los. Muitos não gostam de adimitir mas uma abordagem não anêmica é para poucos, muito poucos mesmo.
Se o sistema que vc irá desenvolver é do tipo: passa informação pra lá;passa informação pra cá anemia não é doença, é remédio.
Agora, se vc é daqueles que, quando corre pra uma cabine telefônica e abre a camisa, tem um S no peito e muito tempo para analisar e modelar caso a caso, aí vai fundo num modelo mais rico.
Penso que o design anêmico encontra limitações na modelagem de problemas realmente complexos que demandam implementações bastante técnicas como otimização, recursões, etc., que geralmente residem em componentes de frameworks e infraestrutura, não em classes de negócio.
Caros, colegas, desculpem-me pela minha tenaz sinceridade e igual mediocridade.
Com certeza. Orientação a Objetos pura é coisa séria. Muita gente leva na brincadeira e acaba pagando um preço altíssimo no futuro.
Isso se torna uma verdade ainda maior quando se trabalha em equipe. Cada um tem um racíocinio. Se não há controle, daqui a pouco existe aquela “miscelânea” de padrões de objetos.