When deciding to develop a website on Kentico, there is an important decision to be made with regards to how it's going to be developed. Basically, there are two options: it can be developed using the portal engine, or MVC. In this blog post you will find some of the reasons for choosing MVC.
Special thanks go out to Dominika Gallot for co-writing this blog post with me.
First things first
Let's start with a brief introduction of the two development models. Kentico provides a good explanation in the
documentation, but let me sum it up here as well. There are different reasons to choose either of the two models. Portal engine offers a lot of built-in functionality that can be customized to customers' requirements. It gives content editors a lot of power to decide how content is displayed. Compared to that, MVC gives developers more flexibility and control over the code they produce. All in all, you could say working with Kentico is a piece of cake. Sometimes it's easier to make a cake from pre-mixed cake batter and only make limited modifications - that's practically what you do when developing on portal engine. In other situations you might want more control over the ingredients, change them and even start from scratch - that's MVC for you.
Our first project developed on Kentico MVC was
Radboudumc. The consensus at the time was that MVC wasn't mature enough, but the customer let us do a proof of concept to figure out whether it was suitable or even technically feasible. We had a good reason to build on MVC -
the website has a unique content structure which made it interesting for MVC. It had a lot of overlays on top of each other which is difficult to achieve with portal engine. It turned out MVC was the perfect solution.
Compared to Radboudumc, we have developed a website on portal engine for
UMC Utrecht. The two projects are at the core very similar. Both are hospitals, MVPs in both projects were similar and they were built in about the same time by teams of about the same size (give or take a front-end/back-end developer). One of the crucial factors why these two similar projects used different development models was timing. Development of UMC Utrecht stated at a time when Kentico MVC wasn't on the radar as a viable option. The key difference between how the development went in these two projects was made visible due the type of work that the Scrum teams had to pick up. When working with Kentico MVC, we produced a lot of code, while working with portal engine entails a lot of configuration in the database which makes team collaboration more challenging.
Now that you know a bit of the background, let’s move on to the factors for choosing MVC as the development model. Here we go…
It's modern
MVC is a relatively modern technology. A few versions of Kentico back, using this development model wasn't even an option yet. However, today it's getting more and more attention. And there are good reasons for that. Kentico portal engine is built on the ASP.NET framework. Development of ASP.NET applications has been moving away from webforms towards MVC as their successor. It is therefore logical for Kentico to do the same. In addition to being constantly updated and evolving, MVC provides developers with more guidance on how to build stuff and it forces developers to make choices about architecture.
Complex front end
In our clever cake analogy, we described portal engine as batter mix. You can use what you get, but if you want something else than what is in there, you need to find ways to modify what you have so that it does what you want it to do. You can't replace baking powder with baking soda in your batter mix, but you can add more flour and add some extra baking soda. (Sorry if you're not fond of recipes.) With MVC it's easy because you don't have a choice: you need to build it custom. The great thing is that you build it towards how it should look from the very beginning. You don't need to spend time evaluating what's the best way to bend the solution (e.g. which component to use, what the output is, how you can tweak the output so it looks like the feature you want). You just do it from scratch.
When we worked on the Radboudumc project, the whole concept of the front end was designed by
Fabrique. One of the goals was to tune the responses of the system to feel more interactive. We worked with Fabrique very closely to get that right and MVC allowed us to do it.
UMC Utrecht was built on portal engine and needed to be compliant with accessibility requirements. This was very important to the customer, but also quite challenging to execute because we needed to modify Kentico components to meet the requirements. In the end, we reached partial compliancy as it would take too much development time to adjust the output of the exiting Kentico code.
Consistency
Giving power to the developers also means that they get full control of website output. This makes the website consistent. True, content administrators do not get to play in the Design tab, but developers can make sure that content admins get all they need without access to the parts of the back end that would allow them to accidentally remove or reorganize bits that were better left alone…
We have found that MVC is preferred by our bigger clients, with more people involved in maintaining content and working with the website in general. It is because of the consistency. Our customers’ guidelines often define a very clear style and they don’t want to configure existing features to make the system comply.
Just think about it, it's much easier to fill in your content in a form and not worry about where it's going to be displayed and how. It all just appears on the site where it's supposed to be, looking exactly how it was meant to look. This is especially practical when there are tons of content. To illustrate our point, Radboudumc has over 6000 pages of content – imagine manually making sure that even basic things such as fonts and letter sizes are consistent throughout the website. MVC enables developers to create a consistent layout in which our customers can do whatever they want. On the other hand, portal engine might be preferred by smaller clients that want the freedom to easily change the look of the website themselves.
Stability
Stability is a good thing. It makes sure you don't faceplant into all sorts of unpleasant situations. In this case, every line of code can be version controlled and deployed using a continuous delivery platform like
Azure DevOps. We learned we can build very stable websites in MVC using a lot less processing power and hardware, which means we can have a lot more traffic on a much smaller server. Because with MVC you're in control of the code, you'll find that it's more stable to deploy – compared to portal engine, MVC is more light-weight and there’s potential for the code to be cleaner. You can see what’s happening more clearly. It also allows us to test our code - we can do performance test on any part and tune it - but if anything goes wrong, we need to fix it. Since everything between retrieving your data and showing it is custom and visible, it is easier to figure out what’s going wrong.
Upgrades
I mentioned this a few paragraphs back, but I want to make sure the message gets across. Since with MVC you’re in control of the code (and the code doesn’t depend on Kentico as a solution all that much) it’s much easier to upgrade the projects you build using MVC. Imagine a portal engine site as being built into Kentico whereas MVC is build next to it, the two being connected by a bridge. When the Kentico part changes, all you need to rebuild or modify is the bridge and everything will work as before.
When building a website on portal engine, we try not to change the Kentico code too much, one of the main reasons being that custom changes are potentially demanding to upgrade. If the upgrade changes anything in Kentico, you need to investigate if there are functionalities on your website that will be influenced. Thankfully, Kentico has extensive resources that tell you what areas are going to be affected. Still, not having to worry about it is easier.
Happy developers
One of the most important assets of a software company are the people. Therefore, one of the goals of the company is to make sure they are happy. This means providing them with a fulfilling and stimulating environment where they can do what they like and expand their knowledge. When it comes to developers, this means not only scoring 105,993,040 on the pinball machine in the lobby, but also writing code.
When developing on the portal engine, there’s a lot of configuration, which is fine, but certainly not what developers have always dreamed about. Admittedly,
we noticed our developers were cherry-picking the type of development work they wanted to do. MVC expands the amount of work that developers like. Projects consist of three main parts: back-end development, front-end development and Kentico configuration. Developing on portal engine entails about 70-80% of work spent on configuration and 20-30% on custom changes and development whereas developing on MVC means about 10-30% of configuration and 70-90% of custom development. We have noticed that working with MVC increases employee satisfaction.
Hiring is easier
Last but not least, it is easier to hire developers to work on MVC projects. Not only because they actually get to do what they like, but also because universities don’t teach web forms anymore. Young people who need to develop anything on portal engine would need to learn how it works on the job. Also, there are considerably more ASP.NET MVC developers out there than Kentico developers
Final words
We can do a lot with MVC – more customization, apply more complex front end techniques like
Angular or
React, increase code quality and create stable environments that are easy to work with. Our own development and deployment processes have improved since developing with Kentico MVC as more code (than configuration) is being continuously deployed.
But this is just the beginning, don’t forget that there is a whole different approach to development. Moving on to MVC makes it easier to onboard with a headless CMS (such as
Kentico Cloud).
Additional resources: