Duvida Arquitetura

Programação Arquitetura
#1

Pessoal, queria tirar algumas dúvidas sobre arquitetura.

Tenho um app com a classe bean TDocumento, mais ou menos assim:

public class TDocumento {
  private Integer codigo;
  private String descricao;
  private TLocal origem;
  private Integer usuario;
}

Utilizando Hibernate, tenho um DAO genérico e uma classe TDocumentoBO pras regras de negócios. Minha dúvida é quando vou salvar um documento novo, eu preencho os campos da seguinte forma:

  documento.setCodigo(<variavel>);
  documento.setDescricao(<variavel>);

Daí, pra preencher a localidade crio outro objeto:

  TLocal localidade = new TLocal();
  localidade.setCodigo(<variavel>);

E por fim, atribuo no objeto documento:

Minha dúvida é sobre a melhor abordagem: montar o objeto documento antes de mandar pro documentoBO, ou passar os valores e montar o objeto dentro dele?

#2

Olá,
Eu usaria a primeira abordagem, pois garante que os dados estarão lá, daí nas regras de negócios só restaria verificar se eles são válidos para continuar o processo.

Att.

#3

A primeira abordagem é melhor, utilizando o POJO ou TO (que é o seu TDocumento) você precisará passar apenas um parâmetro para seu BO, o que facilitará sua manutenção futuramente.

O link abaixo trás mais alguns detalhes sobre a utilizando do TO.

http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html

Abs.

#4

[quote=marcosalex]…
Utilizando Hibernate, tenho um DAO genérico e uma classe TDocumentoBO pras regras de negócios. Minha dúvida é quando vou salvar um documento novo, eu preencho os campos da seguinte forma:
…[/quote]Oi marcosalex,
Permite-me apenas 1 acersão: esse lance de vc “definir” as regras de negócio numa camada Gerenciador (no seu caso XxxBO) denota um programação procedural (feita numa linguagem Orientada a Objetos). Quando o ideal seria vc agrupar (não só) Dados e suas Operações na sua (Classe) Entidade de Negócio. Explico: se vc codifica a Lógica de Negócio em um “BO”, criando Objetos do Modelo (de Domínio) apenas com Atributos e seus Acessors (getters e setters), vc não está usando o princípio “Tell, don’t ask”: o seus Objetos do Modelo não tem nenhuma inteligencia (operações) encapsulada e a sua camada Gerenciador simplesmente é quem altera o estado desses Objetos(algo totalmente procedural, percebe). Me compreende??!

P.S.: esse negócio de começar no nome das Classes c/ ‘T’ era legal no Delphi, aliás é um convenção do Delphi, né?!! Só q isso não cai bem na hora q vc for fazer o mapeamento OO-R, c/ enfase no relacionamento entre as Classes (no qual, IHMO, o ideal é q um Atributo q é do tipo de uma (outra) Classe deve ter exatamente o mesmo nome da Classe, exceto a inicial minúscula.)

#5

Tomando como referência o cenário que foi passado…montaria o objeto através de um construtor na classe recebendo os atributos e com isso encapsulando as regras de montagem e validação se for o caso (1 abordagem).

#6

Eu não entendi muito bem de onde essas informaçoes estáo sendo alimentadas, mas acredito que seja da camada de apresentacão.

Se a sua aplicaçao é pequena e voce nao pretende distribuir sua aplicacao em diversas maquinas, camadas propagando os dados remotamente, balanceamento de carga, clustering e essas coisas, recomendo que voce faca sua camada de apresentaçao acessar diretamente as suas entidades de negocio. Portanto, a camada de negocio deve receber todo o grafo de objetos o que no seu caso seria o Documento e o seu agregado Local

Para projetos onde a escalabilidade em um potente Servidor de Aplicação é crucial deve ser utilizado o padráo Value Objects para transferir os dados entre essas camadas.

Esse conselho de evitar o T na frente dos nomes das classes é bastante construtiva. :smiley:

#7

[quote=FrancoC]…
Para projetos onde a escalabilidade em um potente Servidor de Aplicação é crucial deve ser utilizado o padráo Value Objects para transferir os dados entre essas camadas…[/quote]@FrancoC,
Só 1 Obs.: Antes de a Sun erroneamente usar o termo ‘VO’, Martin Fowler e Eric Evans já tinham catalogado o Pattern ‘Value Object’ como sendo 1 tipo de DomainModel Object: vide Model Objects. Um tempo depois a Sun percebeu o equivoco e de 1s tempos para ka vem corrigindo os termos do seu Catalogo (onde tiver ‘core J2EE Patterns’, leia-se ‘core EJB Patterns’ :hunf: ) nos sites, como indicado pelo caro colega:

[quote=Kerleston Pereira Bom]http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html
[/quote]Observe bem q no corpo dos Textos vc já sempre se vê ‘Transfer Object’, mas nas imagens (q são mais difíceis corrigir) [color=red]infelizmente[/color] ainda vemos ((ressaltando novamente) de forma equivocada VO. :shock:
Conclusão: se vc tiver um gargalo (perda de performance) entre tiers (camadas físicas) diferentes, vc pode contornar esta deficiência (da API EJB) usando o Pattern TO-Transfer Object, ou o DTO-Data Transfer Object.
@marcosalex,
Vc pode transitar seus (Domain)Model Objects entre Camadas Lógicas normalmente -> desde q tenha feito (no Modelo) 1 Encapsulamento irrepreensível (evitando o ‘Anti Pattern’ JavaBean), um ótimo “Hidding of Information” e não ter exposto a estrutura interna de suas Classes (aí vc pode fazer isso sem nenhum peso na consciencia), caso contrário, e/ou tenha algum problema (como LazyLoadingException) vc pode usar o Pattern DO - ‘Data Object’ (algo como XxxDO).

#8