We started this series on ASP. NET Web CMS by looking at architecture models. You can read that post here. This time we're diving into development models.
Let's talk about how your developers code your front-end experience by examining the two typical approaches in ASP.NET: Web Forms and MVC.
ASP.NET Web Forms is the traditional development model for ASP.NET. Microsoft created Web Forms to help developers more familiar with client server development (e.g. WinForms) quickly migrate to building web pages through a visual RAD interface.
The problem with Web Forms is that it supports a tightly coupled architecture, one where the interface is integrated with the application functionality (code behind). This means the application code and the interface are not easily reusable. With Web Forms you are also locked in to the controls available for the CMS platform, dependent on their quality, upgrade cycle, and HTML output standards or you must spend a lot of time creating your own customizations that then require maintenance.
MVC (model view controller) provides a different architectural pattern for development. MVC is the more modern approach to ASP.NET development, and is the future of ASP.NET with full support from Microsoft.
With MVC there is a clear separation of presentation from application logic, enabling the reuse of both. With MVC, a request is first sent to the Controller which then decides which Model (application logic/validations) and UI (View) to put together to create the appropriate front-end interface.
Another difference between Web Forms and MVC is that you can use Microsoft Web Pages (Razor) in MVC. Razor is a lightweight view engine and Microsoft recommends you use it. With Web Forms, your only template option is via an aspx page.
Obviously you can see the importance of an MVC development model if you need to support cross channel, multi-device websites and web applications. Using MVC you can create multiple interfaces and MVC knows which one to use based on the initiating request. In the case of Web Forms, you have to build all your different interfaces and supporting application code separately. If all your CMS supports is Web Forms then you also have no way to send content to external applications - all your web apps need to be built directly on the CMS.
Also, you want to make sure that if the CMS comes with some kind of page builder application (an app that lets you quickly design your web pages), it supports an MVC model, otherwise any advantages you think you are getting from the page builder are quickly lost.
So now you understand architecture models and development models. Next time we'll look at content itself and how you create and store it.
We hope you are enjoying this post series on ASP.NET Web CMS. Here's the full list of posts in the series:
If you are preparing for a Web CMS selection project or just looking for more information on Web CMS capabilities, you may be interested in our Web CMS RFP template guide.
Subscribe to the Ingeniux blog for the latest in web experience management.