Attention: We have retired the ASP.NET Community Blogs. Learn more >

How Orchard works

(c) Bertrand Le Roy I just finished writing a long documentation topic on the Orchard project wiki that aims at being a good starting point for developers who want to understand the architecture, structure and general philosophy behind the Orchard CMS.

It is not required reading for anyone who only wants to write Orchard modules and themes but hopefully it will help people who want to evaluate the platform and start writing patches.

Read it here:
http://orchardproject.net/docs/How-Orchard-works.ashx

5 Comments

  • Seems rather complex with a whole new set of terms and languages I'm not familiar with.

    Honestly I had a difficult time reading it - ie an object described as 'cheap' at first sounds good but then I'm left wondering what cheap objects really are.

    I'm also trying to figure out how normal items we discuss like 'modules' - are they MEF? Are they 'Areas' ? How does this differ from when we had Sharepoint zones, parts, sites, pages (note the familiar terms) and then previewing,authoring, validating content and how content is delivered ?

    I'll go read through it again and see if I can wrap my head around the abstractness of the content.

    Thanks

  • This is a very useful article. It's what I missed in order to grasp the fundamental design of Orchard. Thanks for this!

    I have one reservation at this point: why exactly do you have to inherit your interface from IDependency for injectable dependencies? It's not a very big problem, but still seems a limitation. Does this leak to module development as well?

  • Overall, the doc is pretty good ;) It asnwers the "how" but lacks on the "why" part.

    E.g. Dependecny Injection. I'm not sure why the IDepency interface is required. I'm not familiar with Autofac yet the way Orchard requires to specify objects lifetime through IXXXDependency is a bit strange. Clearly, there are cases where an object assumes a certain lifetime to fulfill it's goal. In that case it's a good thing to explicitly specify it's lifetime through an interface. But for other cases where object's purpose doesn't depend so obviously on the lifetime? I.e. it's very much possible that the objects author at inception can't tell for sure the required lifetime. In that case it's better to leave that decision to external component. That adds flexibility (as mentioned above) and makes it less of a breaking change to change objects lifetime later.

  • @Gauthier: thanks for the great feedback. I applied most of it. Feel free to edit the document on the wiki if you want to improve some parts further :)

  • @Gauthier: thanks. Could you please submit a patch following the instructions on this page? http://orchard.codeplex.com/wikipage?title=patches

Comments have been disabled for this content.