The logic for determining whether a set of login credentials is valid is business logic, but how you remember the answer is usually tied to the presentation layer. You probably won't use session variables if you're being called as a web service, but the validation is identical.
Here's an example, that'll hopefully help. Say I've got a security CFC with a authenticate method that accepts two strings: a username and a password, and returns a boolean indicating whether the credentials are valid. In that same CFC is an addUser method that takes a bunch of information and creates a new user. I'm not saying that's a particularly good design, just setting the stage I need. Scenario #1: Martha is a web user, she comes to your site and wants to add a user. Request #1 Get the login form. She fills it out, and submits. Request #2 Your CF/HTML presentation layer gets the form fields, checks to make sure they exist, have length, whatever, and passes them to your security CFC's authenticate method. It returns true. The presentation layer sets a session variable (authenticated) to true, and creates an instance of the User cfc contaiing Martha's information, and stores that in session.user as well. Finally, it uses CFLOCATION to forward to the add user form. Request #3 The request for the form comes in, the presentation checks to make sure session.authenticated exists, is boolean, and evaluates true. Then is CFINCLUDEs the login form, which happens to use session.user.getFirstName() to personalize the message little. That's sent to Martha, she fills it out, and submits. Request #4 The presentation layer checks the make sure session.authenticated is ok. Then it validates the form fields, and then calls the addUser method on your security CFC. Finally, it CFLOCATIONs to a conformation screen, passing the id of the newly created user. Request #5 The request for the confirmation screen comes in, the presentation layer checks session.authenticated, and creates an instance of the user CFC for the new user from the passed ID, and outputs a confirmation to Martha, again personalized using session.user.getFirstName(). Scenario #2: Edith is a client who connects over web services to the same application, using a third party (reseller) front end. We won't talk about Edith, but rather the server (named johann) that is, in effect, proxying to our web services. Johann calls the authenticate method of the securityproxy web service, passing a username and password. The securityproxy cfc calls authenticate on the security CFC which returns true. The securityproxy uses an array in the application scope to track valid sessions. It creates a custom sessionID, adds it to the appliction scope array, and the returns it to the invoker Johann calls the addUser method of the securityproxy web services, passing the sessionID returned earlier and whatever other information is needed. The securityproxy CFC validates the sessionID against the application-scope array, checks the input parameters, and then calls addUser on the security CFC to actually create the user. Finally, it returns the id of the new user back to the invoker. Hopefully that illustrates the difference between the presentation logic and the business logic. The security CFC didn't change, but everything else did. The CF/HTML interface still used a session-scoped User object, but the web services interface didn't need one. Yes, I admit that the example was somewhat contrived, but not as much as you might think. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Steve Bryant > Sent: Wednesday, April 28, 2004 12:11 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] CFC interaction (user log in) > > Ah! > > I think that I understand (or more appropriately, I think > that I am closer > to understanding). > > So, The logic on how to determine if a session is logged in can be > encapsulated in a CFC as business logic, but the actual > storage of whether > or not a given session is logged in is presentation logic? > > What if I want the same logic to apply regardless of whether > the system is > being accessed by a web browser or a web service. Does the > same reasoning > still apply? > > If I understand correctly, the reasoning on whether some data > belongs with > business logic is based (in part) on persistence. ie, will that data > persist beyond any given session or page. Is that correct? > > That being the case, is any advantage gained by encapsulating > this sort of > logic (not business logic, but not quite presentation logic > either) into > its own CFC (I would say into a facade CFC except that it > would only reveal > that I don't really know what a facade is yet). > > Given that my questions are likely to be fairly endless > (although hopefully > I will wrap up this line of questions soon), any good book > recommendations? > > Thanks! > > Steve > > At 11:24 AM 4/28/2004 -0700, you wrote: > >The way I see it, the 'isLoggedIn' is a very ambigious > property. If you > >need to know whether a user is currently logged into the system > >(irrespective of the interface they are using), then yes, > that's part of the > >business logic, and should be stored in the user table in > the DB, just like > >any other field. That's useful in an abstract, > business-logic sense. For > >example, generating a list of users currently using the > application, or > >checking whether user X is online and can receive a chat request. > > > >However, if you're using the property to track a session, > then it's not > >business logic, because you can't use that info in the > business layer (nor > >will you persist it). In other words, it's meaningless except at the > >presentation layer. You're saying that not only is the user > logged in (the > >business logic part), but also that the specific session > tied to this user > >instance is logged in. The "specific session" should throw > all kinds of > >warning bells, since "session" isn't understood by the > business layer, only > >the presentation layer. > > > >I'm all for storing the first type of info in your user > object; it can be > >very useful information, particularly with applications > where real-time > >collaboration happens. The second type of info should be stored in a > >interface specific means (a session variable, in your case). > Not to say > >that interfaces can't have shared storage, we use client > variables for users > >on the CFML/HTML interface and for CFC-based web services. > It might be a > >third layer between business and presentation, but it's not > a business logic > >concern, and so shouldn't be mixed in with your business objects. > > > >Cheers, > >barneyb > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
