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]
