ASP.NET Providers - Membership, Role, and Profile
Seems like any website you start nowadays involves creating the same common features we see all over the web. These include creating user account functionality, storing profile information, implementing role-based access to content and features, instantiating SQL tables and data access repositories, and so on, so forth. In most cases it would be a complete waste of time and money to roll your own implementation every time.
There are plenty of frameworks out there that tackle this problem for you and abstract out details you shouldn’t have to worry about. If you are in the .NET world, there are a set of these services available to you that are baked right into the .NET 2.0 Framework. I’m going to show you a personal example of how easy it is to add some of this functionality to an existing site, even one with an antique and cumbersome architecture. Implementing these features using the ASP.NET 2.0 Provider Model on said architecture has convinced me that it couldn’t be easier to add such functionality to a website, no matter what beast of a site you are dealing with.
ASP.NET 2.0 Provider Model
With the advent of ASP.NET 2.0, Microsoft introduced a set of configuration-driven services that adhere to the Provider Model pattern. These services focus on storing application state of a website using a very flexible and extensible data access strategy. The available features that can be added to your website include Membership (which includes authentication and authorization), Role Management, Profile, Session State, Web Parts Personalization, and Site Map navigation. The whole idea is to be able to secure and enhance an existing site by dropping in a few lines into the Web.config, using a Microsoft utility to automatically create database tables (most likely your chosen storage medium), and then dropping, configuring, and skinning a few controls into your existing pages. To read a more thorough introduction to the Provider Model and these ASP.NET 2.0 Provider services (including a few helpful diagrams), check out the following link:
We are in the process right now of exploring the cost benefits and customer experience improvements in moving this set of offerings to an online suite of websites. The first step we are taking is to build an online version of one of the products where users can obtain a user account to view the content. Building new applications is one thing, but upgrading and maintaining existing applications (especially ones you have inherited) is a whole different development experience. This is where my appreciation for the ease and flexibility of what Microsoft is offering comes into play.
The rest of the blog posts in this series can be found at the following links:
- ASP.NET Providers - Getting Started
- ASP.NET Providers - Membership
- ASP.NET Providers - Role Management
- ASP.NET Providers - Profile
In addition, I came across an issue when using the Profile system with the Web Application project template instead of the Web Site project template as found in Visual Studio’s default set of project templates. It has to do with the Profile proxy class object not being auto-generated by Visual Studio when using the Web Application project template. Read the following blog post for a discussion of the problem and it’s solution:
Also, I have another post discussing the advantages of using the ASP.NET Provider system under IIS 7 found in Windows Vista and Server 2008; it will also include some issues with using this system if some of your content is static HTML instead of ASPX pages. You can find all of this goodness by following the link below: