Sitecore 6.5.1 will fully support Model View Controller, - not only as native technology, but even utilizing the layout engine to enhance benefits of MVC. Read on, - and learn more about Sitecore's support Microsoft's latest approach to build ASP.NET applications.
I have been struggling for a while with how to bring this great news to the community. Not only because I want to illustrate how Sitecore not only fully supports MVC, but provides a progressive support ranging from fully native MVC to something that best can be described as MVC on speed, but also because I want to discuss the benefits of both MVC and Web Forms without turning this post into a silly framework debate on which is better.
I decided that this is not feasible in a single blog post; there’s simply too much to go about. Therefore, I will split this into 3 different posts:
- Sitecore MVC – An overview: What are MVC, and the differences between MVC and Web Forms? Which is the better option? Overviews of the levels of MVC support Sitecore supplies.
- Upcoming post: Sitecore MVC – Native support: An in-depth discussion on Sitecore and MVC Native Support.
- Upcoming post: Sitecore MVC – Automatic Support: An in-depth discussion on Sitecore and MVC Automatic Support.
What are MVC and Web Forms?
Web Forms and MVC are two different approaches for building ASP.NET pages: Both can be excellent choices, and both can be very bad choices, depending the requirements of the application and the background of those developing the solution.
If you look apart from the page lifecycle of Web Forms and MVC, they are actually very similar and share the majority of ASP.NET API’s/infrastructure. Any .net developer with a reasonable skillset will be able to swap between forms development and MVC.
Microsoft’s ASP.NET and Visual Studio teams invest in both Web Forms and MVC, and in my opinion neither approach is going to go away.
In essence, I feel the discussion on which is the generally better option quite silly, because both the page lifecycle abstractions gives the same outcome. Therefore, it’s really a discussion on what maps best to the requirements, but also what feels best for the developer involved. No definite conclusion can be given on these two big unknowns.
Yet even so, for those not being deeply involved in actual development, here are a few highlights of the two abstractions, and their general strengths and weaknesses.
Web Forms
Web forms are great for rapid application development. The page lifecycle allows you to use web controls with stages, where the component may be a self-containing unit that can be reused without any “knowledge” or dependency of the page itself. It is a very convenient way of assembling applications that is consistent with desktop and informative pages (such as most traditional web sites). However, the drawbacks with Web Forms are less control of the page lifecycle and the code on the page (both server and client-side). Code is bound to controls, and controls to code in a mutual dependency, but also bound to a page state. I tend to think of Web Forms as a messy page lifecycle. However, if the vast majority of the controls output nothing but HTML, with little interoperability between the controls, this disadvantage matters little.
In essence, I believe that the Web Forms abstraction usually can be considered a fine solution for information web sites and sites that deliver page outputs (pages that primarily consist of content, - is less dynamic).
MVC
MVC stands for Model, View and Controller, though I have never understood the order of the abbreviation (by my limited intellect, RCMV would have been more appropriate, with a Route being a significant part of the equation).
Essentially, the request lifecycle of MVC is a Route (usually something that parses the http request) points to a Control (some .net code) which generates a Model (object), which is parsed by a View (usually a Razor view).
This approach is distinctly different from Web Forms, because it requires more code plumbing to create the page, and with less automated code reuse. On the other hand, the developer has more rigid control of the code executed on the page, and the data delivered to the output. Also, not to forget, MVC makes unit testing easier as (most of/all) the code usually is executed in the controller part of the lifecycle.
In my opinion, MVC is well suited for web sites with application functionality (e.g. HTML 5 applications).
Sitecore, Web Forms and MVC
Because both approaches have benefits and disadvantages, Sitecore has decided to support both lifecycle abstractions. You, as the developer, partner or business owner may freely decide to use one or another approach.
Or a combination hereof…
Yes you got it! It is possible to use both abstractions when developing your Sitecore supported site. If you provide a route, of course, the route will override any other determined lifecycle. If you do not provide a route, a standard Sitecore route will parse the item, and with that the layout definition assigned to it. If the layout is an MVC view page such as a Razor file, Sitecore automatically switches into the MVC lifecycle. If the layout is asp.net web forms, everything is parsed as such.
What exactly does this mean for you, as the web site owner or the manager of the project? It allows you to run scenarios where the bulk of your web site is delivered as Web Forms (because it is information web site, and Web Forms allows more control reuse = quicker to develop in), but the application part of your site is delivered as MVC (because it requires more rigid control).
Sitecore MVC – Native support vs. automatic support.
Sitecore provides two levels of support for MVC: Native support, allowing the developer to provide an MVC route and Automatic Support using a standard Sitecore route. Both of these approaches have progressive support for MVC:
Native support
This lightweight MVC support requires the developer to provide their own route. If the Request matches the route, the custom controller is run as with traditional MVC. Developer may freely use the Sitecore API to request content data. In addition, if switched on, Sitecore will enrich the model with Sitecore Context Data (e.g. the current item, device, language, etc.).
If the request does not match a route, Sitecore will parse the URL and find the appropriate item (and layout).
More on Native Support in the upcoming post: Sitecore MVC – Native support: An in-depth discussion on Sitecore and MVC Native Support.
Automatic support
Automatic support is essentially utilizing Sitecore’s existing patent which automatically assembles pages (with layouts, sub layouts, renderings).
If developer has not specified a route, Sitecore will pick up the request, parse the URL and find the appropriate item. A Sitecore provided standard controller will automatically build a model using the context of the current request. If a layout (visual file) has been assigned to the item (content), and the layout is using Razor, Sitecore will automatically switch to MVC and automatically provide the full model to the view file. Custom models may be specified in Sitecore.
If your layout definition points to a view containing placeholders, - Sitecore will be able to render them dynamically, just as with layout, sub layouts and renderings.
It is possible to extend the provided controller by using pipelines, allowing you to enrich the standard model.
Here’s something very cool:
Because Sitecore dynamically assembles a page from one or multiple views, Sitecore will be able to run multiple controllers before any view file is called.
What does this mean to you? It will allow you to attach a controller to an item or a data template standard value (document type), which will be run as part of the main controller (for example a controller that generates a product class for a product data template).
Or, - what about this: You can attach a controller to a rendering (which points to a razor view file), consequently allowing you to get the full benefits of code-behind, without the ordeal of states and messy lifecycle.
Call it MVC on speed!
More on Native Support in the upcoming post: Sitecore MVC – Automatic Support: An in-depth discussion on Sitecore and MVC Automatic Support.
When can we get our hands into Sitecore 6.5.1?
By end of June, if everything pans out, we will be able to release Sitecore 6.5.1 as a technical preview. For those of you who like to get enrolled in the program, stay tuned on this channel.