I'm having trouble designing this role (or permission) based application, when it comes to figuring out how to handle actions that differ per use role.

For instance, our controller is App\ResourceController, and we will be editing the resource. There are 2 roles: admin and user. The admin is allowed to edit every field of the resource, while the user is restricted to some of them.

I'm struggling figuring out the best approach between implementing a single controller that will handle both cases, or routing the request to a different controller for the same resource (like App\Admin\ResourceController, App\User\ResourceController).

The issue with the single controller approach, is that it isn't just showing a different form (with restricted fields) based on role, but also validating different fields and more. The controller's body would pretty much look like a big if-else statement.

Is multiple controller the correct approach, or is there a different one using permissions instead of roles?

This will largely depend on the MVC framework you are using. The ASP.NET MVC framework in .NET, for example, has a permissions system built in (called roles). You could use one controller with multiple methods:

public class ResourceController : Controller
{
    [Authorize(Roles = "User")]
    public ActionResult CreateAsUser()
    {
        // ...
    }

    [Authorize(Roles = "User")]
    [HttpPost]
    public ActionResult CreateAsUser(ResourceModel model)
    {
        // ...
    }

    [Authorize(Roles = "Admin")]
    public ActionResult CreateAsAdmin()
    {
        // ...
    }

    [Authorize(Roles = "Admin")]
    [HttpPost]
    public ActionResult CreateAsAdmin(ResourceModel model)
    {
        // ...
    }
}

Most fully featured MVC frameworks will have some kind of role based permissions system built in that you can use. Really, your next step is identifying the MVC framework you are using (or decide which one to use now that you know it needs role based permissions) and do some research on how to implement those permissions.

  • Basically, this solution is about using a single controller per resource, but multiple methods per action, based on roles. Sounds good. – Christopher Francisco Dec 11 '15 at 18:38
  • This at least removes the if statments from your controller code. Any code related to the actual CRUD operations can be pushed into a service class or two if need be as well, in order to prevent further repetition. – Greg Burghardt Dec 11 '15 at 19:31

In general your choice should be for maintainability and simplicity. In the case you describe it seems that the added complexity from trying to combine the controllers will not be worth the added complexity in the long run.

That being said, making the practical choice between the approaches described depends on the number of elements that differ for user and admin. If that number is small, then the added complexity may be worthwhile.

If you are using an object-oriented environment a third option might be to have the App\Admin\ResourceController inherit from App\User\ResourceController.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.