Hi, Kevin,


That's going to be true for relatively simple queries, but not so for more complicated ones. For instance, if you write a LINQ query to retrieve muliple calculated aggregations from the same parent table, LINQ generates some pretty inefficient SQL code (I've even seen it generate multiple correlated subqueries for the same parent table).


Agreed. But I also think that there is much room for improvement in this area, both until Visual Studio 2008 final release and in the future. Besides that, by using declarative queries into the language we eventually would benefit ourselves from the evolution of the database versions and its features in the case Linq to Sql suppliers evolve the versions of its providers hand in hand with the underlying version of its database engine. In this case, the next version of Linq to Sql would be able to generate code compatible with Sql Server 2008, for example, and we, as developers, would benefit ourselves from this by simply swithing a configuration key - hopefully :)


Somewhere in a prior post, someone stated that since this is "new" technology, it's going to feel like a step backwards. I see it differently - SQL Analysis Services and Reporting Services contain builders to create MDX queries that aren't what I would call efficient. "Builders" in general are functional but not necessarily the most efficient. I think the best way to get the most efficient SQL is to write SQL. ;)


I see builders as translators of the developer's intention at the time he or she uses it. There is no doubt about the eficiency we can reach by writing SQL code by hand, but with Linq to SQL developers are going to have a further level of abstraction before getting the definitive SQL code being generated. I believe that application developers should, most of the time, work on this level of abstraction, since its data repository would not interfere on the application business logic. DDD (Domain Driven Design) proponents (me included) would argue that queries should be treated as abstractions into the application, not as a concrete constructions directed to a specific type of data repository - and here we are talking not only about relational database types, such as SQL Server, but also about data repositories from different natures, such as in-memory, data files repositories and many others.

I understand that this discussion transcends the goal of this thread, but at the same time, this is one of the reasons I think the use of Linq to Sql would be justified as benefical.


On the other hand, I really like Linq to XML, Linq to DataSets (for strongly-typed datasets), and Linq to Objects - those, along with the new language features like lambdas and object initializers, are the cool new features, In my opinion.


Yes! This is the whole point of my original reply. Linq is mostly sintatic sugar, but the language features that make it possible, such as the ones you enumerated and the "Deferred Execution" arquitecture that enables the benefits of Linq to Sql server I talked about above are, in my humble opinion, the real stars of this show.

Best Regards,