Question

N.B., this is all C# 4.0

This might seem like an odd question, let us say that all my business objects bind to a base class, let’s call it BaseObject, so I’ll have my classes inherit it like so:

public class CashRegister : BaseObject { }

Now most of the time I’m using, say, NHibernate on my projects. Some other projects come along and I’d like to use CouchDb. Rather than create a new BaseObject for each of these technologies, I’d like to somehow “bind” something like CouchDbObject to BaseObject … is this possible? Even better would be if I had an attribute and it would bind based on the attribute:

[CouchDb]
public class CashRegister : BaseObject { }

This might be crazy, but is it possible? Given the above example, I’d liek to do this:

var cashRegister = new CashRegister();
cashRegister.SomeGenericBaseObjectMethod();
cashRegister.SomeCouchDbSpecificMethod();

It seems that Ninject “contextual binding” does what I need, does it? I’m brainstorming right now, but it would be great if somewhere in my code I could do something like this to do the actual binding:

Bind<ICouchDbObject>.To<BaseObject>();

I would even be up for making BaseObject dynamic, or any other bleeding edge features that might make this possible. If this is not possible or a “don’t,” let me know! Trying to think outside the box.

Answer 1

No, what you’re asking isn’t possible, for a couple of reasons.

1. .NET doesn’t allow one class to directly inherit from multiple classes.
2. The project needs to refer to the parent class’s library when it is compiled, so it can’t be assigned a new parent class at runtime.

Usually when you run into a situation where you want to do what you’re describing, it’s because you’re using an architecture that doesn’t separate concerns well enough. I’m just guessing here, but you’ll probably be more flexible if you use an approach like this:

public interface IBaseObject
{
    int ObjectId {get;}
}

public class CashRegister : IBaseObject
{
    int IBaseObject.ObjectId { get {return CashRegisterId;} }

    public int CashRegisterId {get;set;}
}

public class BaseObjectUtil
{
    public void SomeGenericBaseObjectMethod(IBaseObject baseObject)
    {
        var objectId = baseObject.ObjectId;
        // Do something with the object ID.
    }
}

public class SomeUtility
{
    private BaseObjectUtil _baseObjectUtil;
    public SomeUtility(BaseObjectUtil baseObjectUtil)
    {
        _baseObjectUtil = baseObjectUtil;
    }

    public void DoSomethingImportant(CashRegister register)
    {
        _baseObjectUtil.SomeGenericBaseObjectMethod(register);
    }
}

You’ll notice that so far we don’t have any code that relies on CouchDb. Now, say there’s another project that wants to be able to use the above project, but wants to be able to perform additional operations based on the CouchDb information. You might do something like this:

public interface ICouchDbObject
{
    string TableName {get;}
}

public class CouchDbUtil
{
    public void SomeCouchDbSpecificMethod(ICouchDbObject couchDbObject)
    {
        var tableName = couchDbObject.TableName;
        // Do something with the table name.
    }
}

public class CouchDbCashRegister : CashRegister, ICouchDbObject
{
    string ICouchDbObject.TableName {get{return "CashRegisters";}}
}

In this project, when you need a cash register, you would use a CouchDbCashRegister, which would allow you to call the CouchDb-specific methods on your CouchDbUtil class, while still allowing you to call the baseline utility methods in your BaseObjectUtil class.

Furthermore, if you leverage a DI framework like Ninject to create your objects, you can actually make it so that all CashRegisters that get created in your second project are actually CouchDbCashRegisters.

Bind<CashRegister>.To<CouchDbCashRegister>();