acdesouza:
sergiotaborda:
ignacio83:
public void saveAluno( Aluno a )
{
a.save(); //Perfeito, pra mim faz sentido
}
Faz sentido. É um padrão de projeto chamado ActiveRecord.
Agora tente implementar isso num sistema complexo…
Não entendi o problema de implementar isso em um “sistema complexo”.
Se vc não entendeu não tem problema, é porque não passou por isso.
Na teoria o ActiveRecord (atenção à palavra Record) é um objeto de dados simples que se auto-persiste.
Esse padrão é explicitamente definido para objetos simples.
Esse padrão é explicitamente definido para objetos simples.
Num sistema complexo, por definição, os objetos de dados não são simples. E portanto, o ActiveRecord está condenado a ser um empecilho em vez de uma ajuda.
A implementação padrão de um ActiveRecord é o mapeamento direto dos campos para uma tabela usando JDBC puro. Afinal é super simples fazer isto quando os campos são fixos. Se os campos mudam, a logica jdbc muda junto porque está tudo no mesmo arquivo. Mas e a transação ?
Se fizer a.save();b.save();c.save(); em sequencia o objeto garante proprieades ACID para o conjunto das 3?
Não, ele garante para cada uma em separado. Bom ai vc resolve encapsulando as 3 num método auxiliar onde vc controla a transação. Mas pera ai, o objetivo de ActiveRecord é não precisar desse tipo de método. Ups , agora ficou complexo.
public void saveAll (ActiveRecord[] all){
Transaction t = ...
t.begin();
for (ActiveRecord a : all){
a.save();
}
t.commit()
}
O codigo save() tem que estar consicente de que existe uma transação global acontecendo. Lá se vai o JDBC puro. A conexão não pode mais ser aberta no método save() , tem que usar algum DataSource. Bom, mas ai eu acabei de amarrar meu ActiveRecord muito-simples-à-primeira-vista com um mecanismo de controle de transação e um de lookup de connections. Qual é a vantagem do save() estar definido no ActiveRecord neste momento ? Bom, é lá que defino o statement de save que depende dos campos.
Convenhamos que hoje em dia isso não é uma boa já que esse statemente pode (e deve) ser criado sem intervenção do programado da classe.
Vejamos agora por outro lado. O ActiveRecord é um objeto que se auto-persiste. Mas qual é a responsabildiade principal dele ? Bom, é um agrupador de dados apenas. Será que um agrupador de dados precisa saber como se persistir ? Separação de Responsabilidade: coloque essa responsavilidade noutra classe.
Como muita gente vem do tempo do Delphi e da filosofia microsoft em que apenas existe a tela, o banco e uma ligação promiscua entre as duas. A diferença entre isso e java é que nessas plataformas os padrões de projeto já foram escolhidos e implementados. A flexibilidade é pouca e a implementação é de “confiança”, logo não ha porque inventar camadas no meio. Em java é quase que obrigatório inventar essas camadas. Logo, activeRecord , que é um padrão muito usado em VB , Delphi , etc… em java é quase um anti-pattern.
como disse no inicio: Esse padrão é explicitamente definido para objetos simples.
Vc pode usar tb em java se os seu objetos e o seu sistema são simples.
Os seus sistemas são simples ? 
