Consegui evitar os VOs e BOs ?

Ola, no começo da semana eu postei um topico com duvidas de como evitar VOs BOs, apos muita discussao eu nao tinha entendido mas depois de ler tudo novamente e inclusive os outros posts que falam sobre o mesmo assunto eu cheguei a seguinte conclusao e gostaria de saber se isto esta correto.

//Meu servlet ou algo do genero
public class Beta {
	
	//Como eu gravava um objeto em um modelo anemico
	private void anemic(){
		PessoaBO pessoaBO = new PessoaBO(); 
		Pessoa pessoa = new Pessoa();
		pessoa.setIdade(30);
		pessoaBO.save(pessoa);
	}
	
	//Como eu deveria gravar um objeto usando DDD
	private void DDD(){
		Pessoa pessoa = new Pessoa();
		pessoa.setIdade(20);
		pessoa.save();
	}
	
	//Teste de uso
	public static void main(String args[]){
		Beta beta = new Beta();
		beta.DDD();
		beta.anemic();
	}
}

//Meu antigo VO, POJO, DTO ou TO, chamem como quiser
class Pessoa{
	private int idade = 50;
	private Repositorio repositorio;
	
	public Pessoa(){
		repositorio = new Repositorio();
	}
	public int getIdade() {
		return idade;
	}
	public void setIdade(int i) {
		this.idade = i;
	}
	public void save(){
		repositorio.save(this);
	}
}

//Objeto de negocio parte do modelo anemico
class PessoaBO{
	public void save(Pessoa pessoa){
		Repositorio repositorio = new Repositorio();
		repositorio.save(pessoa);
	}
}

//Meio de como persistir os dados
class Repositorio{
	//Grava o objeto em algum lugar qualquer
	public void save(Pessoa pessoa){
		System.out.println(pessoa.getIdade());
	}
}

Observacoes:
A classe repositorio poderia ser uma interface, e vc poderia obter uma instancia dessa forma para abstrair aonde vc grava as informacoes

Mas eu acho que isso nao vem ao caso, o que importa é que uma Pessoa tem que possuir um repositorio e a Pessoa deve ser responsavel pela acoes de persistir um objeto do tipo pessoa ! correto ?
Portando a logica de negocio fica no proprio VO.

Se vc esta lendo esse post pela primeira vez, sugiro que leia primeiro os seguintes artigos
http://fragmental.com.br/wiki/index.php?title=Evitando_VOs_e_BOs
http://fragmental.com.br/wiki/index.php?title=MVC_e_Camadas
http://blog.caelum.com.br/2007/06/09/repository-seu-modelo-mais-orientado-a-objeto/
http://guj.com.br/posts/list/105/60916.java

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

Está correto..

Mas questão é mais quando uma logica de negocio de Pessoa for executada.. exemplo

Antigamente você teria

e sem BO e VO, você usa:

Já que agora, pessoa possui estado e comportamentos..

Quando você quiser exibir Pessoa num JSP, você manda o objeto e não um VO dele porque simplesmente não há necessiade de um VO, então veja que nesse caso ele seria inutil.

Só não chame Pessoa de VO.. Pessoa é um objeto de domínio.. VO/DTO tem oturo significado

obs: é importante valorizar as nomeclaturas...

Virtual Machine Man Membro desde: 19/04/2005 10:11:09 Mensagens: 572 Offline

Só acho que o seu exemplo não foi muito feliz...

pessoa.save() não é uma "logica de negócio". Salvar um dado em um banco de dados no fundo não é um problema do negócio, mas quase um "requisito não funcional" do seu sistema. Na minha opinião não seria errado delegar o "salvar" para outra classe (fora do domínio do negócio).

Se fosse tipo pessoa.definirIdade(20), e isto no fundo salva o dado, para mim ai estaria mais correto.

oyama wrote:Só acho que o seu exemplo não foi muito feliz...

pessoa.save() não é uma "logica de negócio". Salvar um dado em um banco de dados no fundo não é um problema do negócio, mas quase um "requisito não funcional" do seu sistema. Na minha opinião não seria errado delegar o "salvar" para outra classe (fora do domínio do negócio).

Se fosse tipo pessoa.definirIdade(20), e isto no fundo salva o dado, para mim ai estaria mais correto.

É por isso que o infeliz do Phillip Calçado nao citou exemplos, pois é dificil retrar a situação atraves de um exemplo.
Porem por mais que o exemplo seja ruim

, eu espero que parte do conceito tenha sido entendido

Agora eu nao entendi o que vc quis dizer em relação a delegar o "salvar" para outra classe (fora do domínio do negócio).
Aonde por exemplo e porque ?

Obs.: Espero que ele nao fique ofendido com o infeliz rsrs

A abordagem que eu costumo usar, você preserva de certa forma a idéia de um Active Record mas sem acoplar o objeto de domínio com a tecnologia de persistência.

mas utilizando ActiveRecord não transformaria o sistema em uma sopa de camadas? A idéia parece legal, uma entidade "completa" que trabalha "sozinha"?

Bom, pelo menos o DAO a gente elimina com esse pattern. Mas e quanto a BOs/TOs? No blog da fragmental não achei/entendi (ainda) como eliminar isso

O que vc quer dizer com "sopa de camadas"?

Leozin wrote:
Bom, pelo menos o DAO a gente elimina com esse pattern. Mas e quanto a BOs/TOs? No blog da fragmental não achei/entendi (ainda) como eliminar isso

Na verdade nao eliminamos nada, A unica coisa que foi feita é definir um objeto de dominio que estava fragmentado no classico BO, TO, DAO.

Agora o objeto de dominio ressurgi como uma entidade que difine os atributos de uma pessoa e ainda contem as funcoes para demonstrar como funciona um Pessoa.

Note que o repository pode ser algo qualquer, um DAO ou seja o que for, eu na verdade so mudei o nome das classes quando me referi ao repositorio, pois antes nos tinhamos:

Esse codigo era definido no PessoaBO, e ela era responsavel por executar as rotinas do repositorio, agora nos definimos isso na propria classe Pessoa, porem as interfaces recebem a nomenclatura de Repository, pois as interfaces de fato sao o repositorio, mas nos nao queremos saber que tipo de repositorio é usado, e para isso nos usamos uma fabrica para resolver o tipo de repositorio usado.

O titulo pode soar meio estranho quando o artigo dizia que deveriamos evitar o uso de VO e BO, isso me deu a impressao que eles iriam sumir do sistema, porem como vc viu nos ainda continuamos a usar o VO o BO, porem nos usamos de uma forma mais organizada e respeitando as regras do DDD.

Rafael Nunes wrote:A abordagem que eu costumo usar, você preserva de certa forma a idéia de um Active Record mas sem acoplar o objeto de domínio com a tecnologia de persistência.

Eu nao entendi muito bem, estou vendo o artigo que vc indicou, vc pode passar mais alguns detalhes

Debugger Membro desde: 05/04/2007 20:42:19 Mensagens: 67 Offline

ronildobraga wrote:
O titulo pode soar meio estranho quando o artigo dizia que deveriamos evitar o uso de VO e BO, isso me deu a impressao que eles iriam sumir do sistema, porem como vc viu nos ainda continuamos a usar o VO o BO, porem nos usamos de uma forma mais organizada e respeitando as regras do DDD.

1 colocação..

Nós não estamos usando mais VO nem BO. Estamos usando um objeto de domínio para cumprir o papel do VO e do BO.

cv wrote:O que vc quer dizer com "sopa de camadas"?

O ActiveRecord "parece" não trabalhar com POJOs, ou seja, a tua entidade faz tudo, o que me referi a sopa de camadas era a respeito de você juntar uma entidade do sistema + DAO, tal como mostrado no exemplo

felipec wrote:
Nós não estamos usando mais VO nem BO. Estamos usando um objeto de domínio para cumprir o papel do VO e do BO.

Entendi, obrigado por corrigir.
Eu so me pergunto como ficaria isso mapeado no hibernate, eu teria um Pessoa.hbm.xml referenciando o objeto de dominio e nao mais a um VO ?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3433 Offline

ronildobraga wrote:(...) cheguei a seguinte conclusao e gostaria de saber se isto esta correto.

Sim. Mas pode fazer melhor.
1) Vc tem pessoa referenciando repositorio só para que pessoa delegue para ele. Não precisa. Use apenas o repositório

2) O repositório não precisa depender do banco

Seria

E dentro do método vc decide. Pode usar um properties ou outra coisa para decidir. Isto elimina mais uma dependencia.
Por outro lado vc só precisa de uma instancia de Repositor. O factory deve controlar o numero de instanciações e para simplificar torne os métodos de Repository estáticos e genericos.

Vc pode ainda separar o acesso ao banco com DAO se quiser.

E ficaria assim.

ronildobraga wrote:Eu nao entendi muito bem, estou vendo o artigo que vc indicou, vc pode passar mais alguns detalhes

Na verdade no link só tem um breve resumo deste padrão, no livro do Fowler tem uma explicação maior.
Mas em suma, Active Record seria além das propriedades e lógica de negócio, inserir nos objetos de domínio também a lógica de acesso a dados. No próprio livro Fowler diz que active record é uma boa solução para sistemas que não tenham uma lógica de negócio muito complexa, tipo CRUDs, e sugere que para domínios com relacionamentos mais complexos, seja utilizado alguma forma de Data Mapper, como DAO por exemplo.
O exemplo que eu dei utiliza as duas estratégias, porém ao invés de o objeto de domínio conter a lógica de acesso a dados, ele delega essa responsabilidade para um Data Mapper.

sergiotaborda wrote:
1) Vc tem pessoa referenciando repositorio só para que pessoa delegue para ele. Não precisa. Use apenas o repositório

2)O repositório não precisa depender do banco

3)O factory deve controlar o numero de instanciações e para simplificar torne os métodos de Repository estáticos e genericos.

1)Eu entendo que o objeto de dominio seja a Pessoa, se colocarmos a funcao salvar dentro do repositio e a funcao salvar necessitar de logica, a logica ficaria fora do dominio, a nao ser que o objeto de dominio seja composto por Pessoa + Repositorio, e por isso eu usei composição pois uma pessoa contem um repositorio.

2)Perfeito, realmente tava pessimo aquela dependencia

3)Tornar os metodos do repositorio estatico e generico, nao entendi como fazer, pode ser mais claro.

Rafael Nunes wrote:
Mas em suma, Active Record seria além das propriedades e lógica de negócio, inserir nos objetos de domínio também a lógica de acesso a dados.

Eu nao achei pratica essa solução, e se eu mudar a logica de acesso a dados, por exemplo: Hoje eu uso hibernate mas amanha eu gostaria de usar JDBC, seguindo o Active Record eu teria de configurar novamente todos os objetos de dominio, nao achei muito inteligente nao

Pessoal, não vamos misturar duas discussões né?

Domain Model x BO + DTO é uma coisa.
ActiveRecord (pessoa.save()) x DataMapper (dao.save(pessoa) / repositorio.store(pessoa)) é outra!

Notícias, artigos e o maior fórum brasileiro sobre Java