Sitecore and ASP.net MVC

Question

We are starting off a new project with sitecore as our CMS. I was thinking of using Sitecore as the Content Authoring Tool and use ASP.net MVC as in the Content delivery(CDA) Side along with Sitecore. Would love to hear your ideas and thoughts on this.

Have anybody tried this?

Is sitecore and MVC competing or Complementing technologies?

Any architectural ideas are welcome.

Answer 1

I think the real question you should be asking here is; if you already have Sitecore in place - why would you want the overhead and complicatino of introducing MVC?

Do you have any business requirements outside the basic web site that would necessitate MVC?

Answer 2

I know that Sitecore developers have considered ASP.NET MVC, but I don't know if they've tried it. I can't think of any Sitecore projects that I think would have benefited from ASP.NET MVC. The Sitecore dynamic response engine, pipelines, handlers, wildcards, and other features seem to provide a superset of what you can accomplish with MVC. Similar story with ASP.NET master pages - you could use them with Sitecore, but Sitecore's layout details are superior.

I'm not against ASP.NET MVC with or without Sitecore, but Sitecore seem to provide the features of a controller (really ASP.NET is the controller, and Sitecore just plugs in), your information architecture is the model, and your presentation components are the views.

Answer 3

Sitecore does not fit to MVC it is "old school" CMS with empty frontend shell and ready backend GUI. Sitecore lets you prototype in wysiwyg your frontend layouts. So it has a different approach.

Answer 4

As luck would have it, I'm currently working on two large projects using both technologies respectively. And while I'm big fan of both, I can't see any benefits to merging the two.

As far as Sitecore goes, there is a learning curve, but quite honestly in my case, since I actually learned ASP.NET MVC "first" as opposed to Web Forms, the learning curve has also been slightly attributed to some of my inexperience with Web Forms. That said, there still is most definitely a learning curve involved with Sitecore, but there are plenty of training and reference materials floating around to help with that. Also, the web controls that come with Sitecore make it feel a lot less like building a straight Web Forms app. Plus there's the option for using XSLT as a rendering engine which comes in handy as well.

If this is just one project you're thinking about, I would say just stick with Sitecore as it's presentation system is quite well thought out. And as Mark said above, it would really complicate things quite a bit I and I'm also not sure what there is to gain from it even. Also echoing the sentiments of commodore73, building stuff in Sitecore seriously does feel like you're using MVC already, just using a different framework.

Answer 5

For certain cases, there can be huge benefit to merging the two. MVC isn't that great of a fit for content-driven sites. However, web applications with structured flow and multiple presentations of data benefit hugely from it. Sitecore has somewhat of a limitation when it comes to multiple presentations of data -- you can only define one set of design details on an item. If you don't have requirements for WYSIWYG editing or easy one-click preview, you can use Sitecore as a data repository, and take advantage of some of the Context values that come from its pipeline (such as language).

A couple modifications are necessary to the Sitecore HTTP pipeline to make this work:

1) If using the aspx extension in IIS6 to get ASP.NET to handle MVC requests (e.g. /Controller.aspx/Action), fix Sitecore's FilePath parsing (there is a bug in how Sitecore resolves the FilePath that will result in the path getting chopped).

To fix this, place a new processor at the start of the httpRequestBegin pipeline.

public class MvcFixHttpProcessor : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
    {
        //when using a path such as /Controller.aspx/Blahblahblah, Sitecore's parsing of FilePath can break if Blahblahblah is too long
        RouteData routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
        if (routeData != null)
        {
            args.Url.FilePath = args.Context.Request.Url.LocalPath;
        }
    }
}

2) Tell Sitecore to ignore URLs that are routed to ASP.NET MVC

To accomplish this, place a new processor in the httpRequestBegin pipeline following the ItemResolver.

public class SystemWebRoutingResolver : Sitecore.Pipelines.HttpRequest.HttpRequestProcessor
{
    public override void Process(Sitecore.Pipelines.HttpRequest.HttpRequestArgs args)
    {
        RouteData routeData = RouteTable.Routes.GetRouteData(new HttpContextWrapper(args.Context));
        if (routeData != null)
        {
            args.AbortPipeline();
        }
    }
}

If using languages in your Sitecore URLs, you will need to add some custom logic that combines Sitecore link generation with MVC ActionLink generation, to ensure that language is added to the start of your MVC URL. However with the pipeline modifications above, the addition of language to the URL should have no side effects on MVC routing (because Sitecore rewrites the URL after reading the language).

Once again, this approach is only useful for certain types of applications. In those cases though, Sitecore makes an excellent data layer for your model. Look into creating custom Item wrappers to create strongly-typed domain objects based on Sitecore Items.

Best of luck.

Answer 6

I second Mark's comment about the requirements. Is it worth the risk? You will most likely loose the following features of Sitecore if you decide not to use native rendering functionality:

1. OMS
2. Web Forms for Marketers
3. Conditional Rendering
4. Page Editor
5. Page Designer

maybe even more.