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]
