Usando herança para que um POJO suporte Active Record!

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Olá Guj's!

Estive pensando em uma possível arquitetura para usar ActiveRecord, mas quero que as classes que serão utilizadas na view não tenham acesso algum aos métodos de persistencia.

O camada de controle por exemplo seria mais ou menos assim:

As classes Team e TeamAR seriam mais ou menos assim:

Assim, toda injeção de dependência será feita no TeamAR. A classe Team fica simples. Está meio crú esta idéia, mas eu queria saber o que vocês acham. Alguma opinião, melhoria ou críticas? Será que estou viajando na maionese e escrevendo código desnecessário?

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Olá Thiago!

1) Minha humilde opinião: isso aí não é camada de controle pra mim, se estamos falando de MVC como se fossem camadas. Isso aí é regra de negócio.

2) Sugestões: usar Façades, transformar Team em uma interface (não parece muito legal), transformar os métodos de persistência em private (já que seria o próprio objeto que se persistiria), etc etc etc...

3) Eu tentaria criar um Team "puro" e um Team "concreto" com capacidade de persistência, como você tá fazendo, só que onde o Team "ideal" não conhece o Time persistível. Mas como fazer isso?

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Olá Renato,

renato3110 wrote:
1) Minha humilde opinião: isso aí não é camada de controle pra mim, se estamos falando de MVC como se fossem camadas. Isso aí é regra de negócio.

Putz, rsrs. Acho que estou com problemas para definir o que realmente é camada de negócio. Por exemplo, se de um lado tenho um facade da aplicação que sabe criar alunos, e por outro lado o facade internamente chama minha classe aluno que sabe como se persistir, ou seja:

Neste caso, posso considerar as duas situações como classes de negócio? Hoje apenas considero o aluno.save() como método de negócio.

renato3110 wrote:
2) Sugestões: usar Façades, transformar Team em uma interface (não parece muito legal), transformar os métodos de persistência em private (já que seria o próprio objeto que se persistiria), etc etc etc...

3) Eu tentaria criar um Team "puro" e um Team "concreto" com capacidade de persistência, como você tá fazendo, só que onde o Team "ideal" não conhece o Time persistível. Mas como fazer isso?

Talvez usando composição vc pode criar uma classe Team "persistivel" que conhecerá o Team, e não o contrário. Apesar que de certa forma, o que propus, a classe Team não sabe que a classe TeamAR existe.

O que pretendo fazer é algo bem desacoplado. Vou fazer um gráfico meia boca.

O desafio aqui é usar AR. Mas não quero que a view e o controle não conheçam os métodos de persistência do meu modelo.

Outra dúvida que tenho é como injetar as dependências no meu TeamAR sem acessar diretamente o BeanFactory do Spring, por exemplo.

o legal seria fazer mais ou menos assim:

até agora não encontrei nada que me deixe fazer algo mais ou menos assim, mas preciso conferir se o hivemind faz isso.

Valeuz!
Thiago

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Thiago Senna wrote:
Putz, rsrs. Acho que estou com problemas para definir o que realmente é camada de negócio. Por exemplo, se de um lado tenho um facade da aplicação que sabe criar alunos, e por outro lado o facade internamente chama minha classe aluno que sabe como se persistir, ou seja:

facade.criaAluno(aluno); ou aluno.save();

Cara, viajei legal legal

, eu pensei que o createTeam faz parte do próprio Team...

Me parece ser um a parte controladora sim, pois no meu conceito de MVC o "C" é o que "dá vida" ao MV...

O resto leio depois que tenho que vazar... fuuuuui...

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Eu gosto da idéia de que o controle só vai delegar a tarefa para meu façade. O façade por sua vez sabe como lidar com o modelo.

Assim fica fácil migrar de uma aplicação web para swing. Talvez uma sigla MVFC seja mais apropriada.

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

Thiago Senna wrote:Apesar que de certa forma, o que propus, a classe Team não sabe que a classe TeamAR existe.

Verdade, eu tinha viajado...

Thiago Senna wrote:Eu gosto da idéia de que o controle só vai delegar a tarefa para meu façade. O façade por sua vez sabe como lidar com o modelo.

Assim fica fácil migrar de uma aplicação web para swing. Talvez uma sigla MVFC seja mais apropriada.

Pois é, pra isso que se usa Façade né? Não acho que o Façade facilite a migração, mas a separação da lógica central, com ou sem ele.

Quanto ao Spring eu não sabo, não consego

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