Session Facade

[Husum, James P. (JSC-IS)[IDI]]

Greetings,

 

Can anyone give me (or point me to) a good explanation of what a Session Façade is and what it does? The wiki seems to be down at the moment.

 

Also, pointers to a good code example would be appreciated.

 

Thanks.

 

James Husum, MCCD

Software Engineer III

JIMMS Contract

281-335-4848 x236

 

[Adrian Moreno]

I've got a post about it here (with code):

http://www.iknowkungfoo.com/blog/index.cfm/2007/2/12/Using-a-Session-Facade-to-handle-evolving-session-variables

HTH,

Adrian

---

From: "Husum, James P. (JSC-IS)[IDI]" <James....@nasa.gov>
Sent: Tuesday, January 20, 2009 10:47 AM
To: "mach-ii-for...@googlegroups.com" <mach-ii-for...@googlegroups.com>
Subject: [Mach-II] Session Facade

[Peter J. Farrell]

Adrian,

Would you consider denoting your post as a wiki entry?  I already had a stub for it here:
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/UsingSessionFacade

Let me know and I'll port it over if it's ok.

Best,
Peter

Adrian Moreno said the following on 1/20/2009 11:34 AM:

No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.176 / Virus Database: 270.10.9/1900 - Release Date: 1/18/2009 12:11 PM

  

[Husum, James P. (JSC-IS)[IDI]]

Greetings,

 

Thanks. That helps clear things up some.

 

James Husum, MCCD

Software Engineer III

JIMMS Contract

281-335-4848 x236

[Mark Mandel]

Just to be clear though, I think the common usage of a
'SessionFacade.cfc' in the long run ends up being a pretty bad idea.

There was a pretty decent discussion of this on the ColdSpring list a
while back:
http://www.mail-archive.com/coldspr...@coldspringframework.org/msg01387.html
(Read the entire thread).

By having a single 'G-d' facade obejct, you have a tight coupling to a
single object across your entire application.

You are better off having several Services that also act in the way of
a ServiceFacade, to encapsulate the usage of the session scope.

I.e. I would have methods such as:

UserService.getCurrentUser() - which would allow me access to the
current user, and managing how that data was stored.

But if I was using the session scope to store form data (for example),
that wouldn't be part of the UserService, it may be part of the
FormService, for example.

Does that make sense?

Mark

--
E: mark....@gmail.com
W: www.compoundtheory.com

[Peter J. Farrell]

Mark Mandel said the following on 1/20/2009 4:07 PM:

> By having a single 'G-d' facade obejct, you have a tight coupling to a
> single object across your entire application.
>
> You are better off having several Services that also act in the way of
> a ServiceFacade, to encapsulate the usage of the session scope.
>

Honestly, I think this is all debatable which we could do I don't think
we'd end up actually getting anywhere. The real thing is there are
choices -- some ideal more than other and other more ideal due to
developer experience. Your solution Mark is maybe more sophisticated
than a general SessionFacade.cfc, however it is less straight forward
for developers with less architecture experience. However, any solution
in my mind is better than accessing session.* everywhere.

Personally, I think the tight coupling to a SessionFacade.cfc argument
is a bit tiresome. I think most people strive for "no coupling" when
thinking of "loose coupling". Honestly, "no coupling" does not exist
because an application has to have *some* dependencies in order to
function. Having a session related helper methods in your Services just
makes you end up using multiple services in other services. It all
depends on how you load data and leverage the session scope. It all
depends on your application and without a lot of information -- it is
six of one and half-dozen of another.

I guess I'm saying there are more than one way to cut a pineapple
(sorry, I just can't bring myself to skin anything these days). Maybe
Mark you might consider denoting some documentation regarding both
techniques at (wink wink):
http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/wiki/UsingSessionFacade

Best,
Peter

[Mark Mandel]

>>
> Honestly, I think this is all debatable which we could do I don't think
> we'd end up actually getting anywhere.

We can agree to disagree. :D

> The real thing is there are
> choices -- some ideal more than other and other more ideal due to
> developer experience. Your solution Mark is maybe more sophisticated
> than a general SessionFacade.cfc, however it is less straight forward
> for developers with less architecture experience. However, any solution
> in my mind is better than accessing session.* everywhere.

I agree on the session.* point.

>
> Personally, I think the tight coupling to a SessionFacade.cfc argument
> is a bit tiresome. I think most people strive for "no coupling" when
> thinking of "loose coupling". Honestly, "no coupling" does not exist
> because an application has to have *some* dependencies in order to
> function. Having a session related helper methods in your Services just
> makes you end up using multiple services in other services. It all
> depends on how you load data and leverage the session scope. It all
> depends on your application and without a lot of information -- it is
> six of one and half-dozen of another.

Well, for me not really. I've seen people using a SessionFacade.cfc
all over the place, especially doing things like passing it into
Controllers and/or Transient Objects, and suddenly you're not
encapsulating session usage, you are promoting it! Which becomes
makes your design more fragile due to the high coupling.

The SessionFacade.cfc just becomes a replacement for session.*, but
all you gain is an extra layer of abstraction, without really hiding
away any of the implementation details, above and beyond what session
mechanism you are using. Given the complexity a single
SessionFacade.cfc can introduce, especially once it starts gathering
dependencies, I find it a big 'con' to the 'pro'.

But like you said, it's debatable :D

Mark

[prashant roy]

Hey Mark,

 

I am not active in this thread but I liked the wordings  "We can agree to disagree". Its awesome.

 

-Prashant

[Peter J. Farrell]

Mark Mandel said the following on 1/20/2009 5:11 PM:

> Well, for me not really. I've seen people using a SessionFacade.cfc
> all over the place, especially doing things like passing it into
> Controllers and/or Transient Objects, and suddenly you're not
> encapsulating session usage, you are promoting it! Which becomes
> makes your design more fragile due to the high coupling.
>

Well, I never considered passing it into transient object because I
never thought it was a good idea and probably because most of my
application don't use an ORM (yet). And I agree that is tight coupling
in that respect.

> The SessionFacade.cfc just becomes a replacement for session.*, but
> all you gain is an extra layer of abstraction, without really hiding
> away any of the implementation details, above and beyond what session
> mechanism you are using. Given the complexity a single
> SessionFacade.cfc can introduce, especially once it starts gathering
> dependencies, I find it a big 'con' to the 'pro'.
>
> But like you said, it's debatable :D
>

Definitely, it really depends on the complexity of the application and
the skill of the developer (or how comfortable the developer really is
developing in the OOP idiom -- baby step need be involved in the
learning process).

[Dan Wilson]

Rather than a session facade, I create loader objects for specific
objects that use shared scopes.

For example, I commonly store a the userid of the currently logged in
user in the session.

When I need the current user object, I simply call
currentuserloader.load() and a user object populated with the
information for the currently logged in user is returned.

Currentuserloader is a singleton, and internally references
session.currentuserID.

This, to me, is the right level of abstraction and can be overridden
for test driven development. I also can just update this object should
I need to store the currentuserid in another scope, say when migrating
to a clustered situation.



Food for thought.

Dan

--
"Come to the edge, he said. They said: We are afraid. Come to the
edge, he said. They came. He pushed them and they flew."

Guillaume Apollinaire quotes