views:

44

answers:

1

I'm looking for an elegant pattern to solve this problem:

I have several user roles in my system, and for many of my controller actions, I need to deal with slightly different data.

For example, take

/Users/Edit/1

This allows a Moderator to edit a users email address, but Administrators to edit a user's email address and password.

I'd like a design for separating the two different bits of action code for the GET and the POST.

Solutions I've come up with so far are:

  • Switch inside each method, however this doesn't really help when i want different model arguments on the POST :(
  • Custom controller factory which chooses a UsersController_ForModerators and UsersController_ForAdmins instead of just UsersController from the controller name and current user role
  • Custom action invoker which choose the Edit_ForModerators method in a similar way to above
  • Have an IUsersController and register a different implementation of it in my IoC container as a named instance based on Role
  • Build an implementation of the controller at runtime using Castle DynamicProxy and manipulate the methods to those from role-based implementations

Im preferring the named IoC instance route atm as it means all my urls/routing will work seamlessly.

Ideas? Suggestions?

A: 

Woo, no answers. Here's my attempt at the IoC approach, I think I'll be going with this unless anyone has any other ideas.

Segregating Controller Logic Based on User Role in ASP.NET MVC

Andrew Bullock