ContentPartRecord和常規MVC模型對象之間有什么區別？

Question

我對ContentPart和常規MVC模型對象之間的區別感到困惑。

我正在上PluralSight高級果園課程。 它經歷了如何創建MovieContentPart和Actor對象。 我知道MoviceContentPart具有電影部分記錄，該記錄與數據庫表中的記錄相關聯。 但是，Actor對象也可以在Orchard方法之外執行相同的操作。

那么使用Orchard方法有什么好處？

Answer 1

ContentPart和常規MVC模型是非常相似的概念。 了解Orchard的一種方法是將其作為基於MVC的合成引擎。 讓我解釋...

在傳統的MVC應用程序中，您有一個非常簡單的管道：請求進入，被路由到控制器動作，該動作使用請求來構建模型並返回結果，然后通常將其用於將視圖模型移交給視圖。 視圖呈現的HTML然后發送到瀏覽器。 這是一個簡化，但這是總的想法。

對於Orchard而言，許多不同的模塊將構成任何單個頁面。 有一個控制器，但是它在果園深處，您不應該關注它（在典型情況下）。 該模型實際上是由所有這些模塊在協作和分離的過程中動態組成的。

Orchard之所以需要這樣做，是因為人們意識到大多數內容都是由可組合的小部件組成的。 例如，博客帖子由標題，正文，子句，作者，標記列表和注釋（它們本身是由部分組成的內容項：標題，作者，文本等）組成。

這些部件中的每個部件都來自某個模塊，並由“部件驅動程序”進行管理，這實際上是您與控制器最接近的東西，但是它在部件級別起作用，這對於果園，比要求更多。 驅動程序負責從零件創建“形狀”，這與創建視圖模型的一部分類似。 該形狀稍后將通過模板（占視圖的一小部分）呈現，並且生成的HTML將被組合到較大的頁面中，以發送到瀏覽器。

綜上所述，與普通的MVC應用程序相比，Orchard模型的優勢在於，您可以獲得一個更豐富，可組合，並行且非常分離的管道來代替可重復使用的頁面，而不是簡單的請求->控制器-動作->視圖管道。部分。 這並不總是恰當的，這就是為什么Orchard仍然允許使用模塊來實現簡單的控制器的原因，但是對於基於內容的網站或網站的某些部分，它功能非常強大，並且可以實現更難實現的高級方案在傳統的MVC應用中從零開始。