I'm not going to repeat what others have said, so I'll just add this: It sounds like he is talking about LINQ to Entities (which is only at CTP stage at the moment) rather than LINQ to SQL. LINQ to Entities is the ORM tool that Microsoft are bringing out. It looks quite neat, but I've yet to try it. WRT performance degredation, a good DBA will be able to write more performant stored procedures that match the database than an ORM tool will write SQL Queries. If the database changes the sprocs can be updated and the application need never know. If you change the data model then the application may need to be regenerated (or at least the mapping files need to be redistributed in the case of LINQ to Entities*) With my DBA hat on, I still prefer stored procedures, because then access to and modification of the database is controlled from within the database. Giving away rights to access tables directly is not something I am keen on from a security stand-point. I don't trust developers (even although with a different hat I am one) with my database. Trust is earned and so far the vast majority of developers have been found wanting. Also, take in to account that database security is difficult, and even although you might start out with the best of intentions the number of systems I've seen where a security problem is eventually resolve with the ah-phukkit-lets-just-make-it-dbowner method of sorting out access problems is heart-breaking** So, personally, I'm in turmoil on this. I really like the idea of LINQ to SQL and LINQ to Entities from a developer stand point, but the database administration in me says "You ain't gettin' your dirty paws on my database!" * Again, I've not used it, so this information may be used by the compiler rather than the runtime - I don't know, but many ORM tools use mapping files at runtime. ** No pun intended.
Upcoming FREE developer events: * Developer Day Scotland Recent blog posts: * Introduction to LINQ to XML (Part 1) - (Part 2) My website | Blog