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:
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:
Finally, the Razor view uses the DeviceFullDetail View model to render the Device:
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.
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; }
...
}
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));
}
}
@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