Cut Development Time: Use LINQ


When Microsoft employees talk about LINQ publicly, we haven’t tended to emphasize how much time you can save by using it. This is perhaps because we don’t want LINQ to be labeled as simply another RAD tool designed to save time. Nevertheless, it is becoming clear to me that shorter development cycles may be one of the first major benefits of LINQ to be widely recognized by the community.

I first began to notice the importance of this issue a month or two ago at a customer visit in San Diego. I asked if anyone at the company we were visiting was using LINQ. Only one person raised their hand. I asked him about his experience, and one of the first things he said was that he was able to get a lot of work done very quickly. DBA’s at our session immediately chimed in with the usual objections about moving queries out of the database and into a codebase, and from there the discussion wandered off on a predictable tangent. Yet since then I’ve remembered that user’s experience with rapid development, and the obvious enthusiasm he had for his subject.

The subject came up again during other stops in Southern California. The same point was raised by several developers I spoke with at Tech Ed, and again in a recent MSDN article by Dr. James McCaffrey. He said that LINQ reduced the time it took him to write test procedures by 50 percent. He added that LINQ to SQL made his test code "much shorter, much cleaner, and therefore easier to create, modify, and maintain."

Of course, LINQ has many other benefits. It provides a single unified query language that can be used across multiple data sources including SQL and XML. It is integrated into the C# language, allowing you to harness the power of .NET and the Visual Studio IDE when writing queries. It is both transformative and composable, allowing you to combine queries from multiple data sources in myriad ways. It uses a succinct and elegant declarative style of programming, and it is extensible so that you can run LINQ queries against any arbitrary data source. Yet sometimes it is simplest just to think of LINQ as a fast, elegant way to get a lot of work done quickly. In this day and age when we are all struggling to work with huge amounts of data, and to complete complex tasks in a short period of time, anything that will simplify our lives is welcome. LINQ is one of those things that just makes it easier to get work done quickly.

kick it on DotNetKicks.com

Comments (18)

  1. Joe says:

    I’d love to use LINQ on more of our production critical stack (web based application and services) … but it would then cause blocking threads in IIS.

    Is there a way to execute LINQ in an APM?

  2. Philip says:

    I love LINQ. I have found so many uses for it. I have found that it not only reduces code and development time, I can actually do MORE with it than I could before. I especially like being able to use Lambda expressions in my LINQ queries.

  3. Anders Borum says:

    In of the first chapters in Jon Skeets book "C# In Depth", there are some great examples illustrating the differences between C# 1.0, 2.0 and 3.0 for common tasks (e.g. selecting and sorting from a list).

    It’s quite clear from the examples that the versio in C# 3.0 is the shortest code-wise, and also the easiest to read and maintain.

    Reading this blog entry, it reminded of these examples and the overall benefits you gain by using LINQ. It’s already changed the way we think about (and write) code.

    Some of the clients we work for in our company are not adopting .NET 3.5 (usually no valid reason is given). It’s a pity and a missed oppertunity to provide developers with the most current and productive development environment.

    LINQ provides a clear and elegant solution to many common tasks that previously required more a more intricate understanding of the framework – something trainees or less skilled developers might not have (with loss of productivity as a result).

  4. ccalvert says:

    Joe,

    Can you tell me a little more about the problems you are having with LINQ and IIS. I’m not familiar with this issue.

    – Charlie

  5. Richard says:

    This post (http://blogs.msdn.com/dinesh.kulkarni/archive/2007/10/15/linq-to-sql-what-is-not-in-rtm-v1.aspx) lists a couple of the shortcomings of LINQ to SQL and the one that stands out the most for me is this one:

    2) Out-of-the-box multi-tier story. Yes, we do have good Attach() APIs but we don’t yet have a simple roundtripping and change tracking on the client.

    It seems to me that LINQ is better suited to RAD Winforms development where you can maintain state, unlike in a ASP.NET application.

  6. Malek Badi says:

    So is LINQ based DB applications development the way to go ???

    What about multi-tier ( Data Access / Business Logic) layers ?? Can these be implemented by inside the dbml file ( which creates the entities for LINQ Data context ) ???

    What is the best practice for LINQed Applications ??? ( ie LINQ based DB Apps)

  7. ton says:

    <quote>

    It seems to me that LINQ is better suited to RAD Winforms development where you can maintain state, unlike in a ASP.NET application.

    </quote>

    @Richard I’m confused by your ending statement. State can be maintained in ASP.NET applications as well thru cookies and session ids. If these techniques are used then you should be able to compensate and LINQ will still be effective I believe, if not being able to maintain state is your problem that is.  

  8. ccalvert says:

    LINQ is still evolving, and some of the short comings mentioned here should be addressed in future versions, though I have not seen final announcements on issues like our multi-tier story. So we will have to wait — for now. It is important to remember, however, that LINQ is about more than database development. There are other data sources, such as LINQ to XML and LINQ to Objects, and third parties are adding more all the time. Finally, the question about Best Practices is a very good one. If you search on the web you will find some information, but more needs to be done in this area. Perhaps the ball is in my court on that one.

    – Charlie

  9. AJ.NET says:

    Hi,

    it seems to me that LINQ is all too often confused(?)/reduced to(?) LINQ to SQL. The later one may come in handy in certain situations but it definitely has its drawbacks.

    However I have yet to find notable drawbacks in LINQ. I have been using LINQ (to Objects) in plain code (business code if you like, as opposed to database access) with great results in terms of reducing the number of LOC, as well as improving readability.

    AJ.NET

  10. Richard says:

    <quote>

    Richard I’m confused by your ending statement. State can be maintained in ASP.NET applications as well thru cookies and session ids. If these techniques are used then you should be able to compensate and LINQ will still be effective I believe, if not being able to maintain state is your problem that is.

    </quote>

    Sorry I was unclear but what I was talking about is that you can’t use the same LINQ objects between requests in ASP.NET. So as I understand it, in a Winforms app, they could possibly be set as a datasource for a grid and be updated directly by the grid. Because those objects hang around. once the changes are made, you just call save changes on the datacontext and your db is updated. Not so in an ASP.NET app as the objects have done a serialization/deserialization round trip and  have lost the context (can’t remember the specifics) and can’t be reattached.

    While I like LINQ to Objects and the LINQ syntax in general, I’m a bit hesitant about totally giving into the abstraction. I’m just not sure what it’s doing under the covers to get to the result. I just remind myself about premature optimization, move on and swear I’ll profile if it’s slow :P.

  11. >> "It uses a succinct and elegant declarative style of programming, and it is extensible so that you can run LINQ queries against any arbitrary data source."

    Yes, this is your product.  But I take heed with that statement.  I don’t think some anecdotal evidence from any MSDN author warrants calling backwards SQL succinct.  Maybe some think it is.  I’ve not met them.  But, "elegant declarative style"?  Declarative is fun to the WPF folks, I know, but it’s not the portent change that LINQ could have been either.  Elegant.  I’m sorry, I make a point to to sound like a flamer, but that is just egregious.

  12. Mahesh Vikraman says:

    I have migrated a website app from dot net 2.0 to 3.5. Now able to use to LINQ as it doesnot compile and shows syntax errors(invalid expression).

    I have set the taget framework to 3.5 and all also checked all references.

    Haven’t got any clue what causes this?

  13. Michael Bird says:

    I love LINQ for usage on objects, however I have 2 issues with it overall.

    1. It keeps being touted as a single query langauage across all your data sources. I  challenge you to show me someone who has only used LINQ on objects and have them write a LINQ to XML query without a lot of research on how to do it. Yes, the keywords are the same, but it’s probably about as similar as C# is to Java. I think the ball was dropped somewhere in working out the LINQ to XML story.

    2. While LINQ to SQL is nice, I still worry about the seperation of data from code (same issue with the Entity framework). We seperate our layer, making them more diconnected using contracts and interfaces and that is the best practice. I always did the same with the DB by using my stored procedures as my contract. The implementation of the procedures could change, even the table schema could change and my code wouldn’t know or care. This allowed my production DBAs to do their job of optimizing to reduce locks and speed transactions. Along come LINQ and the Entity framework and it’s now ok to tie my code to the underlying DB schema? I don’t think so. I hope that in the desire to use what’s new, people don’t forget scalability and loose coupling.

  14. Announcing a new Optimizing Linq Provider The Linq to Financial Markets provider An easier way to consume

  15. The Linq to Financial Markets provider An easier way to consume, visualize, understand and quantify just about any information you can imagine from the world of global financial services. * Real-Time stock quotes to Complex Analytics of Multi-Asset Class

  16. Hitesh says:

    I loved to read topic of LINQ by you..

  17. Joel May says:

    Here’s a quote from "Programming ASP.NET 3.5" by Dino Esposito:

    One thing should be said up front and kept in mind: Linq-to-SQL is not a tool to build your middle tier. Don’t be fooled by the fact it uses objects. It should be seen, instead, as a powerful tool to build a data access layer using objects and a high-level query syntax rather than using result sets and T-SQL statements. In other words, Linq-to-SQL is used to access the database but not to entirely replace the functionality of a complete data access layer.

    —-

    I don’t understand this.   He seems to be saying that we should not use it for serious projects or any heavy lifting.  Could you please comment?

    Thanks.