Entity Framework - Inheritance

Question

0.00/5 (No votes)

See more:

Hi All,

I can't remember if this is possible, but I'm sure it should be.
I have a table in my database which looks as follows:

SQL

Id [bigint] [primary key + auto incremented]
Name [nvarchar(50)]
UserType [tinyint]
LineManagerId [bigint] [nullable]
DivisionHeadId [bigint] [nullable]

There is a relationship limiting LineManagerId and DivisionHeadId to be valid ID's from the same table.

I'm sure you can from that picture the structure? If not ask :-)
I'm using Entity Framework to create my objects and it brings in the User table with no problem.

What I want to do is have the following objects:

C#

public class User
public class LineManager : User
public class DivisionHead : User

These should all map to the same table using the UserType field as the differentiating factor.

Users should have 0..1 Line Manager's and 0..1 DivisionHead's
LineManagers can have many users and 0..1 DivisionHead's, and the class should have a "users" navigation property.
DivisionHeads can have many users and the class should have a "users" navigation property.

I've been able to make a derived class from my Users entity, however when I try to build it I get the error UserType has no default value and is not nullable yet, I've set the default value of UserType to be 1.

(I tried to convert this value to an enum but that results in the following error: default values are allowed only for non-spatial primitive types)

So my question is, how can I achieve this? Or more accurately what am I missing as I have the classes I just can't make them work?
I would have thought it would be straightforward and I feel I'm close but my research so far isn't shedding any light on the issue. I'm hoping you you guys can?

Thanks,

Posted 5-Jan-16 1:42am

Pheonyx

Add a Solution

Comments

Nathan Minier 5-Jan-16 7:53am

Have a look at:
http://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph

The different inheritance approaches are well-described in this blog series.

Now what you're doing with the UserType field is problematic, as EF will automatically try to do some relational mapping for derived types. I'm not sure why it would conflict with the mechanism that you've tried to put in place, but then we haven't seen that code.

The best route that I've found is to use the TPT model (fluent map a derived class ToTable() or attribute [Table()]) and let EF handle the wiring of the relationship under the hood.

Pheonyx 5-Jan-16 8:09am

Hi Nathan,

Thanks for that, tph is what I'm attempting to do but I'm not sure what I'm getting wrong. I'll take a look at that blog post now.

In the mean time, the main reason that I've initially gone down the TPH route is that other than navigation properties there is no difference with my derived classes. I was trying to keep my classes clean but the more I look into it, it might not be appropriate.

You mentioned about the code, what code would you like to see? I've been building this Database first rather than code first so I have an EDMX file for the model.

Nathan Minier 5-Jan-16 8:39am

Ah, that explains a lot. The purpose of DataBase first is really for when you have a data back-end that you can't go about changing, such as when migrating a legacy application. I wouldn't advise using it as a primary development strategy when working with EF, but that's the stance of a guy that looks at a database as an abstract where he keeps his stuff :)

I'm afraid that I won't be able to help you from the .edmx side of the house; I'm not the best equipped for that work. If you start looking at POCO I can give much better support.

Pheonyx 5-Jan-16 8:59am

Thanks Nathan,

Feel free to put your comment down as an answer. It's been very helpful.

BillWoodruff 5-Jan-16 8:17am

imho, this is a good answer, and deserves to be posted as an answer, and get upvoted !

Nathan Minier 5-Jan-16 8:40am

Thanks Bill, I just had a feeling that there was a likely rabbit hole here and I couldn't afford to "buy" the issue today :)

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Nathan Minier · Accepted Answer · 2016-01-05T03:06:00

There's a helpful blog series at:
http://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-1-table-per-hierarchy-tph

The different inheritance approaches are well-described in this blog series.

Now what you're doing with the UserType field is problematic, as EF will automatically try to do some relational mapping for derived types. I'm not sure why it would conflict with the mechanism that you've tried to put in place, but then we haven't seen that code.

The best route that I've found is to use the TPT model (fluent map a derived class ToTable() or attribute [Table()]) and let EF handle the wiring of the relationship under the hood.

These approaches are designed to work with Code-First Entity Framework approaches, and the described mechanisms will not work as specified with an .edmx driven DAL. You can tweak the database some to extrapolate the resulting tables into a workable system; one thing that you can do for TPH is to add null-able columns for the properties of the derived classes into the table as well as a type field (CLR type that is). That should get it over the hump, but building a test TPH using code first should give you the exact construction of a TPH model, and you can extrapolate from there, in case I missed any details.