An Introduction To Use Episerver with MVC

Episerver has supported MVC since Episerver version 7 and since then hundreds of websites have been built using it. For those of you new to .NET, MVC is an architectural pattern that makes it easier for you to rewrite code that is easier to maintain, test and implement, compared to the first method, called Web Forms. Episerver MVC has been out since 2012 so there should be no excuse why you would even consider using web forms over MVC in your new project. The benefits of using MVC over web forms has been documented enough, so I won't go over it. I still get a few people once in a while asking for advice about MVC, or web forms, so it seems there still needs to be better clarification around this topic. In reality, using Episever with MVC is very easy after you understand some core topics. Episerver fully supports the .NET MVC Framework and Razor and getting up to speed with it shouldn't take you very long. It's probably worth mentioning now, that the way Episerver handles MVC is slightly different than the way a normal ASP.NET handles. In this article, I’m going to describe some of those differences and how the MVC Framework fits within the Episerver pipeline.

Introduction with Episerver and MVC

When you create a new project using the Episerver Visual studio extension, select MVC as the installation option, sit back and everything you need to use Episerver with MVC will be installed for you. The fundamental building blocks in Episerver are Page Types. I've talked about page types before, here, so I won't go into too much detail. The main point you need to consider when using MVC with Episerver, is that in MVC a URL maps to a controller and an action. In Episerver this isn't the case. A URL will point to a page type with a specific ID. So, the way we handle routing will always be slightly different. In fact, if you try and learn any other ASP.NET CMS you will also always come across a similar dilemma. In case you haven't come across the code you'll need to create a page type, see below:
using System.ComponentModel.DataAnnotations;
using EPiServer.Core;
using EPiServer.DataAnnotations;
using EPiServer.Shell.ObjectEditing;
using EPiServer.DataAbstraction;

namespace JonDJones.Com.Core.Pages
{

  [ContentType(
  DisplayName = "Content Page",
  GUID = "8dee011f-8dbf-43ab-b4f3-211db5ceb9d5",
  Description = "Content Page",
  GroupName = "Standard")]
  public class ContentPage : PageData
  {
  [Display(
  Name = "Page Title",
  Description = "Page Title",
  GroupName = SystemTabNames.Content,
  Order = 100)]
  [CultureSpecific]
  public virtual string PageTitle { get; set; }
  }
}

In Episerver MVC, we still have models, views and controllers but we also have to think about page-types. When we build our Episerver controller, the data that will be passed around will be based on page-types rather than the usual HTTP Context. Obviously, it's not called Page Type, View, Controller and when we work with Episerver we use models to pass the page type data to and from the view. A model for the page type above might look like this:
using EPiServer.Core;
using JonDJones.Com.Core.Pages;
using JonDJones.Com.Core;
using JonDJones.Com.Core.ViewModel.Base;

namespace JonDJones.Com.Core.ViewModel.Pages
{
  public class ContentPageViewModel : IPageViewModel<T> where T : GlobalBasePage
  {
      public ContentPage _currentPage;

      public ContentPageViewModel(ContentPage currentPage)
      {
           _currentPage = currentPage;
      }
  }
}
If you want to strictly follow the MVC pattern then you should never expose the ContentPage to your view. In the MVC model, you're only meant to expose the minimum set of properties to the outside world. In reality, this does take a lot more work to implement, so you will have to decide how much information you want to pass back. The page controller is the file that strays the furthest away from original MVC. In a lot of circumstances, the way you would write your view and model code is exactly the same as you would in a normal MVCwebsite. When we work with Episerver we don't use the MVC controller, instead, we use the Episerver Controller. The Episerver controller still inherits from the generic MVC controller class, it's just that Episerver adds in some additional Episerver specific stuff as well. For example, when you create an Episerver controller you will still need to implement a default Index method, if you fail to provide one then you'll see an exception rather than your expected page content.
using System.Web.Mvc;
using JonDJones.Com.Core.Pages;

using EPiServer.Core;
using JonDJones.Com.Core.ViewModel;
using JonDJones.Com.Controllers.Base;
using JonDJones.Com.Core.ViewModel.Pages;

namespace JonDJones.Com.Controllers.Pages
{
  public class ContentPageController : PageController<ContentPage>
  {
  public ActionResult Index(ContentPage currentPage)
  {
  return View("Index", new ContentPageViewModel(currentPage, EpiServerDependencies));
  }
  }
}
The last part still to discuss is the view. The view is pretty much the same as a normal MVC one:
@model JonDJones.Com.Core.ViewModel.Pages.ContentPageViewModel

<header class="intro-header" style="background-image: url('/ClientResources/img/about-bg.jpg')">
    <div class="container">
        <div class="row">
            <div class="col-lg-8 col-lg-offset-2 col-md-10 col-md-offset-1">
                <div class="page-heading">
                    <h1>@Model.CurrentPage.PageTitle</h1>
                    <hr class="small">
                </div>
            </div>
        </div>
    </div>
</header>

Following the normal .NET MVC convention, you will need to create your views within the 'View' folder in your web project. For each page-type you will need to create a folder with the name of the controller, without the 'Controller' prefix. So, if you have a ContentPageController, you would create a folder in view called 'ContentPage'. The view will also need to be called 'index.cshtml' as it needs to match the default Index action you created within your controller. You can write some custom code to change this if you really want to, but that's outside the scope of this article. If you do all these three things, then when you load your website, you should be able to add a break pointing your controller and see it being called. When the controller gets loaded, the Episerver current page data will be populated.

MVC Framework Takeaways

I'm hoping that since you've read this tutorial, you should realize that implementing MVC with Episerver is pretty simple. There are a few concepts that you need to understand as the way Episerver works is slightly different to how normal MVC works.

submit to reddit

Jon D Jones

Software Architect, Programmer and Technologist Jon Jones is founder and CEO of London-based tech firm Digital Prompt. He has been working in the field for nearly a decade, specializing in new technologies and technical solution research in the web business. A passionate blogger by heart , speaker & consultant from England.. always on the hunt for the next challenge

Back to top