Roles are then your best option, even if you have to set up a custom provider to handle the roles. Find common elements of admin and customer and put in a class that both are inherited from. You can then cast as customer or provider, as needed. This may not be an option if they have nothing in common, however.

You can logically separate the branches, using folders, and set up a factor that returns either the parent class or even an object. The farther up the stack you go, the more generic, and the more you will have to test to make sure you are not killing yourself.

If none of these options work, you are going to write a lot of code to handle whether a person is a customer or admin. One option, that might work, is a user object that stores either a customer or admin and can return either object, depending on the user's role.

If none of those work, you are back to writing a lot of code.

*************************************************
 I’d really like to avoid this, as the applications will share a number of web user controls.

 

 

 I would separate the logic into two applications, even if the URLs end up looking something like:

 

 http://mysite.com/admin

 http://mysite.com/customer

 

 You may also have a top level application, from a logical point of view:

 

 http://mysite.com

 

 Hope this helps

 --
 Gregory A. Beamer
 MVP, MCP: +I, SE, SD, DBA