ASP.NET MVC 3 Vs Orchard MVC 3

Topics: General
Apr 28, 2011 at 3:25 AM


  For Asp.Net MVC 3, there have Models, Views, Controllers. Anyway Orchard MVC, there have some extra module such as Driver, Handler, ViewModel..  Do they a bit different with basic MVC 3 in terms of architecture and functionalities? What are the differences between ViewModel and View in Orchard?


Apr 28, 2011 at 7:36 AM

There is no difference between a ViewModel and View in Orchard.

The Driver is actually a Controller. The difference is that it allows for some pre/post behavior to be executed by the Orchard Framework.

The result of executing a method in the Driver gets formed into an ActionResult. The ViewModel is just a value object used to pass data to the view.

The Handler just adds some behavior to the Save/Update process. If you look at you'll find that 

A handler in Orchard is analogous to a filter in ASP.NET MVC. It's a piece of code that is meant to run when specific events happen in the application, but that are not specific to a given content type. For example, you could build an analytics module that listens to the Loaded event in order to log usage statistics. To see what event handlers you can override in your own handlers, examine the source code for ContentHandlerBase

Hope this helps.

Apr 28, 2011 at 7:41 AM

Thanks, sharpoverride. Wonderful to have your briefing in details about Orchard MVC.


Apr 28, 2011 at 8:10 PM

I'll have to correct a couple of things though. A driver is *like* a controller but it is not one. A controller action acts at the request level whereas a driver is finer grained and acts at the content part level. During any given request, only one controller action typically runs, but several drivers do.

A view and a viewmodel are not at all the same thing. A viewmodel is data that gets injected into a view for the purposes of rendering, typically into HTML. In Orchard, typically the view model is a dynamic object called a shape and a view is often called a template.

Apr 28, 2011 at 10:24 PM

I'm curious, why do you create new terminology for things?  That seems somewhat confusing.  if a driver is like a controller, but more fine grained.. why not call it a SubController or something that continues to use the same terminology as MVC?

Ok, I realize that SubController is a new definition, but it at least relates to the original definition.

Apr 28, 2011 at 10:26 PM

Because they are different. Names are always difficult. Subcontroller is a term that already exists and that is not quite the same thing.

Apr 29, 2011 at 10:11 PM

I gotta be honest here, stick my hand up and say that I am kinda getting sent to a bit of a mental mind block when trying to put some things, how they work/interact together in my head. Sure 80% of it is down to my inexperience. Its something I expected and I know that if I keep plugging away I will get it eventually. But some days I really feel like throwing the dog off the balcony. As an example, Drivers and controllers is one that I really feel I am just missing something obvious. 

I were looking at  Orchard.Roles AdminController.cs and userRolesPartDriver.cs yesterday (as an example to try and understand something I wanted to achieve)  and it really just lost me as to when Orchard would use the driver or the controller.

Dunno, I stuck loads of breakpoints into both files and only one ever got hit. I cant remember which one off the top of my head as in the end I ended up going to my local to sit under a chestnut tree to drink loads of beer.


PS: RandomPete. Which Orchard bible did you manage to find and eat to know so much about the system? I could do with a copy now and I'm starving ;)




Apr 29, 2011 at 10:18 PM

I'll try once again. So we have these content items that are really a composition of parts and fields. When you are doing any request in Orchard, there will always be a controller action involved. This action may be generic (in the case of dynamic types for example) or they may be specialized but there will always be one for the request. In some cases, the cases where the request deals with content items, executing this action will lead to calls into the drivers, for each of the parts and fields involved. In summary, drivers are to parts what controller actions are to the request, but they are not the same thing and they are not interchangeable. Does this make things a little clearer or am I confusing you further?

Apr 29, 2011 at 11:42 PM

>> Does this make things a little clearer or am I confusing you further?

Confusing me further in places to be totally honest.


Apr 29, 2011 at 11:44 PM

It must be me then. If someone else could chime in to explain this, or if you have more specific scenarios I could help with...

Apr 30, 2011 at 1:19 AM

Bertrand. some of us are just mere mortals not Orchard gurus. I love Orchard don't get me wrong. I think its great and I love what's here and you have got me, I AM CONVINCED!


But for one thing this forum is crap. someone needs to say it and unfortunately the documentation for Orchard isn't up to much either in my eyes.  



fook it i said it I will live with the consequences tomorrow. night folks


Apr 30, 2011 at 2:12 AM
"X is crap" statements have the problem that they are not actionable. For the documentation, there is something that can be done: it's a wiki so that gives you the fantastic power of improving it. Ain't that fantastic?

Sent from my TI-99/4A

From: nickHutchinson
Sent: Friday, April 29, 2011 6:19 PM
To: Bertrand Le Roy
Subject: Re: ASP.NET MVC 3 Vs Orchard MVC 3 [orchard:255501]

From: nickHutchinson

Bertrand. some of us are just mere mortals not Orchard gurus. I love Orchard don't get me wrong. I think its great and I love what's here and you have got me, I AM CONVINCED!

But for one thing this forum is crap. someone needs to say it and unfortunately the documentation for Orchard isn't up to much either in my eyes.

fook it i said it I will live with the consequences tomorrow. night folks

Apr 30, 2011 at 10:13 AM

Ok, let me try here;

Controllers are an MVC concept. There's obviously already tons of documentation about them completely separate from Orchard. It might be a good idea to work thru some "pure MVC" tutorials to help understand what it is and what it isn't.

But in a nutshell, a controller surfaces entry points to an application. These entry points are "actions" and are implemented as methods on your controller. You can then also define routes which determine how URLs are wired up to those actions (although a default route will exist of /Area/Controller/Action)

Orchard provides a modular way to customise routes (via IRouteProvider) but it's still just MVC routing.

Now what a Controller typically does, is load some data from the database, and then decide how it's going to be viewed.

This data could be loaded from an arbitrary XML file, from any data source, or from an Orchard service or just an IRepository<T>.

At this point you can display the data using plain ol' MVC views, and no drivers will ever be called. Orchard will still participate in Theming decisions (if you tell it).

The only way drivers will get called from a controller is if you use specific methods of IContentManager; e.g. IContentManager.BuildDisplay(item). At this point drivers are used to perform shape composition for a content item. They're also used for BuildEditor(item) and at that point can also provide postback/update handling. Drivers only apply to content items. Actually I've been working on some code that lets you write drivers and build shapes in a similar way for any objects, basically by copying a bunch of the driver code and generalising it. But you still have to make a special call to use it.

So what you'll see if you look at something like Orchard.Core.Contents.ItemController.Display is first a call to BuildDisplay (which runs drivers and builds a shape for the content item) and then "return new ShapeResult" which is an MVC action result that Orchard has provided specially for displaying shapes generated by Orchard. You will also see non-content shapes displayed using this method but in those cases no drivers are used.

Does this help separate out those concepts?

Ok - regarding your other questions and comments;

- I've mostly learned by reading source code. Just looking at examples of how things are using in different modules. I've also dug into Orchard core quite heavily and it is pretty hard to understand (particularly everything relating to Drivers!) but it was worth it and it learned a lot of useful stuff.

- I do agree that the Codeplex forums could be much better from a usability point of view. I just have all new messages emailed to me because it's way easier to follow in my email client than in the web interface. It's just obvious things that are missing like when you look at the forum topics list there's no way to see if there are any new/unread posts. I think the way forward for this would be having a forum on the website instead, preferably built in Orchard, with some of these more standard forum features. But I guess for that we're waiting for a community forum module to happen! (Although there have been some discussions and I believe something might be in the works in that regard)

May 23, 2011 at 9:22 PM

Thanks Randompete, that was an excellent explanation. At least I think it is anyway. I've been working on Orchard modules for a while, looking through the source code, and didn't really have a problem differentiating between drivers and controllers anymore, but that

explanation really clarified for me exactly what they are doing.

I think such an explanation should be in the documentation.  Something else which needs more documentation is how to work with shapes/dynamic objects; I think the majority of my bugs are caused by misunderstanding of this area.

Maybe I'll dig through the shape tracing tool to find out how it looks inside them. Gee, it really does help to type/write things down to focus your mind!

Does anyone know of any other good places in the source code to look for how Orchard is working - specifically part/type/item handling workflow and shape creation/handling?

I am working on a forum module myself based on the source code in the Blog module but a number of regressions in way of bugs in formerly working functionality has halted any forward progress at the moment.

I am thinking I shall have to learn this unit testing malarkey and wire the thing up to the gills with tests, as soon as I figure out how to test dynamic objects.