I suppose the question again pops up 'Should a bean know how to persist itself 
or should this not be the bean's concern' but this has been debated and debated 
and there's no right or wrong answers, just opinions!

I don't think its a problem having services with some intelligence, ie doing 
some logging (forget AOP for now!), managing transactions, persistence, 
notifying users when things happen etc. I guess this can be called Application 
Logic.

Its only when the Business Logic starts creeping into services (ie something 
like calculatePay() ), you start getting into the 'anemic domain model' issues 
and responsibilities living outside the objects that should have them (ie the 
bean/business object)

Alan






________________________________
From: Michael Sharman <[email protected]>
To: CFCDev <[email protected]>
Sent: Tuesday, December 23, 2008 11:04:25 AM
Subject: [CFCDEV] Re: DAO in Service and/or Business Object


@Alan

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

This is where I'm at :)

I'm trying to move away from UserService.getUser(myId) because my
business objects should have more behaviour and the services shouldn't
be as "thick".


On Dec 23, 9:38 pm, Alan Livie <[email protected]> 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 :-)
>
> Alan
>
> ________________________________
> From: John Whish <[email protected]>
> To: [email protected]
> Sent: Tuesday, December 23, 2008 9:43:15 AM
> Subject: [CFCDEV] Re: DAO in Service and/or Business Object
>
> I agree with Mark and Jared. The controller should only talk to the
> service. The DAO should only talk to the database. The service is a
> facade which can talk to the DAO and the User object.


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

Reply via email to