Question

I’ve got a scenario with two different applications sharing the same database. For both applications, I’m using Code First EF 4.1. Both of these applications share a common library as well. Everything is fine until I start adding application specific inheritance. For example, say I have a class in the shared library like this

public class Customer
{
    public CustomerOrder Order;
}

And then, in one application, I inherit CustomerOrder to add some custom functionality required for the application.

public class EditableCustomerOrder: CustomerOrder
{
    public void Edit() {};
}

In this application, I want all of my CustomerOrders to load as EditableCustomerOrders. However, I cannot find a way to specify in the mapping that it should ignore CustomerOrder and only map EditableCustomerOrder to the underlying table.

I tried this

modelBuilder.Ignore<CustomerOrder>();

but that omits the Order property from Customer, so I cannot use it. The only way I’ve gotten this to work is by using generics, so that Customer uses a generic for it’s CustomerOrder type, and then I implement Customer in the application to specify that it uses EditableCustomerOrder. However this solution can grow out of hand pretty quickly, with generics all over the place.

Is what I’m trying to do possible? Basically I’m trying to tell entity that, even though there is a base type and an extended type, I want it to only use the extended type.

Answer 1

In case any desperate beings stumble across this, I figured I’d post the solution I ended up with.

The only way I found to make a scenario like this work was to use abstract classes as my base class that was defined in the shared library, and then extend that base class in each application. From that, I could write a DbContext for each application that ignored all added properties on the extended classes. With all of that in place, I am able to use Entity to map to different implementations in different applications to the same set of base classes.

I would also like to advise against this overall idea as a solution. I’ve had this in place for several months now. It works, but it’s awkward to work with and mistake prone. To move away from this, I’m going to seal my model classes and instead focus on an MVVM solution for each application.