Vague error message with EF5 when using Inheritance and Table Per Concrete Class (TPC)

Posted:
14 Jul 2013 - 19:25 UTC.

While doing concept work on the abstraction of Data Manager from Entity Framework, I came across a slightly vague error message, despite following the MSDN guidelines on Configuring/Mapping Properties and Types with the Fluent API.

The error message was consistent across the unit tests, the first DbSet in my EntityFramework Context class would always fail to map with the following:

System.InvalidOperationException : The type 'Dhgms.Wcds.EntityFramework.Model.Info.Blog.Post' was not mapped. Check that the type has not been explicitly excluded by using the Ignore method or NotMappedAttribute data annotation. Verify that the type was defined as a class, is not primitive, nested or generic, and does not inherit from EntityObject.
Having looks on Stack Overflow and MSDN I was a little perplexed as to how it wasn't working but had overlooked an earlier piece of learning. My code looked this this:
namespace Dhgms.Wcds.EntityFramework.Model.Info.Blog

{

public class Post : Dhgms.Wcds.Model.Info.Blog.Post

{

// extra EF relevant relationship properties here

}

}

The problem is very similar to the one which dictated my naming convention of information and difference classes in Data Manager. Entity Framework does not use the fully qualified name of a class when resolving it, thus Data Manager had Difference appended to class names. It appears there is a similar issue when using inheritance where the name is the same. To get around it I simply applied Ef to the name of the inheriting class, like so:
namespace Dhgms.Wcds.EntityFramework.Model.Info.Blog

{

public class PostEf : Dhgms.Wcds.Model.Info.Blog.Post

{

// extra EF relevant relationship properties here

}

}

This now works fine, and allows me to keep a base Information Class which can remain independent of the storage implementation, even if the implementation needs to have extra code to do provider specific mappings of the properties. I do however wish that libraries that do runtime verification via reflection etc. actually used fully qualified classes and properties in their logic.

Share

Comments

There are no comments.

Posting Comments is disabled.