On Thu, 31 Mar 2005 11:11:43 -0700, Paul <[EMAIL PROTECTED]> wrote:
> > This is where Sean and I were heading. You have now found the need to
> refactor your component into more than one.
>
> OK so you've helped me see I need to separate the components, now I'm a bit
> muddled on where to put things. Forgive me if this is hard to follow, my
> brain is full.
>
> Authenticate.cfc
> authenticate() invokes ldap.authenticate(), returns boolean
> Ldap.cfc
> authenticate() returns Boolean
> retrieveUser() returns query
> user.cfc
> Unless I'm real confused, this is a user bean w/ getters/setters
> userDAO.cfc
> read() - invokes ldap.retrieveUser(), returns user
>
> My questions:
>
> 1. Should I rename authenticate.cfc to allow for additional functions like
> checkPermissions() or is that kind of thing in yet another component?
I would rename Authenticate.cfc so that it's a noun rather than a
verb. You could call it "Authenticator," for example.
I think a good case could be made for putting a checkPermissions()
function in any of the four CFCs listed. Based on the momentum you
have going now, though, I think I would create another CFC and call it
Authorizer.
But then you'd have three different CFCs to interact with your user
database. If one application used all three of those CFCs, I might
create a facade for that application to use.
UserService.cfc
authenticate()
invokes authenicator.authenticate()
authorize()
invokes authorizer.authorize()
read()
invokes userDAO.read()
Before long, UserService might become quite popular, to the point that
no other CFC deals with Authenticator, Authorizer, and UserDAO
directly. And if that were the case, I might move the functionality
from those three classes into UserService and quietly delete them.
> 3. By pulling ldap functions into their own CFC, it's now possible for me to
> authenticate against either ldap or mssql by passing a parameter to
> authenticate(). Where would my sql functionality go? Another CFC
> specifically for SQL authentication?
Yes. And you don't have to add a parameter to the authenticate function.
For example:
<!--- App.cfc --->
<cffunction name="init">
<cfargument name="authenticator">
<cfset variables.instance authenticator = arguments.authenticator/>
</cffunction>
...
<cffunction name="login">
<cfargument name="username"/>
<cfargument name="password"/>
<cfif variables.instance.authenticator.authenticate(username,password)>
<!--- go on to the home page --->
<cfelse>
<!--- back to login page --->
</cfif>
</cfif>
You would either pass a SQLAuthenticator or an LDAPAuthenticator to
your init function. Your App.cfc doesn't know anything about SQL or
LDAP. It just knows how to call an authenticate() function, which is
present in both SQLAuthenticator and LDAPAuthenticator.
In the future, you might create a NewFangledAuthenticator, and you
could introduce it to your application without changing a line of code
in App.cfc.
Patrick
--
Patrick McElhaney
704.560.9117
http://pmcelhaney.weblogs.us
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
