我正在阅读以下链接中有关 Sitecore MVC 中视图渲染的文章：
但我对在视图渲染中发布表单感到困惑。 真的可以在视图渲染中发布表单吗？
我认为在这篇文章中，作者在 Posting a form from a view rendering 部分中讨论了控制器渲染。不是吗？
还有一个控制器渲染的链接：
Sitecore MVC controller rendering
在此链接中发布表单的逻辑与第一个链接类似？
谁能解释一下在视图渲染和控制器渲染中发布表单的区别？ 什么时候应该使用视图渲染和控制器渲染？
谢谢
【问题讨论】：
标签： sitecore sitecore-mvc
Martina Welander blog 很好地解释了控制器和视图渲染之间的差异。
查看效果图
什么是视图渲染？
视图渲染由默认采用 RenderingModel 的视图组成。该模型由 Sitecore MVC 管道组装，您可以创建自己的自定义模型。因为管道需要模型上的 Initialize() 方法，所以您可以从 RenderingModel 继承或实现 IRenderingModel。
要发布视图渲染，请在组件的定义项上指定要发布到的控制器和操作。
优点
它们使用简单——尤其是在您不使用自定义模型的情况下。大多数时候，您只想显示上下文或数据源项中的一些内容，而不需要任何业务逻辑——一个简单的“页面”通常由标题和一些文本组成，您可以使用 Sitecore 的 RenderingModel 和@Html.Sitecore() 助手。这里没有太多的单元测试（你当然可以做 web 测试），并且创建一个控制器动作似乎是无关紧要的。 当您从视图渲染发布表单时，它只会发布您指定的操作——之后您可以重定向到另一个页面或触发 Sitecore 渲染管道。控制器渲染并非如此，这使得发布表单更加困难。 缺点
如果您在检索模型时需要执行任何业务逻辑，则需要在单独的层中执行此操作。但是，由于您无法访问控制器，因此您可以执行此逻辑的唯一位置是自定义模型的 Initialize() 方法 - 将业务逻辑放入模型本身并不理想。 它只是不是很 ASP.NET MVC。开发人员习惯于拥有一个控制器和一个动作，而视图渲染不是这样工作的。但是，您必须记住，Sitecore MVC 是 ASP.NET MVC 的一种实现，它需要支持与其对应的 Web 窗体相同的功能。 Sitecore 页面的模块化特性带来了挑战。 用途
就个人而言，如果我所做的只是从上下文项或数据源项中输出一些数据，或者即使我正在输出一个项的子项列表，只要没有业务逻辑，我就会使用视图渲染（例如访问权限）。如果我正在做一些完全需要任何业务逻辑的事情（例如，输出一对滑稽俗气的模糊骰子的特价优惠价格），我会使用控制器渲染。
控制器渲染
什么是控制器渲染？
控制器渲染的组件定义项不是指定视图，而是指定控制器名称和动作名称。当渲染添加到占位符时，执行此操作并返回视图。
优点
它们看起来像 ASP.NET MVC。您可以像往常一样使用依赖注入和通用模式（如存储库模式），并创建自己的操作。 将您的业务逻辑与您的模型分开；您可以创建由业务逻辑层补充的普通 POCO 类。 缺点
虽然它们看起来像 ASP.NET MVC，但它们仍然是渲染，并且不会像标准 ASP.NET MVC 应用程序中的控制器操作那样表现得完全一样。当您尝试在页面上发布多个帖子或尝试 RedirectToAction 时，这一点尤其明显。 它们在主视图已经被渲染之后执行，这会导致一些意外的行为——同样，当你尝试发布一个表单时，这可能会导致一些奇怪的行为，并且使用 TempData（如果你使用它的话）。 在某些情况下，控制器渲染是很多不必要的工作 用途
就个人而言，每当我必须执行任何业务逻辑时，我都会使用控制器渲染——我注入一个域/业务逻辑层并使用它来构建特定于该渲染的视图模型，这通常是渲染参数和内容的混合。如果我要发布表单，我将尽可能使用 AJAX，以避免不得不处理一些表单发布特性。
我没有发现任何证据表明控制器渲染的性能比视图渲染差。
总结
从一开始就喜欢控制器渲染，因为它们感觉更像是 ASP.NET MVC，我现在在我唯一的工作是纯粹输出内容时使用视图渲染 - 由于 Sitecore 是一个 CMS，这种情况经常发生。如果需要一行业务逻辑代码——控制器渲染。我的规则是尽可能遵循通用的 ASP.NET MVC 实践：愚蠢的模型、不属于它的业务逻辑、关注点分离等。如果我可以在我选择的渲染中遵循这些规则，那可能没问题。
还有一篇关于发布控制器渲染的不错的博文，您可以找到here：
【讨论】：