Things to consider when Transitioning from Kentico Web Forms to Kentico MVC - part 2

Written by Ilesh Mistry
February 28th 2018

10 minute read

Welcome to the final blog post in my 2-part series where I’ll explore the things you need to consider before transitioning from working with Kentico web forms to Kentico MVC. In the first part in this series, I talked about a general overview of web forms vs MVC, what is expected of a MVC developer and some of the considerations around Kentico MVC compared to pure ASP.NET MVC. If you missed part 1, you can check it out here.

Right let's move back into some more things you would need to consider when transitioning from Kentico web forms development.

Kentico MVC training

Yellow school bus
With this alternative approach to building Kentico websites, there will be a learning curve for your developers and also your clients. I’ve outlined some key areas to focus on below.

Developer training

For developers, it's important to know that MVC brings a shift towards building your websites in the model, view and controller fashion compared with the drag and drop, templated based, component with code behind approach. It's important to make sure the thinking process is changed to be in line with this.

Currently, there is no official Kentico MVC training program out there, but be assured that Kentico are working on this and there will be more helpful material coming out soon.

In the meantime, there is plenty of Kentico documentation available to provide a lot of the answers to the questions developers will be asking.
Kentico MVC diagram from Kentico documentation
(Diagram taken from the Kentico documentation on how you would see Kentico MVC)

On my previous post, under the section '.Net MVC and Kentico MVC are the same right?', contains useful references you may need to help with training the developers, which include the Kentico MVC sample site and webinar links.

It's also a good idea to upskill your teams with ASP.NET MVC and understand how it all hooks up.

Kentico web forms developers, would need to change their mindset to now focus on how to utilise what they could create before in the web forms route to now rethink and adapt it to get the desired outcome using Kentico MVC.  

Content Only page types are the main way of building Kentico MVC pages.

Top tip: my recommendation would be is to create a Kentico MVC site template after you have created the content only page types you require that could be used for other sites. This way you would not need to recreate or export/import them into your other sites.

Here is a flow diagram example I've created which shows how you could create your MVC page
An example of the processes you may go through in creating a Kentico MVC page

A Template Engine, such as the Razor Syntax will help to display the view/render the content. Razor Syntax is an useful way of rendering HTML and C# generally having a .cshtml extension and to transition HTML to C# it uses the '@' symbol. An example of this is shown below.


@model ViewModels.ProductDetailViewModel  
@using Kentico.Web.Mvc 
 
<div class="page-container">
   <h1>@Model.ProductName</h1>
   <h2>@Model.ProductSubtitle</h2>

   <div class="product-section">
      <img alt="@Model.ProductImageAlt" src="@Url.Content(Model.ProductImage)" />
      <p class="product-description">
         @Model.ProductDescription
         <br />
         <span class="product-price">£@Model.ProductPrice</span>
      </p>
   </div>
</div>


Client training

As well as training developers, it’s also important to upskill your clients as the way they manage content has also changed. With the web forms route no longer available, there is no ‘pages’ tab for content entry, meaning no page widgets.

Top tip – it’s important to manage your client expectations so don't disregard the widgets too soon for Kentico MVC, for Kentico version 12, Kentico are working on providing a better content authoring approach by adding page layout widgets in for Kentico MVC. Check out their roadmap for this and more information on future features - https://www.kentico.com/product/roadmap

The form tab should be a major focus for training for the clients. Explaining to them that this will be the area where majority of the content would be managed by them.

Another important point to note is that some of the expected Kentico EMS features like personalisation would need to be something worked through via Kentico MVC and coded to perform what the client requires.

What's the Kentico upgrade/hotfixing process from web forms to MVC?

Rusty old car
Well, the simple answer is that you can't upgrade a Kentico web forms site to a Kentico MVC site using the upgrade tools provided by Kentico.

I'm not sure why you’d want to, but you can't go the other way either.

Hotfixes will work in the same as they do with web forms, however, bear in mind that you will need to run the hotfix utility for the administration area, as well as update the NuGet packages for the Kentico MVC application area.

Do the Kentico MVC Admin and application have a split personality?

combined image of two women's face
The answer is yes - you now have the ability to separate the Kentico admin area away from your Kentico MVC application structure. This will allow you to manage both elements as you wish, so they can be both in the same location or if it suits, in separate from each other. Therefore, if you use any form of source control system you can have two repositories, one for the admin files and the other for MVC files.

This comes with the added benefit of providing greater levels of security for the admin area compared to the public facing site.

On the MVC application side, as you’ll be using MVC over web forms, you will find it easier to architect a more effective solution that uses design patterns and Dependency Injection. Deploying sites would also be faster.

By combining this separation of concerns approach, you can also incorporate different front end development stacks with MVC. For example, you can find it a lot easier to use JavaScript frameworks like React to add elements on the page, build portions of a page or build Single Page Applications. This is exciting stuff for front-end developers who will have very little restrictions.

Does Kentico MVC have everything that the web forms approach used?

A man shrugging his shoulders and raising his arms
It’s important to understand that not everything will be available to you, should you wish to use the Kentico MVC approach. Have a look at Kentico’s documentation on what is and what isn’t supported on Kentico MVC.

Should you find you need a feature that was available and supported in Kentico web forms and it is not shown in the documentation you will need to look at alternative methods.

A example of a feature that is not supported is the multiple Page Aliases module. This is a key feature in Kentico web forms that allows you to add multiple aliases via the administration area. With the Kentico MVC model, you are only allowed to have a single alias due to the routing of that specific page. Therefore, you would need to think how you capture the possibility of having multiple aliases and then how you manage the routing process for them when a specific alias is requested by the visitor. The page alias management is a key requirement for clients so this is something to think about when building your websites using Kentico MVC.

For more information on page aliases in Kentico MVC, I will be releasing a blog post about it in the near future.

It's important to change your architecture and thought process in terms of how you imagine the layouts to work, this includes your master page layout. Depending on how you've built web form sites in the past, for example, if you used user controls on the master page for the header, navigation and footer, then you could treat these as potential views via the MVC approach.

You will notice variations in the setup depending on how you've installed the websites. For example, with a blank MVC site, you will notice existing page types might not be available, such as blog post page types. In this case you would need to recreate the page types that you require as content only page types using the same namespace/code names.

With this in mind, commonly used page types like the Blog Post, Folder, Events page types, which were heavily used via the web forms approach, will not be available. So you would now need to recreate them.

Top tip: if you want to use the same blog to blog month to blog post relationship functionality in the content tree from web forms e.g. when you create a blog post page type under a blog page type, the blog month is created for you automatically. Then I would recommend you create new Content Only page types for the blog, blog month and blog post, but make sure the namespace and code name is kept the same as you would expect in the web forms site, so CMS.Blog, CMS.BlogMonth and CMS.BlogPost.

Don't forget - Kentico and the Kentico MVC community is there for you!

People sitting in the park
The Kentico documentation is going to be the best starting point for you in terms of transitioning to Kentico MVC.

Don't forget to catch some of the articles written by other people in the community regarding Kentico MVC. I've listed some of the more recent ones below.

Summary

It’s important to note that the Kentico web forms approach is still going to supported, promoted and sold to clients and customers. So, there still are demands for projects and opportunities out there. I hope this blog post series helps you in making the switch over to Kentico MVC. It covers just some of the many areas of Kentico MVC. Remember to consider the training that may be required and the adjustment when building your Kentico websites compared to how you may have built them in web forms. Once you have transitioned, your developers will have different frameworks, providing more opportunities to program in the coding languages and technologies stacks that they would prefer to be working in.

If you’d like anymore information on how a Kentico MVC site could benefit your organisation, the please get in touch.