LINQ to SQL: Does it have much of a future?

Kevin Kline recently posted, wondering about the directions for LINQ.

When people refer to LINQ, they're often referring to "LINQ to SQL" instead.

LINQ as a language enhancement is pretty cool. It provides a way to easy navigate enumerable objects. The only thing that puzzles me is why they picked SQL-like syntax for this instead of something more appropriate for objects.

On the other hand, LINQ to SQL I can't get excited about. The main issues are that it's tied to SQL Server and only gives you a one-to-one mapping of tables to objects. That leaves you with either a lousy database design or a lousy object model.

The easiest example is anything that involves many to many relationships. If I have a flights table and a passengers table, I'd typically have a linking table (like flightmanifests) that records which passengers are on which flights. That's good database design but I wouldn't want an object model based directly on those three tables. What I'd want at the object level is a passenger object with a flights collection and a flight object with a passengers collection.

The Entity Framework lets you cope with both the issues mentioned and seems to be more likely to be the direction that Microsoft will keep heading. It also adds some interesting constructs in the ESQL language. However, its generic nature means you need to work with a very constrained set of data types. You lose the rich data types available with SQL Server in the trade off with the ability to write more generic code.

From the database end, LINQ to SQL can generate quite poor TSQL and the way people often use it ends up causing plan cache pollution issues, much the same as anyone using AddWithValue() to add parameters to a SqlParameters collection in ADO.NET would.

Every time I show people the TSQL code generated from some simple LINQ to SQL queries, I see two reactions. People with a developer background usually say "I'm glad I didn't have to write that". People with a database background say "No-one should write that – it's horrible code". And LINQ to Entities generates even more generic code (as you would imagine it needs to when it doesn't even know what database engine it's targeting).

This is usually all justified by increased developer productivity. "As long as it works well enough and it's done quickly, who cares if what's going on under the covers isn't great?" And that's 100% true for small or simple applications. However, the places I see Microsoft pushing this technology is to ISVs and large enterprise clients. These are likely to be the people it's least appropriate for.

The ADO.NET group seems to have adopted LINQ to SQL now but I know they really don't love it and the Entity Framework is what they're interested in. So I can't see LINQ to SQL having much of a future at all. LINQ to Entities is much more likely to stay around.

The other big issue I see in this area is maintenance. Microsoft have made big strides with the Database Edition of Visual Studio Team System but every time I ask questions about what the plans are for allowing it to "see" all the mapping files from these coding technologies, I get very blank stares back. Many DBAs can't make any changes to their databases today because they have a sea of Access applications all over the organisation and they don't know what will break when they change something. Are LINQ to SQL and Entity Framework mapping files going to be the next generation of Access-database-style management issues?

7 thoughts on “LINQ to SQL: Does it have much of a future?”

  1. They are all just an ORM to me and come with the pro\cons of using an ORM. Does LINQ\EF remove any of the usual con's?
    There was a big stink about the future of LINQ to SQL and I believe this post was meant to address it.
    We're making significant investments in the Entity Framework such that as of .NET 4.0 the Entity Framework will be our recommended data access solution for LINQ to relational scenarios.  We are listening to customers regarding LINQ to SQL and will continue to evolve the product based on feedback we receive from the community as well.
    SQL data services access looks like it is EF based too.

  2. @Jason Massie said:
    >They are all just an ORM to me and come with the pro\cons of using an ORM.
    Unfortunately this naive and ridiculously shallow view of L2S/EF is prevalent in the sql community. This is the first ORM of its kind and it's a belittlement to the technology to lump it in with its ORM predecessors. If you're going to pass a judgment at least make the effort to understand what MS is trying to achieve.

  3. Thanks Steve :) That statement was followed by a question that would have been the perfect chance to enlighten me.

  4. It is interesting the thrust of your point is one I commonly hear in working with MSAccess…   The argument for expediency because of mission critical requirement vs using the tool irresponsibly.  
    Anyone who dares to look under the covers and "Understand" the gizzards is bound to be horrified…   I would point you at the vehicle you drive to work, polluting atmosphere and creating greenhouse gases in the manufacture of the fuel,   we would all walk to work if we truly understood what we are doing to the planet…
    But we all drive,  because it is expedient and necessary that we move quickly from one place to another to be effective at what we do. The good thing about the tool is it puts coders into productive mode without waiting on DBA's to dig the data out…  provided you recognise the limitation and consequence of this…  I believe it to be a responsible use of the product,  and that is where I see its major role.  

Leave a Reply

Your email address will not be published. Required fields are marked *