ContentPartRecord 和常规 MVC 模型对象有什么区别?



我对ContentPart和常规MVC模型对象之间的区别感到相当困惑。

我正在参加PluralSight Advanced Orchard课程。 它介绍了如何创建MovieContentPart和Actor对象。 我知道 MoviceContentPart 有一个电影部分记录,用于关联数据库表中的记录。 但是,Actor 对象也可以在 Orchard 方法之外执行相同的操作。

那么使用果园方法有什么好处呢?

ContentPart和常规MVC模型是非常相似的概念。将Orchard视为MVC上的合成引擎的一种方式。让我解释一下...

在传统的 MVC 应用程序中,您有一个非常简单的管道:请求进入,路由到控制器操作,该操作使用请求构建模型并返回结果,然后通常用于将视图模型移交给视图。然后,视图呈现的 HTML 将发送到浏览器。这是一个简化,但这是一般的想法。

在Orchard的情况下,许多不同的模块将贡献任何单个页面。有一个控制器,但它在果园深处,你不应该注意它(在典型情况下(。该模型实际上是由所有这些模块动态组成的,在一个协作和解耦的过程中。

Orchard 需要以这种方式做事的原因是认识到大多数内容都是由小的可组合部分组成的。例如,博客文章由标题、正文、蛞蝓、作者、标签列表和评论(它们本身是由标题、作者、文本等部分组成的内容项(组成。

这些部件中的每一个都来自某个模块,并由"部件驱动程序"管理,这实际上是您最接近控制器的东西,但它作用于部件级别,这是对 Orchard 有意义的部件,比请求更有意义。驱动程序负责从零件创建"形状",这类似于创建视图模型的一部分。形状稍后将由模板(视图的一小部分(呈现,生成的 HTML 将组合到要发送到浏览器的较大页面中。

总而言之,Orchard 模型相对于普通 MVC 应用程序的优势在于,您获得的不是简单的请求 -> 控制器操作 ->视图管道,而是获得更丰富、可组合、并行且非常解耦的管道,以从可重用部分呈现页面。这并不总是合适的,这就是为什么 Orchard 仍然允许通过模块实现简单的控制器,但对于基于内容的网站或网站的各个部分,它非常强大,并且允许在传统的 MVC 应用程序中从头开始实现的高级方案。

最新更新