Modelos ricos e CRUDs e outras dúvidas

This message was edited 3 times. Last update was at 12/03/2008 08:26:36

Pessoal começo pela seguinte dúvida: em uma arquitetura EE realmente OO (hehe), os modelos de domínios ricos, mas sem lógicas acima do básico Crud, ou seja, os componentes, como por ex: Funcionário, Cliente, Cheques, etc.; quando tratamos de persistência, eles:

salvam seu estado ? Ou recebem uma instância do seu objeto para enviarem para o dao? Em termos especificos, qual das duas opcoes abaixo está correta (ou caso nenhuma esteja, como seria uma correta?):

Forma A: (Acredito ser esta, hehe)

Forma B:

Outra coisa. Tanto nesses mesmos modelos não tão especificos, quanto nos mais (ContaCorrente, Caixa, Estoque) é correto ter todos os Daos dentro do próprio domínio de objeto, já que é ele que faz e corresponde aos seus atos, em outros termos também específicos, isso está correto: (ou como seria a forma correta?)

Este tópico reflete apenas uma dúvida minha de como seria uma implementação sem os famosos DTO/TO/VO e BO.

Eras isso!

Isso depende. Nas formas que você postou, os objetos de negócio conhecem lógica de persistência, ou seja, sabem como se persistirem. Isso é uma implementação de ActiveRecord, e pode ser bom em alguns casos ( que eu não sei dizer quais são exatamente ). Porém, creio que o ideal seria deixar a lógica de persistência em uma camada de infra-estrutura, que ficaria abaixo da camada de negócios. Dessa forma, você retiraria o DAO de suas entidades e daria um jeito de injetá-los usando algum framework de injeção de dependências ( ou Factories ).

This message was edited 1 time. Last update was at 12/03/2008 08:57:23

Como o Tarso disse, sãoe stratégias diferentes e o melhor depende da sua arquitetura. Procure o livro do Fowler sobre padrões de arquitetura.

pcalcado wrote:Procure o livro do Fowler sobre padrões de arquitetura.

Deve ser esse:
http://www.amazon.com/Enterprise-Application-Architecture-Addison-Wesley-Signature/dp/0321127420

Enfim, depende da arquitetura, tá.. mas tipo:

Uma arquitetura para sistemas distribuidos, seria domínio rico.
Já numa outra, onde o fluxo de trasnferência de dados não é relevante, não há problemas em usar a lógica acima das entidades-com-cara-de-banco-de-dados.

eh isso ?

Creio que depende também, dentre outros fatores, do tamanho de sua aplicação, do prazo disponível, do tamanho da equipe... Por exemplo, se o sistema não for distribuído mas tiver um domínio complexo, uma abordagem mais OO pode ser mais eficiente. Mas se for um CRUD básico, não tem pra quê complicar tanto quando um simples Transaction Script poderia resolver.

peerless wrote:E
Uma arquitetura para sistemas distribuidos, seria domínio rico.
Já numa outra, onde o fluxo de trasnferência de dados não é relevante, não há problemas em usar a lógica acima das entidades-com-cara-de-banco-de-dados.

O que você citou acima não são arquiteturas, são características de arquiteturas. Procure o livro do Fowler.

pcalcado wrote:

peerless wrote:E
Uma arquitetura para sistemas distribuidos, seria domínio rico.
Já numa outra, onde o fluxo de trasnferência de dados não é relevante, não há problemas em usar a lógica acima das entidades-com-cara-de-banco-de-dados.

O que você citou acima não são arquiteturas, são características de arquiteturas. Procure o livro do Fowler.

Grr.. tá bom! Solicitei o livro. hehe! até

tnaires wrote:Isso depende. Nas formas que você postou, os objetos de negócio conhecem lógica de persistência, ou seja, sabem como se persistirem. Isso é uma implementação de ActiveRecord, e pode ser bom em alguns casos ( que eu não sei dizer quais são exatamente ). Porém, creio que o ideal seria deixar a lógica de persistência em uma camada de infra-estrutura, que ficaria abaixo da camada de negócios. Dessa forma, você retiraria o DAO de suas entidades e daria um jeito de injetá-los usando algum framework de injeção de dependências ( ou Factories ).

Olhando isso sem a parte de injeção, seria bem como pegar o tal BO e ao invés de frente, jogar para trás dos nossos objetos ricos, certo?

Sim seria... Mas se você tá usando BO dentro de VO, mescle as duas classes em uma só.

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