Sempre trabalhei com modelo anêmico numa boa, até pq sempre trabalhei com aplicações distribuídas.
Usei bem pouco do modelo “rico” , acho as 2 abordagens boas. Preciso de um pouco mais de evidência factível para abominar o modelo anêmico como muitas das figurinhas tarimbadas de twitter e blogs de dev pregam.
[quote=Daniel_MV]Sempre trabalhei com modelo anêmico numa boa, até pq sempre trabalhei com aplicações distribuídas.
Usei bem pouco do modelo “rico” , acho as 2 abordagens boas. Preciso de um pouco mais de evidência factível para abominar o modelo anêmico como muitas das figurinhas tarimbadas de twitter e blogs de dev pregam.[/quote]
Por que voce precisa de dois objeto (na melhor das hipoteses) pra fazer o que um pode muito bem fazer? Eu ja trabalhei com modelos anêmicos (legados) e na prática é muito mais abominável do que as “figurinhas” pregam. Porque nos exemplos aparecem só esboço dos problemas. Na verdade eles geram “BOs” enormes, funcionalidades duplicadas, triplicadas, quadruplicadas, espalhadas para todo lado quando um simples métodos no “VO” resolveriam.
Sinceramente, não vejo como um saco de dados transportado de um lado pro outro possa ser melhor do que uma classe responsável pelo seu próprio comportamento, exceto (talvez) em aplicações distribuídas (aquelas que rodam em mais de uma máquina virtual). Mas aí já não posso falar, nunca vi aplicações nesse formato.
[quote=Daniel_MV]Sempre trabalhei com modelo anêmico numa boa, até pq sempre trabalhei com aplicações distribuídas.
Usei bem pouco do modelo “rico” , acho as 2 abordagens boas. Preciso de um pouco mais de evidência factível para abominar o modelo anêmico como muitas das figurinhas tarimbadas de twitter e blogs de dev pregam.[/quote]
Não vejo o tema soando como proibição, se não existe necessidade de enriquecer as classes, não o faça. O que é condenado é a transformação de classes em “structs” sem ao menos uma análise prévia.