In this first part of a two-part blog series about the freedom that transitioning to MVC brings, we look at how Michael Kinkaid of Ecentricarts has been enjoying beta testing Kentico 12. We also delve into the boost in productivity from improved collaboration between marketers and developers that comes from that shift to MVC.
What would you say were your biggest pain points in previous versions of Kentico when doing MVC development?
There’s been several flavours of MVC in previous Kentico versions. The first approach way back in version 7, where you could register what was called an MVC template, wasn’t the same as building an actual full MVC site - just throwing in controllers and views.
With version 9 you could create a fully separate MVC site but the big pain points with that and future versions was the disparity in supported features between portal and MVC. Kentico closed the gap with each new version release but it was still painful - or limiting - to use.
Some agencies bit the bullet and jumped in with these restricted versions however they had to develop their own workarounds and best practices. We reluctantly kept on Portal until version 11.
As one of the early adopters of the Kentico 12 Beta release, can you share with our readers some of your experience with it?
I got some really early demos of the MVC Page Builder concept back in 2017 during the MVP summit in Brno - so I knew what was on the roadmap and was really eager to get my hands on the first beta.
The coolest thing is seeing new features getting added to each new beta release. We had the new MVC installer, Page Builder and widgets, MVC Smart Forms and personalization. Being able to provide feedback is invaluable. That’s why beta versions are being released in the first place - and Kentico do listen. As an example, the inline editor feature for widgets is great but like a lot of other developers I felt the platform also needed to provide a standard or common approach to editing properties though a properties dialog editor. This is because some widget properties such as a URL or embed code – just don’t lend themself to a visual inline editing approach. This is a point we stressed to Kentico. Kentico listened, evaluated and then built out the feature adding it to the next beta release.
As a developer, what are you really looking forward to in Kentico 12 regarding MVC development?
I think the most exciting thing is that the gaps and pain points mentioned early of the previous versions are more or less resolved. We have MVC widgets, sections, editable areas, personalization, first class MVC forms. Also with Kentico you aren’t using some weird vendors approach to MVC. For example - they haven’t hijacked things like routing with their own proprietary approach. They aren’t forcing you to use conventions you might not agree with. This is straight up MVC 5 so developers should feel comfortable with building out solutions using it.
How do you feel Kentico 12 will improve and help the work of your developers and marketers, especially concerning collaboration?
Ultimately the collaboration between developers and marketers should be equivalent to solid Portal implementations. Developers should build out a library of components – or widgets to use the Kentico term - that meet the needs of their marketers. Marketers are then empowered to build out new pages bringing these widgets together in whatever way they need. Ultimately they should only need to go back to development when something entirely new needs built out - but that is to be expected. The new Page Builder features will alleviate concerns that marketers had with previous MVC versions of Kentico - namely that you couldn’t build pages visually.
Looking specifically at how it will help the work of developers, if you’re a Kentico Portal developer then one nice perk of moving to MVC with Kentico is that you’ll notice some productivity wins when it comes to building, debugging and deploying your code. Unlike in the Portal version, with Kentico MVC the site and admin area are separate applications. This means you don’t have to build the admin project each and every time you make a change to your site - that will cut down on time spent twiddling your thumbs looking at the little blue loading box. You will be able to build and view changes quicker. You also get more flexibility around deployments given the admin project and site project can be managed separately.
In the next part of this blog series, Michael shares his insights into the considerations developers and digital agencies should bear in mind before transitioning to MVC, the kinds of resources that are there to support them, as well as the dangers of making that leap to MVC too late.
We would love to hear about your experiences of MVC development, as well as your opinions on some of the topics raised in this article. Be sure to share them with us in the comments section below. And also, don't forget to check out our MVC Transition Guide!