Messages
Reply
Edit
Delete
The point of the EF Code First business wrapper is to be quite similar to the way wwBusiness works. I've just been through 3 medium sized projects with that code base and it works really well - we didn't hit any snags with this approach, but we were able to easily map the entire domain.
I think the biggest issue with EF and ORMs in general is if you don't control the database (ie. the database is maintained externally). Then EF reverse mapping can become a royal pain in the butt.
For this reason I've been thinking about potentially integrating a secondary data access layer that is much more dynamic. Actually EF CodeFirst already has a low level DAL built in that can retrieve low level ADO.NET objects (like DataReaders/Tables/Sets) or dynamic instances like DynamicDataRow/DynamicDataTable that allow for easier syntax at least.
Recently I've been thinking about possibly adding something like PetaPoco which is even more dynamic and adds a nice query extension syntax to objects as well as really fast object materializations from queries.
Ultimately the latter is really what's missing natively in .NET - a truly efficient way to do the equivalent of SCATTER NAME/GATHER NAME to a typed object...
Everything is a trade off though :-)
+++ Rick ---
Ha! I actually ran across that very post in doing research on all this EF stuff.
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.
West Wind Technologies
Making waves on the Web