Sam
Sam

Reputation: 2792

Implementing TPH using "Database First" approach

I'm trying to implement EF TPH using the "Database First" with the help of the following document from Microsoft,

http://msdn.microsoft.com/en-us/data/jj618292.aspx

I do understand how this works but it sounds a little naive the way it's done or I'm missing something which I would like someone to enlighten me on this.

To my understanding, the whole point of implementing a database first approach is when you have a pre-exisiting database or if you prefer to do your work first hand on your database and work your way up, however, this document suggests that the inheriting tables (Student, Instructor) are meant to be created at the EF design area using a field on the base class which they call a "Discriminator" field which your inherited entities end up pointing to.

However, my question is, why would you have to create these inherited table at the ER designer where you initially intended to create your table structure first hand before working your way up the entity framework and how would this change that you applied on the ER designer (adding the inherited tables) be mapped into the back-end database, and at the end of the day when I want to make a change to my database later on, where will I have to make these changes (on MS SQL or the ER designer). If I end up adding tables from the ER end, then that would pretty much defeat the purpose of the "Database First" methodology, because I basically ended up using the procedures in the "Model First" approach which doesn't make sense at all.

Your help in clearing this up would be much appreciated.

PLEASE NOTE: I would rather have everything done at my database and rather not use the "Model First" approach. I'm interested to implement the TPH and be able to make any changes directly to my database and have those changes mapped into my EF sublayer (not the other way around).

Many Thanks

Upvotes: 0

Views: 1226

Answers (1)

Gert Arnold
Gert Arnold

Reputation: 109195

I don't see how EF could ever infer inheritance for you. Maybe it would be possible to have it triggered it by a field explicitly named "Discriminator" in a table, but what if you want a different name for the discriminator? And then, what should be the names of the derived classes? EF has no clue. The names are nowhere in the data model.

Still, it is database first. But EF just creates a first draft of the mapping. Nearly always you need to make modifications to the conceptual model (the model you see in the edmx), like renaming properties or classes, renaming/adding/removing associations. Or applying inheritance. When you update the the model from the database it may be necessary to apply some more manual changes. For instance, with TPH inheritance you may have to decide in which class to put a new field.

Maybe you are a bit side tracked by the idea that you "have to create these inherited tables at the ER designer". You define classes that map to one and the same table.

Upvotes: 1

Related Questions