EF5, Database/Model First derived types

Question

Using Entity Framework Database/Model First, when deriving from EF automatically generated classes, is there a short way to specify mapping and metadata information for the derived classes to equal that of the automatically generated base class?

For example, we have an EF model generated Customer class:

     public partial class Customer  {…}

Then, we have a programmer created ExtCustomer class, derived from Customer:

     public class ExtCustomer : Customer {…}

The second class is where the programmer put logic code for the customer. The derived class does not define any persistent members; everything needed for serialization is in the Customer class. Yes, I know that the recommended way for extending functionality of EF classes is through partial classes; but let us say we want to use derived classes in this case, for whatever reason.

Now, when trying to persist an instance of the ExCustomer class through Entity Framework, we understandably get the following error:

An unhandled exception of type 'System.InvalidOperationException' occurred in System.Data.Entity.dll

Additional information: Mapping and metadata information could not be found for EntityType ' ExtCustomer '.

So, my question, is there an attribute or something that we can give the ExtCustomer class, to tell the Entity Framework to use the Customer’s class mapping and metadata when persisting ExtCustomer instances?

I am primarily looking for a solution that does not evolve modifying T4 templates.

Thank you.

Answer 1

This is not something that EF supports at the moment. The extended type would need to be part of you model somehow, a TPH mapping to the customer table for example.

However, I'm interested in knowing why you wanted to go down this path. It is possible that we could add support for this type of thing in the future if we have a few scenarios that seem valuable. Could you provide some more information about the scenario?

---

We are seeing a lot of great Entity Framework questions (and answers) from the community on Stack Overflow. As a result, our team is going to spend more time reading and answering questions posted on Stack Overflow. We would encourage you to post questions on Stack Overflow using the entity-framework tag. We will also continue to monitor the Entity Framework forum.

Answer 2

Dear Glenn,

I appreciate your reply. Entity Framework is a great library, and it gets better with every release.

Object inheritance and subtype polymorphism are at the foundation of Object Oriented Programming (OOP). And we certainly want Entity Framework classes to be fist class OOP citizens.

Let us look at a couple of practical examples.

We may have a requirement to keep automatically generated Entity Framework (EF) classes in one library while the code extending the EF classes in separate projects. While partial classes are great, they are prohibited from crossing assembly boundaries. Furthermore, enabling substitutability for mutable objects with EF classes would allow other members of the programming team to extend the classes without unrestricted access to the model.

For the second example, consider default constructors. Automatically generated EF classes may or may not have default constructors; as such when there is a need to implement a default constructor there may be a collision between automatically generated code and the code written by a programmer, since a given class may have no more than one default constructor, regardless of partial implementation. Derived classes, on the other hand may always implement they own constructors.

Thank you again for your reply; it is certainly great to see Microsoft team gathering feedback from the field.

Answer 3

Hi,

Have you considered using Code First instead of database/model first? If you use the EF Power Tools to reverse engineer a code first model from your database, then you just have poco classes that you can do what you like with. The only difference is that you wouldn't be able to modify the database and generate code after that, you'd need to change to using Code First Migrations or some other way of keeping the database in sync with the code. If that setup suits you then it seems like a much better way to achieve the types of things you are after.

However, the ability to have an inherited type just map to its parents table doesn't seem unreasonable. I'll mention it to the team and get it added to the backlog on CodePlex.

---

We are seeing a lot of great Entity Framework questions (and answers) from the community on Stack Overflow. As a result, our team is going to spend more time reading and answering questions posted on Stack Overflow. We would encourage you to post questions on Stack Overflow using the entity-framework tag. We will also continue to monitor the Entity Framework forum.