In my discussions with other fellow Sitecore developers there is one topic that comes up frequently which is, what to do if you find yourself in a situation where you have two feature modules that in some way need to interact. Because of the constraints of the Helix principles creating a reference between the two is not allowed, so how can we solve this?
This scenario is where the foundation layer comes into play. If we create some kind of functionality in a foundation module then boh feature modules will be allowed to reference this functionality as references from the feature to the foundation layer is allowed within the stable dependencies principle.
So we can create a means of communication between two feature modules by introducing a third middleman module in the foundation layer but how do we do that in practice?
To make things a bit less abstract let us introduce a use case. In our solution we have a feature module which is responsible for outputting meta data to our html header. The module is simply called Metadata and it contains a base metadata template in Sitecore with some fields to enter common metadata content such as title, description and keywords. This template can be inherited to any of our page templates in Sitecore so that the user can fill in metadata about the page. So far so good. However in our solution we also have the concept of products which is placed in a different feature module called Products. The products have names and descriptions and we really want to use these names and descriptions as metadata for the product pages instead of the default metadata. Of course we could simply just inherit the metadata template to the Product page template and tell our editors to use the metadata fields to fill in the product name and description. However then this information would effectively be moved out of the Products module and we would no longer be able to access the information in this module. We could also just simply inherit both the Product base template and the metadata base template to the Product page template and tell our editors to fill in the information in both the product fields and the metadata fields but then our editors would have to do more work and maintain the information in two places and we don’t want that either. So how can we solve this?
In our use case we will solve this by introducing a foundation module which will facilitate the communication between the Product and the Metadata feature modules allowing the Product module to pass information to the Metadata module as required to pass the product information to be used in the page metadata.
There are several ways we can create this setup but I find that Sitecore pipelines works really great for this. We can introduce a Metadata service in the Metadata foundation module that can be called from the Metadata feature module to retrieve the metadata and inside the Metadata service we can run a custom Sitecore pipeline to go through any registered processors allowing them to deliver data that they want presented in the metadata. With this Metadata service we will then be able to create a processor in the Product feature module and register it with the pipeline to allow it to send the relevant data from the product to the metadata.
First let us create the metadata service in the Metadata foundation module.
using Sitecore.Data.Items;
using Sitecore.Pipelines;
using TGC.Foundation.Metadata.Models;
namespace TGC.Foundation.Metadata.Services
{
public class MetadataService
{
public Models.Metadata GetMetadata(Item item)
{
Models.Metadata metadata = new Models.Metadata();
MetadataPipelineArgs args = new MetadataPipelineArgs(metadata, item);
CorePipeline.Run("resolveMetadata", args);
return args.Metadata;
}
}
}
Essentially the service will just create an instance of the data model Metadata and send it through the resolveMetadata pipeline as part of the MetadataPipelineArgs. So let us just get these data models out of the way as well.
namespace TGC.Foundation.Metadata.Models
{
public class Metadata
{
public string Title { get; set; }
public string Description { get; set; }
}
}
using Sitecore.Data.Items;
using Sitecore.Pipelines;
namespace TGC.Foundation.Metadata.Models
{
public class MetadataPipelineArgs : PipelineArgs
{
public MetadataPipelineArgs(Metadata pageMetadata, Item item)
{
Metadata = pageMetadata;
Item = item;
}
public Metadata Metadata { get; private set; }
public Item Item { get; private set; }
}
}
Please note that the models have been greatly simplified to keep the example to the point.
Next we will have to implement some processors to provide the metadata. We will create two processors, one to provide default metadata and one to provide the product specific metadata.
using System;
using TGC.Foundation.Metadata.Models;
namespace TGC.Feature.Metadata.Processors
{
public class DefaultMetadataProcessor : IMetadataProcessor
{
public void Process(MetadataPipelineArgs args)
{
args.Metadata.Title = args.Item["MetadataTitle"];
args.Metadata.Description = args.Item["MetadataDescription"];
}
}
}
namespace TGC.Feature.Products.Processors
{
public class ProductMetadataProcessor : IMetadataProcessor
{
public void Process(MetadataPipelineArgs args)
{
if (!IsProductItem(args.Item))
return;
args.Metadata.Title = args.Item["ProductTitle"];
args.Metadata.Description = args.Item["ProductDescription"];
}
private bool IsProductItem(Item item)
{
// Logic to determine if the item is a product.
// The best way to achive this is to check if the
// item inherits from the product base template
return true;
}
}
}
Please note that both processors are again simplified to keep things focused. Normally it will be a good idea to implement some assertion and error handling etc. Also note that the processors implement the IMetadataProcessor. This is not strictly needed as just about anything can be passed as a processor in a Sitecore pipeline. However by implementing an interface it makes it a little bit easier for your fellow developers to create new processors as needed. So let us create the interface.
namespace TGC.Foundation.Metadata.Models
{
public interface IMetadataProcessor
{
void Process(MetadataPipelineArgs args);
}
}
Lastly we just need to set up the pipeline in the Sitecore configuration and include the two processors that we created. Normally this should be done with three different config files. One in the Foundation.Metadata module to add the pipeline, one in the Feature.Metadata module to insert the default metadata processor and one in the Feature.Products module to insert the product metadata processor but for this example I have included all into one. Also note that the way the code works now it is important that the product processor is run after the default processor or the default processor will overwrite anything set by the product processor.
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<resolveMetadata>
<processor type="TGC.Feature.Metadata.Pipelines.DefaultMetadataProcessor, TGC.Feature.Metadata" />
<processor type="TGC.Feature.Products.Pipelines.ProductMetadataProcessor, TGC.Feature.Products" />
<resolveMetadata>
</pipelines>
</sitecore>
</configuration>
In this example I have shown how you can easily send data between two feature modules and still adhere to the Helix principles by introducing a man-in-the-middle service in the Foundation layer. In this case where there is a potential need to provide data from any number of feature modules to a single recipient feature module the use of a custom Sitecore pipeline works especially well. However this could also be solved by implementing a custom observer pattern or if the functionality is event based it could be achieved by utilizing the events engine in Sitecore. In cases where there is no need for a many-to-one or many-to-many relation ship using dependency injection and a type resolver also works well. Whatever the mechanism may be the important thing to note is that the end goal is to ensure decoupling between feature modules by introducing a layer of abstraction.