>
>Chipping in on this thread a bit late but:
>
>Firstly - no one has really pointed out that just about all data-access tecnologies in the .NET world (LinqToSql, EF, nHibernate etc,etc) sit on top of the ADO.NET components. Understanding ADO.NET is not time wasted regardless of the path you choose...
>
>Secondly - putting a lot of code in T-SQL is fine if you know you can stick with MS SQL. But if you may want to move to a different back-end then you will have a lot of re-writing ahead of you. Also, at least at present, the current ORM options don't work very well with SPs on the backend ( although I can't speak out of experience for nHibernate - if someone knows differently?.....)
>
>Thirdly (and I don't think anyone has suggested otherwise) - don't bother with LinqToSql. If you're sticking to the MS camp then use Entity Framework....

Good point about back-end agnosticity (is that even a word?) However, in real life I think it is extremely rare that a program is required to change back-ends. I haven't seen one yet.

Another more important problem for me is the question about how much processing do you offload onto the database server. If you do most of your data manipulation in T-SQL, it tends to put a lot of processing on the server itself, rather than dividing it between different layers.

To me, writing your own data access class is unnecessary given the various frameworks out there that have done this already and much better than I could do given the cost of a good framework vs. my lost "opportunity cost" spent chiseling my own wheel out of stone. But that's just my preference. BTW, Hank Fay found an interesting tool for .NET datamunging, including local cursors a la Fox (http://www.queryadataset.com.) It picks up where ADO.NET leaves off. Most interesting...

Personally, the older I get the more I like to "outsource" tinkering to others (e.g., data tool developers.) I am more interested in the destination than the journey, at least when it comes to program development. So, I've been working with the latest MS RIA framework as of late, and I like it quite a bit. Drag and drop data binding with validation and other builders at your fingertips -- imagine that! The more things change, the more things look the same. The only thing that gives me pause with that one is the question of how efficiently (or not) data moves across layers and boundaries, which I will know only after I have built a system that processes a lot of data. And then it may be too late, especially if I have leaned heavily on a framework. If it turns out to be too inefficient, I'll have to dismantle the entire house of cards and re-start from scratch.

It's... frustrating.