I am working on an ASP.NET4.0 / C # application for a public site that should only authenticate employees working in a related business. The idea is that the site has a CMS, so that employees can enter and make changes to certain content without having to work with any html.
My question is related to the design and use of the ASP.NET membership provider. I am not trying to get the site to work with an existing database, so there is no need to create my own MemberhipProvider for this purpose. However, since each user is an employee, I want to track additional information, such as name and office number. I can think of two obvious ways to achieve this:
Use the default SqlMembershipProvider class. As a result, I will need to add the appropriate tables to my database and create a separate table for any "additional" information that I want to save. This actually creates a vertical partition in the user table, since I will use the asp.net-assigned user ID as the primary key of the employee table. To get "additional" information, I could ask the provider for information about the current user and request a database in case I want to find out something else.
Create one table for all employee information (including username and password) and create my own MembershipProvider and MembershipUser classes with the desired functionality.
I also examined the use of profiles to store such information, however the site will publicly contain lists of employees, and these pages will need to access some of this information. As a result, I should probably cache this data, and it seems that using serialized fields that provide profiles will cause a problem.
So, purely in terms of design ... would it be better to distinguish between user and employee and use standard SqlMembershipProvider and related tables or write my own user tables that store the information I need and my own MemberProvider to access this information?
Shaun