December 1, 2009

How can I customize my user model in my ASP.NET MVC web site? Part 2

What do I extend/replace?

Related Posts

Carrying on from my previous blog post I need to figure out which bits of the framework I need to customize or extend in order to connect to the database schema we created. It turns out there are a number of components and this isn’t exactly the laziest route forward - nor perhaps the most intuitive – especially given that I’m new to ASP.NET MVC, in fact, this is my first project using this pattern – well, I guess this prototype is my second, but you get the idea.

I will first discuss which components need to be modified/extended so that you have an understanding of the scope of what needs to be done and how to go about that. I will then go on to discuss how, so just in case you read this post and wonder when I’m going to get to the how… it’s coming, your patience will pay off ;)

So these are the components that need extending:

  • System.Web.Mvc.AuthorizeAttribute
  • System.Web.Security.MembershipProvider
  • System.Web.Security.RoleProvider
  • System.Web.Profile.ProfileProvider
  • System.Web.Profile.ProfileBase

System.Web.Mvc.AuthorizeAttribute

This is the class that will be used to verify that the user has authorization to access a resource – either a controller or an action. I will explain how this is achieved further on.

System.Web.Security.MembershipProvider

Think of this like a repository manager for our membership base [base as in a community sense not a base-class sense]. This isn’t designed to be used for managing user profiles, but rather it manages the user account credentials, including provision for the ability for a user to reset their password using a security question and answer – although we don’t use that feature in this prototype. It also allows you to search your membership base for things like number of users currently online, inactive user accounts, locked accounts etc [our prototype doesn’t lock accounts out, so we’ve ditched all the fields that pertain to that]. You will need to create a class that derives from MembershipProvider to hook into your own data repository [database, flatfile, whatever you’re using to hold your user information].

System.Web.Security.RoleProvider

The RoleProvider is similar to the MembershipProvider. It is the repository manager for managing roles and role assignment within your application. Once again, you’ll need to create a class that derives from RoleProvider to hook into your own data repository.

System.Web.Profile.ProfileProvider

By now you’ve probably spotted a pattern with the providers – the ProfileProvider is no different. This provider is similar to the MembershipProvider, except that it is used to manage the user’s profile information – this is personalization information about this user as opposed to their credentials. In this prototype they’re all stored in the same table – but if you’ve looked at the aspnet_regsql generated database you will notice that the user’s credential information and their personal profiles are stored in separate tables. Just like the MembershipProvider and RoleProvider you will need to create a class that derives from ProfileProvider that hooks into your own data repository.

The Provider classes all provide the data abstraction layer between your application and your physical data store.

System.Web.Profile.ProfileBase

This is the class that we extend to hold our custom user information relevant to your web application. For instance, in my application things like FirstName, LastName, DisplayName, Reputation, Location and a few other fields. It should be said that strictly speaking you don’t need to extend this class. You can access each of your defined properties using the GetPropertyValue and SetPropertyValue methods to access the data in each of your fields. You only need to extend this class if you’d prefer to access your values in a type safe manner.

Why use these objects instead of completely running your own user API? I asked myself the same question. The best reason I can think of is this: There are plenty of utilities written out there that manage user bases that sit on top of the prebuilt API – this means that they can be modified very simply to sit on top of these objects rather than having to completely write your own management system from scratch.

No comments:

Post a Comment

There was an error in this gadget