对于ContentPart和常规MVC模型对象之间的区别，我感到很困惑。
我正在通过PluralSight高级果园课程。 它经历了如何创建MovieContentPart和Actor对象。 我知道MoviceContentPart具有电影部分记录，该记录与数据库表中的记录相关联。 但是，Actor对象也可以在Orchard方法之外执行相同的操作。
那么使用Orchard方法有什么好处？
答案 0 :(得分：3)
ContentPart和常规MVC模型是非常相似的概念。了解Orchard的一种方法是将其作为基于MVC的合成引擎。让我解释一下...
在传统的MVC应用程序中，您有一个非常简单的管道：请求进入，被路由到控制器操作，该操作使用请求建立模型并返回结果，然后通常将其用于处理视图模型到一个视图。视图呈现的HTML然后发送到浏览器。这是一个简化，但这是总的想法。
对于Orchard而言，许多不同的模块将构成任何单个页面。有一个控制器，但是它在果园深处，您不应该关注它（在典型情况下）。该模型实际上是由所有这些模块以协作和分离的过程动态组成的。
果园之所以需要这样做，是因为人们意识到大多数内容都是由可组合的小零件组成的。例如，博客帖子由标题，正文，子句，作者，标记列表和注释（它们本身是由内容组成的内容项：标题，作者，文本等）组成。
每个零件都来自某个模块，并由“零件驱动程序”进行管理，这实际上是您与控制器最接近的东西，但是它在零件级别起作用，这就是对于Orchard来说意义重大，远比要求有意义。驱动程序负责从零件创建“形状”，这与创建视图模型的一部分类似。稍后，该形状将通过模板（占视图的一小部分）呈现，并且生成的HTML将被组合到较大的页面中，以发送到浏览器。
总而言之，与普通的MVC应用程序相比，Orchard模型的优势在于，代替了简单的请求->控制器-动作->视图管道，您可以获得更丰富，可组合，并行且非常分离的管道来呈现可重用零件的页面。这并不总是恰当的，这就是为什么Orchard仍然允许使用模块来实现简单的控制器的原因，但是对于基于内容的网站或网站的某些部分，它功能非常强大，并且可以实现更难实现的高级方案在传统的MVC应用中从头开始。