View Renderings vs. Controller Renderings in the Sitecore ASP.NET CMS

This blog post contains my perspective on contrasts between view and controller renderings in MVC solutions that use the Sitecore ASP.NET web Content Management System (CMS) and Experience Platform (XP). In many cases, you can use view renderings and controller renderings to achieve the same objectives, and the choice is a matter of preference. In other cases, one rendering technology may be more appropriate based on criteria including those discussed here. This blog post does not consider these constructs in the context of processing entire requests at the page/request level, but only these two types of renderings, and only at the presentation component level.

Sitecore MVC solutions support view renderings, which allow runtime binding of nested views to placeholders in existing views. Sitecore invokes the mvc.getModel pipeline to determine and construct the model to pass to the view as specified in the view definition item. It then passes that model to the class compiled from the .cshtml file specified in the view definition item.

Controller renderings function similar to view renderings in that they define presentation components for nesting within other components. With view renderings, the rendering engine invokes a .cshtml file; with controller renderings, the rendering engine invokes an action method in a controller class.

Logic in the action method of a controller renderings can invoke the View() method in the System.Web.Mvc.Controller base class, which in turn invokes a view. With this approach, the controller rendering functions much like a view rendering, but with at least two differences:

  • The controller can contain logic, including creation of the model passed to the view.
  • The View() method called by a controller renderings can use ASP.NET logic to determine the path to the .cshtml file rather than using a view definition item in which a field must specify the literal path to the file.

Due to the order of operations and for performance or other reasons, some logic may belong or function correctly only in the primary controller activated by the HTTP request rather than an individual controller rendering or view rendering. For example, the primary controller may be responsible for redirection. Again, this blog post does not attempt to account for these considerations at the request level, but only presentation at the component level.

View Renderings

  • Simple to use for relatively small and quick components that mostly contain markup with little logic, and for which the Sitecore model resolution process suffices, such as simple content presentation.
  • Without a solution such as the first blog post linked in the Resources section at the end of this page, require the creation of a model definition item. This can be useful when passing different models to a single view.
  • Relative to controller renderings, simplify form posts
  • Can contain nested placeholders
  • Can be useful for components that generate significant markup
  • Use the mvc.getModel pipeline to determine the view, typically from the view definition item

Controller Renderings

  • Provide a superset of the features available with view renderings
  • Support separation of concerns by adding controller logic not in the model (state) or the view (presentation)
  • Allow the developer to construct and pass a model to a view
  • Can return null, avoiding view invocation if there is no data to present
  • Can be appropriate for generating output other than markup, such as JSON
  • Do not require model definition items
  • Bypass the mvc.getModel pipeline
  • May be overkill for simple things
  • Provide standard MVC support for common patterns such as repository and dependency injection
  • Controller renderings can be more testable than view renderings
  • Potentially fewer files to deploy, specifically .cshtml


If you have suggestions for when view renderings or controller renderings may be more appropriate, please comment on this blog post.