DAO Reference Inside an Entity Domain Object?

[dejanp]

Well, kind of. I'd say Spring 2 @Configurable annotations + AspectJ are the way to go and ORM specific stuff can be ignored.

[ssozonoff]

I would agree with this conclusion though there is at least one viable alternative to using annotations as discussed here by directly using an Aspect

http://blogs.opensymphony.com/plight....html#comments

Also at the moment I have tried the @Configurable solution having read 4-5 different docs about it and can't get it to work. I have no errors and the weaving seems to happen based on what I see in the log output but the dependencies never get injected and I get NullPointer exceptions.

Serge

[Bosmon]

I really can't understand the current enthusiasm, *especially* amongst the Spring community, for annotations applied to the domain model since they do represent a direct Spring dependency. Annotations need importing, just like any other interface - you'd never import "BeanNameAware" into your domain model, would you now!

Spring, to its credit does maintain support for the extrinsic (XML-configured) style of aspect configuration, but disappointingly this receives second billing in the documentation and excites little enthusiasm amongst the community. Perhaps because it is not quite so "cool" and Java 5-ey.

Going further, I'm unconvinced that adding storage-specific signatures (save(), etc.) into ones domain model is an architecturally sound practice, even if with Spring 2 it may now be done as transparently and cleanly as possible. But don't get me started on that... :P

OK, well you did! Persistence functionality within the domain should always be an *option* for rich-domain applications, but I am very concerned to see it being steam-rollered as a "standard solution". To me it seems more of a get-out for deficient persistence and view technologies rather than an architecturally desirable end in its own right.

[ssozonoff]

I really can't understand the current enthusiasm, *especially* amongst the Spring community, for annotations applied to the domain model since they do represent a direct Spring dependency. Annotations need importing, just like any other interface - you'd never import "BeanNameAware" into your domain model, would you now!

Fair enough but its nice to know its possible using annotations and in some cases it might be fine to do it this way. Alternatively as you rightly mention below there is an alternative. I agree that there are not enough examples floating around yet using this alternative and it could be documented more to help out newbies like myself ;-)

Going further, I'm unconvinced that adding storage-specific signatures (save(), etc.) into ones domain model is an architecturally sound practice,

At the end of this day each person will make a call on what he does. I think the main point to walk away with is that you can inject ANY dependecies into your domain objects be it a helper, dao or whatever. This helps promote a rich domain model.

My 2cents

[karldmoore]

I really can't understand the current enthusiasm, *especially* amongst the Spring community, for annotations applied to the domain model since they do represent a direct Spring dependency. Annotations need importing, just like any other interface - you'd never import "BeanNameAware" into your domain model, would you now!

Spring, to its credit does maintain support for the extrinsic (XML-configured) style of aspect configuration, but disappointingly this receives second billing in the documentation and excites little enthusiasm amongst the community. Perhaps because it is not quite so "cool" and Java 5-ey.

Going further, I'm unconvinced that adding storage-specific signatures (save(), etc.) into ones domain model is an architecturally sound practice, even if with Spring 2 it may now be done as transparently and cleanly as possible. But don't get me started on that... :P

OK, well you did! Persistence functionality within the domain should always be an *option* for rich-domain applications, but I am very concerned to see it being steam-rollered as a "standard solution". To me it seems more of a get-out for deficient persistence and view technologies rather than an architecturally desirable end in its own right.

I have to agree with the annotations rant. One of the things I love about Spring, is that the presentations and documentation I have read (from the source so to speak) always talk about decoupling from Spring. The idea of using Spring classes within your application is kept to bare minimum and avoided if at all possible. I am hugely impressed how many times I've heard people banging on about this.

Now don't get me wrong, I do like annotations.... but I'm not convinced that I want to litter my code with Spring specific annotations. Although I can use 1.5 I would prefer to keep the spring coupling as low as possible.

Lots of the documentation does seem to be annotation biased. I do conceed however there is an alternative and there is a discussion of XML or not to XML. I think the documentation should show examples using both approaches.

As for the storage-specific signatures.... Its good that you can inject dependencies into domain objects, but I can see some people now using this new toy everywhere. Spring 2.0 vs. the Anemic Domain Model on TSS shows the confusion amongst the community, and there was an interesting link at the start of this thread to an answer from Eric Evans (worth a read).

I'm glad its there and I'm sure I will use it, but for me its a tool and not a standard solution.

[dejanp]

If you are somehow allergic to org.springframework packages, you can always extend the annotation classes.

Seriously. I don't see the use of Springified domain model in implementing methods like save() or something as generic like that. What I like to have is a model that's consistent. For example I can have Order.getOrderItems() method - simple, lazy loaded foreign key fetch. It's only natural to also have something like Order.getOrderItemWithPrice(double minPrice). Now I can implement that using basic getOrderItems() and iterating over it, or I can invoke a query. It's definitely very, very bad that I have to move the second method out of the Order class just because it's implementation is too slow if I use domain methods only and I have to use some DAO collaborators to optimize it.

[karldmoore]

If you are somehow allergic to org.springframework packages, you can always extend the annotation classes.

Seriously. I don't see the use of Springified domain model in implementing methods like save() or something as generic like that. What I like to have is a model that's consistent. For example I can have Order.getOrderItems() method - simple, lazy loaded foreign key fetch. It's only natural to also have something like Order.getOrderItemWithPrice(double minPrice). Now I can implement that using basic getOrderItems() and iterating over it, or I can invoke a query. It's definitely very, very bad that I have to move the second method out of the Order class just because it's implementation is too slow if I use domain methods only and I have to use some DAO collaborators to optimize it.

I'm not allergic to Spring (its great), I just want references in code kept to a minimum. :-)

I do agree though with the getOrder* () examples though. It is natural to ask the order for a filtered set, its only the implementation that says its a bad idea to iterate over it.

In this case the idea of using injection would be nice, but I'm really not sure. The Eric Evans answer said that injecting the Repository was a bad idea. I like the idea but I'm not sure I like it as a solution.

[dejanp]

As for annotations - I'm pretty sure writing a xml-driven instead of annotation-driven version should be possible.

Injection in domain objects - well, I'm pretty sure you can't create a non-trivial rich domain model without using one single collaborator class somewhere, and if you need collaborators then they need to be instantiated and configured somehow, so - why not DI? Of course, you could use classic statics/singletons, but we don't want to open that can of worms again.

[karldmoore]

As for annotations - I'm pretty sure writing a xml-driven instead of annotation-driven version should be possible.

Injection in domain objects - well, I'm pretty sure you can't create a non-trivial rich domain model without using one single collaborator class somewhere, and if you need collaborators then they need to be instantiated and configured somehow, so - why not DI? Of course, you could use classic statics/singletons, but we don't want to open that can of worms again.

The last two projects have used the XML approach, the question wasn't really can you do it, it was the annotation focus within the documentation.

I like the fact you can use injection with domain objects, I think its just the mindset that is lacking. What should/shouldn't be injected into a domain model? Is it right that a domain object has references to services and daos etc...

[Bosmon]

As for annotations - I'm pretty sure writing a xml-driven instead of annotation-driven version should be possible.

Injection in domain objects - well, I'm pretty sure you can't create a non-trivial rich domain model without using one single collaborator class somewhere, and if you need collaborators then they need to be instantiated and configured somehow, so - why not DI? Of course, you could use classic statics/singletons, but we don't want to open that can of worms again.

I think we all agree - you are talking about *desirable* semantics of the domain model driving the use of the aspect/injection system, which is exactly how it should be. All that concerns me is the reverse - quite often, one sees technological considerations forcing semantics or dependencies onto the domain model, which is a great evil. I'm nothing but enthusiastic about the enormous power we have with the new "Royal Road" leading from Spring-AOP to AspectJ, which now allows us to "inject the dependencies other beers cannot reach" but want to see that this power isn't used indiscriminately.

No, don't get me wrong, I think the power of AspectJ used to deliver dependencies across yet further distances (and hence to avoid polluting yet more further of the intervening code) is nothing short of brilliant. To me, the entire thrust of the Spring framework has been to provide tools to help developers in removing dependencies from wherever in their design they are unnecessary, and the introduction of compile-time or load-time DI is the natural and glorious conclusion of this story.

I'm only concerned that by presenting annotation-driven injection *first*, Spring development has "skipped a step". For many cases, the dependency cost of the annotations is quite acceptable and is easily balanced by the increased convenience and locality, but I'd still like to see the dependency-free version (XML) presented as the "default" option with annotations available as an "optimisation". Otherwise casual readers may be forgiven for coming away with the impression that the first priority is *convenience* rather than excellence of design, in which case we may as well go back to using global variables in C again :P

The thing that always attracted me to Spring was the "pay-as-you-go" dependency system - what set it head and shoulders above every other framework was that it admitted that no matter how marvellous it was, you were not only able, but encouraged to write code free of its dependencies. Now in Spring 2 I see this essential humility and developer-centric (rather than framework-centric) value system more at risk, which makes me concerned.