5

I'm using Entity Framework 5.0 with code-first approach plus inheritance for my business objects represented by Table Per Hierarchy.

I'd like to have the following structure:

//Assembly 'DataAccess'    
public class MyDbContext : DbContext
{
    DbSet<AbstractClass> CommonObjects.AbstractClasses { get; set; }
}

//Assembly 'CommonObjects'  
public abstract class AbstractClass
{
    //implementation
}

//Assembly 'DerivedObjects'   
public class DerivedClass : AbstractClass
{
    //implementation
}

During runtime, when trying to access the DbContext the first time, the compiler throws an InvalidOperationException saying:

The abstract type 'CommonObjects.AbstractClass' has no mapped descendents and so cannot be mapped. Either remove 'CommonObjects.AbstractClass' from the model or add one or more types deriving from 'CommonObjects.AbstractClass' to the model.

Is this scenario even possible? If yes, what am I doing wrong?

Thanks for your answers in advance.

Ben

Additional information:

Maybe I should be a bit more specific:

I got one assembly containing my abstract business objects (only abstractions). The concrete implementations (containing the logic) are kept in the responsible assemblies, as their logic depends upon other classes within that assembly. The issue is, I want to be able to store those conrete implementations in the persistance layer as well. But for that purpose, EF had to know those types in order to enable the mapping. But I dont want to make the persistance layer depend on my business logic layer - only the abstractions.

That's why I tried to add the derived objects to the DbContext directly from the Business Object Layer.

Example: 

AbstractClass derivedClass = new DerivedClass();
MyDbContext.AbstractClasses.Add(derivedClass);

But then the exception above is being thrown. I just can't figure out a good structure to achieve this.

Ben Sch
  • 2,909
  • 4
  • 20
  • 23
  • Is `AbstractClass` meant to be a base class for _all_ entities in `DerivedObjects`? – Gert Arnold Apr 05 '13 at 22:46
  • 1
    No, this is just an example. There are several abstract base classes for several derived objects over several assemblies. – Ben Sch Apr 06 '13 at 09:29
  • So you must map the descendants and choose an [inheritance strategy](http://weblogs.asp.net/manavi/archive/2010/12/24/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph.aspx). I never tried different assemblies, [others did](http://stackoverflow.com/questions/5378678/entity-framework-code-first-and-multiple-assemblies). – Gert Arnold Apr 06 '13 at 09:53
  • 1
    Yea. The problem is, if I want to map the descendents, then the assembly with my derived DbContext has to reference the assembly of the descendents. But the descendents shall reference the assembly with the DbContext as well (as they need to have access to the persistance layer). But that would cause a circular dependency. How can I solve that issue? – Ben Sch Apr 07 '13 at 20:13
  • Why would the descendants (POCOs) need to have access to the persistence layer? They're supposed to be _persistence ignorant_. – Gert Arnold Apr 07 '13 at 20:25
  • Please move these comments to your post (remove the comments). It's an interesting problem. By editing your post it will gain new attention. My first thought is that you should use the decorator pattern, but that's a bit of a pain with nested objects (navigation properties). – Gert Arnold Apr 10 '13 at 07:31
  • 1
    Thanks for the hint and for your help so far. I have also thought of a similar idea like yours, but due to the requirements this is not applicable. – Ben Sch Apr 10 '13 at 13:33

0 Answers0