There has been a fair argument over the blogosphere about “Why we need eSQL when we have LINQ”? Here is my take on it!
Well, consider these points in favor of eSQL –
1.You have a common paradigm moving forward, all you have really is a new ADO.NET provider, except this one targets the conceptual model. And to run on the conceptual model, you need a new language – eSQL.
2.Could the conceptual model be targeted by LINQ? Sure! Do realize however that LINQ queries are translated into C# expressions. In other words, you cannot conjure up LINQ queries at runtime. In contrast, eSQL is just text.
3.eSQL, over time will probably end up becoming a very sophisticated query engine. In fact, I am guessing that all knowledge that was created during writing the query engine for SQL Server will be reused in writing the engine for eSQL. In other words, all the hard work that the database does for you under the scenes, still works.
On the flip side however, Now there is of course an argument that you could make that one of the biggest advantages of LINQ was to remove runtime errors by introducing compile time checks. And this was indeed and still is one of the most touted features – if the compiler has “visibility” into your query, it can then keep it clean for you. And yes you do loose that with eSQL.
I feel given the positives and negatives of eSQL vs. LINQ, I think both will continue to co-exist, but I feel LINQ's applicability will be more on the lines of ad-hoc queries at the programmer level, and eSQL's applicability will be more on the lines of foundation level queries (stuff that sits closer to the db) that work off of the conceptual EDM. I feel going forward eSQL will continue to have further applications as well. Of course I am just surmising, but this is my general feeling.