User Security object along with User Profile object..

JCannelos posted on Tuesday, February 13, 2007

Guys,

In my web application, I have to build a User Profile object that has things like Name, Address, a collection of Preferences, Skills, et. I also need to have some security properties like Password, UserName, Secret Question/Answer, LastLogin.

Should these be two separate objects? I noticed in the book that Rocky uses two different databases - one for Security, one for everything else in the ProjectTracker application.

I am currently using the book approach, but would like to hear what others do. Also, because my Identity object has things like Name (as well as UserName) and Email - these are properties of the Profile object, but I've made them also properties of the Security object so I don't have to hit 2 databases just to log a user in. Is this right or am I overthinking it? I've also created a concurrency issue - when someone updates their Name, Email in the Profile page - I also make sure the Name, Email in the Security object is also updated and saved.

Any thoughts on streamlining this would be appreciated... thanx much!

J'son

ajj3085 replied on Tuesday, February 13, 2007

Remember, the PTracker is just a sample.  You can keep all the security settings in a single database.

Now, it seems to me that if you have Name and email in your application and your security db, that information should only exist in the security db.  No reason to recopy the data and create the issue you now have. 

I've done the book approach because I wanted a unified security system where logons are managed by one application so that IT had an easier time managing the logons.

I would say you probably would want one object to allow user's to manage their own profile / security, but behind the scenes it could possibly delegate to other internal objects.  That would be a facade pattern.

Now you probably need to have admins manage these users as well, and they should probably have a different group of objects because admins have different use cases than users would.