Orchard Harvest 2015 - VNext

Nick Mayne is presenting this session on not the next minor version of Orchard, but the real, actual 2.0 that’s going to happen. One of the things we’re trying to access is the coupling of subsystems in the Orchard framework. Another is making it run on ASP.NET 5. To address those, a complete rewrite of the framework is in order.

The first goal is multi-tenancy, and the second is modularity. For multi-tenant routing, Nick created a new middleware. For modularity to work with multi-tenancy, he scoped services to either the tenant or the request. Building modularity, module loading, and associated build processes, based on the moving target that is ASP.NET 5 at the moment was very challenging.

Then new goals were added. CoreCLR is one, which will address cross-platform concerns: it runs on Linux and OSX. Another is the separation of storage and querying. The third is to break the framework down into its subsystems.

For storage,we shouldn’t need to care where contents is stored, just that we can retrieve it. He implemented an EF content store, but that’s an implementation detail that’s hidden under IContentStore, an async interface. You might as well have the content store, or a document database. Or all of the above.

For querying across content stores, there is a new abstraction called IContentStorageManager that provides indexing, querying, retrieval and access to storage. The base way to represent content is through a StorageDocument, which is an Id and a Data blob. The whole querying idea in VNext is map/reduce style indexing and querying.

When building a new Orchard application, you can now build your own host. This means that it is a lot easier to build applications that use bits and pieces of Orchard without having to necessarily buy into the whole approach. Orchard.Web becomes just one implementation of a host.

Nick showed some concrete implementations of hosts, middleware, and content stores.

He also showed how the framework is now broken into NuGet packages that are all optional. A lot less is hard-coded, including common conventions, so everything is a lot more flexible than it already was. When something, like the default host configuration, is expressed explicitly in code, it’s in an implementation of a contract that can easily be replaced.

The project is still small with 6 contributors, but it’s generating a lot of interest, justifiably so.

Challenges include sticking to the tip of DNX, and finding external packages that are CoreCLR-compliant.

UPDATE: the video is online.