Hmmmm ... Yes, i've heard Mr. Corfield say the same. But i've also
heard him say on many occasions that unless you've verified that something
in your design is causing a bottleneck thru stress testing, and that bottleneck
is causing an actual problem in the app that humans can sense, don't start
making things unnecessarily complicated for performance's
sake.
I
still see one Person down there, with a name, an email, a birthdate, a photo, a
department, and a title. That doesn't seem like an excessively large object to
me.
Of
course, i tend to keep things as simple as possible, and that may not always be
the correct approach. For instance, this getSpouse() thread. I've been following
it closely, seeing if i can learn something. But when it comes down to it, i'd
just return a dialog box asking "Are you SURE?" and if the user replied yes, i'd
give them a spouse. If they replied "No" - i wouldn't.
;)
nando
---------------------------------------------------------------Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Dawson, Michael
Sent: Wednesday, October 26, 2005 10:06 PM
To: [email protected]
Subject: RE: [CFCDev] Modeling Users: One Object, Multiple Uses or Multiple Objects, One UseThanks 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 Membershipetc.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)* BirthdateID Photo Database (SQL Server)* Unique ID (nine-digit ID number)* First Name (12 chars)* Last Name (15 chars)* Birthdate* Binary Photo DataLooking 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.ThanksM!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]
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]
