LibrarySites.Banner

How is Sitecore MVC Different from ASP.NET MVC?

This blog post contains my perspective on differences between standalone development with ASP.NET MVC and development with the Sitecore ASP.NET web Content Management System (CMS) and Customer Experience Platform (XP). Sitecore is just a thin layer on top of ASP.NET. Sitecore MVC is just a thin layer on top of ASP.NET MVC. Anything that you can do with MVC, you can do with Sitecore MVC. While you can take advantage of Sitecore infrastructure such as pipelines and context (especially the context item), those are just layers on top of what is already in ASP.NET. If you want, you can do things exactly how you would in a standalone ASP.NET MVC solution.

Here are some of the possible differences I see between ASP.NET MVC and Sitecore MVC.

Standalone ASP.NET MVC

Sitecore MVC

URLs in HTTP requests correspond to Actions (methods) in Controllers (classes). Action methods can pass a model and invoke the View() method, which determines the .cshtml file to apply.

URLs in HTTP requests can correspond to Actions in Controllers, but by default correspond to items in a Sitecore database, where the items specify which view or controller to apply. The Sitecore controller applies the view.

Code in the controller determines the model to pass to the view.

If the context item specifies an layout view, Sitecore invokes the mvc.getModel pipeline to determine the model to pass to the view. The layout can specify a model, or Sitecore will supply an instance of the Sitecore.Mvc.Presentation.RenderingModel class by default.

Developers use global.asax or similar techniques to register routes.

ASP.NET uses Sitecore’s default route to process items that specify layouts or controllers. Developers can implement <initialize> pipeline processors to register components.

The developer is responsible for establishing any context and accessing any data.

For each HTTP request, Sitecore invokes the httpRequestBegin pipeline to establish a processing context, including the content item containing layout details that specify the presentation components to invoke. Sitecore provides a data store typically accessed through the context item.

ASP.NET assembles the page from the components invoked by the view, such as partial views.

ASP.NET assembles the page from the components invoked by the view. Those components can include the @Html.Sitecore().Placeholder() method, which adds the components specified in the layout details of the context item for a placeholder.

MVC is oriented towards loose coupling with implicit code-based dependency injection.

While Sitecore.Abstractions shows some movement towards loose coupling, Sitecore is more tightly coupled, relying on its static configuration factory and multiple third-party and poor-man’s DI solutions (depending on the module or component). Testing can require the use of additional components such as FakeDB.

ASP.NET provides an implementation.

Sitecore overrides or wraps the controller factory, action invoker, and other aspects of the ASP.NET MVC stack. These attachments can affect how you architect MVC solutions and how you implement other features at those levels.

The ASP.NET implementation provides techniques to implement features.

Sitecore provides pipelines to make development more convenient. For example, rather than using filters, you can use the mvc.actionExecuting, mvc.actionExecuted, mvc.exception, mvc.resultExecuting, and mvc.resultExecuted pipelines.

In addition, Sitecore developers can take advantage of APIs and features far too numerous to list here, such as the rules engine and output caching. There are also numerous free and licensed third-party components and source code published openly on the web.

Conclusion

Sitecore MVC is just a layer of APIs on top of ASP.NET MVC. You can take advantage of that infrastructure or you can work around it if you wish.

If you know of additional differences between ASP.NET MVC and Sitecore MVC, please comment on this blog post.

Resources

  • John, this is a good write-up.  The only thing I would mention is that with base .NET MVC, you can have asynchronous controllers, but you cannot have them when utilizing Sitecore MVC.  I hope this is something that Sitecore is able to support in the near future.

  • Hi Jamie,  Kam has written a nice blog post today about allowing async in Sitecore MVC controllers. Check the post here: kamsar.net/.../  Cheers, Kevin

  • @Navneet: http://launchsitecore.net has an MVC build for 8. You have to register to get it: launchsitecore.net/.../download

  • @John:I have to use Sitecore along with an existing MVC application.I some how not able to render pages in sitecore along with the existing MVC application.However the same works on using it without the MVC Application.Is the routes defined in the normal MVC application such as   routes.MapRoute(                 name: "Default",                 url: "{controller}/{action}/{id}",                 defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }             );  Affesct Sitecore?.How can I marry the Normal MVC Application along with the SItecore?

  • @Suhas: Sitecore uses a "catchall" route, which could be in conflict with yours. What error do you get when you go to a URL that matches that route?  One thing that you may want/need to do is register your routes AFTER Sitecore does its route processing logic. The easiest way is to move your route registration from where it is now (such as global.asax) to an <initialize> pipeline processor after Sitecore's own InitializeRoutes processor.

  • @John:Thanks my issues got resolved.In addition to moving custom routes from Global.asax after InitializeRoutes Processor.I also had to follow your other post at www.sitecore.net/.../prevent-the-sitecore-aspnet-cms-from-applying-mvc-routes.aspx to make sitecore pages work along with MVC Pages.  But I have one questions here: 1. What do you mean by Sitecore uses a "catchall" route, which could be in conflict with yours. and why should we move registration of MVC Routes after  Sitecore does its route processing logic.?  Again thanks a lot you saved lot of my time:)

  • @John:Thanks my issues got resolved.In addition to moving custom routes from Global.asax after InitializeRoutes Processor.I also had to follow your other post at www.sitecore.net/.../prevent-the-sitecore-aspnet-cms-from-applying-mvc-routes.aspx to make sitecore pages work along with MVC Pages.  But I have one questions here: 1. What do you mean by Sitecore uses a "catchall" route, which could be in conflict with yours. and why should we move registration of MVC Routes after  Sitecore does its route processing logic.?  Again thanks a lot you saved lot of my time:)

  • I am having a route problem in sitecore MVC. My controller is controller->blogs->commentcontroller. Having one blogcomment action

  • Hi Sunil. Can you please provide some more info about the route issue and/or possibly post on community.sitecore.net to reach a larger audience? Thanks!

  • What is the benefit of breaking MVC's convention and twisting things? Sitecore is tightly-coupling itself. The days of vendor lock-in are really gone if Sitecore wants to do that. This also negatively impacts unit testing.