Messages
Reply
Edit
Delete
That's very similar to how I was doing it before switching back to nHibernate. I initially avoided multiple DbContexts so I could use Data-Mirgrations (while prototyping) without having to specify the context. I first ran into this when messing around with the "Internet Application" template that wanted to use it's own DbContext for the User Profiles. In changing that to use my DbContext, I went down much the same road as mentioned above.
Eventually I got disillusioned with EF as a whole and switched back to nHibernate. I'm still using Code First EF on some simple projects (mostly proof of concept stuff) and I really like it when fleshing out a project. I do think EF is moving in the right direction, just not sure it's "there" yet.
> A big DBContext will take a little longer to spin up the first time, but after that I think there's the no difference.
Hmm.. Where does this "spinning up" of the DbContext occur? It seems like my current architecture would create a new Context with each new Controller action hit, right? The Controller action creates a new busObj and calls a Getxxx() method on it. I do not have an application-wide Context floating around, so where else is a live DbContext going to come from except in the instantiation of the BusObj class??
That sure does sound like it would be slow.
Surely I'm missing something here.
I don't think it really matters. A big DBContext will take a little longer to spin up the first time, but after that I think there's the no difference. If you have multiple dbContexts it'll take just as long but spread out more.
It really depends on what works for you. I prefer everything in one context *if* it doesn't get too complex to keep track of what's in there. It's difficult to go cross context, so if you create multiples you'll end up implementing the same entities that are shared multiple times (otherwise queries won't work with LINQ). So go with single, unless you have very clear operational boundaries where it would make sense to separate them out.
+++ Rick ---
Rick - in your opinion, is it a good practice to have multiple XXX:DbContext classes for each major section of the app (considering it's an app with several sub-systems and about 50+ tables in its database)? For example: CustomerQuotesContext, ShippingContext, InvoicingContext, etc.
Or it's more convenient to have a single DbContext with every single table (okay, DbSet<class>) dumped in there?
If you go with a big-dump-of-everything DbContext, are there any performance issues? It seems a little bloated to have a Context with 50+ tables, when I know the CRUD work or Controller view that I'm about to render will only ding about 4 or 5 of those tables for any given action.
~Brett