Previously, we built our clients’ websites with the Kentico CMS using an application model known as Web Forms (Microsoft’s ASP.NET Web Forms). Sites were managed and served via a web form – the CMS management was part of the public-facing site and served under the same application. In Kentico, this was known as the Portal Engine. Beginning with Kentico 11, an option to develop with Microsoft’s MVC framework model was introduced. While both the Portal Engine and MVC options are currently supported, we believe the case for the switch to the MVC model is compelling.

Why should you?

Believe me, we looked long and hard at what it would take to transition to MVC (Model/View/Controller). Here’s why we’re making the move:

It’s inevitable.

Microsoft, Kentico and many web developers are transitioning away from the Web Form model in favor of MVC. Kentico will support new development with the Portal Engine until the end of 2020 and will support existing Portal Engine based sites through 2022. While existing Portal Engine sites will continue to function beyond 2022, support from Kentico, Microsoft and the development community is waning.

It’s better.

Ease of development: Moving away from a Web Forms development model has allowed our creative, Kentico developer and UI/UX teams an opportunity to design and architect our sites without the barriers, perceived or real, that Portal Engine-based sites imposed. It gives us the confidence that the hard work put in by our front-end developers and UX team would not be impacted by the kind of markup issues that we’ve typically seen from Web Forms. In developing with the Portal Engine, there were situations where additional HTML and CSS elements were injected into the markup based on how we needed to render the content. We developed methods to mitigate and work around some of these issues, but in isolating the display of content from the underlying management system, we have been able to keep the code clean rather than work to override or find ways to adapt.

Speed: MVC is simply faster than Portal Engine. The time to build the application in your .Net IDE (e.g. Visual Studio) is shorter; the time it takes that first request after an IIS reset is faster; and the general performance of the live site is faster. Faster builds, faster compilation, faster requests. What’s not to like?

Improved CMS: Kentico’s MVC approach supports developing websites using ASP.NET MVC 5. The development model is based on a separate MVC application that handles the presentation of the live site, while the Kentico application serves as the content management system (CMS). Both Kentico and the MVC application access data from the same database and use the Kentico API to manage data between both.

Synchronization of cached content and static files is handled by web application servers or web farms. This approach allows you to separate the live site (MVC application) and the CMS/administration of the site (Kentico).

This means that we use the admin interface in Kentico to store data and manage content. We then leverage our MVC controllers and views to manage the display and functional aspects of the site.

Kentico’s Pages application is the repository for content-only  pages. The content itself is created and modeled by content editors based on a structured content model defined by developers who then, in turn, manage its presentation on the live site via the MVC application.

Portal Engine vs. MVC:

Overcoming our second thoughts.

When we started on our first Kentico MVC project, we had mixed emotions: excitement about getting to embrace the future and work on something new contrasted with concern about losing (or having to re-create) the library of code and institutional knowledge that we had built over the years. “Hurray, new toys!” vs. “Uh-oh, what have we gotten ourselves into?!!”

As is always the case in our industry, change is constant, and that can be unsettling. However, change also provides opportunity. Much of the lift we get from Portal Engine and our own repository of code needs to be rethought, refactored and/or recreated. Although it’s requiring significant resources, starting from a clean slate provides us the opportunity to leverage our experiences and write functional components more efficiently without the burden required to support legacy systems.

One of the biggest concerns we had when we began this process was losing the built-in functionality provided by Kentico’s Portal Engine: layouts, web-parts, etc. Although there is quite a bit lost in the transition, we are confident in growing with Kentico as we embrace the new model together. Kentico is continuing to add out-of-the-box functionality in the new model.

As an example, with the recent release of the K12 Service Pack, Kentico has provided support for the following: page templates, A/B testing, alternative URLs for MVC pages, media library selectors and page selectors.

Let’s go with Kentico.

We are confident that Kentico, the Kentico Market Place, and the developer community will continue to extend and embrace the MVC methodology. The opportunities with Kentico MVC will continue to evolve and become fruitful and rewarding.

The sooner you join us in transitioning to MVC with Kentico, the better. If you need someone to take you there, we’re ready to lead the way.