Tony, > method being delegated to a service or DAO -- you mean it's acceptable > to inject services or other singletons into your business objects? I > didn't even consider that option. (I always thought your singletons > should only be called by a controller). Of course, I understand that > it doesn't make my beans any smarter, as you pointed out.
This has been an ongoing topic of discussion in the Spring (Java) community for a while now. If you have a bit of time to spend and you're willing to filter out the Java-specific stuff, there are some well stated positions in: http://forum.springframework.org/showthread.php?t=15294&highlight=Reference+ Inside+Entity+Domain+Object It's a very long thread, and some of the good stuff is towards the end. But if I can sum up one of the recurring ideas, it'd go something like: "A DAO is just a strategy for storing and accessing a large collection, in the same vein as e.g. using a struct and accessing it via a key, or using an array and accessing it via a for loop. As such it is an implementation detail that most certainly belongs within domain objects. Whether it is included as literal code or as a composed object is a further implementation detail that should be decided by the same principles of code factoring as you would use for any other domain object functionality. One of the most natural ways to factor this functionality is via the use of singletons. The fact that it is difficult to inject singletons into domain objects is a design "accident" that has greatly distorted the design of the domain model layer. If we could specify DI rules for transient objects and be confident they would be applied no matter how the object was instantiated, there would be no anemic domain models." During the life of this thread a truly voodoo AOP solution was developed that intercepts the constructor and calls Spring to instantiate the transient, with full DI. Sadly, I don't think this would fly in Cold Fusion - but maybe one of the gurus out there will be inspired to prove me wrong. Jaime --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
