Custom Identity - two ideas - which is more 'correct' ?

brettswift posted on Sunday, July 02, 2006

I'm putting some extra fields in my Identity ... email, phone, enabled, etc.

Obviously there will be strict rules - only the user can edit their own password, only admins can reset the password etc.

So, 2 choices:

1) Convert custom IIdentity class from ReadonlyBase to EditableRoot, and set validation / authorization rules inside this. - allow your users to edit your IIdentity class (being very careful with authorization settings).

2) Keep custom IIdentity class as is, just add properties, and have another EditableRoot User BO class.


thoughts - pros/cons.
1) a)Pro: one class - less to modify later
    b)Pro:  in UI code, can convert principal.user to CustomIdentity directly and access email/phone properties.
    c)Have to use the IIdentity object as child collection when the User is a foreign key to other tables. (like 2b below).
   

2)
a) Pro: Easier to manage when the User is a foreign key in other tables  ? 

b) Con: In Project Tracker - I'm thinking there may be some odd stuff happening when you have a project, that has a child collection of PTIdentity objects?  Might be better to keep them as "Resource" objects - but the resources would come from the User  table...  hmm



I'm tending to go with option 1, because its usually not good to duplicate code, but I want to throw this out there in case there are situations like 2b, where I may run into problems later... any thoughts?  Is there a best practice in this scenario ?

Jurjen replied on Sunday, July 02, 2006

I would go for option 2.
I don't think it would be a good idea to have a editableroot as iidentity, too much overhead.

What I've done is create a 3 tables : myUser - myRole - myUserRole

myUser contains fields : ID, UserName, password, email, telephone, etc... AND IsActive
myRole contains fields : ID, Role
myUserRole contains fields : ID, RoleID, UserID

Since CSLA Login procedure expects tables USER and ROLE, I've created two VIEWS (USER and ROLE) on the above mentioned tables. This way I've decoupled what I want to store about users and what the CSLA Security expects. As a bonus the VIEW USER only shows Users that are Active so it's easy to disable a user without having to delete it.

For the above mentioned tables you can easily create/generate BO's to do the maintenance on these tables (including password changes).

I would extend your Identy class with a Collection (hashtable) so you can add as many/few properties as you'd like without having to change your Identity class each time you think of another property you'd like to add.

HTH
Jurjen.