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.

Comments

• Anonymous
  June 16, 2008
  PingBack from http://www.travel-hilarity.com/travel-airline-tickets/?p=1561

• Anonymous
  June 16, 2008
  The comment has been removed

• Anonymous
  June 16, 2008
  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.

• Anonymous
  June 17, 2008
  The comment has been removed

• Anonymous
  June 17, 2008
  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

• Anonymous
  June 17, 2008
  The comment has been removed

• Anonymous
  June 18, 2008
  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)

• Anonymous
  June 19, 2008
  The comment has been removed

• Anonymous
  June 19, 2008
  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

• Anonymous
  June 20, 2008
  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

• Anonymous
  June 20, 2008
  The comment has been removed

• Anonymous
  June 21, 2008
  The comment has been removed

• Anonymous
  June 22, 2008
  The comment has been removed

• Anonymous
  June 26, 2008
  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.

• Anonymous
  August 22, 2008
  Announcing a new Optimizing Linq Provider The Linq to Financial Markets provider An easier way to consume

• Anonymous
  August 23, 2008
  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

• Anonymous
  September 04, 2008
  I loved to read topic of LINQ by you..

• Anonymous
  September 05, 2008
  The comment has been removed