Over the last week I've been revisting LINQ, actually spending some time working with it. In the past I've been wary, critical even, of some of the requirements for using LINQ, but I'm relaxing my stance a little in light of the ADO.NET vNext Entity Data Framework. Together, LINQ and EDF are awesome. My test project, whch is for a conference keynote this week, showns LINQ and EDF allowing me to delete 12 classes and simplify the business logic in a trivial site; for larger scale applications it coud have even more benefits. One of the things that attracts me to this, now that I've had more time to work with it, is that the business logic can be placed in a more natural place; often we end up placing business logic in our database, in stored procedures, because that's where the data is fetched. For things like filtering rowsets this is sensible, filter close to the source to reduce data transfer. But it's still business logic and sometimes doesn't sit easily within the database. With the EDF you have little to do with the database itself; EDF maps entities to underlying tables, providing a rich, strongly typed view of the data. This means that queries, using LINQ, can define the business logic; EDF handles the conversion of this to SQL, so the filtering is still done in the right place, close to the data, but it is also defined in the right place, in the business layer.
LINQ is slightly ahead of EDF in completeness, with a fair number of LINQ constructs not yet implemented in EDF, but the potential is huge. I now can't wait for the next CTP to see how it progresses.
[Listening to: Shitloads of Money - Liz Phair - whitechocolatespaceegg]