http://bloggingabout.net/blogs.....tizen.aspx

It’s hard to say which one would save you LOC. Going straight ADO.net has the “benefit” of being the standard though, so any code monkey can wrap their head around that or buy a book that shows how to do it.

Effort might be better spent getting away from sprocs entirely

Thanks for the detailed clarification. I definitely see how having to create 6 mapping files because you have an update, insert, delete, and 3 versions of a select is insanely more difficult than just having to worry about 1 table mapping. That’s the beauty of using ORM’s the way they were supposed to be used (without sprocs).

However, if you didn’t use NHibernate and just used straight ADO.NET code instead, wouldn’t you also have one ADO.NET method for each NHibernate sproc mapping file with basically the same input and output information (and in a slightly more verbose format based on how many data access helper methods you have)? In your experience, if you had to compare number of lines of code between an ADO.NET version and an NHibernate with sproc version, would you actually come out with more lines of code on the NHibernate side?

What I meant by more work was that I had more to worry about in regards to the mapping.

Not only did I have to pay attention to the table structure/columns etc…. but the inputs/outputs of each stored procedure. Which in a sense from the mapping standpoint could be thought of as another table. So essentially a class that would be mapped to one tableish entity now has to be mapped N stored procedures table.

Ultimately what was needed was a convention for the stored procedures in terms of params and their names and what was returned. For example, you would need a sproc for fetching a single row by id at least, and there could be more select sprocs depending on your needs, each one would probably have to return a result set with the same columns/structure or you would likely drive yourself insane, and an update insert sproc that would likely contain identical params probably matching up closely to the columns of the underlying table and a delete by id sproc. Now, if you need a new property which will map to a column in the underlying table what do you have to do?

1: add the column(regardless of whether sprocs were used)
2: change each select sproc(s) to include the new column in the result
3: change param signature for insert and update
4: change mapped class(regardless of sprocs)

And as far as I can tell, the only tool you have to manage all that is your brain. I don’t trust mine to handle all that.

Without sprocs you still have to do 1 and 4, introducing sprocs into the equation to me yields little or no benefit other than keeping some DBA employed, or slowing down development to the point where it can be managed by some pointy haired boss, and distracting the developer from the problem domain.

Hope that explains things, this is strictly my point of view by the way, and runs the risk of your blog post being overrun by a religious war at this point. Apologies in advance.

Thanks for the heads up about the issue related to param ordering. I’m curious about that one so I’ll play with it this weekend to see if either anything has changed or else there is a way around it (i.e. named parameters that make the order irrelevant).

I’m a little confused about your second statement. How would NHibernate cause more work with regards to keeping your sprocs in sync with your source code. Wouldn’t you also have to worry about that with regular ADO.NET code?

I tried my darndest anyway and I think it ended up causing more work for me, not only did I have to keep ~4 stored procedures in sync with the table(s) now there was source code as well.

That said, I’m not sure if using NH with sprocs involves much right-to-left stuff. Ayende has a good post on the basics:

http://ayende.com/Blog/archive.....dures.aspx