Business Object

Olá,

são muitas as discussões sobre BOs, DAOs e TOs. Os mais puristas da Orientação a Objetos consideram um crime separar a lógica dos dados mas, isto se faz necessário em aplicações J2EE, principalmetne para diminuir o número de chamadas pela rede.

Respondendo sua pergunta:
Nos Business Objects vc colocar toda a regra de negócios, a inteligência de sua aplicação. Geralmente um BO é composto por um EJB Stateless e ele é composto por um DAO.
Vou escrever um código pequeno aqui, portanto pode não comoilar:

class AccountDAO{
   public void update(AccountVO vo){
      ...
      //executa SQL de insert, gerencia pool de conexões e/ou usa algum framework como Hibernate.
   }
}

class AccountBusinessObject{
   private AccountDao dao = null;
   public void transferFound(AccountVo from, AccoutVo to, double value){
     //usa o DAO para buscar dados da conta de origem
    from = dao.loadByPrimaryKey( from.getId() );
    //se tem crédito, entãofaz o cálculo necessário
    from.credit( from.credit - value );
    to.credit( from.credit + value );

    //usa o DAO para atualizar o valor decrementado no BD
     dao.update( from );
     dao.update( to );

   }
}

class AccountVO(){
  private double credit;
  private int id;
  //etc
}

Olá Franklin, tudo bom?

Muito bom exemplo… é por ai mesmo que estou procurando,
mas não encontro um exemplo concreto para que eu possa
tentar aplicar na prática.

Deixa eu ti perguntar outra coisa: O VO é o mesmo de TO, não é?

O que eu tava vendo no livro de J2ee é que é o BO que tem relacionamentos entre si,
tipo tenho uma Company que tem atributos como id, name, address e
uma lista de Employees, por exemplo. Como seria isto no BO? Não é no BO que tem
os Relacionamentos?

Estou utilizando o Hibernate 2.1.4 com Oracle.
Então, eu comecei a montar TO´s e são estes que eu fiz os relacionamentos
entre eles, para poder fazer a persistência no hibernate
e diversas regras estão nestes TO´s também.
Isto está me intrigando, pois por exemplo eu tenho um DAO assim:

public class UserDAO
{
	DataSource dataSource = null;

	public void update(UserTO userTO)
	{
		dataSource.update(userTO);
	}
	.
	.

)

Dai este UserTO tem diversos relacionamentos, certo?

Até aki beleza… mas daí eu tava vendo no livro que são os BO´s que tem relacionamentos
aí isto está me confundindo todo.

Os BO´s podem ser simplesmente classes (sem relacionamentos)
que abstraem o acesso ao DAO (por exemplo)
e podem retornar para o cliente os TO´s ou manipulá-los?

Pode ser assim?

Muito obrigado pelas dicas!!!

Abraço

opa… cara, eu não sou nenhum franklin pra poder te responder com exatidão… mas eu tb to estudando patterns, pelo livro Core J2EE Patterns (a 1ª edição), pelo q entendi na conversa de vcs, o TransferObject é o ValueObject, ok…

até onde sei, o BusinessObject é a tua lógica de negócios, o pensante da aplicação, aquilo q teu chefe paga mais pra alguém fazer… hehehe, é implementado por EJBs, quantos forem necessários, q recebem um VO do cliente, fazem o processamento com o banco, e retornam algo, supostamente q outro VO atualizado… bem, pra não deixar as interfaces públicas desses EJBs no teu BO visiveis diretamente pro cliente, tu detemina casos onde seja necessário um Session Facade (vide livro :)), q é um baita EJB de granularidade grossa q tem somente aqueles métodos realmente úteis pro cliente, e q fazem algum processamento adicional tb… ai quem acessa esse Facade é um Bussines Delegate, q é uma classe qualquer q atua como um proxy pra esse Facade, q tb pode colocar as referencias num cache pra não ficar enxendo a rede… ai esse BDelegate usa um ServiceLocator pra achar o Facade, o locator abstrai do resto da aplicação tudo oq tem a ver a lookup JNDI… ah… eu vou ficar escrevendo um monte de conceitos aqui e não vou dizer nada q tu ja saiba… hehehe, deixa pra lá… se alguém não gostou pode deletar o post hehe