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

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

sergiotaborda wrote: 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.

Por exemplo: se opto por utilizar AOP + compile-time weaving (ou mesmo load-time weaving) eu estaria mesmo assim utilizando bytecode rewrite, certo? O AOP entraria apenas como um facilitador de bytecode rewrite? Ou você estaria falando de algo bem mais punk que isso? rsrs..

Shoes wrote: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?

Pensei em um domínio que atendesse e exemplificasse esta citação que você fez: "Um objeto pdoe ser válido e não ser aceito por uma especificação." Mas compreendi como a solução pode variar dependendo do domínio. Um método isMenorDeIdade() no objeto Infrator poderia ser suficiente ao invés de uma Specification. Aff... é confuso, mas tá valendo..

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

Thiago Senna wrote:

sergiotaborda wrote: 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.

Por exemplo: se opto por utilizar AOP + compile-time weaving (ou mesmo load-time weaving) eu estaria mesmo assim utilizando bytecode rewrite, certo? O AOP entraria apenas como um facilitador de bytecode rewrite? Ou você estaria falando de algo bem mais punk que isso? rsrs..

Vc pode usar qq tipo de weaving com AOP. Vc estaria usando bytecode rewrite (instrumentatilização acho que se chama) O AOP é um framewordk generico para fazer bytecode rewrite. Com ele vc faz qq coisa que quiser. Interfere em qualquer coisa que quiser. É generico. Por ser generico é bom para regras desconhecidas à priori ou regras cuja definição é uma condição (cut-point) e não uma interface ou coisa simples. Por isso AOP é bom para incluir transações etc.. Agora, se vc sabe à priori onde estão seus cut-points vc não usa AOP, usa um framework de bytecode rewrite (tou lembrando do Javasssit da JBoss ). Aqui vc não precisa se algo generico, precisa de algo eficiente. No fim vai dar ao mesmo, mas é um equilibrio entre ser generico vs eficiente.

Por exemplo, no JPA todos os objetos @entity têm que ser instrumentalizados para que sejam interceptadas chamadas ao métodos modificadores, para que o estado do objeto passe para dirty. O programador não vê isso.
Quando faz uma query e obtem os objetos , se vc fizer instanceof e comparar com a sua classe de negocio vai retornar true. Mas internamente o drive JPA pode usar outra classe , digamos Persistable para controlar o objeto.
Ele pode fazer isso criando um proxy da classe de negocio : veja bem o proxy herda a classe de negocio e por isso o instanceof funciona. Essa herança é feita com bytecode rewrite. Mas ao mesmo tempo o proxy tb herda de Persistable. Não é só herança "a quente" é "herança multipla a quente'. bytecode rewrite é tão poderoso quanto isso. Normalmente vc não precisa violar as regras do java , e não o pode fazer em programação normal, mas com bytecode rewrite é o dia a dia. AOP é uma forma mais evoluida (generica) de construir bytecode rewrite
mas menos eficaz no sentido que ao aumentar a genericidade diminui o poder de transformação oferecido pelo bytecode rewrite.

Enfim , AOP é um facilitador , mas para coisas simples como interceptar métodos. É ideal para os cuting-concerns . Mas tudo o que é feito com AOP pode ser feito diretamente com bytecode rewrite de forma mais eficaz. Nem tudo o que se faz com bytecode rewrite se pode fazer com AOP , como herança "a quente" por exemplo.
Portanto, num framework vc usa bytecode rewrite. Para implementar uma logica de negocios só sua, vc usa AOP.

Ressucitando tópico

,

Mas não é para continuar essa discussão, e sim perguntar ao autor da soluçao:

Voce conseguiu fazer isso funcionar sem ter que alterar esse aspecto?

Estou tentando reproduzir aqui e estou obtendo erros, ao menos em meu ambiente de testes.

A exception diz: No application context active

Alguma luz ?

Obrigado

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

Em que momento vc tem essa Exception? Quando o Application Server inicia ou quando sua aplicação faz uso efetivo da injeção?

Alessandro Lazarotti wrote:Em que momento vc tem essa Exception? Quando o Application Server inicia ou quando sua aplicação faz uso efetivo da injeção?

Oi alessandro,

Estou fazendo testes com o TestNG + Maven.

Uso um jboss embedded, isso está acontecendo no momento em que o hibernate sobe, depois de carregar os persistence.xml.

Eu ACREDITO que esse problema seja pelo fato do Hibernate subir antes do Core do Seam, por isso a inexistência dos contextos.

Gostaria de alguma forma de deixar o hibernate subir apenas depois do Seam, é possível isso ?

Que ambiente de testes vc usou para esse caso ?

Grato

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

Vc esta tendo este problema pq no código que exemplifiquei aqui, é utilizado um pointcut em "inicialization".
Quando o persistence.xml levanta o mapeamento das crianças, o aspecto já entra em execução, mas de fato nem o Seam nem os contextos JSFs estão prontos.

Se você mudar o pointcut para "get" esse problema não ocorre e de quebra terá lazy-load para estes atributos. Ou seja, um atributo anotado pelo mapeamento do AOP, só entrará em ação quando um método invocar este mesmo atributo, assim como os ORMs fazem com seus atributos em Lazy.

O código ficaria parecido com isso:

public aspect InjectEntity{
	pointcut inject(Object s) :target(s) && (get(@In * br.com.siq.eqm.entity..*.*));

before(Object obj):inject(obj){

try {

String valueOfContextVariable = null;

Boolean createContextVariable=false;

Field field = obj.getClass().getDeclaredField(thisJoinPoint.getSignature().getName());

field.setAccessible(true);

Object objIn = field.get(obj);

if(objIn == null){

if(field.isAnnotationPresent(In.class)){

In in = field.getAnnotation(In.class);

if(in.value().equals("")){

valueOfContextVariable = field.getName();

}else{

valueOfContextVariable = in.value();

}

if(in.create())

createContextVariable = true;

field.setAccessible(true);

try {

field.set(obj, Component.getInstance(valueOfContextVariable, createContextVariable));

} catch (IllegalStateException e) {

//TODO fazer aqui seu mecanismo de Log

}catch(Exception e){

//TODO fazer aqui seu mecanismo de Log
					}

}

} catch (Exception e) {

//TODO fazer aqui seu mecanismo de Log

throw new RuntimeException(e);

}

[]'s

Alessandro,

Era justamente isso, testei esse novo código e funcionou perfeitamente.

Muito Obrigado!

PS: Postei esse tópico no forum do Seam, voce se importa se eu postar esse código lá ?Acredito que tenha mais gente querendo fazer isso.

[]'s

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

Claro, pode postar sim (com os devidos créditos

)
Como lhe disse em off, estou passando estes códigos para javassist, e fará parte oficial do projeto ou irá para o X-Seam.
[]'s

Debugger Membro desde: 21/03/2005 19:13:04 Mensagens: 66 Offline

Alessandro... li as primeiras partes do seu post e consegui tirar minha dúvida, que por sinal era a mesma da sua. (é, eu sei que isso aqui é antigo mas sou meio novato no quesito arquitetura).
Agora queria saber de vc como vc tá usando o Repository, por exemplo, são só interfaces ou há classes que possuem acesso a um DAO?

Aqui no trabalho estamos fazendo os sistemas com base no Spring e precisaremos injetar, em algum momento, o repositório em classes do domínio. Vc conhece o load time weaver do Spring. Seria parecido com o seu aspecto. O que eu queria saber era se seria viável, se eu não perderia performance, essas coisas.

Por último, queríamos meio que isolar a camada de negócio da parte mais de infraestrutura (acesso aos dados). Então pensamos em criar interfaces "Repository" que seriam implementadas por DAOs. Mas vi aqui que eu não precisaria de um Repository pra cada classe... qual seria a forma de fazer nesse caso?

Mencionei Alessandro no início mas vale aí pra todo mundo
Valeu

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