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

5 respostas
Thiago_Senna

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:

public Team createTeam(Team team) {
	TeamAr teamAr = TeamAr.valueOf(team);
	
	teamAr.save();

	return teamAr;
}

As classes Team e TeamAR seriam mais ou menos assim:

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 */

	
}
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;
	}

}

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?

5 Respostas

renatosilva

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?

Thiago_Senna

Olá Renato,

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.

Valeuz!
Thiago

renatosilva

Cara, viajei legal legal :oops:, 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…

Thiago_Senna

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. :mrgreen:

renatosilva

Verdade, eu tinha viajado…

Thiago Senna:
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. :mrgreen:

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

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

Criado 31 de março de 2006
Ultima resposta 3 de abr. de 2006
Respostas 5
Participantes 2