In LINQ. Well, at least in LINQ to SQL, and some of the neat LINQ-to projects like LINQ to flickr and those sorts.
I'm not quite so sure about LINQ to XML -- I still find myself using a lot of XPath, which I thought LINQ would let me get away from. Sure, LINQ to XML is nice for WRITING XML, but reading? I'm not sure it's a big win.
But let's get back to the subject at hand: LINQ to SQL. For quite some time, I felt that LINQ to SQL reduced developer knowledge of the data model below acceptable levels, provided a nearly unnecessary level of abstraction, and coddled the drag-and-drop Mort crowd.
Some of that may still be true, but when building a quick system like one project I've been working on the past three or four weeks and another the past five days, LINQ to SQL, in my mind, gives .NET the feel of something more dynamic like PHP or Ruby. This reduces development pain on short projects, mockups/prototypes or architectural spikes IMMENSELY. You can be much more agile in evolving your data model and business logic without paying the price of a brittle, static data tier. Yes, I found myself dragging-and-dropping tables, over and over again -- and I felt almost no shame in doing so.
According to Microsoft, LINQ takes measures against SQL injection -- one of the topmost reasons for using stored procedures. One of the other big reasons for SQL Server stored procs is performance of course. On small datasets, performance is adequate. I haven't had a chance to test on large datasets yet, or under scale conditions. There are steps you can take to improve performance I plan on exploring.
But of course you can still use stored procedures with LINQ, dragging-and-dropping again, and calling them like a standard .NET method via the wrapper LINQ and the Entity Framework create.
I'm not sure you lose anything with LINQ, and you certainly gain quite a bit in a number of scenarios. I suspect I will be using it quite frequently in the future.
