Thanks to everyone that replied. Nando, I think you
may have explained it better than I could have.
To better clarify other possible issues, I will diagram it
somewhat.
Active Directory User Information
* Unique ID (md40)
* First Name (64 chars)
* Last Name (64 chars)
* Department (128 chars)
* Title
* Phone
* Group Membership
* Email
etc.
AS400 User Information
* Unique ID#1 (nine-digit ID number)
* Unique ID#2 (seven-digit ID number)
* First Name (12 chars)
* Last Name (15 chars)
* Department (20 chars)
* Birthdate
ID Photo Database (SQL Server)
* Unique ID (nine-digit ID number)
* First Name (12 chars)
* Last Name (15 chars)
* Birthdate
* Binary Photo Data
Looking at this information, it does seem that I could
have a rather largish "User" object that has some superfluous methods depending
on the current use.
For
example, if I init() a user object for Active Directory information, I won't
have an actual birthdate in AD, but the method still exists in the User
object. I also won't have the two different ID
numbers.
Then, I have a Active Directory user-related validator
that just checks for the required attributes that pertain only to Active
Directory users. Also, the individual validators would need to check for
the length of data: AD names are 64 chars while AS400 names are 12/15
chars.
Recently, I have seen a post, or two, from Sean
Corfield, that mention having too many methods, per object, often reveals a
design flaw. That led me to believe that having too many "unused" methods
really reveals a design flaw.
Thanks
M!ke
----------------------------------------------------------
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando
Sent: Wednesday, October 26, 2005 12:56 PM
To: [email protected]
Subject: RE: [CFCDev] Modeling Users: One Object, Multiple Uses or Multiple Objects, One UseTo 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.
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]
