User Factory and Repository

I'm in the process of determining an approach for design. I would like your inputs

I have 2 types of users

1. Corporate Internal Users
2. Customer Users

The fundamental differences between them technically is

1. Corporate: Don't need to save passwords in the system but only roles (authentication against AD)
2. Customer Users:Save password in the system and have an associated customer ID.

I have a table User which have the columns like so

User Name  
Password  
Roles  
Customer ID  

If I abstract the user creation process using an abstract factory pattern, I get the 2 types of user objects.

Now when it comes to creating a repository, how do I handle开发者_Go百科 it? Do I create 2 different repositories to handle individual user type objects (mapping to same table)

Can corporate users also be customers? If so, would you expect them to use the same ID? If so, you might want to look at implementing the Party-Role pattern (aka Actor-Participant).

It would allow you a unified solution for handling both internal user roles and corporate vs. customer distinction.

hth.

You should consider adding a user type column to your user table. This way you can track what type of user each record represents. This will be of use when creating user entitys on a find/get operation in your repository layer as well as when you are doing an add or update procedure. I would suggest only one "user" repository. You will not need two repository classes if you use inheritance and track the user type at the database level.

Hope this helps.

Enjoy!

Maybe I can give you some hints. I agree with Doug that you should only use one UserRepository that manage User Aggregate classes.

This is how I would do it with (Fluent) Nhibernate:

User class with a UserType Enumeration field that is mapped to a single column. See this article, its very good and I've used Jimmy Bogard's solution several times (http://lostechies.com/jimmybogard/2008/08/12/enumeration-classes/). Then you have a UserType class that is actually just represented i database as a column in User table, BUT you have a full class with Behaviour etc.

Then to solve your differences in how each type should handle passwords and Customer relationship, you can use a validator pattern to confirm that your User instance is valid (based on your UserType) before saving it to db. Look at this blog http://lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/ (Jimmy again... Do I need to say that you should subscribe on Jimmy Bogard's blog :)).

Then you have a UserPersistanceValidator that check's if UserType is internal, no pwd is required and AD role must be supplied. You get the picture...

I hope this will help you. Good luck!