Modelos ricos e CRUDs e outras dúvidas

Programação Arquitetura
#1

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)

[code]class Funcionario {
save() {
daoFuncionario.salvar(this);
}

}[/code]

Forma B:

[code]class Funcionario {
save(Funcionario funcionario) {
daoFuncionario.salvar(funcionario);
}

}[/code]

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?)

[code]
class ContaCorrente {
private ContasDao daoContas; //anyway
private CCDao daoCC; //ou IoC
private HistoricoDao daoHistorico = new …;

//estado

//comportamentos
transferir(Conta destino, Double valor) {
beginTransaction();
daoContas.verificaTalCoisa(destino);
daoCC.efetuaTransferencia(destino, valor);
daoHistorico.cadatraHistoricoBla(valor);
commit();
throws rollback();
}
}[/code]

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! :slight_smile:

#2

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 ).

#3

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.

#4

Deve ser esse:

#5

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 ?

#6

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.

#7

[quote=peerless]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.
[/quote]

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

#8

[quote=pcalcado][quote=peerless]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.
[/quote]

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

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

#9

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?

class ContaCorrente { setContaDestino getContaDestino setValor getValor .. void transferir() { contaMeuBOdeMentirinha.transferir(this); } }

#10

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

#11