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

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.

Acho aspectos muito bem vindo quando o assunto é injeção de dependências. Um bom exemplo é o @Configurable do spring, ou melhor ainda, inventar uma macumba para seu domain não depender de container de DI nenhum, e isso é possível com AOP.

Thiago Senna wrote:IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.

Thiago, Specfication não serve para isso. Specification serve para verificar s um objeto é condizente com um dado critério, não se ele é válido. Você não precisaria de uma spec ara dizer se um triângulo de dois vértices é válido, o objeto deve se verificar. Como todos nós sabemos um problema deste tipo de coisa é que validação geralmente resulta em código duplicado porque você ode querer verificar isso em outros lugares antes de formar o objeto em si.

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

pcalcado wrote:
Thiago, Specfication não serve para isso. Specification serve para verificar s um objeto é condizente com um dado critério, não se ele é válido. Você não precisaria de uma spec ara dizer se um triângulo de dois vértices é válido, o objeto deve se verificar. Como todos nós sabemos um problema deste tipo de coisa é que validação geralmente resulta em código duplicado porque você ode querer verificar isso em outros lugares antes de formar o objeto em si.

Hmmm.. Vc ta falando de validações basicas, tipo aquelas comum em construtores de VOs que procuram por nulls e illegal exceptions. Acho que seria uma boa mesmo, nem que seja posteriormente com o modelo numa situacao mais estavel com relação a refactoring.

VOs? COmo assim?

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

Thiago Senna wrote:IMHO, colocar aspectos referente a negócios é meio estranho, não que seja errado, mas estranho. A validações por exemplo ficariam melhores usando o padrão Specification, que é uma forma elegante de executar as validações dentro do domain.

Sim, o Specification é o padrão para validação, mas AOP pode ser util para manter a consistencia sem grande trabalho. Em vez de vc escrever aquele código chato que verifica se os paramentos são null ou fora de range vc pode simplesmente anotar e deixar alguem fazer o trabalho. Ok, isto é feitos com alguns frameworks de anotations que usam algo anterior ao AOP : bytecode rewrite. Afinal é a capacidade que o java tem de poder alterar o bytecode em runtime que habilite as ferramentas AOP que são apenas uma forma de implementar inceptações do codigo normal. As implementações de AOP são apenas um frameowrk simples de bytecode rewrite. Existem outras formas de bytecode rewrite que alcançam os mesmo objetivos. No fim, tlv seja mais facil usar um framework baseado em anotations para fazer a consistencia dos objetos do que escrever uma monte de cutting concerns repetidos.

Acho aspectos muito bem vindo quando o assunto é injeção de dependências. Um bom exemplo é o @Configurable do spring, ou melhor ainda, inventar uma macumba para seu domain não depender de container de DI nenhum, e isso é possível com AOP.

A injeção é feita pelo mesmo mecanismo de bytecode rewrite. Os frameworks que fazem isso não usam AOP.
E se vc for escrever o seu proprio DI container tb não vai usar AOP. Porque AOP é baseado em bytecode rewrite, então é muito mais eficaz usar bytecode rewrite logo de base.
AOP é bytecode rewrite para regras genericas que os frameworks de butecode não podem antever.E por isso são ideiais para injetar regras de aplicação (log, transação, etc)

Sobre Specification e validação, o q eu penso sobre, num exemplo simples. Validação verifica se tres numeros formam um triangulo (se nenhum é nulo, negativo, valores minimos e máximos), enquanto eu teria uma Specification (que recebe um objeto triangulo) para determinar se o triangulo é um triangulo retangulo.

Edufa wrote:Sobre Specification e validação, o q eu penso sobre, num exemplo simples. Validação verifica se tres numeros formam um triangulo (se nenhum é nulo, negativo, valores minimos e máximos), enquanto eu teria uma Specification (que recebe um objeto triangulo) para determinar se o triangulo é um triangulo retangulo.

Especification é para validar um objeto contra um critério relevante ao negócio. Geralmente este conceito é único e não faz sentido ter exposto na forma de um comportamento em si. Dois cenários:

- Ser um triângulo retêngulo ou não é algo que é usado em vária partes do sistema para coisas diferente: O objetod eve ter uma propriedade que indique se é retângulo ou não, não uma Specification. A Specification não serve para checar oe stado interno do objeto, validação quem faz é o objeto

- Existe uma situação onde apenas triângulos retângulos são aceitos. Nenhum outro lugar (ou pouquíssimos outros) utilizam esta informação então não vale a pena criar um atributo que informe se o triângulo é retângulo. Neste caso cria-se uma verificação que recebe um triângulo e informa se é um retângulo ou não, se não for ela o rejetia. Esta e a especificação.

O importante é notar que o objeto é quem se valida. Se você possui um critério para rejeitar ou aceitar objetos de acordo com um critério qualquer pode criar uma especificação apra isso mas não é uma validação. Um objeto pdoe ser válido e não ser aceito por uma especificação.

A minha opinião sobre Aspecto é de que só devemos utiliza-lo para os interesses sistêmicos onde o OO falha ou deixa a desejar, como foi dito antes, se utilizarmos Aspectos na camada de negócios então sua aplicação deixa de ser puramente OO.

This message was edited 2 times. Last update was at 10/12/2007 09:04:21

Cobracan wrote:A minha opinião sobre Aspecto é de que só devemos utiliza-lo para os interesses sistêmicos onde o OO falha ou deixa a desejar, como foi dito antes, se utilizarmos Aspectos na camada de negócios então sua aplicação deixa de ser puramente OO.

Ahm? O que é uma aplicação ser puramente OO?

Para começar teríamos que ter uma linguagem puramente OO, não? Então já podemos excluir Java. Outra coisa importante seria que tudo no programa fosse jeito com objetos, talvez? Então podemos excluir aspectos (especialmente os com AspectJ, com Spring AOP, JBoss AOP e essas coisas ainda dá pra engolir). Acredite em mim: você não precisa de e não quer um programa 100% OO.

This message was edited 1 time. Last update was at 10/12/2007 09:50:50

pcalcado wrote:VOs?

DDD

pcalcado wrote:COmo assim?

Eu tenho várias validações assim, não só nos Value Object claro, por isso talvez fosse uma boa usar AOP.

Estou lembrandode um outro tópico que vc falou que linguagens dinâmicas como ruby não precisam de AOP, sei que tem algo a ver com o conceito de open classes, mas nao estou muito por dentro de como isso é implementado.

A cada dia que passa eu tenho mais vontade de aprofundar nessa linguagem..

This message was edited 1 time. Last update was at 10/12/2007 10:03:48

Acho que há uma confusão aqui.

Value Object é um pattern criado por motivos bizzaros e muito utilizados em arquiteturas antiquadas. Veja referência sobre Value Object para ver a diferença deste e Pojo.

cmoscoso wrote:
DDD

Ufa!

cmoscoso wrote:
Eu tenho várias validações assim, não só nos Value Object claro, por isso talvez fosse uma boa usar AOP.

Essas validações, pode definição ficam nos objetos. Dá uma olhada no que escrevi acima nesse exemplo do triângulo.

cmoscoso wrote:
Estou lembrandode um outro tópico que vc falou que linguagens dinâmicas como ruby não precisam de AOP, sei que tem algo a ver com o conceito de open classes, mas nao estou muito por dentro de como isso é implementado.

A cada dia que passa eu tenho mais vontade de aprofundar nessa linguagem..

Você pode utilizar o conceito de AOP em linguagens dinâmicas mas não precisa. Um exemplo é o ActiveRecord do Rails, ele identifica que um método no formato find_by_ALGUMACOISA ele intercepta essa chamada e toma as medidas necessárias. Isso é feito com a meta-programação, procure na internet sobre method_missing e seus amigos

nbluis wrote:Acho que há uma confusão aqui.

Value Object é um pattern criado por motivos bizzaros e muito utilizados em arquiteturas antiquadas. Veja referência sobre Value Object que vai entender a diferença deste e Pojo.

Você está falando sobre Transfer Object, qe antigamente era chamado de Value Object. O Value Object referido neste tópico é outro padrão, vem de Domain Driven Design.

GUJ Master Membro desde: 11/02/2005 08:08:02 Mensagens: 1595 Offline

Opa... valeu pelas correções. Deixe-me bolar um exemplo que veio em minha cabeça.

Este seria um bom exemplo de validação (de regra de negócio) utilizando uma Specification?

Quanto ao AOP o que vocês defendem é que aspectos seriam interessantes para aquelas validações repetitivas como tamanho de campo, se um atributo é nulo, se uma dada String realmente é um e-mail, por exemplo?

Thiago Senna wrote:
Este seria um bom exemplo de validação (de regra de negócio) utilizando uma Specification?

Pode ser que sim, depende Qual o domínio do seu sistema? Onde os 'menores infratores' são utlizados? O sistema é sobre eles, é sobre infratores em geral? A linha tênue que define se você vai ter uma specification ou simplesmente um isMenorDeIdade()só e definida pelao negócio.

Thiago Senna wrote:
Quanto ao AOP o que vocês defendem é que aspectos seriam interessantes para aquelas validações repetitivas como tamanho de campo, se um atributo é nulo, se uma dada String realmente é um e-mail, por exemplo?

É mais amplo que isso: apsectos podem ser utilizados sempre que forem interessantes, não apenas para requisitos não funcionais.

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