Depende do padrão que vc adotar. Vc pode usar activeRecord e o objeto sabe se salvar (e como recuperar) como é comum em Rails. Ou pode usar Repositorios (DDD). O lance é que persistência tem pouco haver com negocio e sim com uma particularidade do seu sistema: eu preciso usar um banco de dados ou outra coisa pois os objetos não podem ficar em memoria (que é um recurso finito) pra sempre.
@dohko Um objeto não deveria ser capaz de criticar e validar o seu estado interno? Pq eu preciso de uma classe externa?[/quote]
Poderia explicar melhor aquele exemplo que você deu sobra validação de pessoa fisica?
Como seria no modelo anemico e rico e qual as vantagens?
Depende do padrão que vc adotar. Vc pode usar activeRecord e o objeto sabe se salvar (e como recuperar) como é comum em Rails. Ou pode usar Repositorios (DDD). O lance é que persistência tem pouco haver com negocio e sim com uma particularidade do seu sistema: eu preciso usar um banco de dados ou outra coisa pois os objetos não podem ficar em memoria (que é um recurso finito) pra sempre.
@dohko
Um objeto não deveria ser capaz de criticar e validar o seu estado interno? Pq eu preciso de uma classe externa?
Não seria mais Simples ter Objetos que se relacionam como Objetos?[/quote]
No meu caso eu resolvo isso com uma classe que estende a entidade… pode ser PessoaFisicaEntity ou PessoaFisiscaVO extendendo PessoaFisica (classe que apenas contem o que a compoe)… Ai sim, nesta classe a um nivel abaixo teria esses métodos… O problema é que eu nao considero uma boa pratica, a nao ser que vc tenha controle e nao deixe que metodos bizarros comecem a aparecer na sua VO, como por exemplo um metodo que define que cor sera uma coluna na view… ex: getCorNome() { return “azul” }… e ai começa a coisa maluca… por isso eu preferiria usar classes que auxiliam na validacao
O modelo anêmico não é um fracasso. Aliás a maioria dos sistemas por aí continua sendo feitos desta forma, entram em produção, e milhões de pessoas os usam sem problemas.
Problema é que ele duplica muitas regras, validações, deixa a lógica mais longa, menos legível, e mais complicada de reusá-la.
[quote=Bruno Laturner]O modelo anêmico não é um fracasso. Aliás a maioria dos sistemas por aí continua sendo feitos desta forma, entram em produção, e milhões de pessoas os usam sem problemas.
Problema é que ele duplica muitas regras, validações, deixa a lógica mais longa, menos legível, e mais complicada de reusá-la.[/quote]
Eu não vejo ele duplicando regras, porque se eu tenho cada VO com seu respectivo BO. Quando eu quero usar a regra do “Carro” por exemplo, eu vou e chamo a CarroBO. Eu não vou reescrever a lógica sendo que ela já existe no BO.
No caso, eu acho mais organizado a entidade em uma classe, as regras de negócio em outra classe e o acesso ao banco em outra.
Mas não que isso seja o correto, eu estou falando o que eu acho mais organizado.
A diferença do rico para o anêmico não é somente colocar a regra de negócio no objeto ao invés de colocar em uma classe separada?
Pra aplicar um pattern vc precisa de uma motivação. Qual a sua motivação pra estar separando comportamento e dados?
Vc está numa aplicação distribuida usando ejb 2? Se não, eu não vejo motivo para isso.
Alias, qual a sua base de patterns? o livro do Fowler, o de Patterns J2EE da Sun, ou outro? pq pelo que eu estou notando, os seus VOs não são na verdade VOs, seriam apenas DTOs, me corrija se eu estiver engano por favor.
[quote=mario.fts]Pra aplicar um pattern vc precisa de uma motivação. Qual a sua motivação pra estar separando comportamento e dados?
Vc está numa aplicação distribuida usando ejb 2? Se não, eu não vejo motivo para isso.
Alias, qual a sua base de patterns? o livro do Fowler, o de Patterns J2EE da Sun, ou outro? pq pelo que eu estou notando, os seus VOs não são na verdade VOs, seriam apenas DTOs, me corrija se eu estiver engano por favor.
[/quote]
Eu li essa mesma justificativa em outro lugar, qual a motivação de separar a entidade da regra? ainda mais se não está em uma aplicação distribuida.
Então seria apenas uma questão de preferência em separar a entidade da lógica. É por isso a pergunta do título do tópico: Modelo Anêmico é realmente ruim? Ele realmente influencia negativamente?
[quote=mario.fts]Pra aplicar um pattern vc precisa de uma motivação. Qual a sua motivação pra estar separando comportamento e dados?
Vc está numa aplicação distribuida usando ejb 2? Se não, eu não vejo motivo para isso.
Alias, qual a sua base de patterns? o livro do Fowler, o de Patterns J2EE da Sun, ou outro? pq pelo que eu estou notando, os seus VOs não são na verdade VOs, seriam apenas DTOs, me corrija se eu estiver engano por favor.
[/quote]
A unica pessoa que diferencia VO de DTO é o Fowler. Infelizmente ainda nao tive a oportunidade de ler sua bibliografia, porém já está “escalonado” (rs). Me baseio em GOF e SUN.
Só de pensar métodos misturados em atributos que representam uma entidade do mundo real ou abstrata, já me da enjoo. Agora considere dao nesses métodos… Vou mais além… Injeção de dependência em cada método, ou você vai querer ter atributos com as DAOs…ou melhor ainda… vc irá instanciar a DAO em cada método desse???. agora imagine q vc ta usando o hibernate… todos eles com o modificador transiente!
Enjoo por que? As coisas nao ficam mais organizadas juntas? Voce tem os atributos da sua classe e os metodos que interagem com eles, e somente esses metodos, no mesmo lugar.
Daos sim, prefiro que fiquem separados, mas as regras especificas do dominio devem ficar juntas.
Imagine a situacao classica do objeto ContaCorrente, com VO BO voce pode alterar o saldo atual dele de qualquer lugar, nada te garante que essa alteracao seja feita apenas pelo BO, ja que no VO voce tem todos os atributos expostos para que o BO possa usar.
Mas qual o sentido em se alterar o saldo de uma conta corrente a nao ser por uma transacao? Com um metodo que atualize o saldo, voce garante que nenhum outro metodo ira atualiza-lo sem que haja uma transacao, por exemplo, porque o atributo saldo nao sera exposto a ninguem pra fazer isso. Ele sera alterado apenas pela propria classe ContaCorrente e se voce preferir apenas por um e metodo dessa classe.
Enjoo por que? As coisas nao ficam mais organizadas juntas? Voce tem os atributos da sua classe e os metodos que interagem com eles, e somente esses metodos, no mesmo lugar.
Daos sim, prefiro que fiquem separados, mas as regras especificas do dominio devem ficar juntas.
Imagine a situacao classica do objeto ContaCorrente, com VO BO voce pode alterar o saldo atual dele de qualquer lugar, nada te garante que essa alteracao seja feita apenas pelo BO, ja que no VO voce tem todos os atributos expostos para que o BO possa usar.
Mas qual o sentido em se alterar o saldo de uma conta corrente a nao ser por uma transacao? Com um metodo que atualize o saldo, voce garante que nenhum outro metodo ira atualiza-lo sem que haja uma transacao, por exemplo, porque o atributo saldo nao sera exposto a ninguem pra fazer isso. Ele sera alterado apenas pela propria classe ContaCorrente e se voce preferir apenas por um e metodo dessa classe.[/quote]
Considerando que o objeto só depende dele mesmo para fazer isso, acredito que sim!
[quote=dohko]
Considerando que o objeto só depende dele mesmo para fazer isso, acredito que sim![/quote]
Mas se nao depende somente dele há algo errado na modelagem das classes. Um modelo rico não é simplesmento um modelo nao VO/BO, ele vai muito alem.
Eu tenho notado ultimamente que há uma grande preocupacao em estudar design patterns, DDD, TDD e uma serie de coisas sem antes estudar o basico do basico de orientacao a objeto. (Nao eh uma critica ao dohko nao, tenho visto muito mesmo isso.)
Responsabilidade dos objetos é um tema muito complexo e geralmente negligenciado por quem estuda OO. É o principio mais importante e é o que normalmente faz a diferença no código, mas é um conceito com um nominho da simples.
