True that SP or not does not directly translate to the general OR/M topic but…

Your project is using nothing but SPs for DAL.

You suggested that I was mad for not wanting to ever write a SP again…and that SPs where the perfered method of DA

So..in the context of this topic…OR/M has everything to do wth the use or not of SPs

and again … the use of / lack of use of SPs has absolutely nothing to do with ORM …

i say SPs provide code reuse -

I’m sorry then; I thought you where referring to DRY. Then my point should have been…your creating to places to maintain the same code. no good.

I could not agree any more. OR/M tools are so much more then a pretty solid abstraction from the underlying persistence layer…I never said they are simply DAL’s…Speaking of…its not my project that is only using EF for nothing more then DAL to SPs

L2S …enough said.

for example …

i say SPs provide code reuse … you say “Using the same database for transaction and reporting is one of the worst examples of the DRY principle I can think of” … which by the way i agree with … but … where in the statement of “SPs provide code reuse” is there a mention of using the same database for “transaction and reporting”? … the SP should be created once and utilized on both the transaction and reporting DBs … further i only mentioned reporting as an “example” of another endpoint working with the data that is not the application … there are others …

i also agree that ORM needs to be utilized more in today’s development efforts … however, if you treat an ORM as a just another way to do data access then you’re not entirely getting it … the objective is to, for as much as possible, forget about, as you’re writing your application, forget about that there is a backing store, forget about what it is that you have to do to go and get things and concentrate on what you are trying to accomplish and what your model is supposed to be doing for your application …

ORM does not mean map to db schema … it’s the means of mapping an application’s objects to the data in a backing store … the use of / lack of use of SPs has absolutely nothing to do with ORM …

“not one of your counter-points makes any sense …”

- Ok; to many words in my reply Lets try this:

Todays performance metrics do not offer any clear performance gain for 99.99% of queries. Execution plan (performance) is a horrible reason to stick with SPs (waste project hours)

Using the same database for transaction and reporting is one of the worst examples of the DRY principle I can think of.

And about your listening analogies. The entire point of the post was to list OR/M resource that would help others learn, from industry experts – not me, why its time for us to move to OR/M. Please listen before regurgitating age old pro-SP points that have been proven incorrect time and time again.

I hope you know I understand where you are coming from. True; Microsoft has recommended using SPs for data access but managed code is managing more of our development (a good thing) and letting us focus on what’s important (building quality systems).

I know your old school, you’ve had SPs beat into your head for the past 10+ years but the times are changing.

I truly value your expertise and I hope you soon realize the issues that architecture creates.

Oh’ during our conversation you asked me to show you where Microsoft has recommended anything but SPs for data access. While I would never want to put words in Rob’s mouth and I completly acknowledge that his comments are not representive of Microsoft…I just want to make sure you know who he is (from comments above).

Please please please watch these videos.
http://www.asp.net/learn/mvc-videos/#MVCStorefrontStarterKit

http://blog.wekeroad.com/
http://subsonicproject.com/
http://tinyurl.com/lgbnyq