Things to consider when transitioning from Kentico Web Forms to Kentico MVC - part 1

Written by Ilesh Mistry
February 19th 2018

5 minute read

Kentico announced during their roadshows last year that during 2018 they will be focusing on the Kentico MVC (Model View Controller) first approach. This means that any new Kentico 12 and above features will be tested and provided for the Kentico MVC development model first and then applied to the Kentico Web Forms model if there is a requirement for it.

I've worked with Kentico Web Forms since version 3.1, that's a long time developing and architecting lots of Kentico websites.

Lots of things have changed, but here is an image of Kentico version 3.1, if you haven't seen it before:
Kentico version 3.1 image of admin area
The Kentico 3.1 documentation out there, should you want to compare it with the latest version ;) - Kentico 3.1 documentation

Although Kentico's drive and focus is towards Kentico MVC, Kentico web forms are not going away just yet and will be around for a decent amount of time still. Personally, I believe Kentico will still be supporting the web forms route for a number of years.

It’s still important however, to consider the transition from Kentico web forms to Kentico MVC as and when this is required within your businesses.

With all of this in mind, I will cover some key hints and tips in this 2 part blog series to help you start thinking about transitioning to Kentico MVC

Web Forms vs .Net MVC

Firstly, let’s look at the differences between the two development approaches.

Lady punching a man with a hat

Web forms

ASP.NET Web Forms are a way of building sites/applications faster using RAD (Rapid Application Development) users perform the request using their browser. Dynamic pages can be built using a combination of client side and server-side controls and their code. The familiar drag and drop capabilities are also available in web forms which allow the layout and components to be manipulated without heavy developer intervention. This generally composes of a single form element to control the pages.

MVC

ASP.NET MVC is a way of building applications via an architectural pattern for faster development, with a highly testable presentation area and lightweight framework in comparison to the Web Forms approach. This method provides a way to build dynamic websites that enable separation of concerns using the main components of the model, the view and the controller. MVC provides far better control of the components and structure of pages. It focuses on the developer first approach, promoting code usability and the ability to have nested form elements.

Web forms and MVC both have their advantages and disadvantages and there are a lot of factors to consider when deciding which option is best for your project. You will need to look at the business objectives, the client requirements your developers skillset, the budget along with your resources and the time you have to build the solution.

Calling the MVC developer from within you

Man stretching his arms in the air in front of a computer
If you decide to go down the Kentico MVC route, you will need someone in the team who knows or has used .Net MVC before. This does not necessarily mean that developers without .Net MVC experience would not be able to progress with this approach, but having the experience would be big advantage to get started.

If you're not too familiar with .Net MVC, then check out some of the many resources online to help you, including this article on codeproject.com.

Here is a simple diagram illustrating the MVC model and how it can work within a typical set up.

An example of how MVC works
MVC diagram steps

  1. Visitor performs an action e.g. requests a page via the browser URL or clicks a button on a page
  2. This alerts the router to say, what should I do?
  3. The first part that picks this up is the Controller who would go to retrieve any data from the database to build the Model
  4. The Controller would then decide which of many Views, which would have a template engine, to render out to the browser to complete the request from the visitor.
     

Here is some pseudo code explaining how an example of the above could be used.


USER REQUEST 
https://yourwebsiteurl.com/products/2058505 
 
ROUTER 
/products/:id = Products.getProduct(id)  
 
CONTROLLER 
Class Products { 
   GetProduct(id) { 
      product = this.ProductModel.getProduct(id) 
      RenderView("/products/", product) 
   }
} 
 
MODEL 
Class ProductModel { 
   GetProduct(id) { 
      dataItem = Kentico Object Query to retrieve the product matching the id requested 
      Return dataItem 
   } 
} 
 
VIEW (using a templating engine)
Within the product view 
<h1>{{product.name}}</h1>
<h2>{{product.subtitle}}</h2>
<p class="prod-section">
   <img alt="{{product.imagealt}}" src="{{product.image}}" /><br />
   {{product.description}}<br />
   {{product.price}}
</p>

.Net MVC and Kentico MVC are the same right?

A man shrugging his shoulders
There is a learning process involved here, having experience with .Net MVC will always help but it’s important to note that there is a dependency on the Kentico EMS platform. Certain expectations of pure MVC functionality need to be customised or configured for it to work with Kentico. This would be expected with any CMS that provides a MVC development model.

With this in mind, it's important to note that Kentico's documentation includes lots of helpful information on clearing up some of the areas that would need to be customised or configured for use with MVC.

Here are some useful links...

That concludes part 1 of the blog post series on transitioning from Kentico web forms to Kentico MVC, stay tuned for part 2 where I will explore training requirements, upgrading Kentico and a few more helpful topics.

You can view the second part of the blog series on transitioning from Kentico web forms to Kentico MVC.