4

I'm using Entity Framework 6 Code First with an Empty Database. I've created a fairly large number of POCO classes with a reasonably complex class hierarchy (a fair number of abstract classes and quite a few concrete classes). I'd like to be able to decorate my classes in some way so that they're automatically added to the DbContext without having to explicitly create a DbSet property for each, but I worry that this will cause problems when I try to update-database. I've seen a couple of threads here where someone seemed to be asking a similar question, but the response seemed more geared to using DbContext.Set() to get a reference to an existing set.

Matt Knowles
  • 387
  • 2
  • 12
  • Can you please add a link to the article you mention? – elolos Oct 10 '14 at 15:02
  • As far as I know, the answer is yes, you have to add a `DbSet` property for each POCO class. – pquest Oct 10 '14 at 15:08
  • Why are you worrying that this will cause problems? You could always just try it out you know :) – Peter Lillevold Oct 10 '14 at 15:14
  • @PeterLillevold, I'd rather not waste a bunch of time trying to figure out *how* to programmatically add DbSets to my DbContext if I'm going to have to manually add them anyway so that the Migrations will work. – Matt Knowles Oct 10 '14 at 16:55
  • @elolos, here are the two links I found while searching, although only one is on Stack Overflow (by far the best resource I've found for this kind of stuff, btw). http://stackoverflow.com/questions/5308336/how-can-i-create-dbsett-dynamically-in-entity-framework http://forums.asp.net/t/1886819.aspx?Creating+DbSet+Properties+Dynamically That last one especially sounded like it was asking the same question I was. The first one seems more like it's asking about how to reference the collection of DbSets rather than being forced to reference them individually - so, my bad for mischaracterizing. – Matt Knowles Oct 10 '14 at 17:00
  • @MattKnowles - sorry, I misunderstood. I thought you meant that explicit DbSet properties could cause problems. – Peter Lillevold Oct 10 '14 at 17:18
  • Just a follow-up. What I was trying to do was rather easily accomplished simply by using the Set<>() method. I am able to just add one explicit DbSet<> to my context, and rely on the relations to include the rest of my model. – Matt Knowles Dec 04 '14 at 05:32

2 Answers2

2

If you're relying on code-first migrations, then yes, EF uses reflection on your DbContext in order to discover what tables to create. Each DbSet property maps to a table in your database.

Peter Lillevold
  • 33,668
  • 7
  • 97
  • 131
  • Thanks much for the clear answer, although it's rather disappointing. – Matt Knowles Oct 10 '14 at 16:56
  • 1
    Although, I suppose I could create a partial class that gets generated with the DbSets I want... Sounds like fun :) – Matt Knowles Oct 10 '14 at 16:57
  • @MattKnowles - do not underestimate the power of code generation :) Though I'm not sure the effort is worth it: "autogenerating DbSet props based on attributes on models" vs. "just add that property when new model is introduced" – Peter Lillevold Oct 10 '14 at 17:21
  • It may well not be worth the effort, but I'm building a pretty complex model from the ground up, so things change - sometimes drastically - fairly often at this early stage. It's cumbersome to have to manually add (or worse, change) all the properties, especially because it's such a rote exercise. – Matt Knowles Oct 10 '14 at 17:49
  • @MattKnowles - sounds like codegen will be your friend :) Good luck! – Peter Lillevold Oct 10 '14 at 20:04
  • I should add that I was apparently operating under a misunderstanding (although I thought I'd tested this previously). I was under the impression that I had to include a DbSet for every type, but apparently EF automatically adds any referenced Types as DbSets, so as long as their referenced by something that is explicitly added, I don't need to explicitly add them. – Matt Knowles Oct 11 '14 at 05:34
1

I discovered that I don't need to add explicit DbSet properties to the DbContext for every class because EF automatically adds all related classes to the model.

I'm able to be lazy and only add explicit properties for some classes, and then reference any other classes using the DbContext.Set<>() method:

var q = from x in myContext.Set<myClass>() select x;
Matt Knowles
  • 387
  • 2
  • 12