Sitecore的和ASP.net MVC(Sitecore and ASP.net MVC)

我们开始了与Sitecore的为我们的CMS一个新的项目。我想用Sitecore的作为内容创作工具，并使用ASP.net MVC作为内容交付（CDA）侧Sitecore的沿。很想听听你对这个意见和想法。

曾经有人尝试过这个？

Sitecore的是和MVC竞争或补充的技术？

任何建筑理念是值得欢迎的。

Answer 1:

对于某些情况下，可以有巨大的好处，以合并这两个。 MVC是不是一个伟大的适合内容驱动的网站。然而，随着结构化流和数据的多个演示Web应用程序从中获益巨大。 Sitecore的具有一定程度的限制的，当涉及到数据的多个演示 - 您只能在项目定义一组的设计细节。如果你没有为所见即所得的编辑或轻松一点击预览的需求，你可以使用Sitecore的作为数据存储库，并利用一些来自其管道（如语言）的语境值的优势。

一对夫妇的修改是必要的Sitecore的HTTP管道，使这项工作：

1）如果使用IIS6的ASPX扩展获得ASP.NET处理MVC请求（例如/Controller.aspx/Action），修复Sitecore的文件路径解析（存在Sitecore的如何解决文件路径的错误，这将导致在路径获得切碎的）。

为了解决这个问题，将新的处理器在httpRequestBegin管道的开始。

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;
        }
    }
}

（编辑2011年9月13日：我还没有使用上述固定在一定的时间。）

2）告诉Sitecore的忽略被路由到ASP.NET MVC的URL

要做到这一点，将在httpRequestBegin管道下面的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();
        }
    }
}

如果使用您的Sitecore的网址的语言，你将需要添加结合Sitecore的链接生成与MVC的ActionLink产生一些自定义的逻辑，以确保语言添加到你的MVC网址的开始。然而，随着上述管道的修改，增加语言的网址应该对MVC路由无副作用（因为Sitecore的阅读语言重写后的URL）。

再次，这种方法只适用于某些类型的应用程序非常有用。不过在这种情况下，Sitecore的让你的模型中的出色的数据层。考虑创建自定义项目包装，以创建一个基于Sitecore的项目强类型的域对象。

（编辑2011年9月13日：自定义项发生器这个伟大工程。 http://blog.velir.com/index.php/2010/10/19/custom-item-generator/ ）

祝您好运。

Answer 2:

我想你应该在这里提出的真正的问题是; 如果你现在已经有Sitecore的 - 你为什么要引入MVC的开销和complicatino？

你有基本的网站，将需要MVC以外的任何业务需求？

Answer 3:

我第二个马克的有关要求评论。是否值得冒这个险？如果你决定不使用原生渲染功能，你很可能会失去Sitecore的以下功能：

OMS
Web窗体的营销
有条件的渲染
网页编辑器
页面设计

甚至更多。

Answer 4:

我知道，Sitecore的开发人员认为ASP.NET MVC，但我不知道他们是否已经试过了。我不认为，我认为会从ASP.NET MVC中受益任何Sitecore的项目。该Sitecore的动态响应发动机，管道，处理程序，通配符，和其他功能似乎提供的，你可以用MVC完成的一个超集。类似的故事与ASP.NET母版页 - 你可以用Sitecore的使用它们，但Sitecore的布局细节出众。

我不反对ASP.NET MVC带或不带Sitecore的，但Sitecore的似乎提供一个控制器的功能（真正ASP.NET是控制器和Sitecore的只是插头中），您的信息体系结构是模型，演示文稿组件的意见。

Answer 5:

他们肯定可以混合使用，而且我确信确实看到了它的价值:)没有原生功能被损耗的与我在我的博客文章在这里描述的方法： http://www.chrisvandesteeg.nl/2012/02/26/sitecore -mvc /

Answer 6:

幸运的是，我目前的两个大型项目分别使用这两种技术。虽然我的两个大风扇，我不能看到合并两家带来任何好处。

至于Sitecore的推移，有一个学习曲线，但坦白地说我的情况，因为我居然学会了ASP.NET MVC“第一”，而不是Web窗体，学习曲线也略有归因于一些经验不足我用的Web窗体。尽管如此，仍然有最肯定参与Sitecore的学习曲线，但也有很多的培训和参考材料左右浮动，以帮助这一点。此外，附带的Sitecore的Web控件使其感觉少了很多像建设直Web窗体应用程序。另外还有使用XSLT作为派上用场，以及渲染引擎的选项。

如果这是你想只是一个项目，我会说只是坚持与Sitecore的，因为它的演示系统是相当深思熟虑。正如马克上面所说的，这将真正复杂的东西相当多的我，我也不能确定什么就有什么，甚至从中获益。也呼应commodore73的情绪，构建东西在Sitecore的严重不觉得你使用MVC已经，只是用不同的框架。