Repository x Spring x Hibernate

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Lezinho wrote:

cmoscoso wrote:

Lezinho wrote:Se você utiliza Seam por exemplo, você pode invocar diretamente do front-end (Páginas, Facelet, GWT ...)suas Entities, Repositories, Services, controlar o fluxo de páginas via jPDL.

Pode claro, mas IMO, não deve!

ps: pode me chamar de purista.

E pq não devo?
O que eu perco invocando um repository em uma página, como:

<h:dataTable value=#{clienteRepositorio.clientesComDivida} ...>

Caso os requisitos do cliente do repositorio sejam alterados para que ele acesse o dominio remotamente você terá um trabalho maior para evitar que seus objetos sejam distribuidos.

É necessário cautela caso você nao tenha certeza se isso pode acontecer.

This message was edited 1 time. Last update was at 13/03/2008 09:43:49

cmoscoso wrote:
Mas quem implementa o dominio sabe diferenciar o domain service da service layer.

Mesmo se o Domain service é a própria fachada remota para um cliente (dispensando a service Layer neste caso , já que um simples metadado resolve tudo)?

Bom, a tecnologia foi simplificada que muitas vezes um próprio elemento do Domínio (como um service), pode assumir um outro papel sem afetar o próprio modelo (só lamento que as anotações em java são tão dependentes), é isso.

cmoscoso wrote:Caso os requisitos do cliente do repositorio sejam alterados para que ele acesse o dominio remotamente você terá um trabalho maior para evitar que seus objetos sejam distribuidos.

É necessário cautela caso você nao tenha certeza se isso pode acontecer.

Eu posso distribuir diretamente o repositório, ele é uma interface. Em caso mais extremos, o método pode ser refatorado caso o cliente radicalize seus requisitos, de maneira a otimizar as chamadas remotas. Caso utiliza-se Façade, o trabalho seria o mesmo, com o acrescimo da possibildade do cliente nunca mudar o requisito de distribuição (foram raros os projetos que ví onde o cliente exigiu: (Agora eu quero que isso seja um EJB).

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Lezinho wrote:
Mesmo se o Domain service é a própria fachada remota para um cliente (dispensando a service Layer neste caso , já que um simples metadado resolve tudo)?

Bom, a tecnologia foi simplificada que muitas vezes um próprio elemento do Domínio (como um service), pode assumir um outro papel sem afetar o próprio modelo (só lamento que as anotações em java são tão dependentes), é isso.

Aí agente volta à diferença entre os conceitos. Se todo seu dominio se resume a apenas esse domain service, ok, mas geralmente um dominio é maior do que isso, o domain service representa um conceito do seu negocio, ao contrario da facade que representa todo o seu dominio atraves de uma interface simplificada.

No caso de remoting, um domain service é um objeto, uma service layer nao, ou seja, domain service não deveria ser distribuido. A velha historio de que nao devemos distribuir nossos objetos.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

cmoscoso wrote:ao contrario da facade que representa todo o seu dominio atraves de uma interface simplificada.

Uma fachada que representa todo meu Domínio? Acho que estou entendendo errado, ou você sugere mesmo uma Mega Booster Super Façade que engloba todo meu domínio? Sinceramente eu acharia isso perigoso, em vista que meu domínio pode não ter uma distribuição homogenia por um único meio.

Concordo que as façades são interfaces simples para o cliente que podem agregar serviços e diminuem a carga na distribuição, isso é fato e utilizo desta forma quando necessário, mas no mínimo aplicar ele por caso de uso. Nisso, usando DDD, em determinados momentos você pode notar que alguns Domain services agregam (não necessariamente e não comumente) atividades que podem compreender perfeitamente a um Caso de Uso, e isso faça sentido para o domínio... neste caso ele é tanto o objeto de domínio que oferece serviços relacionados a entidades ou repositorios como pode ser uma fachada remota (é só anotar... afinal de contas pode compreender um Use Case).

cmoscoso wrote:
A velha historio de que nao devemos distribuir nossos objetos

Concordo e apoio, eu prefiro distribuir a aplicação do que os componentes (cluster web+business no lugar de EJBs clusterizados). Mas requisitos são requisitos... se um cliente quer que exponha um serviço de forma remota para determinado caso de uso, ele terá... da forma que quiser (webservice SOAP, Rest, JSon, EJB, etc).

This message was edited 1 time. Last update was at 13/03/2008 11:28:03

editado: acho que o Phillip não precisa esclarecer nada

Lezinho wrote:Uma fachada que representa todo meu Domínio? Acho que estou entendendo errado, ou você sugere mesmo uma Mega Booster Super Façade que engloba todo meu domínio?

Sei la, caso você possua um Super Mega Booster Dominio...

This message was edited 2 times. Last update was at 13/03/2008 13:45:53

Acho que esta havendo uma confusão entre Domain Models e Domain Objects.
Quando me refiro ao domínio, estou me referindo ao todo do domínio e não uma única classe (apenas para ser claro) e nesta caso uma única façade, é no mínimo, "exótico".

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 687 Offline

Lezinho wrote:Acho que esta havendo uma confusão entre Domain Models e Domain Objects.
Quando me refiro ao domínio, estou me referindo ao todo do domínio e não uma única classe (apenas para ser claro) e nesta caso uma única façade, é no mínimo, "exótico".

Sim, estamos falando da mesma coisa.

Você tem razão, clientes não devem depender de interfaces que eles nao utilizam mas meu ponto era que apesar de as vezes a facade nao se fazer necessaria os conceitos continuam sendo independentes.

Eu apenas acho simplista dizer nessas situacoes que sao conceitos iguais, a nao ser do ponto de vista do cliente que as utiliza.

Ficamos combinado assim?

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 719 Offline

Mas é isso mesmo Carlos.

O conceito não muda (o Domain Service tem seu papel e a Service/Application Layer tem outro). Apenas achei relevante mencionar que algumas vezes podemos ver classes acumulando (por razões de pontos de vista distintos da aplicação) mais de um papel e normalmente isto recai sobre os Services mesmo.

JavaEvangelist Membro desde: 18/02/2008 10:06:25 Mensagens: 413 Offline

Só voltando um pouco a dúvida inicial

Uma outra solução já que você está se utilizando do Spring seria utilizar a anotação @configurable nas tuas entidades, dá uma olhada aqui, isso deve te ajudar, http://debasishg.blogspot.com/2007/02/domain-driven-design-inject.html

Abraços.

A alternativa seguinte seria uma possibilidade para o caso simples em que o repositorio possui uma implementação única... se não for o caso, poderia ser utilizado um Registry.

Nesta implementação, o hibernate chama o construtor privado para criar o objeto, que então se encarrega de instanciar sua dependência. Para o caso de instanciação via operador new, o que pode ser útil para testes de unidade, fica a cargo do cliente a criação do objeto num estado consistente, o que inclui a injeção da dependência com o repositório (ou então coloca-se isso numa Factory).

@Entity
public class Conta {

// outros atributos

@Transient
private Repository repository;

// construtor privado usado apenas pelo Hibernate para instanciar o objeto
private Conta() {
repository = new DaoQueImplementaRepository();
}

public Conta(Repository repository) {
this.repository = repository;
}

// outros metodos

}

Isso resolve o problema proposto? ou cria outros problemas?

Abraços

Thread.start() Membro desde: 20/12/2007 09:48:19 Mensagens: 26 Offline

Sei que já faz muito tempo que este POST foi escrito e com certeza você já deve ter encontrado alguma solução. Mas caso queira conferir mais uma maneira de resolver seu problema, sugiro que leia este post: http://submundojava.com.br/wordpress/2010/04/04/injetando-repositorios-em-entidades-com-spring/

Abraço.

Notícias, artigos e o maior fórum brasileiro sobre Java