Orchard CMS has a very spirited team, they keep trying to catch up with the latest trends, the first version of Orchard CMS was a very successful start, it was built on a strong foundation, which aims to achieve the goals of MVC architecture, and with the second version (until now, it is in Pre-Alpha stage), they applied a lot of learned lessons from previous version, to up the product to another level of dynamicity and efficiency.
If you try to experiment the current Pre-Alpha of Orchard CMS 2.0, you will notice that the main focus in this version is on two aspects, architecture (Decoupling and Abstraction) and performance (Database Structure), and this is what we will briefly talk about in this post (will be explained deeper in the upcoming posts).
Decoupling and Abstraction
The main purpose of MVC architecture is to boost the decoupling of the system components (isolates the application logic from the user interface layer and supports separation of concerns), ASP.NET is one of the best implementations of this architecture, and ASP.NET Core 1.0 is a huge step in loose-coupling development field, on the other side, Orchard is constantly evolving to keep track of changes and improvements, that reflected in Orchard 2 which is based on ASP.NET Core.
To achieve the decoupling goal, Orchard 2 will not has a single framework file (which has all the API's, as Orchard 1), it is broken down to several files, and that will lead to get the following benefits:
- Each of these modules will have a particular target.
- You don't need to reference all these API's in your custom module, While you need only a few of them.
- Improving site performance.
- It will be very smooth to use any orchard module in a non-Orchard projects, since each framework module can be published as a standalone nuget package.
- Most of framework modules have an abstraction layer, to be easy to surpass their implementation.
While Orchard 2 will maintain the same single content items table structure, it will have a huge update on how data indexed for search in the database layer, since data access layer in the next version of Orchard will be based on YesSql library (.NET document database using any RDBMS).
The following image will describe the new database structure compared to the old one:
As you see, the main difference between them, that in the old structure you can index your data per part, and store the part properties in it's connected record table, but the downside of this structure is that all part records for all the content items which the part is attached to them will be stored in the same table, but this will be changed with the new structure, with the usage of YesSql library, where you are free to add any number of indexing records as you need, either if all the properties are from the same content part, or a combined properties from multiple parts, then you can query your data based on these indexes.
These are my thoughts on the next version of Orchard CMS, and this post will be updated periodically to reflect any new findings, since Orchard 2 is still in Pre-Alpha stage, it will have a lot of changes in the upcoming stages, and we eagerly await to see what's new.