On Oct 30, 2007 12:46 AM, Sean Corfield <[EMAIL PROTECTED]> wrote: > > Once a > service has access to a generic facade like that, it can access *any* > data behind that facade and the faux-encapsulation of the facade > encourages developers to do so, believing they're using good OO > practice. All that happens is you get increased dependencies because > you've opened up a conduit to data that a service should not be able > to touch. If a service needs access to data in another service, it > should go through the *service* but with this generic facade approach, > it can go directly through the generic facade, completely breaking the > layering and encapsulation in the application.
Ah, see this makes it more clear why you're discouraging that. See, I would still always go through the appropriate service to get at data outside the current service, *even if the service could attempt to get at the data directly by using the SessionFacade*. In other words, I limit what a service will interact with via the SessionFacade as a deliberate convention. But just because I do this, I was missing the fact that many people might not impose the same limitation on themselves. By eliminating the centralized facade, you're not even giving other services the possibility of digging into shared scope data that is outside their area of concern. OK, I'm sold. ;-) Still, if you could comment on your approach to dealing with the session scope in your services I'd be interested. Do you use a direct reference to the session scope? Or some other approach? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion 8 - Build next generation apps today, with easy PDF and Ajax features - download now http://download.macromedia.com/pub/labs/coldfusion/cf8_beta_whatsnew_052907.pdf Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:292307 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
