You could look at it another way. You could see a service layer as encapsulating your domain / business objects from your application code.
If all application code asks the various service cfc's, it has no knowledge of the domain layer. If the domain layer changes then there is less chance you'll have to change your application code. The other benefit of service cfc's is that you can then do application-specific tasks and keep them seperate from your domain objects (ie use a DAO to insert a record then use a NotificationService to send emails etc) I'm fairly new to OO myself so don't treat this as best practice!! :-) Alan ________________________________________ From: [email protected] [EMAIL PROTECTED] On Behalf Of Bob Silverberg [EMAIL PROTECTED] Sent: 20 October 2007 17:59 To: [email protected] Subject: [CFCDEV] Re: composition question for service cfc Oops, my first post and apparently I got it wrong ;-) So are you guys are saying that you treat gateways as internal components of service objects, so that if you need to use a gateway you always access it via the service object? So in that case the fact that they're tightly coupled doesn't matter, in fact it's preferable. Thanks for opening my eyes to that. Bob On 10/20/07, Alan Livie <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>> wrote: Thanks for the replies. @Bob - I've found CFCDev one of the best CF groups. I've learned a lot so far. @Peter - when I said yObj I didn't mean transient objects, just singletons. And good advice. @Brian - makes perfect sense. I also see the flaw in my logic. What's the point of setting up various services if you start bypassing them and going straight to the domain objects - defeats the whole purpose of why I set the service layer up in the first place! Thanks again Alan ________________________________________ From: [email protected]<mailto:[email protected]> [EMAIL PROTECTED]<mailto:[email protected]> ] On Behalf Of Brian Kotek [EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>] Sent: 20 October 2007 15:27 To: [email protected]<mailto:[email protected]> Subject: [CFCDEV] Re: composition question for service cfc On 10/20/07, Alan Livie <[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]><mailto:[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>>> wrote: I have a service CFC that is composed of various other CFC's in the same package (directory). I have also composed it with CFC's from other packages directly (Gateway CFCs for query returns etc) My question is: Should I compose xService.cfc with yObj.cfc directly or yService.cfc (which is composed of a yObj) ie should xService get a yObj directly or should it be composed of yService and let yService be composed of yObj ? In my opinion, the approach of passing the service objects into the other objects is much better. So I would definitly compose yService into xService and only go through the service object API to make anything happen. And this doesn't just apply when service objects need to call other services...it applies to just about any kind of object. For example, if I have an InventoryService and a ShoppingCart object, and I want to be able to check in my ShoppingCart whether a product is in stock, I would compose the InventoryService into the ShoppingCart. I have opted for the simpler solution of just getting the yGateway object I need composed in xService. My reason being if yService ends up being composed of many other objects I will have all these unnecessary objects I don't need in my xService The flaw in your logic is that when you compose an object, you are creating a reference to that object. You are not creating a copy of it. So if you compose yService into xService, it makes no difference at all how many objects yService has composed into it. In fact, that's the whole point of doing it that way: yService might in turn need to call 1 other object, or 10 other objects, to do its work. But xService never knows. Hope this makes sense :-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
