LINQ To SQL: More Useful Than You’d Think

July 1, 2008

no comments

Concurrently with the finalization of the initial LINQ release bits, community previews of complementary frameworks such as Entity Framework (a.k.a. LINQ to Entities) and Data Services have already been released.  From my experience, this contributed to a great confusion and a mismatch of expectations, especially with regard to LINQ to SQL.

Is LINQ useful at all without these additional frameworks?  Can we develop multi-tier applications with LINQ, or is it just a demo technology for WinForms binding and some additional syntactic sugar for accessing objects and XML?  Is LINQ to SQL customizable enough and flexible enough to suit a wide range of database representations?

Apparently I’m not the only one to bring this subject up.  Comparisons between various ORM frameworks, and comparisons between LINQ to SQL and Entity Framework abound.  The important differences have been summarized before by the Data Programmability team at Microsoft.  My feeling is that for a significant majority of all applications, only the following Entity Framework features offer any tangible advantage:

The ability to query relational stores other than Microsoft SQL Server

Can be addressed by implementing a LINQ provider for a specific relational store.  This is actually relevant for LINQ to SQL as well, so the differentiation between the two products is unclear to me.  One way or another, alternative LINQ providers are already under way.

A full textual query language not limited to LINQ’s language support

While useful for dynamic query construction, the applicability of this requirement for most projects is questionable.  When the queries are not dynamic but complex enough to warrant representation as a string and not a native LINQ statement, a stored procedure or a table-valued function can be used to augment the language syntax.

Advanced mapping facilities, such as mapping a single class to multiple tables

Most of these features can be simulated using database views, although the cost remains questionable.  On the other hand, the cost of the additional complexity introduced by Entity Framework’s significantly more thorny mapping model can’t be ignored either.

I am not an ORM expert: I’ve used NHibernate in the past, I’ve played around with the Entity Framework and I’m using LINQ to SQL in my projects.  The above notes are my pragmatic view at the framework’s offerings – I might have missed a minute yet crucial feature that is a deal-breaker for some applications.  If that’s the case, please let me know via the comments of the contact form:-)

In the second part of this mini-series, I’ll try to demonstrate a feature or two that have been unfairly neglected (in my opinion) when analyzing the applicability of LINQ to SQL.

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published.

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>