Injeção de Dependência em Domain Model (ServiceLayer+DomainModel+Repository)

Lezinho wrote:
PS: Você não apóia o uso de DSLs ? Eu particularmente detestava, até conhecer o Drools e como fazer regras de segurança com ele (o ruim não eram as DSLs e sim como cria-las , IMHO).

Sim, apóio e minha linha de estudo atual é exatamente sobre os conceitos envolvidos em LOP e DSLs: http://fragmental.tw

Eu discordo de alguns conceitos do Fowler, por exemplo o conceito dele de LOP==DSL

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

pcalcado wrote:Após aquele post todo cheio de referências e autoridade completamente furado (e pedir 'abertura' para engolir sua presunção) colar um trecho de um livro que já mostrou que não entende (ou será 'leu'?) é muita cara de pau.

Ataques pessoais!? Lamentável um moderador adotar essa postura.

pcalcado wrote: O outro rapaz aqui (que você já chamou de desonesto neste fórum só por birra) ...

Magina, acho que vc havia cometido um engano ao falar que havia bloqueado meus e-mails, apesar de nunca ter te enviado qualquer coisa. Não precisa forçar neh!?

Quanto à discussão, cada um faz suas escolhas e assume as consequências.

Assunto encerrado.

Só uma dúvida Lezinho...

Estou usando Seam e EJB 3 e não tenho tido a necessidade de injetar Repositories nos Entities e sim alguns Services. (tenho um exemplo para aplicação Desktop em http://www.aspercom.com.br/bitshop). Como são poucos casos, criei um Factoryzinho para injetar isso (se fosse muitos recorreria a AOP como vc fez).

Quais situações você está sentindo a necessidade de injetar repositories? Seria para navegar numa associação derivada? Ou para "simular" uma associação n-aria?

Abraços!

This message was edited 1 time. Last update was at 11/10/2007 16:01:29

Olá Rodrigo ...

O repositório na entidade deve executar métodos de negócio a fim de recuperar elementos relevantes ao comportamento desta Entity, não precisa necessariamente ter uma ordem de relacionamento com a entidade.

Agora uma Service, é um padrão que encapsula seu Domain MOdel. Ele antecede as Entidades e controla o fluxo das execuções. O comportamento da entidade (seus métodos de negócio) possui lógica, um service apenas opera como uma fachada. Sendo assim, uma entidade não deve invocar um service, e sim ser invocada por um.

Para você visualizar o modelo de camadas proposto por Fowler e descrito no POEEA, veja uma breve descrição e um diagrama que aponta isso aqui:

http://martinfowler.com/eaaCatalog/serviceLayer.html

PS: Veja que "DataSource Layer", que deve ser abstraída pelo Repository, esta encapsulada no Domain.

[]´s

Veja,

Digamos que tenho repositórios de entidades diferentes (PessoaRepository e ContaRepository, por exemplo). Aih desejo que um mesmo DAO genérico implemente esses repositórios ( ao menos nos métodos que equivalem a operações CRUD ).

Que estratégia devo tomar para conseguir isso? Dá pra usar interfaces e spring? Devo usar fachada? Como se daria isso?

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 879 Offline

rodrigoy wrote:Só uma dúvida Lezinho...

Estou usando Seam e EJB 3 e não tenho tido a necessidade de injetar Repositories nos Entities e sim alguns Services. (tenho um exemplo para aplicação Desktop em http://www.aspercom.com.br/bitshop). Como são poucos casos, criei um Factoryzinho para injetar isso (se fosse muitos recorreria a AOP como vc fez).

Quais situações você está sentindo a necessidade de injetar repositories? Seria para navegar numa associação derivada? Ou para "simular" uma associação n-aria?

Abraços!

Essa história de Repositories tá confundindo a cabeça do pessoal...

É verdade. No meu caso, como estou acostumado a utilizar um DAO genérico com hibernate e somente criar DAO's específicos quando desejo uma consulta mais específica, estou pensando como se daria para as interfaces de Repositório do DomainModel serem implementadas pelo DAO genérico (ao menos nas funcionalidades que equivalem a CRUD) e só serem implementadas por DAO's específicos em caso de consultas específicas.

Como poderia fazer isso?

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

BiraBoy wrote:
Como poderia fazer isso?

Herança?

Beleza, e como faço para desacoplar o repositório da implementação com DAO's?

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

A estratégia que eu uso é realmente utilizar Strategy

Eu tenho uma interface DAO expondo métodos como do tipo (exemplificando):
- read(String stringQuery);
- read(String stringQuery, Object[] params);
- read(String stringQuery, Map<String, Object> params);
- getAll(Class clazz);
- getById(Object id);
- save(Object obj);
- delete(Object obj);
(etc)

A implementação do DAO faz uso de JPA, Hibernate, Prevayler, ou seja lá o que for ...

Tenho interfaces Repositories do tipo (RepositoryUser):

- findUserByNameAndPassword(String name, String password);
- addUsersWithValidRegisters(List<User> users);
(etc)

A implementação do repositório possui como atributo minha interface DAO definida anteriormente, e utilizo D.I.P. (no momento Seam) da implementação DAO desejada.

Quando o repositório precisa realizar acesso ao framework de persistencia (ou outro recurso de persistencia) ele faz o uso do seu Dao injetado como Strategy.

Assim o DAO continua com seu encapsulamento de acesso a dados, o repositório continua com a lógica, e a leitura do programa fica coesa.

This message was edited 1 time. Last update was at 19/10/2007 15:09:26

BiraBoy wrote: Beleza, e como faço para desacoplar o repositório da implementação com DAO's?

.. o DAO esta desacoplado.

This message was edited 1 time. Last update was at 19/10/2007 15:10:11

Herança?

Prefira composição a herança:

http://javaboutique.internet.com/tutorials/Inherit_Compose/
http://martinfowler.com/bliki/DesignedInheritance.html
http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Lezinho wrote:

Herança?

Prefira composição a herança:

http://javaboutique.internet.com/tutorials/Inherit_Compose/
http://martinfowler.com/bliki/DesignedInheritance.html
http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/

Eu não concordo que isso se aplique aqui, mas se vc tem uma ideia de como composição pode resolver o problema do reaproveitamento de codigo que o BiraBoy explicou, venha ela ...

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

... composição resolve neste caso, conforme descrevi a uns 4 posts acima.

GUJ Expert Membro desde: 22/03/2005 20:57:48 Mensagens: 3420 Offline

Lezinho wrote:... composição resolve neste caso, conforme descrevi a uns 4 posts acima.

???

Usar Strategy não é composição, é Strategy. Ter um objeto DAO injetado não resolve o problema exposto que é : não reimplementar funcções simples de CRUD para cada Repository. Então vc faria

Como ClientRepository poderia reaproveitar o codigo de repository sem herança ?
Bom poderia ser assim (com composição)

Qual é a vantagem ? Herança não é mais simples ?
Afinal ClientRepository É-UM Repository e mais do que isso ele SÓ-PODE-SER-UM reposiotry, que é a condição para que Repository seja uma classe abstract e ClientRepository a herde. Se Repository é uma interface eu poderia fazer

que não faz nenhum sentido. Então, não vejo como composição se encaixe melhor do que herança.

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