Actually, an expansive service layer that contains the majority of your application's behaviors and exists and is accessible from outside the beans themselves is most commonly called the "anemic domain model" anti-pattern... not something we want to encourage.
I suppose it could be argued that implementing your applications use cases within service classes would be anemic whether they're called thru the beans or thru some other mechanism like the application scope. Implementing the behaviors directly within the beans is, perhaps, less abstract and so less "perfect" but I find that abstractions exist in inverse proportion to maintainability. There is a certain balance to be struck here I suppose, where some things are abstracted for general use and some things are implemented directly because there's no point to abstracting them... everything has it's point of diminishing returns, n'est-ce pas? In any case, in Fowler's ideal world (and Helms in particular), the service layer is very thin, only providing persistence services to objects, while the rest of the behaviors are implemented in the business objects and using composition where appropriate to access abstractions of common tasks like FTP. The beans only need access to the services if they're going to know how to save/load themselves... which is fine according to things like the ActiveRecord pattern and not cool according to other patterns. YMMV, and make up your own mind. The most important part is to pick a perspective and follow it thru to the bitter end... in doing so you'll find the strengths and weaknesses of your designs. That, more than whether any particular aspect of your design is "right or wrong", is the most important part. At least that's what I think _this_ morning... ask me tomorrow, I may have changed my mind by then. ;) J On Dec 23, 2008, at 4:38 AM, Alan Livie wrote: > I'm still not 100% comfortable injecting services into business > objects/beans. > > Using Martin Fowler's concept of a 'service layer' the service is > at a higher level than the domain model (business objects, DAO's, > factories, strategies etc etc) > In the same way it would feel odd to inject a service into a DAO I > also think its strange injecting services into business objects > although I have worked on a project with things like User.load() > etc. Then again I can also see that if we want our beans to be > smart they will have dependencies. I'm just not sure if services > should be the objects wired in to them. > > It just feels more natural using something like (from a controller) > User = UserService.getUser(myId) rather than User.load(myid) and > I'm also happier seeing UserService.save(User) than User.save() > that calls an injected service. > > I'm happy to be convinced though :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
