This project is read-only.

Modelling data relationships using Content Types

Topics: General
Nov 1, 2011 at 12:56 AM
Edited Nov 1, 2011 at 1:19 AM

I've just started "playing" with Orchard in the hope of using it to create a commercial data and content driven website. I'm finding the overall architecture pretty complex and it's a steep learning curve to grasp the concepts. I hope it's not just me :-)

I'm trying to model some simple enough entities but I'm not sure how to go about setting these up in Orchard. I have an existing database with tables for Companies, CompanyProfiles, CompanyTypes, Reviews, plus al the link tables etc. I know some of these entities can exist  as content types in Orchard, or could if the relevant module are installed, but what about tables such as companies and company types and the 1-many relationships?  

Should I create my own tables and query these thorugh some repository via linq and controllers or is this already taken care of in the core  framework? I guess what I'm looking for is some examples (in the Orchard code or from the community) of how best to model my data. Are content types best place to store my entities and how do I represent the relationships?

Any help on how I should do this and where to start looking in the source code for examples would be great.   

Nov 1, 2011 at 3:00 AM
Edited Nov 1, 2011 at 3:00 AM

I've written a module called Mechanics which allows you to model relationships entirely using content items. The great thing about content types is they're very modular, you can attach any new parts, behaviours and renderings that you like. I've started looking at content items not as specifically content-related, but as an abstract data store with a huge degree of flexibility. Besides, anything in your website is content ... if a Company has its own page then, well, that's content.

My module has its own learning curve, of course, and documentation is a little slim and increasingly out of date; but it sounds like it'd be exactly what you need, if you can get to grips with it - you can take a look at:

Nov 1, 2011 at 12:56 PM
Edited Nov 1, 2011 at 12:57 PM

Pete, your module looks interesting and I'll spend a bit of time figuring it out no doubt.

On the topic of using content types to model data lets say I have the following 2 entities, Company and CompanyType (e.g Tesco and Supermarket resp) and their properties are:




Now when I attempt to create a 'relational model' of this using content types/parts etc I tried something like this:

Company --> Content Type

Name --> Title Content Part

Description -> Body Content Part,

Rating --> Field,

CompanyType --> new Content Part 

CompanyType.Description --> new Content Part Field on Company Type


Would this work?

What would happen down the line in the future if I wanted to migrate the data to a relational database model. Is it possible to import/export relational data from Orchard with specific mappings?

Nov 1, 2011 at 1:22 PM

Well, Orchard is relational data, it's just deconstructed/genericised a certain amount. Think of it like this: instead of having numerous tables with a "description" column, you have a single table that will hold descriptions for all entities, and any type of entity can join to that table if needed (that table is Common_BodyPartRecord in the above case). You could compose views over the Orchard database that mapped entities to the kind of data model you would more normally expect. But actually, Orchard's database model is very efficient from a design point of view - there is little to no redundancy in either data or structure. And that's a good thing even from the performance angle, because 1-to-1 joins are cheap (at least, this is the impression I got from a conversation a while back with a DBA friend).

You might want to look at Orchard's export module and see how the XML data gets exported.

Let me just suggest a different way of modelling the relationship you described above. "CompanyType" can be a content type, rather than a content part; then you can also give it BodyPart to model the description. Now you just need a relationship between Company and CompanyType - in Mechanics you'd do this by creating a third content type called "CompanyToCompanyType" (I call this a Connector). Why do I go to such lengths to model the relationships? Because this has numerous benefits:

- In-built content editing permissions can control permissions on CompanyToCompanyType, giving you very fine-grained control. Basically you can specify which groups of users are allowed to create, edit and delete that relationship, independent of any permissions users have over Company or CompanyType.

- In-built versioning and auditing. The relationship stores a Published time (and which user owns it), independent of the published time of Company or CompanyType. Versioning isn't quite supported yet, I mostly implemented it but there are still a couple of problems, but once this works you will be able to view full historical data about the relationships of an item!

- Extensibility. Additional parts and fields can be added to the connector. Suppose you added BodyPart on CompanyToCompanyType - you could then use it as a notes field. There are much better applications of this, though. For instance you can add my SequencePart to any connector and that allows you to specify the order of the related items (particular useful for building menus and other scenarios where you want to control the order of a list). You can also add TitlePart to a connector; this allows you to override the title of an item when it's displayed (again useful in menus, when you sometimes want to override with a shorter title than the item actually has).

- UI composability. You can model relationships entirely within the content types admin UI, and perform most rendering customisations in files, without having to write any code.

There are certain other benefits and features I have planned that led me to design things this way, but it works and is extremely flexible.

Nov 1, 2011 at 2:20 PM

Thanks for detailed response. I'll give it a go. Sounds like theres more to this than meets the eye and I need to go away and wrap my head around these abstractions. Is Mechanics part of the roadmap for Orchard? is it included in current builds?

Nov 1, 2011 at 2:31 PM

No, it's a 3rd party module; it's part of a set of modules you can get at .

Nov 1, 2011 at 2:34 PM

I should also note that Orchard documentation contains a tutorial on the "default" way to build relationships:

But, if you have a lot of relationships to model, it's a lot of leg-work, I designed Mechanics to take more of a "building blocks" approach to modelling.

Nov 1, 2011 at 10:39 PM
Edited Nov 1, 2011 at 10:39 PM

Hi Pete, 

Hopefully my model is going to be simple enough with few relationships so I think I'll try the default approach for now. I'd like to pursue the Mechanics option once I have a better understanding of the Orchard architecture. Got to walk before I can run though.

The "default" tutorial ( involves adding classes such as services, models, drivers and handlers in a RelationSample namespace. Is it best to do this in a new project in an Orchard.sln src clone? Or is it a case of adding a custom  MVC project? It doesn't say how to set it up and build it in the tutorial so it must assume some prior knowledge, which I'm lacking I'm afraid. Is this covered in another doc?

Nov 1, 2011 at 10:41 PM
Edited Nov 1, 2011 at 10:48 PM

Sorry, the module is downloadable at Orchard.Module.RelationSample.0.5.0.nupkg on the last page of the tutorial

I should have read the whole doc.

May 24, 2013 at 12:26 AM
Edited May 24, 2013 at 12:27 AM
I tried the Mechanics module on 1.6 and it doesn't so much as compile. Looks like it hasn't been touched in a long while either. Is there anything else around that is comparable?
May 26, 2013 at 7:08 AM
Content item picker.
May 27, 2013 at 12:21 AM
Thanks Bertrand, I've become quite familiar with the content item picker. What we are contemplating doing is using the Orchard API layer to access a complex underlying data model, with numerous tables with varying relationships that we can then use the power of Orchard for the display layer. Are we on the right track here, as from what I have seen it's might be simpler to have our own module with a ORM and web API to achieve the same end. Thoughts?
May 28, 2013 at 2:09 AM
I wouldn't use Mechanics or Content Item Picker Field for anything too complex. You'd probably be better off following the relationship doc topic.