Click here to Skip to main content
15,905,607 members
Please Sign up or sign in to vote.
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
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 !

1 solution

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.
 
Share this answer
 

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900