When we want to build interactive websites in any CMS system, we need a way to split our single pages into smaller chunks of functionality that can be re-used within our project. If you have a header on every page, it doesn’t make a lot of sense of having more than one version of the code to it.
When we work with Sitecore MVC, we can add these dynamic components using Renderings. In Sitecore MVC, we have two different flavours, view renderings, and controller renderings. In today’s tutorial, I’m going to cover the difference between them and give some loose tips as to when you should use one over the other.
A view rendering is an MVC view (a cshtml file) and nothing else. A view rendering can be thought of in a similar manner as a partial in normal MVC. You can pass a Model into it, or, in Sitecore terms a ‘RenderingModel’. A RenderingModel can be defined just like any normal POCO; as a developer you are free to define your own properties. The model is then injected via the Sitecore MVC pipeline into the view on page load.
The biggest advantage of using a view rendering is the ease of use. From my experience, I would say you would usually want to use a view rendering when you want to display some HTML that has no logic in it at all, outputting some data from the context item or data source item.
One example of where you might use a view rendering is when you need to render the same data in different ways. One example is a product in an e-commerce site. The product uses the same data, like Name, Price etc.. but depending on where the product is added to the page, you may want to have it render differently. A common scenario is having a mega-menu that displays the product as a featured item, as well as a listing page that shows a cut-down version. In this example, you could create one Product Model and then create many view renderings to display it differently.
A controller rendering will probably be more familiar to people who come from a standard MVC background. When we define a controller rendering in Sitecore, instead of specifying a view, we point Sitecore to an action within a controller. When the controller rendering is added to a placeholder, the action you define Sitecore to use will be executed and from within here you can define the view to be used for the request.
Controller renderings should be used when you need to add business logic into your control. Maybe you need to call a web API in your controller to get some real time data, or, you want to dynamically get content from Sitecore and do something with it, like a search control.
When you use controller renderings it also means you can unit test your work and use dependency injection. If you combine this with a good deployment process, you can get better confidence that the changes you have made won’t break your system.
View Renderings Vs Controller Renderings
In terms of which one is better, then I’m afraid I can’t answer you. There is definitely no right or wrong answer to that questions, although depending on your requirements, it sometimes makes sense to use one, or the other.
If you need to do any business logic in your rendering you will want to do that in a separate layer. However, because you do not have access to a controller, the only place is a controller rendering. Technically you can always use controller rendering but you end up creating a lot of unneeded controllers if the rendering doesn’t do any custom logic.
I hope this has cleared up any confusion you might have between view renderings and controller rendering. The basic concept is that view renderings are very simple and should be used in a simple situation. Controller renderings are more advanced and should be used when you need to do some cool stuff before the control is rendered.