Orchard CMS Shift to Document Storage and Module Development
I am teaching an Orchard CMS Class in a couple weeks on developing Orchard Modules and created some examples using the new "document storage" method of saving Content Part data using Infoset. You cannot store data like this using the production bits of Orchard, but you can start playing with it using the 1.x branch of Orchard CMS on CodePlex. Infoset has already been used by Orchard for persisting field data, and appears to be a good solution for minimizing joins and select n+1 queries. I assume this means we will see even greater performance from Orchard using this new technique if used wisely.
Live Chat Site Settings
As I thought about Infoset and where I might find the most benefit, I immediately thought of Content Parts that are a part of Site Settings. I then took the simplest module I could think of - my Olark Live Chat Orchard Module.
This module stores two pieces of data in its own table, a boolean value as to whether the module is enabled or not and the script provided by Olark that will be injected into your website. We can easily simplify this code and the data retrieval queries used by Orchard using Infoset!
Orchard Code Simplified
For a bit of inspiration I looked at the new code for the Orchard.Email Module in Orchard 1.x and made a few obvious changes to my Olark Live Chat Module.
First, I no longer need to create a table in Orchard to save the enable flag and script. I immediately removed the call to Schema.CreateTable in my Data Migrations File. There is no more need for the custom table.
Second, I completely removed my custom ContentPartRecord Class, since hey, we won't be saving data to a custom table.
Third, I changed the ContentPart Class to use the new Retrieve and Store Methods for peristing and retreiving data using Infoset. A picture is worth a thousand words in this case.
And last, I removed all references to the Orchard.Data namespace and the IRepository<LiveChatSettingsPartRecord>,especially the one in the constructor of the handler responsible for storing data in the data table we used in the past.
This felt good. Really good. I removed a lot of technical baggage that made such a simple module that much easier to maintain. I also hope I made it easier for Orchard to query this data. The best part is that I no longer explicitly tell Orchard how to store the data, but rather tell it what I need to store and have it do it in the most efficient way. I just don't need that level of control with such a simple module.
Where's the Data?
In this case Infoset stores the data in the Orchard_Framework_ContentItemRecord Table in the same row as the other Site Settings.
As I mentioned, I'll be teaching the basics of this to a class after the upcoming holiday. It's just some extra info that I thought would be interesting if we have the time. I can post the code, but your best bet is to peek at the Orchard 1.x Source Code in CodePlex and start looking at the modules. Many of them are using these new techniques and you'll see just how easy it is to use the new method of persisting data. Infoset is much smarter than I mention here, and I will talk about it more in the future.