I’ve been spending a lot of time futzing with stored procedures in Entity Framework and losing sight of the fact that one of EF’s core features is its ability to do query processing – and that is something it does very very well.
The Stored Proc support is obviously critical for many and while it’s there, some scenarios are pretty easy to pull off, while many others are possible but not so easy to implement and that can get frustrating.
What I’m trying to do is just truly see which things are easily pulled off in the designer (and discovering more than I realized), which are doable and which might take a hack or two to get around.
I think that in my case I was focused on the trees and forgot the the forest.
Thanks to the person who helped remind me of that.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
Unfortunately, our DBA is requiring stored procedures for all CUD operations and any complex select queries, which is why we took the time to create a template to generate EF-friendly sprocs.
Remember that one of the reasons that StoredProcs are used so frequently is the ability to not have to re-compile the binaries for bug fixes, etc.Unless you have the codebase locked down, you never can guarantee that the *only* fix you’ll deploy is the change to a query to fix or even expand something.Another huge benefit of using the StoredProcs is the decoupling of the DataModel from the Application.Unless, I’m missing something (which is totally possible – LOL), LINQ (and its variations) have brought the development momentum back towards a tightly coupled design.Though writing queries with LINQ/EF is relatively easy and less work than StoredProcs, the coupling of the DataModel and the Application is one of the reasons I’m hesitant to move away from StoredProcs.Note that I’m still on the fence about this – maybe there is a pattern to help decouple them while still use LINQ/EF for queries but I haven’t seen anyone post anything about this being a concern???
THe question really wans’t "should I use STored PRocs?" – I’m a big Stored Procedure person, which is why I’ve been beating this to death when exploring and describing Eentity Framework’s capabilities. It was more about stepping back a little bit and seeing what EF is currently great at rather than just focusing on this.You may want to take a look at Bob Beauchemin’s 6 part series "MHO: LINQ to SQL and Entity Framework: Panacea or evil incarnate?". Here’s a link to the first onehttp://www.sqlskills.com/blogs/bobb/2008/02/14/MHOLINQToSQLAndEntityFrameworkPanaceaOrEvilIncarnatePart1.aspx