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 Use

In 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 System
3. Datatel Colleague Student Information System
4. Shelfware Applications
5. Home-built Applications
 
For discussion purposes, in all of these systems, we have basic, "shared" user information such as:
 
1. First Name
2. Last Name
3. Username/userid
4. (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 Dawson
Database Administrator and Manager of Web Applications
Office of Technology Services
University of Evansville
1800 Lincoln Avenue
Evansville, IN 47722
812-488-2581
MSN 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]

Reply via email to