Question

We are currently building architecture for thin-client bookkeeping application. It should follow two main requirements:

1. Application should have module design. Each module can have (and they actually do have) own Role system.
2. Later application should be adapted for running using different databases on different machines.

We think Asp.NET MVC 3 is appropriate platform for this task. For managing application data we chosen latest version of Entity Framework – its batch of Data Providers and Code First feature can save us much time.

The part we are tangled with is user/role management system. We should have some kind of Global Administration section for adding users and giving them access to modules (only global admins can add user to the system, no “guy from street” registration supported) and each module has its own administration section with its own admins and roles. We already have data model to store everything we need in appropriate way but have no idea how to access this data correctly from application.

Currently we see two possible ways to resolve this problem:

1. To write custom Membership and Role providers based on our DAL. Nobody from our team have done this before so we are not sure if this way worth the trouble. Membership provider cant offer as much flexibility as application needs so some crunches would be needed.
2. To dig through some obsolete books to find out how web sites administration system was organized before Membership providers where created.

Both this ways are not elegant and not obvious for us and its not an easy question which way to choose. Also we do believe that it can be other solution (of cause architecture can be affected). So, we would be glad to see any suggestion connected to this problem.

Answer 1

Well, finally we decided write all from scratch and it was easier that it seemed to be

• Add own IPrincipal implementation. Additional fields and completely different logic for IsInRole() method to avoid writing own attributes.
• Assigning our IPrincipal in Global.ajax event to User.

It wasn`t hard at all. Now we have all the flexibility we wanted. No providers involved.