At the risk of disagreeing with Sean, which usually ends up with me realizing I'm wrong about something...
On 10/29/07, Sean Corfield <[EMAIL PROTECTED]> wrote: > > And having references to sessionFacade.getFoo() everywhere is somehow > better than having references to session.foo? I do see a difference, in that the calling code doesn't actually know about the session scope or how the data is being persisted. So I suppose a better name might be PersistenceFacade (or even PersistenceAdapter), but the point is that you are free to change how things are actually stored without changing anything outside the facade. Having a giant kitchen sink session facade CFC is not a good idea and > is not encapsulation. That sort of session facade is not a coherent > object and having "sessionfacade" everywhere means you have not > encapsulated use of session scope at all - you've just required that > people call functions to get at data. Isn't that the very definition of encapsulation? I don't see it as a kitchen sink, nor a non-coherent object. On the contrary, I see it as a very coherent object: it is the gatekeeper to the shared scope, and everything that wants to deal with the shared scope needs to talk to the facade. The better solution is to consider what data you have in session scope > in the first place and encapsulate each piece of data in an object > that relates to that data. You might have a user object in session > scope - encapsulate that knowledge in a userService (singleton). That > way you've encapsulated how the user is stored - none of your > application code knows about session scope (or sessionFacade!). You > ask the service to perform operations on the current user and it knows > how to do that. It can even give you the user object if you want to > operate on it directly. That means your application code is only > dependent on a fully encapsulated service. It also means that you can > change how the user object is stored independent of any other data in > session scope (because that other data is encapsulated elsewhere) and > nothing in your application needs to change. I totally agree here. I would pass the SessionFacade into the UserService, and nothing outside the UserService has any idea where it is getting or storing anything. If I call userService.getCurrentUser(), internally the service might be grabbing the object from the SessionFacade, but nothing outside of it knows that. I still think there is value in having a single point of interaction with the shared scope via the SessionFacade. If I understand your point of view on this, either your UserService would need to interact directly with the session scope, or you have to create service-specific objects that encapsulate interaction with the session scope and pass those into each service that needs them. Which means instead of having one object that deals with the session scope, now you have a bunch of them. The upside to that design decision seems to be that you have granular control over how/where the data is persisted for each service, but the downside is that you have multiple additional objects to deal with (one for each service). And since I have never run into a situation where different services needed to use different persistence mechanisms (everything is usually just in the session scope), this seems like an increase in complexity for not much real benefit. Further, since I'm passing the SessionFacade into the service at configuration time, if the need ever arises, I can simply pass in some other object that works differently without having to change anything in the service. Or perhaps are you advocating pushing the interaction with the session scope into a DAO, do be grouped with anything else that needs to be persisted (including the database)? Maybe part of the issue is that aside from a User object and maybe a Shopping Cart or something, I really don't keep much in the session scope at all. Sorry, but this weird obsession with sessionFacade CFCs drives me nuts > - it's completely misguided and a very procedural way of thinking. If one had direct references to the SessionFacade all over their code, I'd agree with you. But I'd say the approach outlined above is definitely not a procedural approach. If anything, the only point of contention is your approach of having each service deal with the session scope through a service-specific object vs. my approach of having the services go through a single component to deal with the session scope. Thoughts? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion is delivering applications solutions at at top companies around the world in government. Find out how and where now http://www.adobe.com/cfusion/showcase/index.cfm?event=finder&productID=1522&loc=en_us Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:292282 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
