�ltimas mensagens do t�pico "Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)"

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Muito tem se falado no grupo sobre DDD, Repository, Domain Model, etc.
Contudo estou tendo muita dificuldade para tornar estes conceitos pr�ticos, utilizando JavaEE.

Por exemplo:
Quem orquestra os objetos de dom�nio � uma [b]ServiceLayer[/b], no meu caso um Stateful ou Stateless do Seam.

Meu [b]DomainModel[/b] � constitu�do de Entitys(Objetos com identidade) com l�gicas de neg�cio al�m obviamente de seus atributos :arrow: no meu caso ele � uma classe [b]JPA anotada com @Entity[/b].

[code]
@Entity
@Name("user")
public class User implements Serializable {
...
}
[/code]

Na maioria das vezes as l�gicas neles contidas precisam de um acesso a banco, ent�o eles levam um (ou varios) repository consigo... como atributo da classe ou dentro do pr�prio m�todo.

[code]
@Entity
@Name("user")
public class User implements Serializable {
@Transient
RepositoryUser repositoryUser;

...
}
[/code]

Ent�o come�am alguns problemas. Meu Entity deveria receber inje��o deste repository... por�m como o Entity � carregado por JPA, eu n�o consigo injetar nenhum objeto nem por @In do Seam nem mesmo por Spring.

[code]
@Entity
@Name("user")
public class User implements Serializable {

//nao funciona a Injecao pq eh em entity
@In
@Transient
RepositoryUser repositoryUser;

...
}
[/code]

Uma solu��o seria fazer com que a ServiceLayer enviasse por "set" um repository para o Entity. Mas o c�digo do Service iria ficar poluido, tendo um repository que ele nem faz uso, s� instancia para o entity. Toda vez que fosse utilizar uma l�gica de neg�cio do entity que utiliza acesso a banco, teria que minha outra camada setar o repository pra ele.

[code]
/*A ServiceLayer*/
@Stateless
@Name("authenticator")
public class AuthenticatorService implements Authenticator{

@In(create=true)
@Out
User user;

@In
private RepositoryUser repositoryuser;

public boolean authenticate(){

//setando porcamente o repositorio
user.setRepository(repositoryuser);
user.authByNameAndPass();
...

}
}
[/code]
Qual seria uma outra solu��o que poderia ser adotada? Mesmo com o advento do JavaEE 5 com tantos frameworks de D.I. vou ter que utilizar ServiceLocator para localizar Repository nos entitys?

[]�s

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Ednelson — GMT

[quote]... por�m como o Entity � carregado por JPA, eu n�o consigo injetar nenhum objeto nem por @In do Seam nem mesmo por Spring. [/quote]Com Spring 2.0 vc pode injetar depend�ncias em objetos criados fora do conteiner, vc tem at� mesmo duas op��es, por AOP ou por chamada explicita do BeanFactory, Urubatan corrija-me se estiver errado

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Isso � mesmo poss�vel? Impressionante!
Bom, acabei descobrindo tbm que consigo acessar qualquer componente do Seam atrav�s de Componente.getInstance("nomeDoComponente"). Mesmo abstraindo este acesso nos objetos de entidade, n�o me parece uma coisa muito elegante, contudo ao que parece utilizando o Seam n�o tenho outra saida.

Ou Tenho?

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Paulo Silveira — GMT

No Hibernate (mesmo usando JPA) voce pode adicionar um Interceptor que toda vez que um bean sai do entity manager/session, o setXXXRepository � invocado.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Ferryman — GMT

Paulo,

Mas esses interceptors fazem parte da spec de JPA? Porque se n�o fizer, qual o sentido de utilizar JPA se o sistema s� ir� funcionar com a implementa��o do hibernate?

[]s

Ferry

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Fabio Kung — GMT

Me falta tempo, mas eu t� tentando resolver justamente esses problemas no: http://sourceforge.net/projects/hinjector/

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository) - RESOLVIDO

Alessandro Lazarotti — GMT

Bom, fiz algo que ficou bem interessante:
- Um Aspecto que intercepta a instancia��o de todas as classes do meu pacote com classes de entidades, injetando neste momento as depend�ncias que forem necess�rias. O legal � que fica completamente transparente para o desenvolvedor.

Com isso tanto faz se a instancia��o for atrav�s de "new", "jpa" ou qualquer outro framework, a inje��o vai funcionar do mesmo jeito.

Veja o c�digo usando AspectJ:

[code]

public aspect InjectEntity{

//pointcut criado para interceptar na instanciacao de uma classe
// br.com.siq.entity � o pacote onde estao minhas entidades
pointcut inject() : initialization(public br.com.siq.entity.*.new ());

//execucao do aspecto apos concluida (advice after) a instanciacao da classe
after():inject(){
//obtendo o objeto em questao (joinpoint)
Object obj = thisJoinPoint.getThis();

//variaveis que injetarao em um determinado atributo
String valueOfContextVariable = null;
Boolean createContextVariable=false;

//Procurando anotacao de injecao na classe, no caso do Seam o "In.class"
for(Field field:obj.getClass().getDeclaredFields()){
if(field.isAnnotationPresent(In.class)){
In in = field.getAnnotation(In.class);

//se a anotacao nao tem o atributo value setado, utilizar o nome do campo
if(in.value().equals("")){
valueOfContextVariable = field.getName();
//caso contrario utilizar o atributo value
}else{
valueOfContextVariable = in.value();
}

//verificar se esta anotado como create
if(in.create())
createContextVariable = true;

//tornando acessivel o atributo caso ele seja private, para ser possivel fazer a injecao
field.setAccessible(true);

try {
//injetando no atributo, como uso JBossSeam obtenho a referencia atraves do
//Component.getInstance() , mas poderia ser qualquer coisa,
//como um applicationContext do Spring
field.set(obj, Component.getInstance(valueOfContextVariable, createContextVariable));
} catch (Exception e) {
//escrever aqui rotina de excecao
}
}
}
}

[/code]

Na entidade, basta anotar:

[code]

@In
private Repository repository;

[/code]

O C�digo do Aspecto pode ser melhorado, como incluir suporte para injecao pelo m�todo "set", mas esse foi apenas um esbo�o de como pode ser feito.

[]'s

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=Lezinho]
Na maioria das vezes as l�gicas neles contidas precisam de um acesso a banco, ent�o eles levam um (ou varios) repository consigo... como atributo da classe ou dentro do pr�prio m�todo.

[/quote]

Hmmm... l�gica de acesso a banco nos Entitys... estranho isso...

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

L�gica de acesso a banco? Onde?

A entidade tem acesso ao "[b]reposit�rio[/b]", que de nada tem haver com "[b]L�gica de acesso ao banco[/b]". O [b]reposit�rio[/b] tem "intimidade" com a [b]l�gica de neg�cio[/b], faz parte dela, nada mais justo que estar no [b]modelo de dom�nio[/b].

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Mas concordo que fui infeliz na minha afirma��o do primeiro post " [i]precisam de um acesso a banco[/i]", o q queria dizer foi:
"[b]precisam de um acesso ao reposit�rio[/b]".

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=Lezinho]Mas concordo que fui infeliz na minha afirma��o do primeiro post " [i]precisam de um acesso a banco[/i]", o q queria dizer foi:
"[b]precisam de um acesso ao reposit�rio[/b]".[/quote]

Continua estranho, Entitys dependendo de Repositories....

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

A dependencia � injetada, entao nao vejo problema. O fato de ser um repository dentro de um entity tbm n�o encontro nada de errado, ambos fazem parte da l�gica de neg�cio.... mais uma vez.... REPOSIT�RIO � NEG�CIO..

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Lezinho]A dependencia � injetada, entao nao vejo problema. O fato de ser um repository dentro de um entity tbm n�o encontro nada de errado, ambos fazem parte da l�gica de neg�cio.... mais uma vez.... REPOSIT�RIO � NEG�CIO..[/quote]

Correto. A falta de entendimento das pessoas sobre Repositories x DAOs causa este tipo de confus�o mas basta ler a bibliografia para entender que um Reposit�rio � parte do dom�nio e por isso n�o h� qualquer problemas em relacionar entidades � ele.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=Lezinho]A dependencia � injetada, entao nao vejo problema. O fato de ser um repository dentro de um entity tbm n�o encontro nada de errado, ambos fazem parte da l�gica de neg�cio.... mais uma vez.... REPOSIT�RIO � NEG�CIO..[/quote]

A quest�o � a forma como ela � injetada (lembre-se do princ�pio do KIS).

Os Repositories - e os DAOs dos quais eles dependem, j� que vc prefere assim - dependem do Service e n�o dos Entitys.

D� um olhada no caveatemptor (aplica��o de refer�ncia para uso de Hibernate).

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Taz, vc pde injetar por "set" sendo enviado pelo Service, como mostrei no primeiro post, gerando o problema que tbm j� mostrei.

O que fiz, via annotation, faz a inje��o pelo SEAM (por debaixo dos panos do aspecto), n�o a nada de errado nisso... a dependencia foi invertida.

Voc� n�o esta sendo claro, ou n�o esta entendendo.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=Lezinho]

Voc� n�o esta sendo claro, ou n�o esta entendendo.

[/quote]

Esqueceu de levantar a possibilidade de que vc n�o esteja entendendo. D� uma olhada na aplica��o de refer�ncia que te falei e nos exemplos de JBoss Seam (que n�o s�o poucos). Depois discutimos....

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

De fato n�o olhei estes codigos, assim como tamb�m n�o sei pq deveria. N�o tenho d�vidas de como usar "repository", e sim "tinha" de como injeta-los no load de algum framework de persistencia (o que foi resolvido via Aspect).

Portanto Taz, dispenso a discuss�o, o foco desta thread n�o foi este. Quem achou estranho usar repository em entity foi voc� (o que o Shoes desmistificou muito bem).

Se voc� esta com dificuldade de entender repositories em entities, abra uma thread sobre isso.

Boa Sorte.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

Belez...

"O pior cego � aquele que n�o quer ver" (ditado popular)

Abra�o e boa sorte (vc vai precisar se n�o estudar os exemplos)

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Taz, eu sei como o Hibernate trabalha com interceptors, tbm sei como delegar isso para service.

Contudo n�o quero dependencia dos interceptors Hibernate (eu posso instanciar minha entidade atraves de "new", nesta caso o Interceptor do hibernate n�o me ajudaria) e tbm n�o quero associar metodos de negocios do repositorio na ServiceLayer, mas sim na minha entidade de dom�nio. Eu n�o preciso ler fontes dos exemplos do Hibernate para isso, sei o que quero ou n�o fazer, assim como n�o sei de nenhuma literatura mencionando que o que fiz esta quebrando algum conceito OO.

"O pior orador � aquele que se pronuncia sem necessidade alguma"

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

fabio.patricio — GMT

[quote=Taz]

Belez...

"O pior cego � aquele que n�o quer ver" (ditado popular)

Abra�o e boa sorte (vc vai precisar se n�o estudar os exemplos) [/quote]

O problema � que as duvidas dele nao sao referentes ao Sean mas sim se tem como aplicar DDD com o Sean. Ai faz sentido ter repositorios dentro dos entities (entities do DDD).

]['s

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Voc� entendeu Fabio, � isso mesmo a duvida que tinha quando criei o t�pico.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=fabio.patricio][quote=Taz]

Belez...

"O pior cego � aquele que n�o quer ver" (ditado popular)

Abra�o e boa sorte (vc vai precisar se n�o estudar os exemplos) [/quote]

O problema � que as duvidas dele nao sao referentes ao Sean mas sim se tem como aplicar DDD com o Sean. Ai faz sentido ter repositorios dentro dos entities (entities do DDD).

]['s[/quote]

Ok, vamos falar em DDD.

Seguem trechos do cap�tulo "Repositories" do Livro do Eric Evans (Domain Driven Design Complexity In Software):

Onde ele fala que s�o os Entitys que acessam os malditos Repositories!? Todos os diagramas que ele desenha no livro mostram os "Clients" acessando os REPOSITORIES.

[quote=Evans]Clients request objects from the REPOSITORY using query methods that select objects based on
criteria specified by the client, typically the value of certain attributes. The REPOSITORY retrieves
the requested object, encapsulating the machinery of database queries and metadata mapping.

(...)

Provide REPOSITORIES only for AGGREGATE roots
that actually need direct access. Keep the client focused on the model, delegating all
object storage and access to the REPOSITORIES.
[/quote]

Sabe o que s�o AGGREGATES!? Procure no mesmo livro que ele te explica.

[quote=Evans]
A REPOSITORY "contains" all instances of a specific type, but this does not
mean that you need one REPOSITORY for each class.
[/quote]

Traduzindo: Vc n�o precisa criar um reposit�rio para cada classe.

[quote=Evans]
It is tempting to commit after
saving, for example, but the client presumably has the context to correctly initiate and
commit units of work. Transaction management will be simpler if the REPOSITORY keeps its
hands off.
[/quote]

Traduzindo: Como ficaria o controle da transa��o se ele n�o fosse feito pelo cliente!?

E caso vc ainda acredite que esteja subvertendo seu modelo de dom�nio, o que � muito dif�cil quando se faz o uso correto do Hibernate...

[quote=Evans]In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven
design and let go of the specifics when the framework is antagonistic. Look for affinities between
the concepts of domain-driven design and the concepts in the framework
[/quote]

Por esses e outros motivos, repito...

[quote=Taz]
Continua estranho, Entitys dependendo de Repositories....
[/quote]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Capacidade de abstra��o, ou neste caso a falta dela, � uma coisa muito interessante. � f�cil perceber quando algum trecho foi pego sem entendimento do contexto (especialmente quando o contexto � composto por 500+ p�ginas de texto denso) pela forma como algu�m se atem � trechos que sozinhos n�o t�m qualquer significado.

Entity � um padr�o, p�gina 89. Repository � um padr�o, p�gina 147. Aggregate tamb�m, p�gina 125. N�o existe um padr�o 'client'. por que ser�? Porque o cliente de algo � simplesmente o que precisa de acesso a este, no caso espec�fico cliente pode ser um Entity. Claro que poderiam haver diagramas mostrando cada uma das possibilidades, entity x repository, service x repository, specification x xrepository... s� que haveriam algumas dezenas de p�ginas a mais a toa.

O texto n�o traz uma defini��o de 'cliente', talvez porque... uhm... seja bem obvio quando se tenta.. uhm... ler o dito cujo. Por exemplo quando factories s�o definidas temos:

[quote]
But shifting responsibility to the other interested party, the client object in the application, leads to even worse problems. The client knows what job needs to be done and relies on the domain objects to carry out the necessary computations. [...] Even worse, if the client is part of the application layer, then responsibilities have leaked out of the domain layer altogether.
[/quote]

ou seja: o cliente [b]pode[/b] ser Camada de Aplica��o, mas n�o necessariamente.

Mas para entender mais profundamente o texto de Evans (coisa que s� � necess�ria quando voc� est� estudando DDD em um n�vel mais profundo ou quando precisa refutar uma desinforma��o, que � o caso) � necess�rio pesquisar no seu antecessor, amplamente referenciado por este: Fowler no seu POEAA. E uma das coisas mais legais do Fowler � que ele consegue responder este tipo de d�vida com um exemplo claro, como este retirado do livro (pagina 325, no cap�tulo sobre Repository):

[code]
public class Person {
public List dependents() {
Repository repository = Registry.personRepository();
Criteria criteria = new Criteria();
criteria.equal(Person.BENEFACTOR, this);
return repository.matching(criteria);
}
}
[/code]

Veja que curioso: uma entidade referenciando a seu pr�prio Reposit�rio. Onde mesmo que havia visto isso? E veja s�, ainda usa Registry.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

fabio.patricio — GMT

[quote=pcalcado]Veja que curioso: uma entidade referenciando a seu pr�prio Reposit�rio. Onde mesmo que havia visto isso? E veja s�, ainda usa Registry.[/quote]

Uma coisa que vem ficando cada vez mais frequente no GUJ � certos usu�rios acharem que s� eles leram os livros/artigos/papers/coloque aqui sua fonte preferida. Essa resposta do Taz fazendo como se ele fosse o unico e ter lido esse livro me fez procurar o e-mail da primeira vez que eu ouvi falar dessa obra do Evans. Quem me falou disso a primeira vez foi o Marcos Pereira (usuario aqui do GUJ tb) la em 2004 acredito que pouco tempo depois do livro ter sido lancado.

Ps.: Desculpem o desabafo, mas esse tipo de coisa no GUJ vem se tornando frequente e enche um pouco o saco.

]['s

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Eu tenho quase certeza que a pimeira refer�ncia que vi foi aqui no GUJ pelo cv (e vindod e quem vem n�o estranharia se fosse a primeira vez que isso apareceu num site em portugu�s ). Infelizmente o grande apagamento dos posts de uns dois anos atr�s levou a mensagem para o limbo.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=fabio.patricio]

Uma coisa que vem ficando cada vez mais frequente no GUJ � certos usu�rios acharem que s� eles leram os livros/artigos/papers/coloque aqui sua fonte preferida.

[/quote]

N�o deveria haver motivos para m�goas. Eu n�o disse que s� eu havia lido... :wink:

Quanto ao outro rapaz, percebo certa rispidez em sua r�plica, o que j� � um comportamento hist�rico que pode ser ocasionado por uma certa inseguran�a.... Por outro lado, o mesmo reclama de lidar com pessoas que n�o se at�m � bibliografias. Quando encontra algu�m que l�, deveria ter uma postura mais aberta...

Uma pena que ele n�o percebe que o Hibernate converte aquilo que ele escreveu:

[code]public class Person {
public List dependents() {
Repository repository = Registry.personRepository();
Criteria criteria = new Criteria();
criteria.equal(Person.BENEFACTOR, this);
return repository.matching(criteria);
}
}
[/code]

por isso (obviamente em um contexto "managed")...

[code]public class Person {
public List getDependents() {
return dependents;
}
}
[/code]

Ou seja, o Hibernate cont�m o pr�prio Repositorio em si...

Lembrem-se:

[quote=Evans]In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven
design and let go of the specifics when the framework is antagonistic. Look for affinities between
the concepts of domain-driven design and the concepts in the framework[/quote]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

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.

Quem quiser entender melhor sobre Hibernate & Repositories � legal olhar a lista de DDD, o que a pessoa escreveu a� em cima (pra variar) n�o condiz com a realidade da t�cnica. O trecho que ele postou substitui Registry por algum meio autom�tico (talvez IoC) de inje��o, mas a tecnologia utilizada n�o tem nada a ver com a aplica��o ou n�o do padr�o. Repositories podem ser criados para lidar diretamente com Hibernate, JDBC, search engines ou n�o, provavelmente delegando seu trabalho � DAOs e DataMappers em geral. Mas nem adianta tentar refutar com argumentos ou at� mesmo refer�ncias bibliogr�ficas, como se p�de perceber. O bichinho n�o anda, simples assim.

O outro rapaz aqui (que voc� j� chamou de desonesto neste f�rum s� por birra) n�o precisa ter inseguran�a, pelo menos n�o quanto � voc�. [url=http://guj.com.br/posts/listByUser/285/6813.java]Seu hist�rico aqui j� o condena[/url] ([url=http://www.guj.com.br/posts/list/64771.java#342019]inclusive profissionalmente[/url], mas tudo bem, voc� n�o revela seu nome exatamente para n�o te reconhecerem, certo?), isso sem contar o portal Java...

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Apenas respondendo a sua pergunta Taz, sim eu conhe�o o que � Aggregate, assim como tbm sei que Repository n�o � um para cada classe. Agora o que n�o sei mesmo � o que isso tem haver com o que tenho postado ou oq j� rolou neste t�pico.

Alguma vez afirmei que iria construir repositorios a torto direito para cada entidade minha?

E que porcaria que voc� andou digitando sobre "Clients"?

Quanto aos "clients", apenas completando o que Shoes j� disse... vale comentar tbm que al�m de usar uma entidade (People), no livro de Fowler (POEAA) ele tbm usa duas classes "Strategy" com um Repository, o que nos mostra a flexibilidade do padr�o.

Mas � claro, n�o espero que Taz concorde com estas afirma��es... J� discordou de mim, do Fabio Kung, do Sergio, do Phillip, do fabio.patricio, n�o duvido que ele discorde de Fowler tbm...

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Lezinho]
Mas � claro, n�o espero que Taz concorde com estas afirma��es... J� discordou de mim, do Fabio Kung, do Sergio, do Phillip, do fabio.patricio, n�o duvido que ele discorde de Fowler tbm...
[/quote]

S� � bom focarmos que discordar � �timo. Eu discordo do Fowler bastante em DSLs, por exemplo. O ponto � ter um m�nimo de respeito pelos outros e darmos base �s nossas discord�ncias, seja usando uma bibliografia ou argumentando. Pela minha experi�ncia muitas discord�ncias contra conceitos s�o na verdade falta de entendimento (desconfio que meu ponto de diverg�ncia com a coisa das DSLs seja exatamente porque ainda n�o as compreendo bem) e uma conversa e/ou debate �tico e profissional s�o proveitosos para todos.

O que n�o d� � atirar pedra em todo mundo sem sequer entender o que fala.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

O problema Phillip � quando o "discordar" parece ser mais importante do que "compreender". S� depois de compreender um problema podemos "discordar" de alguma solu��o para tal, o que n�o ocorreu por aqui.

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).

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Lezinho]
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).[/quote]

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=pcalcado]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. [/quote]

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

[quote=pcalcado] O outro rapaz aqui (que voc� j� chamou de desonesto neste f�rum s� por birra) ... [/quote]

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

rodrigoy — GMT

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!

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

BiraBoy — GMT

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?

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=rodrigoy]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!

[/quote]

Essa hist�ria de Repositories t� confundindo a cabe�a do pessoal...

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

BiraBoy — GMT

� 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?

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=BiraBoy]
Como poderia fazer isso?
[/quote]

Heran�a?

[code]Repository
public void store(Object obj){
dao.save(obj);
}

ContaRepository extends Repository
PessoRepository extends Repository[/code]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

BiraBoy — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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 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 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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote=BiraBoy] Beleza, e como fa�o para desacoplar o reposit�rio da implementa��o com DAO's?[/quote]

.. o DAO esta desacoplado.

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote] Heran�a? [/quote]

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/

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=Lezinho][quote] Heran�a? [/quote]

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/
[/quote]

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 ...

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=Lezinho]... composi��o resolve neste caso, conforme descrevi a uns 4 posts acima.[/quote]

???

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

[code]
abstract class Repository {

protected DAO dao = DAOFactory.getDAO();

public void store (Object obj){
dao.save(obj);
}

public void remove(Object obj){
dao.delete(obj);
}

}

//e depois

class ClientRepository extends Repository {

public List clientesComPagamentoEmAtrazo(Date date){
// monta uma query e envia ao dao
// o dao � o mesmo que no pai.
return dao.list (Client.class,query);
}

// n�o � necess�rio implementar nem remove, nem save, nem nada que j� exista no Repository pai.
}

[/code]

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

[code]
Repository � uma interface

class GenericRepository implements Repository {

private DAO dao = DAOFactory.getDAO();

public List list(Class c , Query query ){
return dao.list(c,query);
}

public void store (Object obj){
dao.save(obj);
}

public void remove(Object obj){
dao.delete(obj);
}
}

class ClientRepository implements Repository {

private final Repository generico = new GenericRepository();

public List clientesComPagamentoEmAtrazo(Date date){
// monta uma query e envia ao dao
// o dao � o mesmo que no pai.
return generico.list(Client.class,query);
}

// repeti��o dos m�todos da interfac Repository, que � exactemtne
// o que n�o se quer fazer
public void store (Object obj){
generico.store (obj);
}

public void remove(Object obj){
generico.remove(obj);
}

}[/code]

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

[code]XPTO extends HashMap implements Repository [/code]

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=BiraBoy]� 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?[/quote]

Eu tb uso DAOs gen�ricos, do jeito que os caras da Hibernate recomendam. Quando preciso de uma consulta mais espec�fica, eu coloco no ObjetoDeDominioDAO (que extende a GenericDAO).

Nunca precisei usar Repositories (pelo menos classes com o nome ObjetoDeDominioRepository) e consigo ter um modelo arquitetural bastante enxuto com o uso dos recursos do Hibernate.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Sergio, n�o � um erro voc� utilizar heran�a caso o controle do c�digo esta em sua m�o. O perigo � quando voc� tem uma grande equipe e decide usar componentes com base em sua implementa��o e o resto do desenvolvimento necessita herdar de seu componente sem a garantia que a implementa��o dos m�todos ganhos lhe satisfazem

O reposit�rio � espec�fico da regra do dom�nio, assim como sua persist�ncia.
N�o existe garantia que o Reposit�rioUsuario utilize o mesmo DAO para persist�ncia que o Reposit�rioFornecedor (isso pq sabemos da famosa afirma��o, Repository � neg�cio, DAO � servi�o de persist�ncia). Ao afirmar que os DAOs podem ser diferentes, n�o apenas afirmo que um pode usar JDBC e outro JPA, mas principalmente que um pode persistir no Servidor X Oracle e outro no servidor Y MySql. Herdar a forma de que um reposit�rio faz acesso a dados � engessar a abstra��o Repository (a n�o ser que voc� tenha garantias da forma de persitencia, incluindo a localiza��o f�sica).

Ent�o algu�m pode dizer: "Simples, sobreescrevo o m�todo CRUD se necess�rio". Se pensar assim, voc� tem conhecimento dos detalhes da implementa��o da classe pai (caso contr�rio voc� n�o teria m�trica para tomar tal decis�o). Obrigar este tipo de conhecimento, � justamente o que condena os links que postei.

Outra situa��o � de que um userRepository.store() pode fazer muitas outras coisas do que simplesmente invocar um dao.save. Aqui tbm poderia ser dado overhide e depois invocado um super.store, contudo qual � a garantia que o m�todo store do "pai" n�o anule as altera��es do filho?

No exemplo que voc� postou, eu n�o utilizo "Repository generico = new GenericRepository(); " nos Repositories como objeto composto, e sim a interface DAO como atributo. Isso permite que injete diferentes DAOs dependendo que Repository estou e garanta a forma como vou acessar os dados.

[quote=sergiotaborda] Usar Strategy n�o � composi��o, � Strategy.[/quote]

E como eu n�o posso utilizar de composi��o + interface para implementar Strategy?
http://en.wikipedia.org/wiki/Strategy_pattern

Utilizo Strategy para resolver meu acesso a dados do repository. O repositorio n�o sabe como fazer isso, quem sabe � seu atributo DAO (que � a interface "estrat�gica").

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Ah, claro, lembre-se tbm que voc� n�o deve ter um repository para cada Entidade, e sim apenas para Agreggate roots. Sendo assim o reposit�rio tem que fazer CRUD tbm nos agregados. Neste caso a heran�a tbm n�o ajudaria.

Quando eu mencionei que tinha respondido em 4 mensagens anteriores, com o uso de composi��o, n�o queria dizer que escrevi algo gen�rico, pq em minha opini�o isso n�o casa com tudo que estamos discutindo com o que o Repository deve prover. Apenas descrevi a maneira de desacoplar o dao do repository.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

rodrigoy — GMT

[quote=Lezinho]Ol� Rodrigo ...

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.

[/quote]

Lezinho, n�o confunda o Service Layer do Fowler com o Service do Evans. � uma confus�o bem comum. O Service do Evans � um elemento do dom�nio que encapsula comportamentos que voc� n�o consegue alocar naturalmente a um entity. O Evans chama Service Layer de Application Layer (n�o sei porque esses caras s�o t�o amigos e n�o usam a mesma terminologia). Service != Fa�ade.

Eu injeto Services nos Entities para encapsular processamentos complexos ou que podem variar (Strategy).

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=Lezinho]Sergio, n�o � um erro voc� utilizar heran�a caso o controle do c�digo esta em sua m�o. O perigo � quando voc� tem uma grande equipe e decide usar componentes com base em sua implementa��o e o resto do desenvolvimento necessita herdar de seu componente sem a garantia que a implementa��o dos m�todos ganhos lhe satisfazem
[/quote]

Isso pode at� ser verdade. Mas se tivesse medo disso n�o usaria as classes abstractas do java.
Ou as classes abstractas s�o bem implementadas ou n�o s�o. Cabe a quem as faz prover que sejam boas.

O que eu n�o entendi � o codigo que vc prop�e que se use se n�o quisermos usar heran�a. Vamos pensar por um momento que � proibido usar heran�a. Ent�o, como � que, com composi��o, resolveriamos o problema proposto de n�o reescrever m�todos CRUD [u]simples[/u]? Ou vc acha que tais m�todos n�o existem ? Que todos os m�todos do Repositorio s�o complexos por tratarem de agregados ? Vc mesmo me lembrou que nem todos os entitty s�o agregados complexos...

Parece que � ha uma dicotomia: por um lado vc aceita que existem entities simples o suficiente que n�o precisam de repository. Por outro vc aceita que o cliente de um dao deve sempre ser um repository.
Ora, se para comunica com o dao preciso sempre de um repository, ent�o preciso de um mesmo quando o codigo � simples o suficiente para ser igual para todas as entidades. N�o ?
Agora vc me diz que nem todas as entities tem repository... bem, vc tem que escolher. Afinal como �?

Tudo bem que vc pode querer dao de locais fisicos diferentes, mas ai vc simplesmente parametiza a fabrica.
Nada disso impede que o algoritmo que procura e seta o dao do repositorio seja comum a todos os repositorios. Tb nada impede que existam m�todos simples no repositorio que eu herde e reimplemente quando precisar.

Se formos levar esta arquitectura �s ultimas consequencias r�pidamente vc descobre que vc vai precisar de um registro de repositorios, porque essa � a forma correta de declarar os repositorios de forma independente do codigo que os usa (mesmo quando o registro for implicito). No outro extremo vc vai descobrir que se usar um dao do tipo hibernate e todas as entidades forem simples, ent�o vc vai precisar de apenas 1 repositorio generico que delega tudo para 1 dao. E isso autom�tica transforma o " 1 repositorio + 1 dao hibernate " num anti-pattern.

Eu s� tentei apresentar um solu��o para o colega de como reaproveitar os m�todos. Vc levantou a quest�o de usar composi��o em vez de heran�a. Como � que composi��o resolve o problema de n�o ter que reescrever os m�todos ? Foi isso que n�o entendi.

Eu at� entendi que "composi��o" se referia a usar os DAO/Strategy , mas n�o entendo o que isso tem a haver com heran�a da classe repositorio.

[quote]
Ent�o algu�m pode dizer: "Simples, sobreescrevo o m�todo CRUD se necess�rio". Se pensar assim, voc� tem conhecimento dos detalhes da implementa��o da classe pai (caso contr�rio voc� n�o teria m�trica para tomar tal decis�o). Obrigar este tipo de conhecimento, � justamente o que condena os links que postei.
[/quote]

N�o � necess�riamente verdade. Desde que a super classe esteja bem documentada � perfeitamente natural us�-la. Vai-me dizer que nunca usou AbstractAction do swing ? ou AbstractTableModel ? Ent�o! classes abstractas s�o boas. Acho que � bastante simples um contrato que usa um default e vc � livre de redefinir o default quando quiser. E reimplementar store() parece-me bastante intuitivo se vc quiser alterar o algoritmo que guarda o objeto.
Agora vc vai argumentar que o DAO � uma coisa interna do repositorio e portanto teria que saber que o repositorio tem um dao para que ao reimplementar store() o possa usar. Ora, isso � bem simples de conseguir. Fa�a o dao ser privado e crie um metodo protegido para o acessar. Desta forma classes da hierarquia t�m toda a informa��o que precisam e classes clientes nem sonham que existe um dao.
Enfim, se vc quiser fazer bem feito e sem esse temor sobre como o pr�ximo vai reimplementar sua classe abstrata, ha como fazer.

[quote]
Outra situa��o � de que um userRepository.store() pode fazer muitas outras coisas do que simplesmente invocar um dao.save. Aqui tbm poderia ser dado overhide e depois invocado um super.store, contudo qual � a garantia que o m�todo store do "pai" n�o anule as altera��es do filho?
[/quote]

Vc est� partindo do pressuposto errado de que se chamaria super.store(). Se o seu objetivo � redefinir o algoritmo, n�o ha porque usar o algoritmo velho dentro do novo. N�o faz sentido, at� porque vc n�o sabe qual era o velho.

[quote]
No exemplo que voc� postou, eu n�o utilizo "Repository generico = new GenericRepository(); " nos Repositories como objeto composto, e sim a interface DAO como atributo.
[/quote]

Eu sei. Eu entendi isso. O que n�o consigo ver � onde isso substitui heran�a.
(veja que usei o DAO dentro do GenericRepository)

[quote]
[quote=sergiotaborda] Usar Strategy n�o � composi��o, � Strategy.[/quote]

E como eu n�o posso utilizar de composi��o + interface para implementar Strategy?
http://en.wikipedia.org/wiki/Strategy_pattern

[/quote]
[/quote]

Releia os links que passou antes. O dilema n�o � entre herdar ou compor. O dilema � saber usar as diretivas �-UM e TEM-UM corretamente. Quando vc usa strategy, vc claramente sabe que a classe n�o �-uma estrat�gia, a classe tem-uma estrat�gia (de entre v�rias posssiveis). Foi isso que quiz dizer com "strategy n�o composi��o" referindo-me ao facto de ao vc usar DAO como estrat�gia n�o est� escolhendo entre se o repositorio �-UM DAO ou ele TEM-UM DAO. Vc j� escolheu que ele TEM-UM DAO ao escolher o padr�o Strategy. Agora, isso, n�o tem nada a haver com eu poder ou n�o extender o repositorio. Por isso que eu sigo sem entender o isto tem a ver com heran�a. Se houve alguma duvida quanto a se um repositorio �-um dao eu entenderia o seu coment�rio, mas n�o � o caso. O que estava em causa era os v�rios tipos de repositorio compatilharem codigo. A composi��o n�o � um meio deles fazerem isso... pelos menos n�o a composi��o de DAO/Strategy.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote=Domain Driven Design Quickly]A service is not about the object performing
the service, but is related to the objects the operations are
performed on/for. In this manner, a Service [b] usually becomes a
point of connection for many objects[/b].[/quote]

rodrigoy, como voc� pode ver na cita��o acima, um service do DDD � um ponto de conex�o de v�rios outros objetos, afim de fornecer uma determinada opera��o. Muita semelhan�a com o padr�o descrito por Fowler, n�o concorda?

Quanto a nele conter os objetos de dom�nio ou os objetos de dom�nio conter eles:

[quote=Domain Driven Design Quickly]The operation performed refers to other objects in the domain.[/quote]

A execu��o da opera��o do Service � referenciada para outros objetos no dom�nio.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

andre_salvati — GMT

[quote=Lezinho]
[quote=Domain Driven Design Quickly]The operation performed refers to other objects in the domain.[/quote]

A execu��o da opera��o do Service � referenciada para outros objetos no dom�nio.[/quote]

A tradu��o correta seria:

"A execu��o da opera��o do Service [b]refere-se a/aponta para/depende de[/b] outros objetos no dom�nio."

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote=sergiotaborda]Isso pode at� ser verdade. Mas se tivesse medo disso n�o usaria as classes abstractas do java.
Ou as classes abstractas s�o bem implementadas ou n�o s�o. Cabe a quem as faz prover que sejam boas. [/quote]

A quest�o n�o � ser classe abstrata, e sim as funcionalidades herdadas e seu uso. A pr�pria classe Repository do seu pseudo-c�digo n�o tem caracter�stica de classe abstrata, � uma classe convencional, que [b]n�o exige[/b] nenhum m�todo a ser implementado pela classe filha.

� v�lido uso de classes abstratas quando seus filhos assumem como "seus", os m�todos implementados do pai, apenas especializando os m�todos abstratos que justificam a existencia de "N"classes filhas. As classes filhas n�o sobreescrevem os m�todos do pai, pois pela modelagem � assumida tal coes�o.

No seu exemplo n�o existe tais m�todos abstratos logo n�o se justifica a heran�a de classe abstrata. As opera��es de CRUD nos reposit�rios n�o recebem necessariamente o mesmo tratamento (n�o existe conceituamente esta garantia) , logo isso tbm desmotiva o uso da Heran�a para os reposit�rios.

[quote=sergiotaborda]reimplementar store() parece-me bastante intuitivo se vc quiser alterar o algoritmo que guarda o objeto[/quote]

Parece intuitivo pra voc� que criou o m�todo. E se o store da classe pai escreve em log a opera��o e dispara um email al�m de persistir? Voc� acabou de perder funcionalidades. Herdar e sobreescrever quebra o encapsulamento, pois voc� [b]tem[/b] que conhecer os detalhes da implementa��o do pai.

[quote=sergiotaborda]O que eu n�o entendi � o codigo que vc prop�e que se use se n�o quisermos usar heran�a.[/quote]

Para evitar heran�a se usa composi��o (quando a heran�a n�o se qualifica como um subtipo). Heran�a n�o serve para deixar de digitar c�digo, serve para qualificar um subtipo. N�o existe um objeto de neg�cio "Repository" com CRUDs na defini��o de neg�cio, e sim CustomerRepository, ProductRepository e etc, isso �, a n�o ser que de fato Repository fosse abstrata, mas como voc� definiu, ela � concreta, pelo menos l�gicamente. Portanto n�o faz sentido o ancestral em comum, tbm n�o faz sentido tais subtipos, pelo menos para os motivos expostos.

Contudo o q sugeri foi simplesmente desacoplar o DAO, n�o foi fazer "A Repository Gen�rica", mesmo em CRUD. Como venho dizendo n�o vejo sentido nisso.

[quote=sergiotaborda]Parece que � ha uma dicotomia: por um lado vc aceita que existem entities simples o suficiente que n�o precisam de repository. Por outro vc aceita que o cliente de um dao deve sempre ser um repository. [/quote]

Quem disse que n�o s�o todas as entidades que precisam de repositories n�o sou eu, � a literatura:
[quote=Domain Driven design Q.]Provide
repositories only for Aggregate roots (...)[/quote]

Os agregados que n�o possuem Repositories s�o reportados ao Repository da Entity root do Agreggate. Tal reposit�rio � cliente de um DAO, simples assim. Nesta caso o "benef�cio" da heran�a do CRUD pode n�o ser utilizado.

[quote=sergiotaborda]Ou vc acha que tais m�todos n�o existem ? Que todos os m�todos do Repositorio s�o complexos por tratarem de agregados ? Vc mesmo me lembrou que nem todos os entitty s�o agregados complexos... [/quote]
Nunca disse que [b]todos[/b] os m�todos s�o agregados ou que todos s�o complexos. Mas s� por saber que v�o existir agregados e v�o existir CRUDs que n�o v�o simplesmente chamar um DAO diretamente (o neg�cio possibilita isso), ja me faz crer que o poss�vel ancestral comum seria apenas por conveni�ncia e n�o por um bom Design, e isso n�o me agrada.

[quote=sergiotaborda]Agora vc vai argumentar que o DAO � uma coisa interna do repositorio e portanto teria que saber que o repositorio tem um dao para que ao reimplementar store() o possa usar[/quote]
Pelo contr�rio, pra mim quem tinha que ter o DAO � o MinhaClasseRepository, pois OutraClasseRepository pode ter um DAO diferente... Uma classe "gen�rica" com a implementa��o do DAO toda sua n�o acho uma boa sugest�o. No m�nimo isso deveria ser setado pelos filhos, para quem quer utilizar este tipo de arquitetura ...

[quote=sergiotaborda]Vc est� partindo do pressuposto errado de que se chamaria super.store(). Se o seu objetivo � redefinir o algoritmo, n�o ha porque usar o algoritmo velho dentro do novo. N�o faz sentido, at� porque vc n�o sabe qual era o velho. [/quote]
Claro que pode fazer sentido. Voc� pode apenas somar uma regra, como disparar uma thread de gera��o de relat�rio, e continuar com a outra defini��o do super.store. Mas a quest�o � se isso seria uma boa id�ia. Eu acho que n�o, mas tem gente que faz (principalmente se usou a heran�a s� por conveniencia).

[quote=sergiotaborda]
Se formos levar esta arquitectura �s ultimas consequencias r�pidamente vc descobre que vc vai precisar de um registro de repositorios, porque essa � a forma correta de declarar os repositorios de forma independente do codigo que os usa (mesmo quando o registro for implicito).[/quote]

Que exagero... eu s� usaria Regyster se hoje em dia ainda n�o existisse tantos frameworks com D.I.P.

[quote=sergiotaborda]O que estava em causa era os v�rios tipos de repositorio compatilharem codigo. A composi��o n�o � um meio deles fazerem isso... pelos menos n�o a composi��o de DAO/Strategy[/quote]

Estamos de fato discutindo coisas diferente. Meus posts foram em rela��o a pergunta "Como desacoplar o DAO?". Justamente pq acho uma p�ssima id�ia os Reposit�rios compartilharem CRUD... (ja disse, opera��es do reposit�rio s�o opera��es de neg�cio, n�o existe garantia que todos os CRUDs dever�o ter o mesmo comportamento de neg�cio).

Mas t�, nada disso � regra e ningu�m vai chegar a lugar algum, gosto � gosto. Particularmente, eu n�o aprovo Heran�a por conveni�ncia, n�o acho uma boa pr�tica.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote=Taz]A execu��o da opera��o do Service refere-se a/aponta para/depende de outros objetos no dom�nio[/quote]

Apenas transcrevi a id�ia ... no caso use ent�o:
A execu��o da opera��o do Service aponta para outros objetos no dom�nio(...) d� na mesma.
Em DDD Service continua sendo um workflow para os objetos de neg�cio.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=Lezinho][quote=Domain Driven Design Quickly]A service is not about the object performing
the service, but is related to the objects the operations are
performed on/for. In this manner, a Service [b] usually becomes a
point of connection for many objects[/b].[/quote]

rodrigoy, como voc� pode ver na cita��o acima, um service do DDD � um ponto de conex�o de v�rios outros objetos, afim de fornecer uma determinada opera��o. Muita semelhan�a com o padr�o descrito por Fowler, n�o concorda?

Quanto a nele conter os objetos de dom�nio ou os objetos de dom�nio conter eles:

[quote=Domain Driven Design Quickly]The operation performed refers to other objects in the domain.[/quote]

A execu��o da opera��o do Service � referenciada para outros objetos no dom�nio.[/quote]

O que Fowler descreve n�o � um padr�o, mas uma camada... No DDD, services s�o conceitos do dom�nio, assim como reposit�rios e entities.

[url=http://martinfowler.com/eaaCatalog/serviceLayer.html]Services Layer[/url] (tamb�m conhecido como Application Layer) n�o deve ter regras de neg�cio (apesar de que do ponto de vista do cliente � indiferente). O papel do services como camada � a coordena��o de fluxos e responder �s solicita��es, eventualmente entrando na camada de dom�nio.

Ou seja, de semelhante s� tem o nome.. Por isso prefiro o termo Application Layer.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

[quote=cmoscoso ]"O que Fowler descreve n�o � um padr�o, mas uma camada..."[/quote]

Se n�o � um padr�o, ent�o tente dizer isso a Randy Sttaford, que descreve no POAA a literal diferen�a entre o "PATTERN" Session Fa�ade e o "PATTERN" Service Layer, exatamente com estas palavras. Neste mesmo cap�tulo � mencionada a Application Layer, tendo como a ServiceLayer uma ponte entre esta (AppLayer) e a modelo de dom�nio.

O Domain Driven Design diz que:
"A Service usually becomes a point of connection for many objects"
... exatamente como um objeto da ServiceLayer, onde que n�o tendo l�gica de neg�cio, delega essa aos objetos do dom�nio.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=Lezinho][quote=cmoscoso ]"O que Fowler descreve n�o � um padr�o, mas uma camada..."[/quote]

Se n�o � um padr�o, ent�o tente dizer isso a Randy Sttaford, que descreve a no POAA a literal diferen�a entre o "PATTERN" Session Fa�ade e o "PATTERN" Service Layer, exatamente com estas palavras. Neste mesmo cap�tulo � mencionada a Application Layer, tendo como a ServiceLayer a ponte entre esta e a modelo de dom�nio.[/quote]

Voc� quer dizer ent�o que Application Layer � a Client Layer? S�rio, n�o entendo sua interpreta��o de Application Layer.

No link da minha resposta anterior tem uma cita��o desse cara sobre Services Layer: "Defines an [b]application's boundary[/b] with a layer of services that establishes a set of available operations and coordinates the application's response in each operation."

[quote=Lezinho]O Domain Driven Design diz que:
"A Service usually becomes a point of connection for many objects"
... exatamente como um objeto da ServiceLayer, onde que n�o tendo l�gica de neg�cio, delega essa aos objetos do dom�nio.[/quote]

Uma defini��o mais clara seria: Um Service (DDD) � um ponto de conex�o para v�rios objetos (de dom�nio) que compartilham de uma mesma regra de neg�cio. Observe que n�o sa�mos do domain layer aqui.

A diferen�a fica evidente se dissermos que um Service (DDD) poderia ser chamado da Service/Applcation Layer, mas o contr�rio n�o deveria ser permitido se voc� considerar uma premissa b�sica da separa��o em camadas: Depend�ncia apenas de camadas abaixo.

Services e Repositorios pertecem ao dom�nio
Service/Application Layer N�O pertece ao dom�nio (apesar de fazer uso do mesmo)

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

"Client Layer"?

Client Layer � qualquer camada que fa�a uso de outra camada, ou seja, uma camada cliente da outra... isto sim n�o � Padr�o. Praticamente todos diagramas DDD envolve "Client"s que representam tais camadas.

Um reposit�rio pode ser client de um DAo, uma Entity pode ser cliente de um VO, um Aggregate pode ser client de um Entity ...

"Camada de aplica��o" � aquela relevante ao contexto da aplica��o (ManagedBeans, Actions) ou aquelas que server como uma Supercamada para a de Servi�os, oferecendo suporte como de email, ftp, etc (de nada tem haver com o neg�cio).
No livro de Fowler voc� v� Service direcionados ao neg�cio, que faz o workflow aos entities e VOs, e aqueles definidos como seu supertipo para suporte a servi�os da aplica��o.

Na pr�pia cita��o que voc� coloca, � definido o Service como uma fronteira entre a aplica��o e o Dom�nio.

No DDD isso n�o muda, podendo existir tanto Service voltado a neg�cio como para Aplica��o:

[quote=Domain Driven Design]"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between services which
belong to the domain layer, and those belonging to the
infrastructure. [b]There can also be services in the application layer
which adds a supplementary level of complexity.[/b]"[/quote]

O texto em negrito do DDD � praticamente o mesmo do PoEAA.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=Lezinho]"Client Layer"?

Client Layer � qualquer camada que fa�a uso de outra camada...[/quote]

Quem disse o contr�rio?

[quote=Lezinho]Um reposit�rio pode ser client de um DAo, uma Entity pode ser cliente de um VO, um Aggregate pode ser client de um Entity ...[/quote]

Estamos falando de camadas; reposit�rio n�o � camada, entity n�o � camada, aggregate n�o � camada.. Isso sim � padr�o

[quote=Lezinho]"Camada de aplica��o" � aquela relevante ao contexto da aplica��o (ManagedBeans, Actions) ou aquelas que server como uma Supercamada para a de Servi�os, oferecendo suporte como de email, ftp, etc (de nada tem haver com o neg�cio).[/quote]

Aqui deu a entender que seus Actions poderiam estar na camada de aplica��o. O que n�o � o caso certo?

[quote=Lezinho][quote=Domain Driven Design]"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between services which
belong to the domain layer, and those belonging to the
infrastructure. [b]There can also be services in the application layer
which adds a supplementary level of complexity.[/b]"[/quote][/quote]

Quem est� dizendo que os Services s�o os mesmos � voc�. Agora j� temos 3 services. Sua cita��o confirma que Services do DDD n�o � o Service Layer. Ou seja, nada impede que tenhamos entities chamando repositorioes ou entities chamando services ja que estamos falando estritamente de services "which belong to the domain layer".

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Eu j� estou achando a discuss�o confusa demais para entender mas s� um pontinho:

[quote=cmoscoso]
Estamos falando de camadas; reposit�rio n�o � camada, entity n�o � camada, aggregate n�o � camada.. Isso sim � padr�o
[/quote]

[url=http://www.amazon.com/Pattern-Oriented-Software-Architecture-System-Patterns/dp/0471958697]Camadas (Layers) � um padr�o sim[/url]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=pcalcado]Camadas (Layers) � um padr�o sim[/quote]

Eu quis dizer que fowler n�o define Service Layer como um padr�o de domain model (ou um "building block" como Evans define seus padr�es)

Services de DDD pertencem ao dom�nio do problema e por isso podem existir entities que dependam de tais Services.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Aiaiai ...

Services s�o Services. Existem de aplica��o e de neg�cio, n�o sei onde esta a complica��o disso. Tanto o DDD quanto o PoEAA comentam dos dois.

De fato Phillip, a discuss�o era de Manga e j� estamos falando de Banana.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=Lezinho]Aiaiai ...

Services s�o Services. Existem de aplica��o e de neg�cio, n�o sei onde esta a complica��o disso. Tanto o DDD quanto o PoEAA comentam dos dois.

De fato Phillip, a discuss�o era de Manga e j� estamos falando de Banana.[/quote]

Desnecess�rio seus gemidos... Inclusive, � lament�vel a atitude de desd�m das pessoas quando questionadas quanto a sua interpreta��o sobre os textos mencionados.

Voc� n�o percebe mas a complica��o est� no fato de voc� n�o conseguir explicar com clareza a diferen�a entre a camada Service e Application. Talvez porque n�o haja. Voc� cita duas fontes que definem a mesma coisa com 2 nomes, reconhecidamente um conflito na nomenclatura atual sen�o, vamos l�, precisamos ter claro as responsabilidades de cada camada, mas esse n�o parece ser o caso, pelo contrar�io, voc� parece ignorar princ�pios importantes como YAGNI e KISS e se justifica colando cita��es sem contexto do seu autor preferido.

Talvez o tamanho dessa thread tenha feito voc� perder o foco mas eu vou tentar ser ainda mais claro:
[b]Eu considero as camadas Service e Application como a mesma e n�o sinto falta de outra camada.[/b]

Pense que existem pessoas que est�o interessadas em comecar a aplicar pr�ticas mais modernas para o seu projeto de software OO e precisam competir com as tais arquiteturas de "refer�ncia" estabelecidas. Eu n�o vejo como essa camada adicional pode ajudar essas pessoas a melhor organizar sua arquitetura usando apenas o seu argumento de que tem que ser assim porque o mestre mandou.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

Bom, deixando suas observa��es pessoais de canto (pq em meu p� quem pega � a minha namorada), vamos l�:

[quote=cmoscoso]Voc� n�o percebe mas a complica��o est� no fato de voc� n�o conseguir explicar com clareza a diferen�a entre a camada Service e Application. Talvez porque n�o haja[/quote]

Talvez [b]VOC�[/b] n�o percebeu que n�o sou eu que menciona sobre as diferen�as, mas sim os pr�prios autores, como no texto que citei no post anterior. Ali�s vale repetir a cita��o:

[quote=Domain Driven Design]
"While using Services, is important to keep the domain layer
isolated. It is easy to get confused between [b]Services[/b] which
belong to the [b]domain layer[/b], and those belonging to the
[b]infrastructure[/b]. There can also be [b]Services in the application layer[/b]
which adds a supplementary level of complexity."
[/quote]

... pra mim esta bem clara e n�tida a exist�ncia entre Services de infraestrutura, pertencentes a camada de aplica��o, e os services pertencentes a camada de dom�nio, aqueles que se relacionam com um caso de uso. Detalhe, o trecho acima trata de Services no cap�tulo destinado a Services em um livro de DDD, portanto s�o Services do DDD. N�o h� falta de contextualiza��o.

Com base no trecho acima, olhe no diagrama de classe que Fowler colocou no PoEAA (a qualidade ficou p�ssima, mas acho que voc� vai conseguir visualizar as classes), que esta anexada com este post. L� esta descrito um modelo exatamente como na cita��o, um service para o neg�cio e um para a infraestrutura da aplica��o.

[quote=cmoscoso]
(...) e vc se justifica colando cita��es sem contexto do seu autor preferido.[/quote]

Fora do contexto? S�o trechos totalmente pertinentes a suas coloca��es, vindas de autores como Martin Fowler, Eric Vans, Floyd Marinescu... Se estas pessoas n�o s�o boas refer�ncias, ent�o realmente estou mal embasado.

[quote=cmoscoso]
Eu considero as camadas Service e Application como a mesma e n�o sinto falta de outra camada.

Pense que existem pessoas que est�o interessadas em comecar a aplicar pr�ticas mais modernas para projeto de software OO e precisam competir com as arquiteturas de refer�ncia estabelecidas. Eu n�o vejo como essa camada adicional pode ajudar essas pessoas a melhor organizar sua arquitetura usando apenas o seu argumento de que tem que ser assim porque o mestre mandou.
[/quote]

Se voc� n�o sente falta, n�o utiliza. Nenhum destes autores citados dizem que voc� DEVE usar um Service voltado para os servi�os de aplica��o, ou um como ponte para os objetos de dom�nio. Voc� usa conforme sua necessidade. Toda camada � "adicional", voc� usa se sente necessidade de us�-la.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

rodrigoy — GMT

[lugar errado]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

rodrigoy — GMT

[quote=pcalcado]

S� � bom focarmos que discordar � �timo. Eu discordo do Fowler bastante em DSLs, por exemplo. O ponto � ter um m�nimo de respeito pelos outros e darmos base �s nossas discord�ncias, seja usando uma bibliografia ou argumentando. ...[/quote]

Eu coleciono essas discord�ncias com autores famosos... n�o d� pra concordar com tudo. Eu discordo com a vis�o do Philipe Krunchten sobre An�lise e Design. Discordo com a vis�o do Ambler sobre MDA. Discordo com a vis�o do Ivar Yacobson sobre as maravilhas de um Use Case ser um Classifier.

Lezinho, vc tem algum paper sobre essas regras de seguran�a com o Drools? (creio que vc tenha aplicado isso na sua aplica��o SEAM).

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Eu estive com o Krunchten num workshop do SPIN em porto alegre e pesar da fantastca sacada dos pontos de vsta arquiteturais eu discordo bastante dele tambem. Ele nsiste em BDUF sem parar muito para debater.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Cobracan — GMT

Aspecto s� dever ser utilizado para tratar dos interesses transversais ou sistemicos e n�o na sua l�gica de neg�cio.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Cobracan]Aspecto s� dever ser utilizado para tratar dos interesses transversais ou sistemicos e n�o na sua l�gica de neg�cio. [/quote]

Por que?

Uma regra de neg�cio ode se comportar como aspecto, valida��es s�o um exemplo.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

rodrigoy — GMT

Injetar um repositorio ou um service numa entidade � um interesse transversal. Mesmo que n�o fosse, se uma determinada regra de neg�cio fosse melhor implemetada com aspectos, na minha opini�o, n�o teria problemas. Desde que exista boas raz�es para tal.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Acho que a confus�o este caso � o que � regra de neg�cio. Um Domain Model contem regras de neg�cio mas provavelmente n�o � o �nico lugar onde estas ficam. Dificilmente as rela��es dentro de um domain model seria tratadas com aspectos mas as outras regras isoladas poderiam.

Service Layer (PoEAA) == Application Layer (DDD)

wanderson.santos — GMT

[quote]
Talvez porque n�o haja.
[/quote]

E realmente n�o h�.

O proprio Fowler explica em um post no seu bliki, esta confus�o (normal) sobre a salada de termos que os autores criam.

[quote]
Eric Evans's excellent book Domain Driven Design has the following to say about these layers.

[list]Application Layer [his name for Service Layer][/list]
[list]Domain Layer (or Model Layer)[/list]
http://martinfowler.com/bliki/AnemicDomainModel.html

[/quote]

Vejam que ele precisa explicar isso, porque esta falta de entendimento que causa o "Anemic Domain Model". Vejam: � normal existir esta confus�o.

E a explica��o pra isso � a mais clara poss�vel: pessoas agem e pensam de formas diferentes. E d�o "nome aos bois" de formas diferentes. E autores s�o pessoas!

Estas pessoas (Fowler, Evans, Booch, Rockford Lotha, etc..) tem id�ias/solu��es e as publicam em formas de livros e artigos. E sempre encontram os que concordam e discordam.

Eles n�o formam um grupo para debater e formalizar estas id�ias/solu��es e nomes. E mesmo assim elas s�o compartilhadas.

Estas id�ias/solu��es existem para nos ajudar, "iluminar nosso caminho", mas normalmente cada uma delas foi concebida em um "caminho" distinto. N�o devemos tomar como verdade ou como padr�o o que um ou outro autor apresenta sem definir o contexto, o caminho que *n�s* estamos pisando.

A prop�sito, a diferen�a entre uma solu��o e uma id�ia seria um bom assunto pra outro post. Normalmente solu��es nos ajudam na pr�tica, e id�ias quebram paradigmas, ajudam a vender livros e palestras, mas n�o h� garantia de que v�o resolver um problema e ainda deixam a cabe�a dos arquitetos pegando fogo! (DSL?).

* (Como toda regra tem uma exce��o, o Manifesto �gil partiu de uma reuni�o entre os autores)

PS.: Este � meu primeiro post. Espero poder contribuir e aprender muito por aqui.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Cobracan — GMT

[quote=pcalcado][quote=Cobracan]Aspecto s� dever ser utilizado para tratar dos interesses transversais ou sistemicos e n�o na sua l�gica de neg�cio. [/quote]

Por que?

Uma regra de neg�cio ode se comportar como aspecto, valida��es s�o um exemplo.[/quote]

Aspecto � um assunto bastante interessante, e um bom livro sobre aspecto � Aspectj Programa��o Orientada a Aspectos com Java, editora Novatec. O aspecto veio para ajudar onde a OO falha, separar os interesses funcionais dos interesses sist�micos.
"A incapacidade da OO de modularizar os interesses sist�micos ocasiona os problemas resultantes da descentraliza��o do c�digo:
.Replica��o do c�digo;
.Dificuldade de manuten��o;
.Redu��o da capacidade de reutiliza��o de c�digo;
.Aumento da dificuldade de compreens�o;" (Diogo Vin�cius Winck e Vicente Goetten Jr)

Entenda funcional como sua l�gica de neg�cios e sist�micos o restante como exce��es.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Cobracan]
Aspecto � um assunto bastante interessante, e um bom livro sobre aspecto � Aspectj Programa��o Orientada a Aspectos com Java, editora Novatec. O aspecto veio para ajudar onde a OO falha, separar os interesses funcionais dos interesses sist�micos.
"A incapacidade da OO de modularizar os interesses sist�micos ocasiona os problemas resultantes da descentraliza��o do c�digo:
.Replica��o do c�digo;
.Dificuldade de manuten��o;
.Redu��o da capacidade de reutiliza��o de c�digo;
.Aumento da dificuldade de compreens�o;" (Diogo Vin�cius Winck e Vicente Goetten Jr)

Entenda funcional como sua l�gica de neg�cios e sist�micos o restante como exce��es.

[/quote]

Voc� n�o me respondeu. Porque eu n�o posso tratar minhas regras de neg�cos como aspectos?

Eu n�o li este livro mas acredito que possa ter passado alguma confus�o. [b]AOP diz como implementar os conceitos mas n�o diz quais s�o[/b] (tanto que os exemplos sempre recaem nos mesmos de sempre: log, seguran�a, transa��o), regras de neg�cio podem ser implementadas como conceitos ortogonais se for interessante. Um exemplo que j� citei � valida��o, outro � seguran�a. Ambos geralmente s�o regras de neg�cio e n�o uma necessidade n�o-funcional (o que voc� chamou de 'sistemico'). Recomendo que leia o livro de Ramnivas Laddad , AspecJ in Action. N�o sei se tem em portugu�s.

[url=http://www-128.ibm.com/developerworks/java/library/j-aopwork15/]Um artigo do autor cita[/url]:

[quote]At the system level, security, transaction management, and thread-safety concerns are commonly implemented using AOP. Many business logic problems (also known as domain-specific concerns) also exhibit crosscutting concerns upon close examination and lend themselves to modularization using aspects. On the other side, units such as classes and packages show code tangling and code scattering at a smaller scale (what I call local or micro crosscutting concerns). Aspect-oriented refactoring can help resolve these kinds of concerns by using aspects to improve the code structure. (See Resources to learn more about aspect-oriented refactoring techniques.)
[/quote]

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Cobracan — GMT

[quote=pcalcado][quote=Cobracan]
Aspecto � um assunto bastante interessante, e um bom livro sobre aspecto � Aspectj Programa��o Orientada a Aspectos com Java, editora Novatec. O aspecto veio para ajudar onde a OO falha, separar os interesses funcionais dos interesses sist�micos.
"A incapacidade da OO de modularizar os interesses sist�micos ocasiona os problemas resultantes da descentraliza��o do c�digo:
.Replica��o do c�digo;
.Dificuldade de manuten��o;
.Redu��o da capacidade de reutiliza��o de c�digo;
.Aumento da dificuldade de compreens�o;" (Diogo Vin�cius Winck e Vicente Goetten Jr)

Entenda funcional como sua l�gica de neg�cios e sist�micos o restante como exce��es.

[/quote]

Voc� n�o me respondeu. Porque eu n�o posso tratar minhas regras de neg�cos como aspectos?

Eu n�o li este livro mas acredito que possa ter passado alguma confus�o. [b]AOP diz como implementar os conceitos mas n�o diz quais s�o[/b] (tanto que os exemplos sempre recaem nos mesmos de sempre: log, seguran�a, transa��o), regras de neg�cio podem ser implementadas como conceitos ortogonais se for interessante. Um exemplo que j� citei � valida��o, outro � seguran�a. Ambos geralmente s�o regras de neg�cio e n�o uma necessidade n�o-funcional (o que voc� chamou de 'sistemico'). Recomendo que leia o livro de Ramnivas Laddad , AspecJ in Action. N�o sei se tem em portugu�s.

[url=http://www-128.ibm.com/developerworks/java/library/j-aopwork15/]Um artigo do autor cita[/url]:

[quote]At the system level, security, transaction management, and thread-safety concerns are commonly implemented using AOP. Many business logic problems (also known as domain-specific concerns) also exhibit crosscutting concerns upon close examination and lend themselves to modularization using aspects. On the other side, units such as classes and packages show code tangling and code scattering at a smaller scale (what I call local or micro crosscutting concerns). Aspect-oriented refactoring can help resolve these kinds of concerns by using aspects to improve the code structure. (See Resources to learn more about aspect-oriented refactoring techniques.)
[/quote]

[/quote]

A quest�o em s� � que aspecto veio para completar a OO, onde a OO falha ou deixa a desejar. Voc� pode usar aspectos para sua l�gica de neg�cio mas me parece muito estranho um SOO usar aspecto em sua camada de neg�cios e particularmente tenho minhas d�vidas. Esse assunto � muito interessante e pol�mico. N�o sou um especialista para afirmar o que deve ser ou n�o, mas a minha opini�o � que devemos separar as responsabilidades.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Thiago Senna — GMT

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=pcalcado]
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.[/quote]

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

VOs? COmo assim?

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=Thiago Senna]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.
[/quote]

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.

[quote]
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.[/quote]

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)

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Edufa — GMT

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Edufa]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.[/quote]

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Cobracan — GMT

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Cobracan]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. [/quote]

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 ([b]especialmente[/b] os com AspectJ, com Spring AOP, JBoss AOP e essas coisas ainda d� pra engolir). Acredite em mim: [b]voc� n�o precisa de e n�o quer um programa 100% OO[/b].

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

cmoscoso — GMT

[quote=pcalcado]VOs?[/quote]

[url=http://domaindrivendesign.org/]DDD[/url]

[quote=pcalcado]COmo assim?[/quote]

[code]
public class Intervalo {
...

public Intervalo(int inicio, int quantidade) {
this.inicio = inicio;

if (quantidade < 1) {
throw new IllegalArgumentException("Quantidade no intervalo deve " +
"ser maior que zero");
}

...
}
[/code]

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..

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

nbluis — GMT

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=cmoscoso]
[url=http://domaindrivendesign.org/]DDD[/url]
[/quote]

Ufa!

[quote=cmoscoso]
Eu tenho v�rias valida��es assim, n�o s� nos Value Object claro, por isso talvez fosse uma boa usar AOP.
[/quote]

Essas valida��es, pode defini��o ficam nos objetos. D� uma olhada no que escrevi acima nesse exemplo do tri�ngulo.

[quote=cmoscoso]
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..[/quote]

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

Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=nbluis]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.[/quote]

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Thiago Senna — GMT

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

[code]
public class Infrator {

String nome;
String idade;

// getters and setters omitidos ;)

}
[/code]

[code]
public class MenorInfratorSpecification {

public boolean isSatisfiedBy(Infrator infrator) {
return infrator.getIdade() < 18;
}

}
[/code]

[code]
public class FEBEM {

public void addMenorInfrator(Infrator infrator) {
MenorInfratorSpecification spec = new MenorInfratorSpecification();
if (spec.isSatisfiedBy(infrator)) {
// prende o menor infrator
} else {
throw new RuntimeException("Este infrator n�o � de menor");
}
}

}
[/code]

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?

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

pcalcado — GMT

[quote=Thiago Senna]
Este seria um bom exemplo de valida��o (de regra de neg�cio) utilizando uma Specification?
[/quote]

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.

[quote=Thiago Senna]
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?[/quote]

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Thiago Senna — GMT

[quote=sergiotaborda] 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. [/quote]
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..

[quote=Shoes]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?[/quote]
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..

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

sergiotaborda — GMT

[quote=Thiago Senna][quote=sergiotaborda] 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. [/quote]
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..
[/quote]

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.

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

GraveDigger — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

GraveDigger — GMT

[quote=Alessandro Lazarotti]Em que momento vc tem essa Exception? Quando o Application Server inicia ou quando sua aplica��o faz uso efetivo da inje��o?[/quote]

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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:

[code]
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);

}

}

}
[/code]

[]'s

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

GraveDigger — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Alessandro Lazarotti — GMT

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

Re:Inje��o de Depend�ncia em Domain Model (ServiceLayer+DomainModel+Repository)

Romulinho — GMT

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