Eu achei bem interessante uma arquitetura que implementa DDD utilizando-se o padrão AR para aplicações de pequeno porto EM JAVA. Quais as desvantagens ? Pq vc não usaria ?
Olá
Qual? Tem link?
[]s
Luca
[quote=Luca]Olá
Qual? Tem link?
[]s
Luca[/quote]
Em tese foi uma que fiz.
Ficou bem legal. Tipo, por ex:
[code]
Pessoa implements PessoaComportamento {
public Pessoa(Repository repository) { … }
//gets
//sets
void insert {
repository.save(this);
}
}[/code]
A pergunta melhor seria: por que você usaria, sendo que existe um ORM interessante como Hibernate que usa outros padrões que te dão mais flexibilidade? Implementar AR no braço? Sinceramente não vejo vantagem.
Sim, estou usando o padrão, apenas. Com DDD, consigo persistir os dados com base em repositorios, que abstraem qual modelo de persistência eu estaria usando.
Eu queria ver tambem…
bom eu uso AR com Java quando é interessante, qual o problema?
Estamos falando disso (http://martinfowler.com/eaaCatalog/activeRecord.html) ne?
[quote=ddduran]Eu queria ver tambem…
bom eu uso AR com Java quando é interessante, qual o problema?
Estamos falando disso (http://martinfowler.com/eaaCatalog/activeRecord.html) ne?[/quote]
Isso, perfeito!
[quote=Martin Fowler]
“An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.”[/quote]
Tem essa implementacao
http://www.javalobby.org/articles/activeobjects/
https://activeobjects.dev.java.net/
Acredito que um pouco é gosto/opinião mesmo…
Pois em um cenário hipotético a seguir :
Tenho um atributo da classe Pessoa, que é o cpf, onde ele também é uma classe, pois tenho algum tipo de comportamento específico lá, e preciso fazer uma busca de pessoas com cpf iniciando em 268. Essa busca estará implementada no repositório do CPF certo ? Então dentro do objeto pessoa terei uma referência à um segundo repositorio… ou a busca estará no repositório da pessoa, que irá referenciar o repositório do CPF, de um jeito ou de outro aumenta o acoplamento.
E tem outro cenário também :
Imagine que existam várias buscas específicas, com vários parâmetros específicos(listPessoasAtivas,listPessoasDoDeptoX,listPessoasAposentadas, etc…), essas buscas serão vários métodos listXXX() na classe Pessoa, ou irei acessar o repositório direto utilizando esses métodos, então fico com dois lugares para recuperar dados de pessoa.
Nas duas situações não acho muito legal, dá margem à diversas interpretações de como fazer, isso em uma equipe grande vira um pandemônio ! 
Já vi várias abordagens para esses cenários, uns melhores outros piores, eu particularmente não achei algum que eu gostei.
Mas é somente minha opinião, pq sei de muita gente que odeia ter aquele padrãozinho XXXService para uma coisa, ou YYYService para outra e os dados em objetos burros sendo transportados por um lado e outro…
[]´s
Num repositório de CPFs você deveria procurar CPFs, não pessoas 
Com certeza !!
Acho que não consegui um exemplo muito bom devido à pressa…
Mas se por acaso eu precise pesquisar pessoas baseadas em um CPF(já que ele é um atributo, como nome, altura, peso, etc…), mesmo que eu ja tenha ele inteiro, então eu passaria um objeto da CPF como parâmetro certo ?
Aí acho que caíriamos no mesmo problema não é ?
[quote=MrDataFlex][quote=Luca]Olá
Qual? Tem link?
[]s
Luca[/quote]
Em tese foi uma que fiz.
Ficou bem legal. Tipo, por ex:
[code]
Pessoa implements PessoaComportamento {
public Pessoa(Repository repository) { … }
//gets
//sets
void insert {
repository.save(this);
}
}[/code][/quote]
Se vc ja tem um repositório pronto para receber pessoas como no código acima (que seria um repositório de pessoas), pq aprisiona-lo dentro de uma entidade? No seu caso vc tem uma redundância, um objeto no domínio responsável por armazenar pessoas (repositorio) e um método em um Entity que faz a mesma coisa, onde um apenas chama o outro (isso é, se de fato o repository no código acima é o pattern Repository).
Usar ActiveRecord em Java pode até ser “interessante” em algum tipo de implementação (talvez utilizando instrumentação ou aspecto), mas não apenas dando uma volta ao mundo para chegar de novo no repositório.
Exatamente a minha duvida enquanto eu ia lendo os posts. Ai eu pergunto: segundo a definicao do AR, basta que ele tenha um metodos de acesso, mesmo que por tras usem os repositorios, pra que sejam AR? Pelo que eu havia entendido do padrao é que o proprio objeto continha as regras de persistencia. Estou errado?
Na verdade o padrão diz que o objeto tem que saber como “se persistir” mas acho que colocar regras de mapeamento em banco, ou detalhes maiores de persistência dentro de um objeto de negócio já começa a causar aqueles nossos queridos patterns BFG(Big Fucking Class) 
Essa separação em repositórios é para ter as vantagens OO mesmo…
A vantagem do AR é não ter que ficar instânciando outras classes para persistir, vc só conhece seu objeto de negócio, tudo fica ali na mão onde estiver a classe de negócio vc tem as operações necessárias.
Lembrando que tb não sou um grande fã de AR, mas com certeza é interessante separar essas responsabilidades sim…
[quote=reinaldob]Mas se por acaso eu precise pesquisar pessoas baseadas em um CPF(já que ele é um atributo, como nome, altura, peso, etc…), mesmo que eu ja tenha ele inteiro, então eu passaria um objeto da CPF como parâmetro certo ?
Aí acho que caíriamos no mesmo problema não é ?[/quote]
Não, não há problema nenhum em se passar um CPF como parâmetro. A Pessoa é o aggregate, e esse aggregate tem um CPF, então nada mais natural do que usar o CPF para filtar as pessoas em um repositório ou activerecord de Pessoas. A questão é que pra mim não interssa ter o CPF, o que interesssa é ter a pessoa com aquele CPF.
Acho que eu entendi
Pensando na implementação…
O Repositorio de pessoas, necessáriamente conheceria a classe CPF, correto ?
A única coisa que não gosto de AR é usar métodos estáticos pra fazer consultas. É muito ruim pra fazer testes. Acabo criando um repositório pras consultas e criação dos objetos.
[]'s
Rodrigo Auler
[quote=reinaldob]Acho que eu entendi
Pensando na implementação…
O Repositorio de pessoas, necessáriamente conheceria a classe CPF, correto ?[/quote]
Correto.
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?
Concordo com vc !
Tb acho estranho esse lance “uma pessoa se auto salva a si mesma”… 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).
Isso realmente dá muitas interpretações !
E viva a diversidade, pq senão estavamos todos programando em Assembly !! 