I was fairly confused on the difference between ContentPart and regular MVC model object.
I was going through PluralSight Advanced Orchard course. It went through how to create MovieContentPart and Actor object. I understood that MoviceContentPart has a movie part record that associates the records in the database table. However, Actor object can also do the same thing outside of Orchard approach.
So what is the benefit of using Orchard approach?
A ContentPart and a regular MVC model are very similar concepts. One way to see Orchard is as a composition engine over MVC. Let me explain...
In a traditional MVC application, you have a very simple pipeline: request comes in, is routed to a controller action, which uses the request to build a model and return a result, that is then typically used to hand a view model over to a view. The HTML rendered by the view is then sent to the browser. This is a simplification but it's the general idea.
In the case of Orchard, many different modules will contribute to any single page. There is a controller, but it's deep in Orchard and you should pay no attention to it (in typical cases). The model is actually composed dynamically by all those modules, in a collaborative and decoupled process.
The reason why Orchard needs to do things this way comes from the realization that most content is made of small composable parts. For example, a blog post is made of a title, a body, a slug, an author, a list of tags, and comments (which are themselves content items made of parts: title, author, text, etc.).
Each of those parts comes from some module, and is managed by a "part driver" which is what really is the closest thing you have to a controller, but that acts at the level of the part, which is the one that makes sense for Orchard, much more so than the request. The driver is responsible for creating a "shape" from the part, which is similar to creating a fraction of a view model. The shape will later get rendered by a template (which is a fraction of a view), and the resulting HTML will get composed into the larger page to be sent to the browser.
So to summarize, the advantage of the Orchard model over a plain MVC app is that instead of a simple request -> controller-action -> view pipeline, you get a richer, composable, parallel and very decoupled pipeline to render a page from reusable parts. This is not always appropriate, which is why Orchard still allows for simple controllers to be implemented by modules, but for content-based web sites or sections of web sites, it's extremely powerful and allows for advanced scenarios that would be much more difficult to implement from scratch in a traditional MVC app.