To
me, it seems a User is indeed a User, since from your explanation you
can guarantee that across systems because of the shared userID.
What seems to differ is the validation/persistance layer. A single User.cfc
that would interact with each system would have redundant methods in certain
moments, but i don't see that as being much of a problem. In certain moments
during application flow, many methods in any object are not in
use.
Your
users don't differ, but the validation / persistance mechanisms do - so it seems
like that's where you may need to have various objects (or perhaps various
methods in a UserValidator). You can pass a single User into various
validators / DAO's for each of your systems and it will work fine. The
Validator / DAO will just pull the data it needs from User in each
case.
That's hoiw i see it at least. Sounds like a
UserManager might be very helpful to pull all the pieces
together.
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Dawson, Michael
Sent: Wednesday, October 26, 2005 3:44 PM
To: [email protected]
Subject: [CFCDev] Modeling Users: One Object, Multiple Uses or Multiple Objects, One UseIn our environment, we have user information scattered here and there. For example, we have many different user databases/directories such as:1. Active Directory (Accessed by both LDAP and VB COM)2. AS400 Student Information System3. Datatel Colleague Student Information System4. Shelfware Applications5. Home-built ApplicationsFor discussion purposes, in all of these systems, we have basic, "shared" user information such as:1. First Name2. Last Name3. Username/userid4. (A few other attributes)I would like to have a common "User" object (cfc) that encompasses most, if not all, of these systems. However, as you can guess, there are many attributes that are not shared between systems. For example, email address is not available, or even stored, in a couple of our systems.Now, down the the basics. A user is a user. Right? Or is it more-correct to say an Active Directory User is an Active Directory User, but a AS400 User is an AS400 User. This is where I am getting confused. (I understand the concept of not modeling an object that only mirrors the persistence layer.)Does it make sense for a single User object to cover all of the bases, or should I have separate objects for each type of user: ADUser.cfc, AS400User.cfc, ColleageUser.cfc? The gist is that some attributes are shared between users in different systems, but not all are.Then, part two of my question: What logic will let me transfer, and validate, user information between the various systems? Let's say I need to create an Active Directory domain account based off of AS400 student information.Do I need some sort of handler/manager that will pull only the necessary AS400 user attributes and create an Active Directory user object? What about the "holes" where the AS400 cannot completely fill the ADUser.cfc object? How will I get my ADUser object to validate correctly?Now that I have a ADUser object, semi-created from the AS400User object, how do I validate that "some" of the information is OK only because I know it came from an already-validated system (AS400). In addition, I don't want to lose the normal validation that I would perform on a ADUser object.To sum it up with my final thoughts, for now.1. Should one object serve multiple, but related, purposes?2. If an object can serve multiple purposes, how do you validate per-purpose?3. Is this a good candidate for inheritance or composition? An ADUser is-a User; An AS400User is-a User. I don't think composition fits this problem.Thanks for any suggestions with this.M!chael A DawsonDatabase Administrator and Manager of Web ApplicationsOffice of Technology ServicesUniversity of Evansville1800 Lincoln AvenueEvansville, IN 47722812-488-2581MSN Messenger ID: [EMAIL PROTECTED]"There are 10 types of people in the world: Those who understand binary numbers and those who don't."----------------------------------------------------------
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
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' as the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
