Sitecore MVC for Front-end developers
Part 1: Introduction

29 September 2017


In this blog series I describe building a full site using Sitecore MVC with minimal back-end code. The solution will evolve over the blog series and you can see the full source here on GitHub. I'm aiming to show one of the many benefits of Sitecore MVC: View renderings. These can be made without compiled C# code. This is useful for front-end developers (FEDs), prototyping or making components which are deployable without re-starting Sitecore. This is not a common approach, but I will show how easy it is. At the end of the series I will give a full rundown of the pros and cons.

Why am I doing this

As developers we often over-complicate things. I'm going to see how simple I can make a Helix solution and make it accessible to FEDs. Teams often insulate FEDs from Sitecore. FED workflow is separate from back-end developers (BEDs). View renderings used with extension methods can enable FEDs to work in the same technology stack as BEDs. Publish in Visual Studio can update a remote Sitecore instance if FEDs don't have a local one.

Surely view renderings can't be used for everything?

To answer this, we first need to ask the question what do we actually do in Sitecore? Answer: We render content from items. There are three basic scenarios for choosing what content to render.

  1. Context Item
  2. Datasource Item
  3. Settings Item

Rendering content from the Context Item

This is the simplest scenario for rendering content from Sitecore. Use the following in your view rendering (cshtml).


This will render the Title field of the current page item.

Rendering content from a Datasource Item

This uses the same code as above. A nice thing about Sitecore MVC is that accessing a datasource item is OOTB functionality, unlike in WebForms.

To retrieve content from a different item (e.g. parent or child) you use an overload which takes an item as a parameter.

@Html.Sitecore().Field(item, "Title")

Rendering content from a settings item

This is the same as the previous example. The complexity is in retrieving the settings item. One way to do it is like this:

        var db = Model.Item.Database;
        var itemPath = @"/sitecore/content/Sites/MySite/Settings/SomeSettingsItem";
        var settingsItem = db.GetItem(itemPath);
    @Html.Sitecore().Field(settingsItem, "Title")

The code above is simple. If you access this item in one place, then this is not a problem. If you need to get content from several different settings items, then you should avoid re-writing this path in each component. If you use the component in more than one site, then you need to copy the component and change the query path.

Source Code

Feel free to register bugs, submit pull requests, fork etc.

Technology Mix

What's Covered?

This blog series illustrates how simple it can be to build a site using purely view renderings. I will cover the topics below. For each component I will describe why it went in to which Helix layer and its grouping with other modules.

  1. Introduction: (this page)
  2. The Layout
  3. MetaData
  4. Header Structure
  5. Navigation
  6. Section Header
  7. Content
  8. Product Details
  9. Product/Article List
  10. Sidebar Widget
  11. Footer

Next Article

Sitecore MVC for Front-end developers - Part 2 - Layout

Tags: Sitecore MVCHelixHedgehog TDS
comments powered by Disqus