Published: 4th Jan 2016

Kentico and MVC

Presenting at Kentico Connection in the Czech Republic on our experiences of working with Kentico and MVC

- true team

My presentation was very topical, as Kentico released version 9 of their product during the conference, and there was a lot of talk about MVC as a result of the improved support for it in Kentico version 9.

MVC is a technology that many organisations feel they should be using, however it’s clear that not many other Kentico partners have adopted the MVC approach.

Making the decision to use MVC

True have been using Kentico and MVC together for the last two years. We made the decision at the tail-end of 2013 to build all new projects on MVC for the following reasons:

1.  Attracting developer talent

Like most places in the UK, there is a digital skills shortage in Bristol. Developers are very much in demand, and we noticed an increase in developers coming for interviews who were reticent to take jobs using Web Forms. This was particularly prevalent amongst younger developers who may never have used Web Forms, and weren’t keen to learn what they viewed as an archaic technology.

In order to attract the right talent, we needed to move with the times and make sure we were adopting MVC.

2.  Clean semantic markup

We’ve always wanted to have complete control over our markup. Our front-end developers spend their days crafting finely tuned HTML, only to have Web Forms inject additional code into the page - much to their general consternation.

At other times, we find ourselves fighting against Web Forms and the way it implements the HTML specification. Some of the implementation goes against the fundamentals of HTML, for example, the implementation of a single form tag on a page that wraps all the other content. Or the lack of .Net user controls for modern HTML5 elements such as navigation. Or where Web Forms doesn’t provide the capability to extend an element’s attributes in the way modern usage requires e.g. input placeholder attributes.

The additional markup that Web Forms spits out also has performance implications. More markup results in a bigger page footprint, and in an age where our markup is consumed over mobile networks, we want that markup to be totally optimised.

This is ever more important as Google are using page speed as a ranking signal.

We’ve learnt to live with Web Forms as a necessary evil, but when something better arrived on the market that made more sense to our developers, we wanted to embrace it.

3.  Separation of layers

Web Forms doesn’t lend itself well to clean separation of layers – it’s impossible to entirely separate the ASPX presentation layer from the code behind. Separation of layers is considered good coding practice, because it makes code easier to maintain.

For us, it also has practical applications in that Razor views are separated from underlying code much more cleanly, meaning our front-end developers can use Razor without needing to understand any of the complexities of Asp.Net. They can work in the view while the .Net developers continue wiring up the underlying code, without stepping on one another’s toes.

4.  Unit testing

While we have unit tested Web Forms applications in the past, we find that the amount of additional code we have to write to enable this is time consuming and adds to code complexity.

MVC lends itself much better to unit testing because of the clean separation of layers.

Adapting our approach

These were the key reasons we felt it was important to make the switch to MVC back in 2013, but changing our approach threw up a number of challenges in terms of learning a new technology and how to use it in a way that worked for us.

Like many other Kentico partners, we were wedded to the Portal Engine way of working and using web parts. This is one of the areas of Kentico that will no longer work with MVC.

Hybrid approach

Initially we trialled a ‘hybrid’ approach, which allowed us to use both web parts and MVC. This approach used a ‘thin’ ASPX template, which allowed web part zones to be placed on the page. Apart from that, its sole purpose was to fill literals with the output from MVC controller actions as illustrated in the below code snippets.

Kentico MVCN
Figure 1: Thin ASPX Template
Kentico MVCN 2
Figure 2: Example code behind

This approach allowed us to continue using web parts, but we felt it was a bit too ‘hacky’, and still didn’t give us the full control over our markup we desired.

Kentico/.Net Routing Approach

Following on from this trial, we decided to go for a purer MVC approach as recommended by Kentico. This meant:

  • Replacing web parts with our own MVC components
  • Ditching the Design tab in Kentico and controlling any editing from the Form tab
  • Using a combination of Kentico routing as well as .Net routing

Kentico routing

The basis for this methodology entails adding a page template using the MVC template type where the page template is linked to a controller action method in code. A page type is then created that uses this page template as its default.

What we like about this approach:

  1. Standard Kentico URL routing functionality is maintained, so page aliasing and all the in-built SEO capabilities are still available. When a user lands on a URL that is tied to a controller action, the action method will be executed.
  2. Content editors can create content pages anywhere in the tree and don’t need to be tied to using specific URL structures. The page will be tied up to the correct action method correctly as dictated by the page type/template.
  3. The Kentico context is automatically available to the developer, so we know which page a user is requesting, and any other contextual information about this request.
  4. The editing experience is simplified for editors who no longer need to edit content across multiple tabs – the Page, Design and Form tabs. All content editing is now done on the Form.

.Net routing

Additionally, we used normal .Net routes for URLs that weren’t related to pages in the CMS. This was typically used for Ajax requests.

The routes in this instance are added to the RouteConfig in code.

Kentico MVC 3
Figure 3: Example of .Net route for ajax requests

Tips and Recommendations

  1. When using .Net routing, use a specific url format e.g. /ajax/{action} – this will ensure your .Net routes don’t conflict with any Kentico routes.
  2. Exclude .Net route URLs from the Kentico rewriting engine for performance reasons – so the rewriting engine doesn’t try to resolve them. This can be done under Settings -> URLs and SEO -> Excluded URLs.
  3. Create a bank of reusable MVC components to use on other projects.
  4. Embrace the API – you’ll need to use it to build your bank of components. It is very powerful – you can do most anything with the API. Use a decompiler tool such as Telerik’s JustDecompile to interrogate the Kentico DLLs and understand what’s available in the API, and what’s going on behind the scenes.
  5. Ensure you check permissions in your MVC code, as this won’t be applied out the box.
  6. Cache any API calls that are retrieving data from the database, as caching won’t be applied automatically.
  7. Write code that adheres to Kentico settings so that your solution is kept in line with Kentico settings. You may not always need the functionality straight away, but it will be frustrating to editors if they try to change something in the CMS, and the change doesn’t take effect on the site. E.g. when creating a custom navigation component, make sure it adheres to the ‘Show In Navigation’ setting on the page’s Property tab.
  8. Apply relevant events for marketing automation in your custom code. E.g. when creating a login component, ensure you are recording this as a log in event, so that marketing automation can be applied properly. Even if this isn’t turned on in the first instance, it will save you a rework in the future if you want to use this functionality down the line.

Dissecting the Kentico web parts to understand what they’re doing is an invaluable way of making sure you haven’t missed anything.

The Benefits

Having adapted our approach to using MVC, we have reaped a number of benefits:

  1. An uplift in the ability to be an attractive place for developers to work which has helped us to recruit the right talent.
  2. Better performing websites as a result of the performance benefits of MVC. Gaining complete control over the markup and the fact it is separate from underlying code has meant we can push optimisation of output even further.
  3. Efficiency savings in having better code and unit testing which has resulted in less time spent in QA and less time spent maintaining code, with the developers having more confidence in the code base.
  4. Happier developers – our dev team is far more energised and enthusiastic because they’re able to work on cutting-edge technologies and they are able to apply best practice to their work.
- true team