Messages
Reply
Edit
Delete
> 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.
The EfCodeFirst and Linq To Sql classes before it, actually mimic much of the behavior that wwBusiness provided and I find it to work pretty well.
In the last half a year I built 3 medium sized applications using this data model and it's worked out great - never really ran into any serious limitations mainly because there's a low level ADO.NET fallback built into it that provides the abililty to go raw if you have to. It's worked out well.
The biggest issue with EF (and ORM in general) is the static nature of the model. Trying to keep model and database in sync if development doesn't own the data base is tough.
For this reason I think it's very important to allow for 'dynamic' mechanisms to get at the data. In my bus classes there are low level DAL components that let you query raw DataRows and 'manual' entity fillers (which is unfortunately slow). I've been thinking it would be nice to actually build something like PetaPoco directly into the business layer as a subcomponent so you can use EF wherever it works, and PetaPoco's dynamic features and manual SQL access where it works best.
Overall though for most small to medium sized projects the EFCodeFirst bus object has been working really well. It's so easy to do the typical transactional operations and it all comes basically for free. In my case I've been able to keep control of the Db and mapping and there have been 2 instances total out of these 3 apps where we needed to go around EF and use low level data access to wring out some extra performance and once to get a query to work that was mind bogglingly complex with LINQ2Entities and reasonable easy with plain SQL.
Brett, I'd be interested to hear what failure points you see in EF that aren't ORM in general failure issues that are better in nHibernate?
+++ 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