Evitar VOs/BOs ou não?

6 respostas
MrDataFlex

Pessoal já vi várias discuções aqui no forum sobre isso. Também já li alguns artigos do Philip Calçado em seu blog sobre tal.

Mas afinal, em que fim chegamos? Usar VOs/BOs ou tornar o objeto com suas próprias funcionalidades?

Pois na faculdade aprendemos usando VOs/BOs como se fosse a “maneira certa” …

então… o que é correto???

Valeu galera! :slight_smile:

6 Respostas

A

Cara,

Na minha opinião não existe “maneira certa”. Tudo depende da sua necessidade. Imagine que na sua camada de negócio vc tenha um método para recuperar cada atributo da sua classe… Se sua camada de negocio for remota, para cada atributo que for recuperado, uma chamada ao servidor de negocio para cada atributo terá que ser feita (se for uma classe com 10 atributos, 10 chamadas). Se vc tiver apenas um metodo que retorne um VO, apenas uma chamada ao servidor de negócios será feita, independente da quantidade de atributos. No entanto, essa unica chamada irá conter os dados de TODOS os atributos. Logo, se vc usar um VO para “mostrar” apenas uma atributo na tela, pode ser overkill.
Resumindo, se vc quer usar apenas um atributo, um VO vai te atrapalhar por causa do custo dos outros 9 que vc vai trazer. Se vc vai usar todos os 10 atributos, o VO vai te economizar chamadas ao servidor… Ou seja, é uma questão de bom senso

pcalcado

No contexto de Transfer Object (o nome VO já foi aposentado há alguns anos), ou seja: quando é para assar informações entre duas JVMs dois servidores ou etc é um padrão válido.

Quando não se trata de comunicação remota, entretanto, não há motivo para usar esta técnica. Você precisa apenas de objetos normais. Este e o cenário mais comum e tenho certeza que e o que você vê na faculdade. Infelizmente a maioria das faculdades não da qalquer base de projeto orientado a Objetos de verdade.

A

pcalcado:
andreban:

Na minha opinião não existe “maneira certa”. Tudo depende da sua necessidade. Imagine que na sua camada de negócio vc tenha um método para recuperar cada atributo da sua classe… Se sua camada de negocio for remota, para cada atributo que for recuperado, uma chamada ao servidor de negocio para cada atributo terá que ser feita (se for uma classe com 10 atributos, 10 chamadas). Se vc tiver apenas um metodo que retorne um VO, apenas uma chamada ao servidor de negócios será feita, independente da quantidade de atributos. No entanto, essa unica chamada irá conter os dados de TODOS os atributos. Logo, se vc usar um VO para “mostrar” apenas uma atributo na tela, pode ser overkill.
Resumindo, se vc quer usar apenas um atributo, um VO vai te atrapalhar por causa do custo dos outros 9 que vc vai trazer. Se vc vai usar todos os 10 atributos, o VO vai te economizar chamadas ao servidor… Ou seja, é uma questão de bom senso

No contexto de Transfer Object (o nome VO já foi aposentado há alguns anos), ou seja: quando é para assar informações entre duas JVMs dois servidores ou etc é um padrão válido.

Quando não se trata de comunicação remota, entretanto, não há motivo para usar esta técnica. Você precisa apenas de objetos normais. Este e o cenário mais comum e tenho certeza que e o que você vê na faculdade. Infelizmente a maioria das faculdades não da qalquer base de projeto orientado a Objetos de verdade.

Concordo.

MrDataFlex, o importante dos Padrões é entender como eles funcionam e para que eles servem, e aí sim decidir utiliza-los ou não.

Calcado, infelizmente as universidades hoje não ensinam mais o aluno a pensar nos impactos do código que ele está escrevendo (nem sei se na minha época ensinava). Parece que as coisas são ensinadas meramente como “receitas de bolo”. Não se explica o porquê fazer, apenas o como.

MrDataFlex

mas minha duvida persiste…

eu devo colocar o “BUSINESS” dentro do Objeto ou em classes separadas (BOs) ?

Valeu pessoal!

sergiotaborda

MrDataFlex:
mas minha duvida persiste…

eu devo colocar o “BUSINESS” dentro do Objeto ou em classes separadas (BOs) ?

Valeu pessoal!

Se vc coloca o “business” dentro do objeto , por definição, esse objeto é um business object (BO).
Vc tem que colocar a logica em algum lugar. O lugar deve estar o mais próximo dos dados possivel.
A palavra chave é : possivel. Se a logica precisa de muitas entidades e contato com muitas partes do sistema,obviamente
ela não pode ficar num lugar isolado do sistema.
Então, contrua seus objetos e coloque o máximo de operações possiveis junto dos dados que elas usam.
à medida que o sistema cresce algumas logica têm que “subir de nivel” para poder usar mais dados. Ai vc faz um refactoring e promove essa logica. Existem padrões que precisam ser aplicados e não é simples criar um modelo bem desenhado.
Mas existem principios , directivas, que podem ser usadas. A principal é a encapsulação. Primeiro encapsule e só torne publico se for realmente necessário.

Agora, o que vc não deve nunca fazer é replicar informação e logica. Um logica deve estar apenas num lugar. se ela é usada em vários lugares crie um objeto que permita isso, não replique a logica.
Se vc cria um TO (aka DTO) e um BO vc está replicando a logica. Entenda que vc está separando os dados das logicas, e isso é sempre ruim. Entenda que mesmo quando a arquitetura pede que se usem TO, isso é feito por meio de infraestrutura, por truques, e não pelo programador.

Use o principio de separação de responsabilidade, mas não separe os dados das funçoes que os usam.

com exemplos práticos é mais facil, em termos gerais siga os padrões e as directivas.

pcalcado

MrDataFlex:
mas minha duvida persiste…
eu devo colocar o “BUSINESS” dentro do Objeto ou em classes separadas (BOs) ?

Por definição objetos possuem estado e comportamentt, lóica e dados. Se um objeto possui apenas dados ou apenas lógica ele em problemas de design. Algumas vezes, como por exemplo para implementar Transacton Scripts, isso ocorre mas não é um procedimento normal.

Resposta Longa: Antes de definir uma estrutura você precisa entender o que está usando, não adianta eu sugerir uma aqui se você não entender o porque. Dê uma pesquisada na Internet sobre Transaction Script, Domain Model e nos motivos para usar o TO.

Resposta Curta: Substitua o TO/BO por objetos de negócio, com lógica e dados no mesmo componente, e você já está no caminho. Existem bilhões de tópicos no GUJ sobre isso, faça uma pesquisa.

Criado 24 de dezembro de 2007
Ultima resposta 26 de dez. de 2007
Respostas 6
Participantes 4