Messages
Reply
Edit
Delete08:35 am
3O00IEXJX
| From: | Matt Slay |
| To: | Brett Baggott |
I too am cautiosly deciding which data access route to go as I contemplate doing real app work int he .Net space.
I still have one active app in FoxPro using wwBusiness, and moving away from that is going to be be hard. Rick's wwBusiness (and FoxPro in general) has spoiled me.
I'd hate to invest several months of development in a certain data access solution that turns out to plague me and my app for many years to come.
I have the luxury of moving slowly, so I am taking my time for now. But at some point, I've got to man-up and make a choice, otherwise, I'll still be sitting on the sidelines watching all the big kids playing and laughing and having a good time. Or, are they secretly crying under their covers at night because there data access choice has given them a big headache, while I sleep comfortably resting my head on my old FoxPro client app for a few more years.
Matt, take a look at this post on Code Review:
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.