SiteCore6.5.1将完全支持模型-视图-控制器，不仅是作为本机技术，甚至利用布局引擎来增强MVC的优势。继续阅读，-了解更多有关Sitecore支持Microsoft最新构建方法的信息ASP.NET应用程序。我已经为如何将这个好消息带给社区而奋斗了一段时间。这不仅是因为我想说明Sitecore如何不仅完全支持MVC，而且还提供了一种渐进式的支持，从完全原生的MVC到速度上最好的MVC，但也因为我想讨论MVC和Web表单的好处，而不是把这篇文章变成一个愚蠢的框架辩论，讨论哪个更好。我认为这在一篇博文中是不可行的；有太多的事情要做。因此，我将把这篇文章分成3篇：Sitecore MVC-概述：什么是MVC，MVC和Web表单之间的区别？哪个是更好的选择？MVC支持Sitecore供应品的级别概述。即将发表的文章：Sitecore MVC-原生支持：关于Sitecore和MVC原生支持的深入讨论。即将发表的文章：Sitecore MVC-自动支持：关于Sitecore和MVC自动支持的深入讨论。什么是MVC和Web表单？Web表单和MVC是两种不同的构建方法ASP.NETpages：这两者都是很好的选择，也可能是非常糟糕的选择，这取决于应用程序的需求和开发解决方案的人员的背景。如果不考虑Web表单和MVC的页面生命周期，它们实际上非常相似，并且共享大多数ASP.NETAPI/基础设施。任何拥有合理技能的.net开发人员都可以在窗体开发和MVC之间进行切换。微软的ASP.NETvisualstudio团队同时投资于Web表单和MVC，在我看来，这两种方法都不会消失。从本质上讲，我觉得关于哪个是更好的选择的讨论相当愚蠢，因为两个页面生命周期抽象给出的结果是相同的。因此，这实际上是一个关于什么最符合需求的讨论，同时也是对相关开发人员的感觉最好的讨论。对这两个大的未知数还不能下定论。尽管如此，对于那些没有深入参与实际开发的人来说，以下是这两种抽象的一些亮点，以及它们的一般优点和缺点。Web表单Web表单对于快速应用程序开发非常有用。页面生命周期允许您将web控件与stage一起使用，其中组件可能是一个自包含单元，可以在没有任何"知识"或页面本身依赖性的情况下重用。这是一种非常方便的组装应用程序的方法，它与桌面和信息页面（如大多数传统网站）保持一致。然而，Web表单的缺点是对页面生命周期和页面上的代码（服务器端和客户端）的控制较少。代码绑定到控件，控件与代码之间存在相互依赖关系，但也绑定到页状态。我倾向于认为Web表单是一个混乱的页面生命周期。然而，如果绝大多数控件只输出HTML，而控件之间几乎没有互操作性，那么这个缺点就无关紧要了。从本质上讲，我认为Web表单抽象通常可以被认为是信息Web站点和交付页面输出的站点（主要由内容组成的页面，动态性较差）的一个很好的解决方案。MVC MVC代表Model，View和Controller，尽管我从来没有理解过缩写的顺序（以我有限的智力，RCMV更合适，路由是等式的重要部分）。实际上，MVC的请求生命周期是一个路由（通常是解析http请求的东西）指向生成模型（对象）的控件（一些.net代码），该模型（对象）由视图（通常是剃须刀视图）解析。这种方法与Web表单明显不同，因为它需要更多的代码管道来创建页面，并且自动化代码重用更少。另一方面，开发人员对页面上执行的代码和传递到输出的数据有更严格的控制。另外，不要忘了，MVC使单元测试更容易，因为（最重要的是）代码通常在生命周期的控制器部分执行。在我看来，MVC非常适合具有应用程序功能的web站点（例如html5应用程序）。由于这两种方法各有利弊，Sitecore决定支持这两种生命周期抽象。作为开发人员、合作伙伴或企业所有者，您可以自由决定使用一种或另一种方法。或者两者的结合…是的，你明白了！在开发Sitecore支持的站点时，可以同时使用这两种抽象。当然，如果您提供路由，该路由将覆盖任何其他已确定的生命周期。如果不提供路由，则标准Sitecore路由将解析项，并使用该路由解析分配给它的布局定义。如果布局是MVC视图页面（如Razor文件），则Sitecore会自动切换到MVC生命周期。如果布局是asp.netweb表单，所有内容都是这样解析的。作为网站所有者或项目经理，这究竟意味着什么？它允许您运行这样的场景：大部分web站点以web表单的形式交付（因为它是信息web站点，web表单允许更多的控件重用=更快地在中开发），但是站点的应用程序部分以MVC的形式交付（因为它需要更严格的控制）。Sitecore MVC–本机支持与自动支持。Sitecore为MVC提供两个级别的支持：本地支持，允许开发人员提供MVC路由和使用标准Sitecore路由的自动支持。这两种方法都对MVC有渐进式的支持：本机支持这种轻量级MVC支持要求开发人员提供自己的路径。如果请求与路由匹配，则自定义控制器将与传统MVC一样运行。开发人员可以自由使用Sitecore API请求内容数据。此外，如果打开，Sitecore将使用Sitecore上下文数据（例如当前项、设备、语言等）丰富模型。路由和请求不匹配时，将解析该请求。关于本机支持的更多信息，请参阅下一篇文章：Sitecore MVC–Native Support：关于Sitecore和MVC本机支持的深入讨论。Automatic support Automatic support本质上是利用Sitecore现有的专利自动组装页面（包括布局、子布局、渲染）。如果开发人员没有指定路由，Sitecore将接收请求，解析URL并找到适当的项。Sitecore提供的标准控制器将使用当前请求的上下文自动构建模型。如果布局（可视化文件）已分配给项目（内容），并且布局使用Razor，Sitecore将自动切换到MVC并自动向视图文件提供完整模型。可以在Sitecore中指定自定义模型。如果布局定义指向包含占位符的视图，-Sitecore将能够动态地呈现它们，就像布局、子布局和渲染一样。可以通过使用管道扩展所提供的控制器，从而丰富标准模型。这里有一些非常酷的东西：因为Sitecore从一个或多个视图动态地组装一个页面，Sitecore将能够在调用任何视图文件之前运行多个控制器。这对你意味着什么？它允许您将控制器附加到项目或数据模板标准值（文档类型），该值将作为主控制器的一部分运行（例如，为产品数据模板生成产品类的控制器）。或者，-这个呢：你可以把一个控制器附加到一个渲染（指向一个razor视图文件），这样你就可以获得代码背后的全部好处，而不必经历状态和混乱的生命周期。快叫它MVC吧！关于本机支持的更多信息，请参阅下一篇文章：Sitecore MVC–Automatic Support：关于Sitecore和MVC自动支持的深入讨论。我们什么时候可以进入Sitecore 6.5.1？到6月底，如果一切顺利，我们将能够发布SiteCore6.5.1作为技术预览版。对于那些想参加这个项目的人，请收听本频道。