Question

No issues really, this is more for my personal comprehension. Using MVC3 + EF 4.1 Code First. I’m trying to make a one-to-one relationship between a Provision and an Enactment.

I tried using the conventional way of making DbSet<Provision> and a DbSet<Enactment>. However, it turned out EF didn’t like that. I had to change the OnModelCreation override to define the principal/dependent relationship (fyi Provision is principal, Enactment dependent). I had a bunch of errors and exceptions for some reason. So I tried something a tad creative:

I commented out the public DbSet<Enactment> Enactments { get; set; } line from my Context. Nonetheless, my Provision class still calls for a public virtual Enactment Enactment { get; set; } property. I thought that would make it so that a Provision will just save in its Enactment property an object of the Enactment class itself (if this sounds odd, I apologize I took up programming only a month ago and still learning). That was acceptable, since I thought I would be able to access the Enactment by looking at Provision.Enactment.<EnactmentProperty>.

What surprised me was that even with DbSet commented, the db still created an Enactments table mapped to my Enactment class properties. So if anything it seemed like I got an even better result than anticipated – but I just don’t understand the logic behind my code now. Is commenting the particular DbSet and still getting a table normal in the circumstance? Am I playing with fire and should back away from this method?

Answer 1

Commenting DbSet doesn’t matter. EF code first uses some conventions which will check you entities and mapping and infer all classes which should be mapped. So if you have any fluent mapping describing some entity or if any entity you explicitly mention in DbSet or mapping has navigation property to other class (which can be entity = EF is able to infer its primary key) it will be mapped as well.