Controller vs. View Renderings: A Case for Controller Renderings

Sitecore MVC offers multiple ways of implementing a rendering, with the most common being View Renderings and Controller Renderings.

Each of these two implementation options have advantages and disadvantages over the other. While these differences mostly come down to details in each implementation, there are very good reasons to choose one over the other. Spoiler alert: Controller Renderings win. Here's why.

View and Controller Renderings are two of the most used renderings in Sitecore.

View Renderings

A View Rendering definition item.

A Sitecore View Rendering is the simplest type of rendering in Sitecore MVC. In Sitecore, this consists of a rendering definition item that points to a Razor view file on disk (a .cshtml file). The default model is RenderingModel and is assembled by the Sitecore MVC pipeline automatically. This model can be used directly or extended via inheritance or a custom implementation of IRenderingModel.

A basic Sitecore MVC view.

Notice the lack of controller logic - no ActionResult methods or controller class to implement! Super-simple. Even better, the RenderingModel object usually contains enough fields to reliably output all content from the context and datasource items behind the current rendering.

Controller Renderings

A Controller Rendering definition item.

A Sitecore Controller Rendering is more complex than a View Rendering, mainly in that it requires a controller action. The rendering definition item includes both a controller name and controller action to execute. The controller action is then responsible for returning the correct view.

A basic controller rendering method. 1) Check for datasource, 2) populate model, 3) return view.

A basic view that is returned by a controller method. Notice the explicit model definition on line 3.

As where View Renderings are great for rendering simple content, Controller Renderings allow business or other complex logic to execute before returning a view. In fact, it is possible to branch and return different views - for example, you may want to use one view for rendering content and one view for displaying Experience Editor fields.

The "Right" Solution

It may seem simple to choose between Controller and View Renderings - View for simple content, Controller for complex content - there is an argument to be made for using Controller renderings more often than not:

• Consistency - Being able to implement new components in the same way as old components helps a development team implement with consistent quality.
• Discoverability - Finding rendering definition items in Sitecore and locating the related code in the Visual Studio solution is easier. This especially helps new developers discover existing functionality.
• Expandability - If a component needs to be upgraded with new or complex business logic, a View Rendering will present challenges. Sure, you could implement some logic in the view based on the RenderingModel, but that breaks the separation of concerns that is so crucial to MVC.
• Performance - View Renderings are generally faster than Controller renderings (no extra Controller to instantiate, etc.), but the difference is tiny compared to the overall time it takes to assemble a whole page in Sitecore. Any performance difference can be easily offset with proper HTML/output caching, assuming your controller-based component is a good candidate for that level of caching.

The benefits of implementation consistency, code discoverability, and component expandability far outweigh the minor performance difference between View and Controller Renderings, and for that, I've been building Sitecore solutions almost exclusively with Controller Renderings since I started working in Sitecore MVC.

Do you have questions, comments, or corrections for this post? Find me on Twitter: @BrandonMBruno