Dúvida de projeto

Programação Arquitetura
#1

Pessoa, eu estou começando agora (uns meses) e tenho uma dúvida de projeto.

Eu tinha feito:

[code]public class Conta implements Serializable {
private Collection transacoes = new ArrayList();

…

public Transacao criarTransacao() {
Transacao t = new Transacao(this);
transacoes.add(t);
return t;
}

…

}[/code]

e

[code]public class Transacao implements Serialazable {
private Conta conta = null;

…

public Transacao(Conta c) {
setConta©;
}

public void setConta(Conta c) {
if (conta != null) {
conta.getTransacoes().remove(this);
}
conta = c;
c.getTransacoes().add(this);
}

…

}[/code]

(Desculpe-me se errei alguma coisa. O código mesmo está em casa e talvez eu tenha errado algo aqui, mas a lógica acho que deu pra pegar, né?)

Mas eu estava lendo que isso é errado. Que eu implementei regra de negócio no modelo. Alguém poderia me dizer uma melhor forma de se fazer isso nestas situações em que um objeto é composto por outro? Como eu poderia fazer? Acho que não posso falar que é um Data Access Object porque ele tem lógicas, né?

Uma outra situação parecida seria no caso de transferência, que sempre que eu faço algo num objeto (débito ou crédito) implica na ação inversa em outro?

Grato.

#2

colega…

é igual as camadas de um bolo…

a de baixo da suporte para a de cima…

entao…

dentro da classe de apresentação vc chama a classe de controlador
e dentro da classe de controlador vc chama o de modelo… nao tem segredo…

vc tem que ficar atento com relação as definições do que vai dentro de cada camada!

aqui no guj esse é uns dos tópicos mais comentados! valeu a pena uma busca sobre o padrão MVC…

Não da pra te falar ao certo se está errado ou certo! Tudo depende do que vc quer fazer e de quais os requisitos vc tem.

:stuck_out_tongue:

#3

Olá

Implementar regra de negócio no modelo é errado? Onde você leu isso? E vai colocar as regras de negócio aonde, se não for no modelo do domínio de sua aplicação?

Não, você não pode falar que é um DAO. Mas não é porque “ele tem lógicas”, e sim, porque um DAO é uma implementação responsável por cuidar da persistência de suas entidades. Ou seja, ele só conhece a lógica necessária para gravar os seus objetos em algum meio físico ( banco de dados, XML ou mesmo em memória ), e não a lógica de negócio em si.

#4

camada de modelo = DAO´s + entidades + logica de negocios e outras combinações possiveis entre esses três.

:stuck_out_tongue:

#5

Então acho que me confundi.
Mas se eu colocar aquela regra fora de Transacao ou Conta eu não estaria permitindo que alguém fizesse uma transação sem conta, por exemplo? Ou um objeto Transacao que tem link pra conta mas a coleção de transações não tem esta transação.
Se eu for tirar dali eu teria que obrigar a pessoa a criar as coisas por onde vai ficar a regra, né?

#6

se for seguir a OO a risca, entao vc deve colocar a logica de negocio junto as entidades! uma classe deve ter estado e comportamento. Então coloque a logica de negocios junto as entidades e separa o acesso a dados e talls… nos DAO´s

obs: Construa o seu estilo de programação, é muito complicado entender as melhores soluções sem antes praticar as piores.
depois que seu código estiver um pouco mais funcional, voce vai começar a perceber que ele pode ser refatorado e ai sim vc começa a visualizar com mais facilidade esses detalhes de arquitetura e relacionamento.

:stuck_out_tongue:

#7