This is a good discussion and I think all the opinions presented here are
valid. I'm going to add my own, for the sake of another viewpoint.
I don't really use a ScopeFacade or a SessionFacade in my applications. This
is because I don't use the session really. The session isn't easily
replicated across machines and especially isn't useful for replicating
complex objects across machines (like in a cluster). There is always an
inconsistent period where one machine has certain data in the session and
the second machine does not yet have the data.
Both the ScopeFacade and the SessionFacade are merely abstraction points for
touching the scope or session directly. There is merit in the abstraction
and here's what I do.
I use a CurrentMemberLoader object. This object is in charge of retrieving
the current member ID and loading an object with it. This Current Member
Loader knows where the MemberID is stored and it touches it directly. There
are three operations, destroy, load and set.
This object is a singleton thus I can inject it with ColdSpring into any
other object that needs the currently logged in Member.
At no other point in my application will you find references to the scope
where the memberID is stored. All operations dealing with it go through this
method. Should I need to change the place where the memberID is stored, I
can do it in this single object.
What I've found, is I sometimes need to change where a variable is stored,
like from Session to Client or Cookie. I almost never need to change where
ALL my variables are stored, thus I'm not a big fan of the ScopeFacade or
the SessionFacade because I think they are too abstract and don't add enough
intelligence to the architecture.
In the code below, you would replace the call to transfer.get() with
whatever code you'd use to retrieve a Member object by the primary key. Like
MemberDAO.load( MemberID )
<cfcomponent>
<cfset variables.instance = structNew() />
<cffunction name="init" returntype="CurrentMemberLoader" output="false"
access="public" hint="I perform initialization functions for this
component">
<cfargument name="Transfer" type="any" required="true"/>
<cfset variables.transfer = arguments.transfer />
<cfreturn this />
</cffunction>
<cffunction name="destroy" output="false" access="public" returntype="void"
hint="I destroy the current member">
<cfset cookie.memberID = "" />
<cfset structDelete( cookie, "memberID") />
</cffunction>
<cffunction name="load" output="false" access="public" returntype="any"
hint="">
<cfset var loggedInMemberID = 0 />
<cfif structkeyExists(cookie, "memberID")>
<cfset loggedInMemberID = cookie.MemberID />
</cfif>
<cfreturn variables.transfer.get("Member", val( loggedInMemberID ) ) />
</cffunction>
<cffunction name="set" output="false" access="public" returntype="void"
hint="">
<cfargument name="Member" type="any" required="true"/>
<cfset cookie.MemberID = val( arguments.Member.getMemberID() ) />
</cffunction>
</cfcomponent>
On Thu, Aug 5, 2010 at 2:21 AM, denstar <[email protected]> wrote:
> On Wed, Aug 4, 2010 at 11:39 PM, Matt Quackenbush wrote:
> ...
> >> I've got to say a whole lot of OO style coding
> >> still feels to me like I'm driving around the block to go next door.
> >
> > 2) When you get into the maintenance phase of your application, you will
> be
> > happy as a lark that you drove around the block. It will save you loads
> of
> > time on the back end. :-)
>
> This is sooo true.
>
> Like, I'm on a personal crusade against direct access of the CGI scope.
>
> Model-Glue has been one of the *very* few frameworks (including CMSs)
> which hasn't forced me to muck around with various files when I do
> some crazy url rewriting or some-such.
>
> I got burned a long time ago by relying on cgi.script_name in a lot of
> places. Would have saved me a lot of time if I had abstracted that
> out by just one level.
>
> The analogy is more similar to running around the block, than
> driving-- You're in better shape for those days when you have to run
> next door 50 times in a row. You won't be all out of breath after the
> first couple sprints. =)
>
> That said, it's easy to go totally nuts and um, run too much, so to
> speak. I guess balance takes practice.
>
> But not /too much/ practice. ;)
>
> :DeN*
>
> --
> All political revolutions, not affected by foreign conquest, originate
> in moral revolutions. The subversion of established institutions is
> merely one consequence of the previous subversion of established
> opinions.
> John Stuart Mill
>
> --
> Model-Glue Sites:
> Home Page: http://www.model-glue.com
> Documentation: http://docs.model-glue.com
> Bug Tracker: http://bugs.model-glue.com
> Blog: http://www.model-glue.com/blog
>
> You received this message because you are subscribed to the Google
> Groups "model-glue" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]<model-glue%[email protected]>
> For more options, visit this group at
> http://groups.google.com/group/model-glue?hl=en
>
--
William Osler - "We are here to add what we can to life, not to get what we
can from life."
--
Model-Glue Sites:
Home Page: http://www.model-glue.com
Documentation: http://docs.model-glue.com
Bug Tracker: http://bugs.model-glue.com
Blog: http://www.model-glue.com/blog
You received this message because you are subscribed to the Google
Groups "model-glue" 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/model-glue?hl=en
