Design of LINQ to SQL – What was I thinking or was I?


A little break from my “LINQ to SQL tips” series of posts. A recent vote of no confidence on a related component orchestrated by community activists reminded me of many questions I have fielded and how the design team approached the design of LINQ to SQL (and also core LINQ APIs and C# language changes for LINQ). Nah, that’s for another day when it is cloudy and raining. Instead, let’s talk about my recent dream. Or rather, a nightmare!


But first turn off your flame throwers, grab a cup of coffee and don’t take this too seriously …


I had this Q&A nightmare about the component I worked on – LINQ to SQL. I am the “expert” providing the non-answers.


Q: How do I use blah pattern with LINQ to SQL (e.g. blah = ActiveRecord if you don’t like abstract concepts)
A: You don’t!


Q: I think I wasn’t sufficiently clear. I stood on one leg and when the phase of the moon was 64% of full, it worked but now that the moon is waxing further, your foo method throws bar exception when I do baz. How do I just get that bit working with LINQ to SQL.
A: You don’t


Q: (By now quite upset) Do you even understand blah?
A: (Forced to be less terse) Yes. We considered blah and decided against it for a set of reasons listed below. That pattern is not consistent with the core design assumptions and recommended usage patterns with LINQ to SQL.


Q: (Now a full-force verdict) I hearby find you guilty of violating the implicit agreement to solve the world hunger problem using blah methodology. Hence, what you produced is useless, evil and must be stopped at once. Any software built using your component will accelerate global warming and cause all glaciers to melt at once. And of course, it will irreparably damage the young and impressionable minds of generations of developers leaving them utterly useless for anything except writing some old fashioned code.
A: Thank you for your interest in LINQ to SQL err blah.


Nightmare aside, (what) were we thinking? Stay tuned for that … 


P.S. 


1. This release includes backward-looking statements intended to qualify for the safe harbor from liability established by the Public Flagellation by Community Act of 2008. These backward-looking statements generally can be identified by phrases such as “did”, “was”, “thought” … and by the absence of “will” “fix” “in future release”.


2. I just wanted to get you objects from the table. I swear. Nothing more than that!


3. Scott B., if you are reading this, peace! I won’t let you drag me on to the stage at another PDC BoF and I won’t fix anything either. I can’t. I don’t drive LINQ to SQL anymore. I just drive righteous developers crazy J


Comments (11)

  1. Keith Farmer says:

    Thanks, Dinesh.. I needed that 🙂

  2. Kevin Daly says:

    Personally I would have said "You don’t, because ActiveRecord is an anti-pattern".

    Then the Rails groupies would’ve lynched me, but what the Hell.

  3. jdobrien says:

    I went to test the Entity Framwork. But when I tried ‘using System.Panacea;’ I got an error.

    That’s it, back to DataSets I go.

  4. Skurmedel says:

    I don’t see the connection between LINQ and ActiveRecord, they are different entities and good at different things.

  5. Dinesh,

    I think it would be valuable for you to have hands-on experience with the advantages of approaches that haven’t made it past Microsoft’s defenses yet so that we would have a shared basis for comparison.

    Presently, I remain the only person in our on-going dialog stretching back to 2004 that has endeavored to understand the implications of both paradigms in question.

    I welcome the opportunity to work with you on an application using contemporary approaches to software development so that we can enrich this conversation with shared understanding.

  6. Scott,

    I hear you. I even regret not pushing testability into L2S DataContext with some sort of IContext so you don’t have to do the clever contortions described in Matt’s blog.

    On my current project, we are experimenting significantly with many of the concepts and I am cautiously optimistic about making them more accessible to the mass developer audience. Specifically design for testability, MVC (VM) and domain object design.

    I would love to get your (and other community influencers’ feedback) for my current project. Once we have a few things worked out to discuss (and well before a beta). BTW, thank you personally for your continued engagement since ObjectSpaces days despite setbacks and shortcomings from our side.

    Thanks all for your continued interest. Stick with us, it is going to get better despite my wacky postings.

    Dinesh

  7. Keith Farmer says:

    FWIW — Adding an IContext for LINQ to SQL wouldn’t be a breaking change, I would think. That said, I haven’t had the need for such a thing.

    I would, however, vote to see Matt’s expression visitor base class added to the BCL and maintained as the Expression types expand.

  8. Dinesh,

    I will likely be on campus during the week of July 7th.

    Would be very rewarding to hang out with you while I’m up there.  I certainly wouldn’t be opposed to an ObjectSpaces reunion either.

    -Scott

  9. Jim Wooley says:

    Dinesh, I greatly appreciated this post. Although I did have a disagreement with some of the design decisions (InsertOnSubmit), I understand the issues and why the decisions were made. I’m glad to see such a great sense of humor (sarcasm? What sarcasm?) in the midst of such a heated debate.

  10. Govind says:

    Dinesh, Please don’t take it personally. I think ORM tool needs to designed by folks who develop and maintain a enterprise code base (or have done it rather than pure theory folks )rather than dishing out API which never makes the door (objectspaces – ?, linq to sql and now linq to entity ).  Let us clear up the smog around the fact whether linq to sql is going to survive the EF onlslaught. It is sign of wisdom to accept the fact that there are alternatives which have been around for quite some time and doing well and supporting them would be sense of sanity. EGO should be the last factor inhibiting the growth and mutual admiration. It is OKAY for API to come out of NON-MS world.

    Heck amazon has become software friendly and is now more known for the EC/AWS than Ms was.  It is good to have competition, but competition for the sake of it is dumb. Look at the proliferation and success of java lite frameworks (spring). We should be kind and accepting of the wisdom which does not originate in Redmond. Apologies if I sound harsh – but I have seen similar attitude towards js frameworks where tightly bound Atlas is thrust down. Unity in IoC/DI world was answer to existing stuff. We need not go the Java – committee way, but at the least support the level headed folks rather than calling them mafia??? (I know I have diverted here )

  11. Sono (con orgoglio) un dipendente Microsoft, una azienda che ha fatto molto nel campo dello sviluppo