Umbraco SurfaceController vs RenderMvcController

Question

What is the purpose, and when should I use a SurfaceController vs RenderMvcController? It seems that there isn't really anything I can do with a SurfaceController I can't do with RenderMvcController. For example, I'm specifically thinking about handling form submission. With RenderMvcController I can do:

public class HomeController : RenderMvcController
{
    private IUmbracoMapper _umbracoMapper;

    public HomeController()
    {
        _umbracoMapper = new UmbracoMapper();
    }

    [HttpGet]
    public ActionResult Home()
    {
        HomeViewModel viewModel = new HomeViewModel();

        _umbracoMapper.Map(CurrentPage, viewModel);

        return CurrentTemplate(viewModel);
    }

    [HttpPost]
    public ActionResult Home(HomeViewModel viewModel)
    {
        // Handle form submission
    }
}

This seems more in keeping with MVC to me, especially since I can use packages like UmbracoMapper to map the current Umbraco node to a view model and pass that to my View? Why and when should I use a SurfaceController?

If I was so inclined, I could use RenderMvcController to hijack every route for a given node giving me more control over my applciation, a bit more like a pure ASP.NET MVC app. Is this a good thing?

Centurial

Answer 1

From the official documentation:

Surface Controller

A SurfaceController is an MVC controller that interacts with the front-end rendering of an UmbracoPage. They can be used for rendering Child Action content, for handling form data submissions and for rendering Child Action macros. SurfaceControllers are auto-routed meaning that you don't have to add/create your own routes for these controllers to work.

Source: http://our.umbraco.org/documentation/Reference/Templating/Mvc/surface-controllers

Custom Controllers

By default all of the front end routing is executed via the Umbraco.Web.Mvc.RenderMvcController Index Action which should work fine for most people. However, in some cases people may want complete control over this execution and may want their own Action to execute. Some reasons for this may be: to control exactly how views are rendered, custom/granular security for certain pages/templates or to be able to execute any custom code in the controller that renders the front end. The good news is that this is completely possible. This process is all about convention and it's really simple!

Source: http://our.umbraco.org/documentation/Reference/Templating/Mvc/custom-controllers

Does that help? You're right though, I think the only real difference with the Surface controller is the auto routing.

Simon

Flieger

Thanks for replying. I started thinking about this after reading Sebaastian Janssen's blog post on cultiv.nl about route hijacking (What's this Umbraco route hijacking all about?). I wonder why would you use a SurfaceController when you can achieve the same results in a more pure (in the ASP.NET MVC sense) approach. Maybe there is no technically correct answer and it is a matter of preference..? – Centurial

Answer 2

The difference is mainly on intend of use. You will find either one will work in most cases.

Surfacecontroller is intended to be used if you have some user interactions on that view. Such as form submission. It contains a few helper methods for redirects such as

RedirectToCurrentUmbracoPage(...)
RedirectToUmbracoPage(...)

RenderMvcController expose a Security property of type WebSecurity that may be helpful in some cases. Some of the methods are

IsAuthenticated()
IsMemberAuthorized()
PerformLogin(userID)

Granger