Entity acessa repositório diretamente?

Assuntos Gerais
#1

Estou tentando refatorar algumas classes que tenho aqui de uns projetos pessoais…e estou com algumas dúvidas…

As chamadas aos repositórios para operações CRUD, devem ser feitas diretamente das entidades, através de services ou diretamente das controladoras?

Entidades:

public class Teste {
    private TesteRepositorio repositorio;

    public void save() {
        respositorio.salvar();
    }

Services:

public class TesteService {
    private TesteRepositorio repositorio;

    public void save(Teste teste) {
        respositorio.salvar(teste);
    }

Controller:

@Post
	@Path("/expenseType")
	public void save(ExpenseType expenseType) throws GenericInitializeException {
		this.expenseTypeRepository.add(expenseType);
		
		this.result.redirectTo(this).form();
	}

Valeu!

#2

ninguém?

#3

Eu particularmente não gosto de misturar as coisas. Para mim entidade é um “saco de propriedades” e apenas isso. Quem acessa meus repositórios são minhas classes de negócio, mas nunca uma entidade.

#4

Frango, existe uma divisão a respeito disso. Há quem diga que a classe deve saber se persistir e outras que isso deve ser delegador para outras camadas.

Particularmente, nos projetos que participei, isso sempre era feito numa camada de serviço. Essa camada era que chamava o repositório, garantia transação, etc

Ah, não sei se todo mundo aqui do fórum faz isso, mas eu costumo procurar perguntas com 0 respostas para responder. A sua, eu olhei por mero acaso. Então, quando você responde em cima da sua própria resposta, diminui as chances de alguém olhar seu tópico pra responder.

#5

desde ontem não tinha respostas…mas valeu ai a ajuda…

então fico meio na duvida tb…

antes eu trabalhava com VO BO DAO…tava tentando mudar agora mas estou meio confuso de onde colocar as coisas…

Se eu colocar meu acesso ao repositório em uma service…eu não estaria fazendo a msm coisa que com VO BO DAO só que com nomes diferentes?

#6

DAO não é um repositório, e vice-versa. Eu particularmente não uso mais DAO, já que JPA deixa o DAO praticamente desnecessária. Há muitos posts do Sérgio Taborda no subfórum “Arquitetura de Sistemas”, inclusive há um que você pode gostar de ver: http://guj.com.br/posts/list/198186.java

Sobre usar VO, BO… não vejo um problema nisso. Se alguém te falou que isso é ruim, essa pessoa não sabia o que falava. Um Session Bean, muito usado e inclusive está muito bom no EJB3 é um BO. O próprio Spring usa o mesmo conceito dos BOs quando você anota uma classe como @Service.

Quanto aos nomes, não é o nome que define o que um objeto é, mas sim o que ele faz.

#7

DAO não é um repositório, e vice-versa. Eu particularmente não uso mais DAO, já que JPA deixa o DAO praticamente desnecessária. Há muitos posts do Sérgio Taborda no subfórum “Arquitetura de Sistemas”, inclusive há um que você pode gostar de ver: http://guj.com.br/posts/list/198186.java

Sobre usar VO, BO… não vejo um problema nisso. Se alguém te falou que isso é ruim, essa pessoa não sabia o que falava. Um Session Bean, muito usado e inclusive está muito bom no EJB3 é um BO. O próprio Spring usa o mesmo conceito dos BOs quando você anota uma classe como @Service.

Quanto aos nomes, não é o nome que define o que um objeto é, mas sim o que ele faz.[/quote]

Nao é bem assim, garcia, a nao ser que voce esteja usando o nome VO, BO para outra coisa. Mas quando se fala em VO BO é uma classe que carrega as propriedades e outra que executa as operacoes sobre estas propriedades. Se é disso que voce está falando isso é sim uma coisa ruim, pois fere um principio basico de orientacao a objeto, que é o encapsulamento. Qualquer classe externa poderá operar sobre os dados do seu VO, não somente o seu BO e isso é, definitivamente, ruim.

Nao se deve confundir os services do DDD com BO VO, eles sao bem diferentes. Os services sao usados normalmente quando é necessario interagir com mais de uma entidade numa mesma transacao, o que ele faz é apenas invocar os métodos das entidades, mas é nos metodos dessas entidades que estao as regras de como agir sobre sua propriedade.

#8

DAO não é um repositório, e vice-versa. Eu particularmente não uso mais DAO, já que JPA deixa o DAO praticamente desnecessária. Há muitos posts do Sérgio Taborda no subfórum “Arquitetura de Sistemas”, inclusive há um que você pode gostar de ver: http://guj.com.br/posts/list/198186.java

Sobre usar VO, BO… não vejo um problema nisso. Se alguém te falou que isso é ruim, essa pessoa não sabia o que falava. Um Session Bean, muito usado e inclusive está muito bom no EJB3 é um BO. O próprio Spring usa o mesmo conceito dos BOs quando você anota uma classe como @Service.

Quanto aos nomes, não é o nome que define o que um objeto é, mas sim o que ele faz.[/quote]

Nao é bem assim, garcia, a nao ser que voce esteja usando o nome VO, BO para outra coisa. Mas quando se fala em VO BO é uma classe que carrega as propriedades e outra que executa as operacoes sobre estas propriedades. Se é disso que voce está falando isso é sim uma coisa ruim, pois fere um principio basico de orientacao a objeto, que é o encapsulamento. Qualquer classe externa poderá operar sobre os dados do seu VO, não somente o seu BO e isso é, definitivamente, ruim.

Nao se deve confundir os services do DDD com BO VO, eles sao bem diferentes. Os services sao usados normalmente quando é necessario interagir com mais de uma entidade numa mesma transacao, o que ele faz é apenas invocar os métodos das entidades, mas é nos metodos dessas entidades que estao as regras de como agir sobre sua propriedade.[/quote]

Exatamente. Mas a minha dúvida é, os métodos CRUD devem existir dentro do “VO” ou somente no service? Se eles devem ficar no “VO”, deve haver uma service que delega os CRUD para o “VO”?

Valeu

#9

[quote=Frango]

Exatamente. Mas a minha dúvida é, os métodos CRUD devem existir dentro do “VO” ou somente no service? Se eles devem ficar no “VO”, deve haver uma service que delega os CRUD para o “VO”?

Valeu[/quote]

Como disse o mtakeda, existe uma divisao a respeito disso. Ha quem goste de usar nas proprias entidades, ha quem goste de usar os services pra isso. Em java eu prefiro usar os services para deixar a interface da entidade somente com metodos relacionados ao negocio e nada de infraestrutura.

Em frameworks como rails e grails a propria classe é responsavel pela persistencia, mas mesmo assim mantem a interface limpa, porque o dinamismo das linguagens permite isso.

Entao dizer que esse ou aquele é correto depende muito, em java eu prefiro usar os services pra acessar os repositorios, mantendo as entidades sem qualquer referencia a eles.

#10

Mas um VO nada mais é que um “saco de propriedades” que refletem o que tem nas tabelas, ou seja, uma entidade do Hibernate não deixa de ser um VO. No caso do BO, um Session Bean não deixa de ser um BO, afinal, ele que cuida das suas classes de negócio.

Tirando esses nomes feios de VO e BO, não vejo o porque de ser ruim. Ou estamos falando de outra coisa?

#11

Mas um VO nada mais é que um “saco de propriedades” que refletem o que tem nas tabelas, ou seja, uma entidade do Hibernate não deixa de ser um VO. No caso do BO, um Session Bean não deixa de ser um BO, afinal, ele que cuida das suas classes de negócio.

Tirando esses nomes feios de VO e BO, não vejo o porque de ser ruim. Ou estamos falando de outra coisa?[/quote]

Acho que você está confundindo um pouco…

O VO e BO ao qual me refiro é separar as propriedades de uma Entidade no VO e seu comportamento no BO. É isto que eles dizem que não é bom e está errado.

O Session Bean que você diz deve coordenar as chamadas aos métodos da Entidade e não conter toda a lógica dela… Afinal se você coloca apenas as propriedades(atributos) na entidade e toda sua lógica no session bean você está criando uma grande dependência e ferindo o principio de OO do objeto ser o conjunto de propriedades e comportamentos.

A dúvida que eu tinha não era referênte a usar ou não o BO, porque ja estou convencido de que não é correto. Mas a dúvida seria da onde acessar meus repositórios…direto das entidades ou através de services…

#12

[quote=garcia-jj]

Mas um VO nada mais é que um “saco de propriedades” que refletem o que tem nas tabelas, ou seja, uma entidade do Hibernate não deixa de ser um VO. No caso do BO, um Session Bean não deixa de ser um BO, afinal, ele que cuida das suas classes de negócio.

Tirando esses nomes feios de VO e BO, não vejo o porque de ser ruim. Ou estamos falando de outra coisa?[/quote]

Sim, VO nada mais eh do que um saco de propriedades e por isso mesmo ele nao eh indicado, porque eu teria uma classe para as propriedades e outra para os metodos que agem sobre ela, se eu posso ter os dois no mesmo lugar e proteger as prorieadades das ações de programadores desavisados (e que muitas vezes somos nos mesmos)?

Imagine uma situacao em que voce tenha uma entidade Estoque, um metodo setSaldo(10) nao faz sentido para esta entidade e é um risco para a integridade do sistema, pois num service voce pode fazer todo o tratamento corretamente que nao vai ter problemas, mas nada impede em outro momento de voce simplesmente chamar o método sem validacao alguma. Ja se voce fizer um diminuirDoEstoque(5), este metodo mesmo fará as verificacoes necessarias e informar o erro. O seu service (ou session bean) vai chamar o metodo diminuirDoEstoque, mas nunca vai acessar diretamente o atributo saldo, pois nao haverá num setSaldo.

#13

[quote=YvGa]Em frameworks como rails e grails a propria classe é responsavel pela persistencia, mas mesmo assim mantem a interface limpa, porque o dinamismo das linguagens permite isso.

Entao dizer que esse ou aquele é correto depende muito, em java eu prefiro usar os services pra acessar os repositorios, mantendo as entidades sem qualquer referencia a eles.[/quote]
Eu também. Esse padrão aí que o Rails usa se não me engano é chamado de ActiveRecord. Dotnet também tem algo parecido, mas não conheço a fundo pra dar certeza. O ‘concorrente’ dele é o Data Mapper.

Tentei implementar o AR num projeto, mas não gostei. Cheguei a conclusão de que é natural da linguagem Java não ‘facilitar’ isso (esso não ficou muito boa). O código ficou meio ruim de refatorar, as coisas ficaram meio fora do lugar. Então pra Java eu ainda prefiro aquela coisa mais separada (DataMapper): as classes de ‘serviço’ mantém uma referência pras entidades (ou recebem, delegam pra outras classes de ‘serviços’ e coisa do tipo). Só acho que a entidade não deve ser aquele ‘saco de coisas’. Algumas funções devem ir dentro dessa classe, como validações referentes àquela entidade.

Uma leitura interessante é o livro de DDD do Eric Evans. Eu vi um tópico com uma discussão MUITO boa sobre isso… Acho que é esse.

Editado:
Encontrei mais dois links interessantes:
http://www.guj.com.br/posts/list/130463.java (acho que eu aprendi sobre AR e DM com o Emerson Macedo :D)
http://www.guj.com.br/posts/list/30/129676.java

#14