Question

With the following business object:

public class ItemsRow : BusinessObject<ItemsRow>
{
    public static readonly DependencyProperty ItemIdProperty = DependencyProperty.Register("ItemId", typeof(int), typeof(ItemsRow));
    public static readonly DependencyProperty DescriptionProperty = DependencyProperty.Register("Description", typeof(string), typeof(ItemsRow));

    public int ItemId
    {
        get { return (int)this.GetValue(ItemIdProperty); }
        set { this.SetValue(ItemIdProperty, value); }
    }

    public string Description
    {
        get { return (string)this.GetValue(DescriptionProperty); }
        set { this.SetValue(DescriptionProperty, value); }
    }
}

How would you go about exposing the properties in a model, seeing as how the properties are already DependencyProperty’s?

I was wondering if it would make any sense to do this:

public class ItemModel: DependencyObject
{
    Item _item;

    public ItemModel(Item item) 
    {
        _item = item;
    }

    public static readonly DependencyProperty DescriptionProperty = Item.DescriptionProperty;

    public string Description
    {
        get { return _item.Description; }
        set { _item.Description = value; }
    }
}

Would that work as intended or would the model necessarily have to have its own set of DependencyProperty’s that are backed by the business object’s DependencyProperty’s? Or could this be modified slightly to work correctly?

Answer 1

That won’t work because the dependency property registration needs to know on which type the property is being defined; that’s why you pass the third argument to the register method. So far that reason alone, it won’t work properly. But from a theoretical MVVM design stand point, having a separate object in your model that closely resembles your business object is a trade-off that you chose to have another layer of abstraction. You are essentially buying the redundancy to allow yourself to have another layer of abstraction allowing you to swap the business object without changing your model. However, if you make your model object dependent on specifics of your business object implementation, you are defeating that purpose. In that case, I would just directly use the “business object” as your model object.