Sitecore Blog: Technical Trends

lars nielsen

Technical Trends

Lars Nielsen, Senior VP Technical Marketing

Sitecore MVC – An overview

By Lars Nielsen, June 08, 2012 | Rating:  | Comments (17)

ASP.net MVC

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.


WebForms and MVC is based on same foundation


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.


WebForms Request Lifecycle


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).

MVC Request Lifecycle

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.


Tags: API, Architecture, Infrastructure

Comments

  • Sweeet! Can't wait! :)

    - Lars Erhardsen
    June 08, 2012 at 2:43 AM

  • I love this approach, giving you the best of both worlds. I agree that MVC is great for application builing and web forms is great for web site building.

    The way Sitecore implements web forms allows us to break a web page into reusable and independent components. And with the new MVC implementation we are allowed to continue our component architecture even when MVC application logic is required.

    Good job Sitecore!

    - Brian Pedersen
    June 08, 2012 at 3:45 AM

  • Very interesting for a MVC Architect. :)
    When Sitecore 6.5.1 will be available in Final Release?

    - Alessandro Gialnisio
    June 08, 2012 at 9:42 AM

  • Very exciting developments. Love that we'll have the flexibility to choose.

    - Arthur Wait
    June 08, 2012 at 11:46 AM

  • Some implementation details:

    http://www.sitecore.net/Community/Technical-Blogs/John-West-Sitecore-Blog/Posts/2012/06/Using-Web-Forms-and-MVC-in-a-Single-Solution-with-the-Sitecore-ASPNET-CMS.aspx

    - John West
    June 08, 2012 at 1:03 PM

  • Hey Lars,
    that's great news! Just checked my old blog archive (which is offline because Windows Live Spaces went away) and found a post from Feb. 1st, 2009, titled "When Will Sitecore Adopt ASP.NET MVC?" (http://softwarearchitectblog.com/oldblog/sitecore-mvc.html). I still think that the combination of Sitecore and MVC is a great approach and maybe there will be a chance for me to work more with it in the near future.
    All the best,
    Julius

    - Julius Ganns
    June 09, 2012 at 5:24 AM

  • We do not have an exact date on the Sitecore 6.5.1 release, but it has been released internally within our organisation now. Usually, that's a very good sign as it can be compared to a final candidate for release.

    That said, I would expect this product to be launched before Sitecore Symposium.

    - Lars Nielsen
    June 11, 2012 at 3:12 AM

  • Will this architecture support mapping MVC actions to sublayouts, like Chris Van Steeg's approach: http://www.chrisvandesteeg.nl/2012/02/26/sitecore-mvc/

    - Alan Gallauresi
    June 11, 2012 at 9:58 AM

  • @ Alan Gallauresi

    Yes, we support this as the "controller renderings", where you specify a controller and action into a rendering of type "Controller Rendering".


    - Lars Nielsen
    June 13, 2012 at 5:06 AM

  • Will the page editor be available for an end user to modify Razor layouts?

    - Orion Orion
    June 13, 2012 at 9:00 AM

  • @Orion Orion - Yes. Page editor will work.

    - Lars Nielsen
    June 13, 2012 at 10:48 AM

  • Fantastic, I'm looking forward to trying it out. Thanks Lars!

    - Alan Gallauresi
    June 14, 2012 at 7:34 AM

  • This is really great to hear. And to support both world in such a way is really nice! Good work!

    - Per Lundqvist
    June 15, 2012 at 4:21 AM

  • Hi Lars,

    Great post. When will 6.5.1 (now 6.6 if I believe John West posts) be available to MVP's?

    gr,

    Robbert Hock
    Sitecore MVP 2011

    - Robbert Hock
    June 15, 2012 at 12:22 PM

  • From what I've read in this post, I can't wait to check it out!!!!

    - Hetal Dave
    June 25, 2012 at 1:39 PM

  • When Form is submitted in sitecore MVC application...request will invoke controller action method or Sitecore item?

    - Naveen Naveen
    September 21, 2012 at 4:08 AM

  • so when will we see those two upcoming posts?

    - Neil Timmerman
    November 14, 2012 at 12:19 PM

*
*
*
More Posts

Learn More with Sitecore

Newsletter

Enter your email address to see subscription options or manage your existing account

Boy Scouts of America | Read Case Study >

We have been impressed with Sitecore’s extensibility and ease of use. In addition, the time to market for new websites and web pages has decreased dramatically.

- Eric Brown, CMS Project Manager, Boy Scouts of America