Question

I want to add metadata to my object graph for non-domain type data that will be associated to my objects but is not essential to the problem set of that domain. For example, I need to store sort settings for my objects so that the order in which they appear in the UI is configurable by the user. The sort indices should be serializable so that the objects remember their positions. That’s just one among a few other metadata items I need to persist for my objects. My first thought is to solve this by having a MetadataItem and a MetadataItemCollection where the base Entity class will have a “Meta” property of type MetadataItemCollection. E.g.:

public class MetadataItem
{
    public string Name;
    public object Data;
}

public class MetadataItemCollection
{
    /* All normal collection operations here. */

    // Implementation-specific interesting ones ...
    public object Get(string name);
    public MetadataItem GetItem(string name);

    // Strongly-type getters ...
    public bool GetAsBool(string name);
    public string GetAsString(string name);

    // ... or could be typed via generics ...
    public T Get<T>(string name);
}

public class Entity
{
    public MetadataItemCollection Meta { get; }
}

A few concerns I can think of are:

• Serialization – the database has a single table of EntityID | Name | Value where Value is a string and all types are serialized to a string?
• Future Proofing – what if a metadata item’s type (unlikely) or name needs to be changed?
• Refactorability – should the keys come from a static list via enum or a class with static string properties, or should free-form strings be allowed:

var i = entity.Meta["SortIndex"];

vs.

public enum Metadatas { SortIndex };
var i = entity.Meta[Metadatas.SortIndex];

vs.

public static class Metadatas
{
    public static string SortIndex = "SortIndex";
}
var i = entity.Meta[Metadatas.SortIndex];

• Anything else?

Thoughts, ideas, gotchas???

Thanks for your time.

Solution:

Following @Mark’s lead, and after watching the Udi video Mark linked to, I created two new interfaces: IUiPresentation and IUiPresentationDataPersistor. It’s important to note that none of the objects in my Entity object model have any awareness of these interfaces; the interfaces are in a separate assembly and never referenced by my Entity object model. The magic is then done via IoC in the presentation models. It would be something like the following:

public class PhoneViewModel
{
    IUiPresentationDataPersistor<Phone> _uiData
    IUiPresentation<Phone> _presenter;

    // Let IoC resolve the dependency via ctor injection.
    public PhoneViewModel(Phone phone, IUiPresentationDataPersistor<Phone> uiData)
    {
        _uiData = uiData;
        _presenter = uiData.Get(phone);  // Does a simple lookup on the phone's ID.
    }

    public int SortIndex
    {
        get { return _presenter.SortIndex; }
        set { _presenter.SortIndex = value; }
    }

    public void Save()
    {
        _uiData.Save();
    }
}

It’s a little more complicated in that the ViewModel implements INotifyPropertyChanged to get all the goodness that it provides, but this should convey the general idea.

Answer 1

Metadata literally means data about data, but what you seem to be asking for is a way to control and change behavior of your objects.

I think such a concern is much better addressed with a Role Interface – see e.g. Udi Dahan’s talk about Making Roles Explicit. More specifically, the Strategy design pattern is used to define loosely coupled behavior. I’d look for a way to combine those two concepts.

As we already know from .NET, the use of static, weakly typed attributes severely limits our options for recomposing components, so I wouldn’t go in that direction.