Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Showing some support for LINQ to SQL

Posted by Ian Cooper on July 2, 2008

While I have finished my series on LINQ to SQL I wanted to talk about some of the reaction. In his summary post of 30 June Roger Jennings mentions his concerns that because the SQL Server Data Programmability group, who are bringing us Entity Framework v1, now owns LINQ to SQL we will not see the kind of development I asked for in my last post of my Architecting LINQ to SQL series. Indeed Matt Warren’s comment in this post, that the provider model for LINQ to SQL was disabled before release is troubling for what it implies about internal politics over data access strategies in Redmond and might confirm concerns I had a long time ago.  Looking at the the Data Platform team’s blogs and site, LINQ to SQL seems almost forgotten.

I would like to see MS give this product the support it deserves. I would like to see a commitment from the Data Platform team to stop its focus on talking LINQ to SQL down as a RAD tool and tallking up its advantages for use in the OO approaches to software development. For example  I would like to see the Data Platform team talking about LINQ to SQL’s support for POCO strategies, lazy loading, etc. and pointing out to customers who request those features. There needs to be more acknowledgement that if you want them you should consider LINQ to SQL. Right now their only response is to repeat that those features will be in Version 2 of the EF. Well, an MS ORM supports those features today, you should point that out to your customers, and give advice on how to achieve it. As of now, in my opinion, LINQ to SQL is their best development tool for OO an approach to development and they need to reflect its strengths in the advice they give, not just focus on its weaknesses when compared to EF. 

Martin Fowler posted some time ago about different schools of software development.
Perhaps one solution for the conflict over the future of these tools is
for MS to accept that it has (at least) two audiences and build a
product for the OO folks and one for the data-first folks. In that case
LINQ to SQL would be a better start for the OO folks because it already
contains so much of what they need, it may represent a better starting
point for supporting them.

People feel sorry for the Entity Framework team for the criticism in the open letter. For my part I feel sympathy for the LINQ to SQL team, who fell foul of product strategy decisions with ObjectSpaces and seem to have done so again.
Considering how well they understood the OO approaches we wanted,
unlike the EF team, the team are unsung for their efforts. The
Alt.Net community in particular should give them wider support for
having, unlike the Entity Framework team, recognized the needs of those
developers taking an OO approach to development. it does not give us everything, but credit where it is due.

Today, while I would not recommend using the Entity Framework I would recommend looking at LINQ to SQL. Everything needs evaluation for your own needs, but unlike EF, LINQ to SQL is a better contender for OO approaches today.

Sasha points out when looking at how LINQ to SQL is suprising people who had been misinformed as to what if offered and how we should use it, the noise in the blogsphere from Entity Framework supporters seems to have drowned out the value of LINQ to SQL as an ORM. Indeed I believe the Data Team’s own pitching of LINQ to SQL as a RAD tool is an underestimates the product.

As a community, as people begin to realize the suprising power of LINQ to SQL, I would like to see us dispel many of the myths that seem to have grown up around that product. I would like to see us put pressure on the Data Platform team to provide the support for LINQ to SQL that we want going forward. Community reaction is everything and if the LINQ to SQL community remains silent in the face of the more vocal, but probably less numerous, EF community, we won’t get the product we deserve.

About Ian Cooper

Ian Cooper has over 18 years of experience delivering Microsoft platform solutions in government, healthcare, and finance. During that time he has worked for the DTi, Reuters, Sungard, Misys and Beazley delivering everything from bespoke enterpise solutions to 'shrink-wrapped' products to thousands of customers. Ian is a passionate exponent of the benefits of OO and Agile. He is test-infected and contagious. When he is not writing C# code he is also the and founder of the London .NET user group. http://www.dnug.org.uk
This entry was posted in LINQ. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Arman

    I work mainly with EF and it’s a nightmare if you try to do some complicated stuff. It’s way more rigid than Linq To SQL. I have a project that I could easily do with Linq To SQL but have to do hours of research to get around the EF limitations. And WHY? Linq To SQL is one of the best MS technologies they ever had. What is wrong with MS folks?

  • http://www.zakinafs.co.uk Muzammil
  • Shred

    Jiang,

    I am not sure you know the full potential of L2S based on your comment. L2S has supurb support for stored procs. In typed datasets, you have to either write a seperate stored proc for each type of join, or join in C#. In L2S, based on what your query is, the join is done using T-SQL.

  • Iain Smallwood

    I could not disagree with Jiang more. Typed datasets enforce a woeful syntax, high maintenance and a bloated way of working cf L2S.

    Yes if you are working with legacy stuff L2S may well not be the way to go – EF will probably work better for you with a widely distributed data scenario too. However for a standard blue sky web type project it is perfect. You can write T-SQL as needed or use the provided facilities for simple cases – which make up 90% of most projects. I have implemented whole projects without bothering with more than one or two procs – this seriously cuts maintenance.

  • JohnP

    I agree with Jiang. But I admit I’m not an uber expert. Maybe that’s why I don’t get the Linq To SQL advantages over TableAdapters when it comes to accessing a MS SQL server db.
    If I’m not afraid of T-SQL, and I’m committed to MS SQL Server, why would it be more efficient to have a framework translate linq code into T-SQL? Ok, Linq is cool. But I must be missing something here. Using stored procs and hand-tuning T-SQL statements should generally be more scalable and efficient, with fewer surprises than hidden in autogenerated T-SQL. Database portability is nice, but how often is that a critical issue? Does Linq have provisions to fine tune queries, avoiding potential deadlocks and query slowness? Isn’t this the truly critical data access issue? Why learn yet another data-access language? Or maybe I’m not up to date on the bleeding edge?

    There are so many dot.net data access options now (straight ado.net, dataset/data-adapters, tableadapters, Linq To SQL, Linq to Entities, ORM, nhibernate, etc… ) and it’s very confusing. Which are planned to move forward with internal performance optimizations? And it is hard to find compendia of best practices. I like the concept of an Entity Framework, but I worry about performance & scalability.

    Actually what I would prefer is a reliable, thin database layer that can generate typed data objects classes from a database model, where it would be easy to refresh changes, and where these data object classes can be easily serialized into JSON & XML. (Datasets & tableadapters are close efforts.) Microsoft has done alot of good work, but an emphasis on simplicity, speed & elegance is preferred.

    I respect the smartness of the devs at Microsoft, but I really need some more explaination about implementation best practices.
    For those with a conservative mindset, preferring safer approaches to projects, over nifty-ness and bleeding edge fun, I think adoption hesitation may be a common response because of a surfeit of information about the long term consequences of choosing one data access strategy, and the uncharted nature of these new technologies when it comes to maintainability and scalability.

  • slude

    I work for a company that has recently been making a push to develop as much as possible using the 3.5 framework. As a result recently I’ve been working a fair bit with Linq To SQL. I’ve written quite a lot of T-SQL code and I honestly don’t understand jiang’s comment that L2S somehow has more convoluted syntax than T-SQL. I’ve found it to be pretty straightforward and L2S queries are far more readable than straight T-SQL. There are times when you just have to write a stored proc because T-SQL gives you control over how the query is executed but in terms of usability and readability L2S is much quicker to learn than trying to muddle through T-SQL your first time.

  • jiang

    Linq is great for XML, Objects etc, but Linq to SQL is so limited that it’s almost useless working with existing databases. I found typed datasets with tableadapter worked much better, especially great support for stored procedures. Linq to SQL makes tasks that can easily be performed with T-SQL convoluted and make a competent T-SQL programmer want to jump out of the window for those convoluted syntax. T-SQL has been the mainstay of database programming for so many years and it’s getting better and better. Linq to SQL is appealing to developers who can’t write decent T-SQL. Face it, what is going to stay longer, the database or the application? In any organization, the applications are the first to be thrown away when new languages and tools come to the horizon. It was VB before C#, then probably one day it will be F#. But database is still there, stored procedures are still there. So for all practical purposes, please respect the business you are working for; respect that data is the life blood of an organization. So far, nothing can beat typed datasets and tableadapter in terms of RAD or else in data central application. Chasing fancy technology for the sake of technology is dangerous.

  • http://www.techavalanche.blogspot.com/ Simon Segal

    Find a Linq to SQL bumper sticker showing our support here http://www.simonsegal.net/blog/2008/07/30/how-to-show-support-for-linq-to-sql/

  • Ian Cooper

    @David

    Classically ORM tools tend to find life harder with legacy Dbs, because the structure may not be amenable to mapping. Tools like WORM have similar limitations. For sure some ORMs come with more support for legacy scenarios, such as NHibernate, but it does not diminish the viability of LINQ, particularly in domain-first scenarios (where by implication there is no Db).

    However, LINQ to SQL is an ORM by the usual definition of that tool. I’m not sure that your loader/mapper distinction is useful to the more general debate because it seems to be a personal definition.

    It’s non-suitability for legacy DB scenarios does not validate your argument that it is only a RAD tool.

    LINQ to SQL does come with some useful support around SQL and stored procedures for helping with some legacy Dbs though, if you want to go down this route

  • http://www.commongenius.com David Nelson

    As I implied but apparently didn’t state explicitly in my comment, I am not building the database. I am writing applications to work with existing databases. So I need much more than a loader, I need a mapper, and LINQ to SQL just doesn’t fit the bill.

  • John Rusk

    If you are building the database for the system concerned, then a “loader” is arguably all you need – and probably what you _should_ be using, I’d suggest, since if you control both the app and the DB, it makes sense to make the “mapping” as direct as possible. (Support for more types of inheritance mapping would still be helpful, in future releases of LINQ to SQL )

  • http://www.commongenius.com David Nelson

    Unfortunately, after using LINQ for several months both through the RAD designer and using POCOs, I can still only recommend LINQ to SQL as a RAD tool for limited scenarios. The concept is great, but the implementation is lacking in too many key areas to be useful at the enterprise level. In particular, the lack of support for complex and/or legacy relational database structures makes using LINQ with any existing database in my organization a non-starter. This is unfortunate, as I would love to start using LINQ to SQL in my applications. But I need something with richer ORM capabilities. At this point I can only call LINQ to SQL a “loader”, not a “mapper”.

  • http://dotnet.agilekiwi.com John Rusk

    Well said. I too am happy with LINQ to SQL. It’s not perfect, but I’m glad to be using it. With relatively modest additional investment (compared to it’s initial development) Microsoft could fix its weak spots in a future release and end up with a very good ORM suitable for many projects.

    It’s unfortunate that Microsoft have emphasised the visual designer to the point that it is percieved as a limited RAD tool.

    By the way, after some delay, I’m back working on some helper classes to give a richer “designer free” coding experience. Basically to support lazy loading and bi-directional relationships in hand-written classes. Should have something released within a few weeks.

  • Ian Cooper

    @Bill

    >perf and quality of generated SQL
    Is an area of importance, but less what I am looking at than the development approaches it supports. I am sure someone out there has looked at the performance differences in detail by now. But performance is not the sole factor in choosing an ORM.

  • Bill Pierce

    Great post but it would be more in line with your other posts if you could compare Linq to Sql and EF. I would be interested in seeing perf and quality of generated SQL compared instead of lame features that are touted on ADO.NET blog.

    In my book EDM is a big negative. The other bizarre features I don’t even care about but have to pay for in size, complexity etc.

  • Dan Andersen

    Just use nhibernate!

    Entity Framework is unworkable bloatware that wants to do everything but does everything badly. LINQ to SQL was small and focused but is incomplete without providers and some way to handle changes to database schema. Now it is being abandoned. Whatever Damien might say here, I hear the opposite from the official party line. Nothing to point to in SP1 and not even any plans for V2 that I have heard of!

    On the other hand, I am impressed with nhibernate. It also allows me to use hibernate on other platforms. I will take it over Entity Framework anyday. Nice try with LINQ to SQL but sorry, I am not going for a dead end.

  • Ian Cooper

    @Simon

    Sure let’s have bumper stickers and T-Shirts to wear at conferences 😉

  • http://www.sidarok.com Sidar Ok

    Excellent post, surely points out the biased opinions even without using linq to sql. Data Team seems to promote EF heavily (http://blogs.msdn.com/dsimmons/archive/2008/05/17/why-use-the-entity-framework.aspx) and seeming ready to face very accurate and tough challenges about the limitations of it, but they don’t promote what they have, that’s insane.

    Also some additional points to POCO support:

    – Linq to SQL is a complete product. EF is still beta.
    – Linq to SQL doesnt have EDM nightmare.
    – Poco Change Tracking is built in

    Of course it has flaws too (http://www.sidarok.com/web/blog/content/2008/06/04/linq-to-sql-wish-list.html) But they are not as major as EF ones, since PI leaks and shared canonical model will exist in V2 for backward compatibility.

    Thanks again.

  • http://www.simonsegal.net/ Simon Segal

    Ian your series and earlier posts on PI with L2S was terrific and I echo your sentiments LOUDLY here. Recently Greg Young created a bumper sticker with the text “I want Spec #”, hoping that people would promote the idea on their site and help get the message out. I would gladly include such an image on my blog that conveys our wish for L2S to get the attention it deserves. What do you think?

  • Ian Cooper

    @Damien

    Damien, great to see your response. For those who do not know, Damien is a recent hire working on LINQ to SQL. Damien, if I can help in any way with promoting LINQ to SQL let me know.

    Great to see your confirmation of LINQ to SQL’s future

  • http://damieng.com Damien Guard

    @mike: LINQ to SQL is not being dropped.

    [)amien

  • http://www.dimebrain.com Daniel

    For my purposes L2S is a great, lightweight solution for persistence and I find it fits snugly with WCF and Silverlight in layered web applications. What I would love to see, of course, is support for the community to write providers for alternative databases like MySQL. This would make it a needed addition to a RAD toolset that is budget-friendly for startups.

  • Ian Cooper

    @Mike

    Like I say, I hope that is not true, and that the Data team will respond to my challenge to support LINQ to SQL and promote its strengths in domain-first approaches over the next couple of years.

  • Ian Cooper

    @Michael

    Agreed that is why we need to re-educate folks as to the positives in LINQ to SQL. We need to clarify a really murky set of messages. That was one of the motivations behind my series of posts in the first place.

  • http://mike.griffin@entityspaces.net Mike Griffin

    LINQ to SQL will be dropped because Microosft wants everyone to use ADO EF and not be able to roll their own archtiectures, that is the real motiviation here.

  • Michael Wagg

    I definitely agree with this. I’m currently working on a project using LinqToSql and I seem to be spending a lot of time convincing some of the doubters that LinqToSql is a serious tool rather than just a fancy RAD toy. The big problem is what I’m saying doesn’t match what Microsoft is saying and what the 5 minute power point on the web show.

  • http://alan.sheats@bredband.net Alan Sheats

    I couldn’t agree with you more. Your Architecting series has been one of the eye openers for me in appreciating what LINQ to SQL can and can’t do. What it puts on top of ADO.NET to leverage LINQ and C# 3.0 is just enough and exactly what is needed for OO design. Please get everyone you can to influence the folks in Redmond to keep LINQ to SQL alive as an independent product.

  • http://colinjack.blogspot.com Colin Jack

    Superb stuff and has opened my eyes a bit, I’ve only dabbled with LINQ to SQL but I was reasonably impressed and you could have a point about it being a reasonable alternative to EF.

    I’m still not clear on what EF is for though, I thought I understood some of what it aimed to provide but now I’m not clear.