Skip to main content

A DD4T.net Implementation - Domain Models vs View Models

I have been talking so far about strongly typed models for DD4T .net in the sense of mapping a Tridion Schema into an identical View Model, where each Schema field is represented by a property of the model class.

In real life thought, this one to one mapping is never enough -- never shall such mapping be sufficient in a real implementation. There will always be a need for more state, more business logic, more information in a model than what there is by mapping Tridion Schema fields.

The problem becomes more complicated when we try to reuse models in different contexts. In this situation, we might need some additional information for one context where the model is displayed, while in another context, we should have other information available.

There are two ways of solving this issue, which I'm detailing below.

A. Add extra information to the model

In the existing Tridion Schema --> View model, we add all extra information, properties, or business logic needed for each situation where we need to render that View model.

This approach is easy and messy. So even it time to market is short, the end model ends up being polluted with properties that don't necessarily pertain to the model itself. When the model is used in different contexts, some properties will have no values or will be meaningless for a specific context.

B. Use different Domain models and View models

This approach is much cleaner because it maintains the separation of the Tridion Schema model class (now called a Domain model) and the different contexts it needs to be used in (called View models).

The Tridion Schema --> Domain model class does not change. It is created once, in the beginning of the project and has the same fields and structure as the counter part Tridion Schema.

But, for each context where we need to render the Domain model, we create a specific View model class that contains all specific information, state, or business logic needed for the said context.

The advantage is a cleaner and proper separation of the Tridion Schema mapped Domain model and the specific context View model. Reuse of the Domain model is guaranteed in its purest form, maintaining at the same time the Tridion concept of reusing Components (content) with different Component Templates (design).

The Domain model itself is stateless and contextless, providing nothing but the actual data (i.e. the content) for the specific renditions of it. The View models provide the additional information needed and provide context for the content.

As example, let's consider the Device domain model class:

    public class Device : ModelBase
    {
        public string Brief { get; set; }
        public Banner Banner { get; set; }
        public IList<EmbeddedParagraph> Body { get; set; }
        ...
    }


When needed to display the Device in a Full Detail context, we define a View model DeviceFullDetail that takes the Device domain model and decorates it with additional state, or business logic:

    public class DevicesFullDetail
    {
        public Device Device { get; private set; }
        public bool IsNew { get; private set; }

        public DevicesFullDetail(Device device)
        {
            Device = device;

            //Additional logic for Device
            IsNew = device.Metadata.UpdateDate > DateTime.Now.Subtract(TimeSpan.FromDays(1));
        }
    }


Finally, the Razor view uses the DeviceFullDetail View model to render the Device:

@model DevicesFullDetail

@if (Model.IsNew)
{
    @Model.Device.Brief
}

Should we need another context, we can simply create another View model using the same Device domain model class and populate it with the additional attributes needed in there.



Comments

Anonymous said…
What would be a good place to create the DevicesFullDetail instance and set it to be used i in the view, within the DD4T viewmodel creation/processing process?
Mihai Cădariu said…
That would be in a Component controller. Typically I have a ResolveModelAndView method that creates the Domain model object from the IComponentPresentation, then I create each View model object I need for the actual view rendering.
Anonymous said…
Hi Mihiai, I am fairly new to DD4T. I assume your CTs metadata specify different controller/actions, and you prepare the correct viewmodel in the specific controllers' actions? Or do you use a different way?
Mihai Cădariu said…
I build the models as you describe

Popular posts from this blog

Toolkit - Dynamic Content Queries

This post if part of a series about the  File System Toolkit  - a custom content delivery API for SDL Tridion. This post presents the Dynamic Content Query capability. The requirements for the Toolkit API are that it should be able to provide CustomMeta queries, pagination, and sorting -- all on the file system, without the use third party tools (database, search engines, indexers, etc). Therefore I had to implement a simple database engine and indexer -- which is described in more detail in post Writing My Own Database Engine . The querying logic does not make use of cache. This means the query logic is executed every time. When models are requested, the models are however retrieved using the ModelFactory and those are cached. Query Class This is the main class for dynamic content queries. It is the entry point into the execution logic of a query. The class takes as parameter a Criterion (presented below) which triggers the execution of query in all sub-criteria of a Criterio

A DD4T.net Implementation - Custom Binary Publisher

The default way to publish binaries in DD4T is implemented in class DD4T.Templates.Base.Utils.BinaryPublisher and uses method RenderedItem.AddBinary(Component) . This produces binaries that have their TCM URI as suffix in their filename. In my recent project, we had a requirement that binary file names should be clean (without the TCM URI suffix). Therefore, it was time to modify the way DD4T was publishing binaries. The method in charge with publishing binaries is called PublishItem and is defined in class BinaryPublisher . I therefore extended the BinaryPublisher and overrode method PublishItem. public class CustomBinaryPublisher : BinaryPublisher { private Template currentTemplate; private TcmUri structureGroupUri; In its simplest form, method PublishItem just takes the item and passes it to the AddBinary. In order to accomplish the requirement, we must specify a filename while publishing. This is the file name part of the binary path of Component.BinaryConten

Scaling Policies

This post is part of a bigger topic Autoscaling Publishers in AWS . In a previous post we talked about the Auto Scaling Groups , but we didn't go into details on the Scaling Policies. This is the purpose of this blog post. As defined earlier, the Scaling Policies define the rules according to which the group size is increased or decreased. These rules are based on instance metrics (e.g. CPU), CloudWatch custom metrics, or even CloudWatch alarms and their states and values. We defined a Scaling Policy with Steps, called 'increase_group_size', which is triggered first by the CloudWatch Alarm 'Publish_Alarm' defined earlier. Also depending on the size of the monitored CloudWatch custom metric 'Waiting for Publish', the Scaling Policy with Steps can add a difference number of instances to the group. The scaling policy sets the number of instances in group to 1 if there are between 1000 and 2000 items Waiting for Publish in the queue. It also sets the