Skip to main content

A Implementation - The Model Factory

Now that we have Strongly Typed Models, Umbrella Models, Model Builders, Umbrella Model Builders and even a Model Generator Tool, we are still missing a little bit of functionality -- the model factory.

The ModelFactory class should simply take the TcmUri of a Component and give us the model for it. The models should be cached, in order to gain performance, and the cache should listen to publish flush notification (but more about caching in a subsequent post). In this post, I'll focus of the ModelFactory class and its methods.

I started by defining an interface IModelFactory that I can then hookup in Ninject as singleton, pointing to the only instance of its implementing class -- ModelFactory.

    public interface IModelFactory
        T GetModel<T>(string componentUri, string viewOrTemplateUri) where T : ModelBase;

        T GetModel<T>(IComponent component) where T : ModelBase;

        T ResolveModel<T>(T model, string viewOrTemplateUri) where T : ModelBase;

        IList<T> ResolveModels<T>(IList<T> models, string viewOrTemplateUri) where T : ModelBase;

The methods of interest are GetModel, which take a generic parameter in the type of model to build and either a TcmUri or a IComponent object. Based on the model type T to build, the correct subclass model of ModelBase is created and returned. I will talk about the ResolveModel methods in a follow-up post.

In the previous builders that we have defined, we need either an IComponent for Web Schemas, or IFieldsSet for Embedded Schemas.

The sample code we need to run would be, for example for the Device model:

    Device device = DeviceBuilder.Instance.Build(component);

Using the ModelFactory class, the same code would be:

    Device device = modelFactory.GetModel<Device>(component);

or if we used TcmUris:

    Device device = modelFactory.GetModel<Device>("tcm:1-2", "tcm:1-3-32");

One thing to note is the TcmUri parameter for the Component Template. This is needed in order to retrieve the Component Presentation that contains the IComponent loosely-typed model. In my implementation, this can be either a TcmUri or a ViewName. This implies there is a mapping from ViewName to Component Template TcmUri, but again, more information about that, in a follow-up post.

The two GetModel methods are as follows:

    public T GetModel<T>(string componentUri, string viewOrTemplateUri) where T : ModelBase
        string templateUri = DD4TResourceProvider.GetViewLabel(viewOrTemplateUri);
        IComponent component = ComponentFactory.GetComponent(componentUri, templateUri);
        T model = BuildModel<T>(component);

        return model;

    public T GetModel<T>(IComponent component) where T : ModelBase
        T model = BuildModel<T>(component);

        return model;

For simplicity, I left out the CachingProvider part (which I shamelessly copied from Rob's Labels in DD4T), as well as all error handling.

The ComponentFactory is simply a "Ninject"-ed property, which will also be presented later:

    public virtual IComponentFactory ComponentFactory { get; set; }

The worker method is of course the BuildModel that takes a generic T being the type of model to create and the IComponent to build from.

The BuildModel method does nothing else than finding the Builder class for the given Model class using reflection, call it's Instance static property, then calling Build method on the builder instance:

    private T BuildModel<T>(IComponent component) where T : ModelBase
        Type modelType = typeof(T);
        string builderTypeName = string.Format("{0}.{1}{2}", BUILDER_NAMESPACE, modelType.Name, BUILDER_SUFFIX);
        Type builderType = Type.GetType(builderTypeName);
        var builderInstance = builderType.GetProperty("Instance", BindingFlags.Public | BindingFlags.Static).GetValue(null);
        MethodInfo buildMethod = builderInstance.GetType().GetMethod("Build", new[] { typeof(IComponent) });
        T result = (T)buildMethod.Invoke(builderInstance, new object[] { component });

        return result;

For reference, the two constants look like this:

    private const string BUILDER_NAMESPACE = "Mitza.Model.Builders";

    private const string BUILDER_SUFFIX = "Builder";

The builder logic expects a naming convention between the builder class for a specific model and the model class name. Namely, the builder class name should consist of the model class name appended with string "Builder".

  • for a model called Device
  • the corresponding builder is expected to be Mitza.Model.Builders.DeviceBuilder


Popular posts from this blog

Running sp_updatestats on AWS RDS database

Part of the maintenance tasks that I perform on a MSSQL Content Manager database is to run stored procedure sp_updatestats . exec sp_updatestats However, that is not supported on an AWS RDS instance. The error message below indicates that only the sa  account can perform this: Msg 15247 , Level 16 , State 1 , Procedure sp_updatestats, Line 15 [Batch Start Line 0 ] User does not have permission to perform this action. Instead there are several posts that suggest using UPDATE STATISTICS instead: I stumbled upon the following post from 2008 (!!!), , which describes a way to wrap the call to sp_updatestats and execute it under a different user: create procedure dbo.sp_updstats with execute as 'dbo' as

Content Delivery Monitoring in AWS with CloudWatch

This post describes a way of monitoring a Tridion 9 combined Deployer by sending the health checks into a custom metric in CloudWatch in AWS. The same approach can also be used for other Content Delivery services. Once the metric is available in CloudWatch, we can create alarms in case the service errors out or becomes unresponsive. The overall architecture is as follows: Content Delivery service sends heartbeat (or exposes HTTP endpoint) for monitoring Monitoring Agent checks heartbeat (or HTTP health check) regularly and stores health state AWS lambda function: runs regularly reads the health state from Monitoring Agent pushes custom metrics into CloudWatch I am running the Deployer ( installation docs ) and Monitoring Agent ( installation docs ) on a t2.medium EC2 instance running CentOS on which I also installed the Systems Manager Agent (SSM Agent) ( installation docs ). In my case I have a combined Deployer that I want to monitor. This consists of an Endpoint and a

Debugging a Tridion 2011 Event System

OK, so you wrote your Tridion Event System. Now it's time to debug it. I know this is a hypothetical situtation -- your code never needs any kind of debugging ;) but indulge me... Recently, Alvin Reyes ( @nivlong ) blogged about being difficult to know how exactly to debug a Tridion Event System. More exactly, the question was " What process do I attach to for debugging even system code? ". Unfortunately, there is no simple or generic answer for it. Different events are fired by different Tridion CM modules. These modules run as different programs (or services) or run inside other programs (e.g. IIS). This means that you will need to monitor (or debug) different processes, based on which events your code handles. So the usual suspects are: dllhost.exe (or dllhost3g.exe ) - running as the MTSUser is the SDL Tridion Content Manager COM+ application and it fires events on generic TOM objects (e.g. events based on Tridion.ContentManager.Extensibility.Events.CrudEven