.png?width=667&height=667&ext=.png)
8 Things Developers Should Know about Kentico MVC
Introduction
For a few years now the great debate around the ASP.NET community has been around how ASP.NET MVC is the only framework of the future. The general point of this debate is that MVC is the winning framework that is finally ready to obsolete the ASP.NET Webforms technology. While I could write an entire blog post on my full opinions of this debate, today I am not going to do that. Instead, today I am going to focus on how Kentico 9.0 has come to fully embrace ASP.NET MVC.
In the latest release of the CMS, MVC is getting very close to being a first class citizen in the choice of Kentico development models, with the other leading candidate being the Kentico Portal Engine model (which has always been based on ASP.NET Webforms). I say first class citizen because the MVC improvements in version 9.0 have been considerable enough for my team and I to start building out client projects in this model, and we are quite happy with the results.
In fact in the last 6 or 7 months of using Kentico 9.0 MVC we have learned a few things that I feel are worth sharing with the Kentico developer community. So without further ado I would like to present 8 Things Developers Should Know about Kentico MVC.
Before we get fully started I'd like to thank Budd Wright and Sterling Heibeck on my team for helping out with some of these topics and sharing their MVC expertise with me.
1. Separation of Kentico Admin Site and Your Site (or not)?
One of the very first choices that developers will have with utilizing Kentico inside of an MVC development style project will be: How do you want to setup the environment? The MVC approach is not like a standard Kentico portal engine based website, where the entire website and entire admin interface is combined into one application (think 1 website with 1 corresponding application pool in IIS).
Kentico MVC has the ability to split these two responsibilities into separate resources on the server or cloud instance (2 different IIS websites). You can also choose to leave your application in the 1 IIS website approach and nest the admin interface with some minimal configuration (http://www.kenticomvc.com and http://www.kenticomvc.com/cms/admin).
While both of the new approaches work, there are of course pros and cons to each. I've actually been lucky enough to be able to bounce the two approaches off of a few of the other Kentico MVPs and developers in the Kentico community. With each of them I discussed a few points (mostly over Slack, man I love that little chat system).
We agreed a pro of the 2 IIS website approach was that having the Kentico admin interface all by itself could be an advantage for updating and/or hotfixing the core Kentico code away from any custom code of the specific project. A second pro could be derived from this situation in terms of raw performance. Since the public website would be on its own set of resources, a large operation in the admin side wouldn't slow down the public site (in theory).
A pro of the 1 IIS website approach is that it is more of an all-in-one "thing" to manage. If there is a production issue on your MVC site you know you have one website to deal with in IIS, if you are deploy a full site update, it is one package to deploy. Simple is good in my experience. A con of this approach is that is does require a few small tweaks to the web.config file(s) that the standard Kentico 9 install ships with. Mainly around some of the inheritance rules. But once you have it up and running it totally works fine.
Both approaches are able to be deployed to either on premise servers or Azure instances. And also in both approaches the content admins generally don't see or feel any difference (normally). To them, they are just using Kentico to manage their content.
At BizStream we have tried both approaches and have not fully decided which is the absolute winner yet, but time will tell.
2. Most of the documentation is still on the Kentico Portal Engine
One of the reasons that I have enjoyed building Kentico sites over the years is the excellent quality of the Kentico documentation. Even since the early days of Kentico, I have always appreciated the fact that most of time I needed an answer on how a certain API worked, or how to configure a certain portion of Kentico functionality, that answer typically can be found inside of the documentation.
However, when you think about it, that means that there is years of information, configurations, and code samples on the existing Kentico platform. Since so much re-write effort went into ASP.NET MVC support for Kentico 9, and the fact that K9 was only released a relatively short time ago, there is no way Kentico could have an update for every single article in the documentation. It would have taken an army of technical writers to do that.
The good news is that if you are a developer who is running in the MVC development mode in Kentico, the API still functions the same way. You just need to realize that if you are developing in the MVC way, the existing documentation and code samples need to be slightly translated sometimes. Even if the docs talk about things like how Kentico module loaders are a way to extend core Kentico functionality, that is still a true statement, but in MVC that its more like 99% true. The "guts" of any code sample still work exactly as is, but the "hook" of where you place that code sample probably has changed.
One great concrete example of where the documentation needs to be interpreted slightly in the above manner is my favorite area in Kentico, Global Event Handlers…
3. Where did my Global Event Handlers go?
When dealing with Global Events in Kentico MVC you will quickly realize that even though the documentation mentions global event handling as an instance of the CMSModuleLoader, you might not necessarily have any of those classes in your MVC project. However, even thought the loader isn't there you can still use the guts of the documentation inside of your Global.asax.cs file in the Application_Start method.
{
CMS.DocumentEngine.DocumentEvents.Insert.After += Insert_After;
CMS.DocumentEngine.DocumentEvents.InsertLink.Before += InsertLink_Before;
}
Again, you can use whatever Global events you need to here. The system will still work exactly as if it were in a CMSModuleLoader class in the standard Kentico portal engine.
4. What to do if your Clear Cache button isn't Working
This means you most likely do not have your installation configured to use Kentico Web Farms. Remember since the Kentico admin interface is most likely not in the same place as your public facing web application, clearing the Kentico cache is only half the battle. Here is where one of the new improvements in Kentico 9.0 comes in to save the day. Web Farms were completely re-written to Kentico 9.0 and now have much more capabilities than before. One of those capabilities is that basically the web farm sync ability just "fixes the glitch" in this scenario.
5. You'll Need More Than One Server in your Kentico Licensing
Of course if you want to handle Web Farms, you will need a license that allows you to do so. This is something that caused a snag in one of our engagements. Even if you have a Kentico license that is server based, and allows for 1, 10, or more Kentico sites on that server, you may still need to reach out to support@kentico.com and ask for a development license that allows for 2 servers to have the Kentico Web Farm capability correctly work. If your license has a SERVERS: 1 line in it (inside of the Licenses app) you may get an error message that says Web Farms aren't allowed, or "License Limitation hit".
The Kentico documentation on licensing for MVC applications is a great place to start when figuring out if you have enough licensing or not. By the way, thanks to Chris Knepp for doing such an awesome job on getting us liceneses quickly whenever we need them!
6. Why isn't Kentco + MVC picking up my Forms Authentication
This is one that threw us a bit at first too. On one of the main MVC projects we were developing recently, there was a requirement for a membership system that allowed users to create profiles, save favorite pieces of content, and return later to find their favorites. Normally in Kentico, this is a no brainer type of task, the system makes this a ridiculously easy task. However in the Kentico MVC world, you have to roll your own security. After adding a login and register form and basic set of secure pages, we still were having some issues. After a few rounds of "swearing this should work", we found that the default web.config file didn't have any authentication nodes in it. After many years of doing Kentico, we just took for granted it would be in the standard web.config.
Not having that node makes doing security in an ASP.NET application pretty tough. Adding the following lines in the root web.config file fixed the problem.
<forms loginUrl="CMSPages/logon.aspx" defaultUrl="Default.aspx" name=".ASPXFORMSAUTH" timeout="60000" slidingExpiration="true" />
authentication>
Don't forget to update the default loginUrl and defaultUrl if you want here as well. Also one other good point here. Technically, in Kentico 9 MVC, membership & security is an "unsupported" feature, but like I said it is working for our project.
7. Image URLs get interesting, especially with Azure or AWS external file storage
So this is a pretty interesting point, and does only apply if you are using Azure or AWS external file storage for your images. When it comes to delivering those images on your public site you might need to play around with using the Kentico API to actually get the attachments from the CMS backend and have them show up in your site. On our first try we were having issues with images showing correctly. However, it actually turned out to be more of a configuration issues with Azure permissions then Kentico. Just be aware that the default Azure permissions required to have the out of the box solution just work are to use public containers via the CMSAzurePublicContainer web.config application setting variable. To be honest that's more of an Azure thing than an MVC thing.
However working with images in Kentico MVC is a bit different than the standard transformation macros and/or macro methods. It is a good fact to be aware of. My recommendation is that you download the Kentico MVC starter site from Github to see how Kentico intends you to work with images. That really is the best place to start to see code that generates an image tag via a helper method like:
{
if (attachment == null)
{
return MvcHtmlString.Empty;
}
var urlHelper = new UrlHelper(htmlHelper.ViewContext.RequestContext);
var image = new TagBuilder("img");
image.MergeAttribute("src", urlHelper.Kentico().Attachment(attachment, constraint.GetValueOrDefault(SizeConstraint.Empty)));
image.AddCssClass(cssClassName);
image.MergeAttribute("alt", title);
image.MergeAttribute("title", title);
return MvcHtmlString.Create(image.ToString(TagRenderMode.SelfClosing));
}
This code sample is from ~/Helpers/Extensions/HtmlHelperExtensions.cs in that sample Github repo.
8. Want Preview Mode? Your going to need the Kentico MVC Integration NuGet package
Let's say you just installed a new Kentico 9 instance and chose the MVC site template to start with. You might be surprised to see this happen when you go to preview the home page in the Pages application.
What this means is that you don't have the final configurations needed for running MVC in Kentico, or you did yout set your site's Presentation URL in the Sites Application for the specific site.
I pretty much saved the best point for last. The new Kentico MVC Integration package that Kentico has released is a major reason that MVC works well with the Kentico admin interface. This NuGet package (Kentico.Web.MVC) gives you four main abilities: Preview Mode, Localization, Search, and Glimpse (something new that I am saving for another blog post). Once this package is installed and your follow the documentation on how to Add Preview mode support for Kentico MVC sites you previews should start working again.
Conclusion
As you can see there are definitely some nuances to using the ASP.NET MVC development model in Kentico. And even though I am a huge fan of the Kentico Portal Engine, I think I have shown that at the end of the day it's not too much effort to get past some of the common issues that developers might have while ramping up on the new capabilities of Kentico 9.
I'm pretty excited about starting to use Kentico MVC more and more, epecially with the release of Kentico 9.0. At the end of the day MVC gives you full control of the HTML markup rendered, cleaner seperation of code layers, advanced routing capabilities, and plays very nice with deployments to Azure. If you would have asked me 1 year ago, do I think the future of Kentico included ASP.NET MVC as a key component, I probably would have said, well it's a bit early to tell. If you ask me that same question today, I'd say you bet it does. Especially if you look at the newest update to the Kentico product roadmap. There are quite a few mentions there of extending more MVC support into more areas of the product. I think this shows Kentico is committed to embracing ASP.NET MVC.
