Matéria da MJ17: Desenvolvendo Sistemas OO com Padroes de Negócios

Num esquema de Camadas empilhadas a Camada de cime depende da interface da Camada de baixo, isso faz com que objetos que façam parte da interface da Camada de Baixo (como objetos de negócio quem entrem e saiam) possam ser utilizados.

Quanto à TOs, por que simplesmente não utilizar os objetos de domínio ao invés de copiar dados entre objetos, manter hierarquias paralelas, criar objetos de dados sem comportamento e todos os outros problemas de TOs?

Se você não quer que a Camada de cima tenha acesso à métodos específicos faça-a manipular uma interface. Exemplo:

Se eu não quero que minha Camada de Apresentação consiga chamar o método depositar (que é um método que muda o estado do Objeto e só deve ser chamado de outras Camadas) basta criar uma interface:

Fazer C/C implementá-la e a Camada de Apresentação lidar apenas com ela. Sem repetiçãod e dados, sem objetos burros.

Note que mesmo esta solução é um tanto drástica demais, eu mesmo nunca vi real necessidade em meus projetos.

O que eu quiz dizer foi:

Em uma consulta, por exemplo:
- Meu Controller recebe uma interface Service a partir de uma fabrica
- Meu Controller chama um método e recebe um objeto de dominio (DTO, que tb é utilizado para espelhar a minha tabela, por exemplo, no hibernate).

Em um caso de criação:
- Meu controler recebe os campso do formulário e cria um DTO populado com tais valores.
- Meu Controller recebe uma interface Service a partir de uma fabrica
- Meu Controller chama um método e passa o objeto de dominio (DTO, que tb é utilizado para espelhar a minha tabela, por exemplo, no hibernate).

O que vc acha disso?

Ainda achei a criação de uma interface melhor do que ter VO´s espalhados pela aplicação.

Mas por exemplo se você não cria esta interface e deixa a camada de apresentação conhecer os objetos de domínio, o que impede de a camada de apresentação fazer uma chamada para um método que não deveria?

Não vejo problemas (até agora não ví) da camada de aplicação ou apresentação conhecer e usar entidades do Domain. É exatamente esse sentimento que gera muitas coisas desnecessárias no projeto (TOS, DTOS) e tendem a levar ao código procedural (já sofri bastante com essas más definições arquiteturais, meu projeto atual está bem procedural e o refactoring disso vai levar mais de um ano, exatamente por essa tentativa dos arquitetos anteriores de isolar o negócio de tudo, pra quê?).

Se existir uma necessidade da interface que o Philip falou, será mais por questões de arquitetura do que por necessidade de negócio. Por exemplo, se um pedido pode ser faturado [pedido.faturar()], não seria a camada que ele se encontra que limitaria a chamada do método. O que limitaria seriam as regras de negócio do próprio pedido.

Isso se aplica quando está executando rotinas que não tem objetos de retorno...

Neste mesmo exemplo, como vc colocaria o retorno da interface para o método getDetalhesCliente(idCliente)?

Rafael Nunes wrote:Ainda achei a criação de uma interface melhor do que ter VO´s espalhados pela aplicação.

Mas por exemplo se você não cria esta interface e deixa a camada de apresentação conhecer os objetos de domínio, o que impede de a camada de apresentação fazer uma chamada para um método que não deveria?

conta.save() ou conta.regraDeNegocio()

Esse ponto que eu ia colocar, nessa forma você vai ter uma interface a mais, porém não vai impedir que haja quebra de encapsulação. E se a proposta for reduzir a complexidade, diminuir uma classe VO e adicionar outra interface, daria no mesmo, não ?

Uma sugestão, seria colocar as classes que compõe a camada de aplicação, no mesmo pacote das classes de domínio. Assim, os métodos que a view poderia acessar marcaria-os como públicos, e os que seriam acessíveis somente pela camada de aplicação marcaria-os como acesso default ou protected.

rodrigoallemand wrote:
- Meu Controller chama um método e recebe um objeto de dominio (DTO,

DTOs não são objetos de domínio, são objetos usados apenas apra transmitir dados entre Camadas Físicas, não tem nada a ver com o Domínio da Aplicação.

rodrigoallemand wrote:
que tb é utilizado para espelhar a minha tabela, por exemplo, no hibernate).

Você não precisa (e nem deveria) usar DTOs com Hibernate. Isso é uma herança de Entity Beans que não faz o menor sentido quando se usa uma ferramenta de ORM para POJOs.

http://www.hibernate.org/hib_docs/online/javapolis2003_presentation/hibernate_javapolis2003.pdf

Rafael Nunes wrote:
Mas por exemplo se você não cria esta interface e deixa a camada de apresentação conhecer os objetos de domínio, o que impede de a camada de apresentação fazer uma chamada para um método que não deveria?

Eu nunca vi necessidade disso mas se você precisa se precaver basta criar a interface.

rodrigoy wrote:
Se existir uma necessidade da interface que o Philip falou, será mais por questões de arquitetura do que por necessidade de negócio.

Eu diria que esta interface em específico seria mais relacionado com a estrutura de desenvolvimento. Imagino que um projeto onde times diferentes desenvolvemas Camadas você queira se rpecaver da outra equipe trapacear nos métodos, mas como disse nunca vi acontecer com tanta importância.

rodrigoallemand wrote:
Neste mesmo exemplo, como vc colocaria o retorno da interface para o método getDetalhesCliente(idCliente)?

Ué, faria um método na interface que retorna um objeto.. não entendi sua dúvida.

Fabrício Cozer Martins wrote:
Esse ponto que eu ia colocar, nessa forma você vai ter uma interface a mais, porém não vai impedir que haja quebra de encapsulação. E se a proposta for reduzir a complexidade, diminuir uma classe VO e adicionar outra interface, daria no mesmo, não ?

Por isso que eu falei que não é comum utilizar esta técnica e as diferenças mais básicas são que você não rpecisa manter duas hierarquias de lasses nem ficar copiando dados para objetos de transferência.

Rafael Nunes wrote:Uma sugestão, seria colocar as classes que compõe a camada de aplicação, no mesmo pacote das classes de domínio. Assim, os métodos que a view poderia acessar marcaria-os como públicos, e os que seriam acessíveis somente pela camada de aplicação marcaria-os como acesso default ou protected.

Acho que isso limitaria demais a escolha de hierarquia de pacotes, mais do que estou disposto, mas é uma saída...

Phillip, vamos trocar mais experiências aí.

No seu artigo você comentou a respeito de Domain Model vs Transaction Scripts, algo do tipo "nem todo sistema exige a complexidade de um domain model... blá blá blá...".

Bom, atualmente com mecanismos ORM um mapeamento fica mais simples. Isto é, é mais fácil atualmente ter uma estrutura OO persistente e convenhamos 90% dos projetos são aplicações de banco de dados. Se você tem o seu banco espelhado em objetos, potencialmente, já seria um Domain Model. Desse modo, não seria sempre mais fácil ter um Domain Model do que trabalhar com TranScripts?

Digo isso porque não acredito que é a complexidade que vai ditar o uso ou não de um domain model. Acho que para aplicações de banco de dados o Domain Model vai sempre existir, com doses maiores ou menores de TranScripts dependendo do caso.

Abraços!

rodrigoy wrote:Se você tem o seu banco espelhado em objetos, potencialmente, já seria um Domain Model.

Acredito que não, pois o Domain Model seria formado também por classes de negócios, que realizam processamento de use-cases e que não são obrigatoriamente espelhadas em tabelas.

Rafael Nunes wrote:

rodrigoy wrote:Se você tem o seu banco espelhado em objetos, potencialmente, já seria um Domain Model.

Acredito que não, pois o Domain Model seria formado também por classes de negócios, que realizam processamento de use-cases e que não são obrigatoriamente espelhadas em tabelas.

Isso não responde a minha pergunta. Que situação você teria Entities e Transaction Scripts que não justificam um Domain Model?

rodrigoy wrote:

Isso não responde a minha pergunta. Que situação você teria Entities e Transaction Scripts que não justificam um Domain Model?

Transaction Scripts e Entities são uteis quando você não tem uma aplicação rica em comportamento, com predominancia de crud por exemplo, e a maioria dos casos de uso são apenas manipulação do banco de dados sem muita lógica de negocio (sumariza todos registros X, insere na tabela Y e atualiza na Z).

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