PQ vc NÃO usaria Active Record em JAVA?

Programação Arquitetura
#21

[quote=rodrigoallemand]Não vejo muita diferença disso aqui…

[code]public class Pessoa{
RepositorioPessoa repositorio;
//get/set

public void insert(){
	reporitorio.insert(this);
}

public Set dependentes(){
	repositorio.dependentesDe(this);
}

}

public class RepositorioPessoa{
public void Insert(Pessoa pessoa){
//Insert
}
public Set dependentes(){
//Get dependentes
}
}[/code]
… para isso aqui…

[code]@Entity
public class Pessoa{
@ManyToOne
public Set dependentes;
//Get/Set
}

public class RepositorioPessoa{

public void Insert(Pessoa pessoa){
	//Insert
}

}[/code]

Alias, vejo sim!! No código abaixo eu escrevo bem menos… e eu não gosto de pensar que “uma pessoa se auto salva a si mesma”…
Parece um negocio sem controle, onde qq coisa se salva, etc… :lol: é brincadeira, ok?[/quote]

Por isso a questão aqui é: ACTIVE RECORD! :slight_smile:

#22

Se tivesse um ActiveRecord igualzinho ao do Rails pra Java eu usaria sem pensar 2 vezes 8)

#23

[quote=reinaldob]Concordo com vc ! :slight_smile:

Todo o caso é que se formos levar OO ao pé da letra, isso seria o correto, pq todos os comportamentos possíveis para a Pessoa estariam dentro da própria classe(mesmo que implementada através de composição).

[/quote]

Eu discordo, segundo OO, isso fere a regra de responsabilidade da classe, que é alguma coisa dentro das regras de negocio. A partir do momento que nela esta contido o codigo de persistencia ela está fazendo mais coisas do que deveria.

Agora, na pratica eu ja nao sei, nunca usei AR e talvez por isso nao vejo suas vantagens.

#24

Ainda assim não vejo muita vantagem em relação a usar o Hibernate do jeito que ele é hoje, a não ser se tua aplicação for simples ao ridículo.

Sei lá, acho que eu é que não gosto muito desse troço :smiley:

#25

A pergunta é sobre Active Record + Java ou Active Record + Domain Driven Design +Java?

A primeira -apesar de dificultada pela verbosidade- eu uso. Acabo de entregar um projeto onde um objeto de negócios era o melhor lugar para a comunicação com o Hibernate. É claro que isso é uma peculiariedade do domínio em questão, o mesmo projeto tinha todos os outros objetos persistidos via DataMapper/DAO.

A segunda, em teoria, é possível mas você teria que fazer do seu objeto um Repositório dele mesmo. Eu nunca vi necessidade para isso utilizando Domain Driven Design.

#26

[quote=YvGa][quote=reinaldob]Concordo com vc ! :slight_smile:

Todo o caso é que se formos levar OO ao pé da letra, isso seria o correto, pq todos os comportamentos possíveis para a Pessoa estariam dentro da própria classe(mesmo que implementada através de composição).

[/quote]

Eu discordo, segundo OO, isso fere a regra de responsabilidade da classe, que é alguma coisa dentro das regras de negocio. A partir do momento que nela esta contido o codigo de persistencia ela está fazendo mais coisas do que deveria.

Agora, na pratica eu ja nao sei, nunca usei AR e talvez por isso nao vejo suas vantagens.[/quote]

Isso mesmo. Diminui a coesão da classe e ainda aumenta seu acoplamento com entidades alheias ao seu domínio.

#27

[quote=YvGa][quote=reinaldob]Concordo com vc ! :slight_smile:

Todo o caso é que se formos levar OO ao pé da letra, isso seria o correto, pq todos os comportamentos possíveis para a Pessoa estariam dentro da própria classe(mesmo que implementada através de composição).

[/quote]

Eu discordo, segundo OO, isso fere a regra de responsabilidade da classe, que é alguma coisa dentro das regras de negocio. A partir do momento que nela esta contido o codigo de persistencia ela está fazendo mais coisas do que deveria.

Agora, na pratica eu ja nao sei, nunca usei AR e talvez por isso nao vejo suas vantagens.[/quote]

Sim. Uma coisa a ser lembradaé que Orientação a Objetos em si não conhece persistência. Persistência é uma limitação técnica, o que fazemos com DataMappers, Camadas, ARs e amigos é tentar minimizar o impacto desta.

#28

Tem como dizer o que foi pra eu tentar visualizar? Nunca me vi numa situação dessas de usar uma mistura das 2 coisas no mesmo projeto.

i++

#29

Phillip, apesar de nunca ter vivido situação parecida, será que é uma peculiaridade do domínio ou a maneira como ocorre a interação entre a camada de domínio e a apresentação?

[editado]

Outra pergunta: como vocês lidaram com os estados (detached, managed). Era sempre merge?

[/editado]

#30