Convention Binding

Apr 8, 2012 at 6:37 PM
Edited Apr 8, 2012 at 6:38 PM

Hi Kent,

I've just started experimenting with this library. It looks great so far, and really seems to address an issue I run into over and over again.

One issue I have with a project I'm currently working on is that I have a couple objects with a lot of properties in common (both the property names and types match). Without Truss, the default solution might be something like this:


public class Class1
    public string Name { get; set; }
    public int Age { get; set; }

public class Class2
    private Class1 _class1;

    public string Name
        get { return _class1.Name; }
        set { _class1.Name = value; }

    public int Age
        get { return _class1.Age; }
        set { _class1.Age= value; }

    public BusinessObject2(BusinessObject1 businessObject1)
        _businessObject1 = businessObject1;


There are two problems with this:

  1. The two classes are strongly coupled.
  2. It's tedious and error prone to keep the code for the second class in sync with the first, particularly if there are more than a handful of properties.

Truss solves issue #1, but if I understand the feature set, it doesn't really solve issue #2. I would still need to manually connect each property of Class1 to each property of Class2. What I think would really add tremendous power to Truss is if I could sync two types together with a single line of code (or at most, a small amount of configuration).

There's already a popular library, AutoMapper, that allows convention mapping between two types. If the type and property name are the same, you don't have to do anything. If not, there are various options for configuring each mapping. Also, it's possible to validate all your mappings to make sure every destination property is accounted for.

Where AutoMapper falls short is that it won't keep two types in sync. If you wanted this functionality, you would need to manually perform a mapping operation any time a property changed. In addition, you wouldn't just be mapping the property that changed, you'd be mapping every property.

You can probably see where I'm heading at this point--what would happen if you combined Truss with AutoMapper? AutoMapper already provides a solid system for configuring mappings. Truss would just need to make those mappings "live". (I don't mean to make this sound trivial to implement, just conceptually simple.) I certainly wouldn't remove the ability to bind or multi-bind specific properties, but I think being able to bind entire types would be very powerful.

What do you think?

Apr 10, 2012 at 1:28 PM

Hi danthman,

I've not personally used AutoMapper, but am aware of it and what it achieves. If it provides some sort of lambda-based mapping ability so that you can specify what happens when mapping properties, it would theoretically be quite simple to get this marriage going. However, I'm not sure whether AutoMapper has that flexibility.