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:
[code]public Team createTeam(Team team) {
TeamAr teamAr = TeamAr.valueOf(team);
teamAr.save();
return teamAr;
}[/code]
As classes Team e TeamAR seriam mais ou menos assim:
[code]public class Team {
private Long id;
private String name;
private String trainer;
private Date foundationDate;
private Set<Player> players = new HashSet<Player>();
/* construtores */
/* getters and setters */
/* equals, hashcode and toString */
}[/code]
[code]
public abstract class TeamAR extends Team implements ActiveRecord {
private TeamRepository teamRepository;
/* persistence methods */
public void save() {
repository.save(this);
}
public static Set<Team> listAll() {
return teamRepository.listAll();
}
public static Set<Team> listTeamsByChampionship(Championship championship) {
return teamRepository.listTeamsByChampionship(championship);
}
/* fabrica de objeto AR */
public static TeamAR valueOf(Team team) {
// aqui converto um objeto team em um objeto AR
return teamAr;
}
}[/code]
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?
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.
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…
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?
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();
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.
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.
View ----------> Controle ----------> Facade ---------> teamAr.save()
Team Team TeamAR
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:
TeamAR teamAr = new TeamAR();
applicationContext.register(teamAr);
ao invés de
TeamAR teamAR = BeanFactory.getBean(TeamAR.class);
até agora não encontrei nada que me deixe fazer algo mais ou menos assim, mas preciso conferir se o hivemind faz isso.
