Losing my Kentico MVC virginity
Since Kentico released version 9 of its powerful Content Management System, we’ve been chomping at the bit to try out the new offering of its MVC implementation.
As a first run of its new implementation, we’ve been restricted to use it due to current lack of ecommerce and marketing support that a lot of our clients require. As a result, we have continued to use the portal engine and its power for some time.
Finally, we had some free development time to try it out on a smaller site that ticked all the boxes for use.
Clean MVC patterns
The first thing to note is that Kentico have opted to use a clean, standard .Net MVC project. No hijacking of controllers, no forced patterns. You as the developer have complete control over how the project is structured, with the exception of a few small integration points.
Good coding practice dictates that separate layers/separation of concerns is the correct approach. While Web Forms has its plus points, separation of concerns is not one of them. The MVC patterns allows a greater separation of layers, which in turn allows developers to implement Unit tests with ease.
Ease of adoption
Another thing that struck me as I was working through the project is how using this pattern for implementation allows new developers with little or no Kentico knowledge to jump straight into a project without the steep learning curve of Kentico itself. Further to this, it also allows front end developers to work in isolation without being disturbed by back end developers breaking and fixing code as they go.
Modern front-end development
The step away from the portal engine allowed us to use some modern front end development tools such as Gulp and Browser sync to automate the build process, compile SASS into CSS, control modular JS compress and minify at build time with the configurations changing depending configuration/release mode for the visual studio project.
Lack of ‘out of the box’ features
Unlike the portal engine the MVC offering doesn’t come with anywhere near the amount of ‘out of the box’ features. As a result, initial development can be slow as you build up an arsenal of page types, partial view and view models to use — not to mention building the whole solution from scratch. Spend some time doing this right and you can easily spin up a template solution and shareable libraries to save a ton of time in future projects.
Once the main outlay is complete, building a site can be just as fast as using the portal engine.
Speed improvements
As I worked thought the project, I became ever more aware of the speed increases across the board.
As the admin system and front end are separate projects/sites, you can run them as separate sites in IIS. This has a few notable benefits, with the main one being that the admin system will start to run a lot faster as it doesn’t have to be rebuilt after each code change (unless you’re creating modules or something that is admin specific).
As a quick experiment, I recreated the same site in the portal engine (which as a comparison took less than 25% of the time to build the MVC equivalent), trying to make the two as similar as possible.
As this point, both have no caching and a little optimisation. The first set of results speak for themselves:
Result 1 — Portal Engine
Result 1 — MVC
Result 2 — Portal Engine
Result 2 — MVC
Result 3 — Portal Engine
Result 3 — MVC
Overall first impression
All in all, I’m a strong believer that Kentico’s MVC offering is the way forward speaking from the developer perspective. As powerful and accessible to everyone as the Portal engine is, it’s still somewhat of a black box with a sometimes confusing mix of ‘off the shelf’ web parts and custom development, whereas MVC gives the developer complete control over how the solution is structured and coded. In a safe pair of hands I believe better results can be obtained using MVC.
However, there are certain features missing from the MVC offering that were very helpful on a daily basis, two of the more notable ones being:
1. Lack of widget support
Widgets are a staple in our daily development, allowing clients to easily add content and customise their pages. We needed an alternative to how these work and with a little research decide to use CKeditor plugins (the built in WYSIWYG). They take a little more leg work to produce but can easily cover some of the more basic functionality.
2. Lack of control over page URL aliases
The ability to add multiple alias paths to a document is a very handy feature but unfortunately there is no option to do this in the MVC offering. To get around this you will either have to use URL rewriting in IIS or add additional routes at the controller level.
Tips
If you intend on using MVC for your future projects, take the time to set up a good, well-structured solution, preferably n-tier with IOC and Dependency injection. Add a whole bunch of reusable partials and page types such as, News, Offices, People etc. to mimic what the Portal engine already offers. You could use this as a boilerplate template for all future sites which will save you a heap of time.
Take some time to consider your controller patterns. Do you use multiple controllers or one main one? How you decide will affect how you use your routes throughout the system.
Make sure you cache any API calls. The Portal engine does a lot of this for you without having to think about it, but you’ll have to do the leg work in MVC.
In summary, I’d definitely recommend giving the MVC offering a shot if you haven’t already. Although it lacks a few features right now, it’s in your developers’ interests to get up to speed with it at least in parallel to the Portal Engine, if not replacing it entirely.
For some more information on some of the gotchas in Kenticos MVC, have a read of Brian McKeiver’s blog.
