At our Friday community day I got to see a demonstration of MS LINQ by Mike Taulty. Being rather busy on projects I haven't had much time to look at it in any detail but Mike's demo of LINQ was enough to amaze me on how easy it was to use LINQ to do direct SQL query's from a .NET language without the need for worrying about creating a data layer with ADO calls. The power of LINQ to also run against business objects, arrays and XML with a simple query language similar to SQL (but without the double quotes et al) was fascinating.
The LINQ demo raised some interesting questions for me I could just imagine trying to implement it on a project and my DBA looking at me and saying "No way! I control that I make the stored procedures you need to put data in and take it out of SQL not LINQ!". I would then say "Yes but with LINQ you can still make the stored procedures and we will just use that". The DBA would then look at me skeptically "Mmm I'm not convinced.."
The DBA aside there are probably other things that need to be taken into account.
- How will best practices for architecting solutions change? In many best practices we've always been thrown the basic principle of keeping the presentation separate from the business logic and then business logic separate from the data layer and the knee bones connected to the thigh bone etc..
- Will ADO suddenly dissolve into LINQ or will many database providers out there suddenly develop LINQ drivers to make it that much easier for us to slip into this cool technology?
- Will there be a performance hit? Talking to Mike he informs me that Microsoft are attempting to fine tune LINQ so that using it or ADO will be appear almost identical in speed.
I personally can't wait to try it out on a new project!