Software Development

Essential LINQ covers all the basics

Justin James says Essential LINQ is well written and suggests anyone who is still learning about LINQ read it. Check out his complete book review.

 

Over the last couple of years, few technologies have interested me as much as LINQ, and yet, it looked like a black hole to me. I knew LINQ was built on a lot of ideas, including lambdas, extension methods, and type inference (var), all of which had to be added to C# just to support it. And, while I could talk about some of LINQ's benefits, I didn't think it pertained to my work, since I haven't been working on data-driven Web sites lately.

After reading Essential LINQ by Charlie Calvert and Dinesh Kulkarni, I have a totally different view of LINQ. In fact, my first two Code concepts columns, Code concepts: C#'s var keyword and Code concepts: C#'s extension methods, are inspired by the book.

In this review, I'll highlight some things I learned about LINQ, a few of my minor complaints about the book, and who would benefit most from reading it. (Download a sample chapter from the book about the essence of LINQ.)

At a glance

Essential LINQ is fairly limited in scope despite its size (it's a little more than 500 pages). As part of the authors' mission to focus on the essential items, they presuppose nothing other than the reader has a basic knowledge of C# and the .NET Framework. While the information in the book is applicable to VB.NET, VB.NET does have limitations, such as the forced one-line lambdas that make working with LINQ painful in VB.NET. You can expect this to change with the version of VB.NET that will be released in .NET 4.

After providing a great understanding of the ideas behind LINQ, the authors devote an entire chapter to all of the underlying technologies that you need to understand to work with LINQ. This was a welcome change of pace from some books I've read that tried to "fast track" you into learning the main topic, without laying the proper foundation first. In fact, I considered this section of the book to be an excellent primer on many of the new C# 3 language features, which I wanted to learn. The information the authors provided on these topics was so thorough that, in my first LINQ-enabled project, I found myself using many of the ideas outside of LINQ's requirements.

The authors discuss LINQ to Objects first, since it is the least complex of the standard LINQ providers. This section inspired me to write my first LINQ-enabled project. Based on the ideas I learned, I immediately was able to apply LINQ to a wide variety of tasks for which I never knew it could be used. And I rarely needed to consult the book or the .NET documentation, which is one of the strongest endorsements I can give to an educational resource.

Next, the authors proceed into LINQ to SQL and then LINQ to Entities. Some readers may say that the discussion on LINQ to SQL was too long or that not enough time spent on LINQ to Entities, given that Microsoft has given the impression that LINQ to SQL should be phased out in favor of LINQ to Entities. I think it was the right amount of space to give to LINQ to SQL, mainly because the Entity Framework is far too heavy and complex for many projects. In addition, the Entity Framework is very new, and it's expected to change significantly as time goes on, making any in-depth discussion about it prone to obsolescence. That being said, I would have liked to see a little more attention devoted to LINQ to Entities. The authors give plenty of attention to issues such as data concurrency, making CUD database operations, and working with stored procedures.

LINQ to XML is discussed next. Even though this is probably the most complex section (given the complex needs of many developers working with XML), it is still readable. While some of the topics are outside of my experience (I still don't understand why so many developers spend more time "transforming" XML than actually using the information contained in it), I had no trouble understanding what was discussed. If working directly with XML comes into a project spec for me, I feel confident that I will have no problems applying LINQ to the task.

The book concludes with information about LINQ best practices, performance information, details on other LINQ providers, and a summary of LINQ. I feel that much of this section is a bit disposable, particularly the chapter on other LINQ providers; all of the items are pre-version 1 and still rapidly changing, so I didn't feel like the information was pertinent or useful to many developers. However, it was nice to see other possible uses of LINQ.

Summary

Overall, I was absolutely delighted with the extraordinarily well written Essential LINQ. It's one of the few technical books I've read that didn't feel like a chore to read. I set aside a pages quota for myself each day to ensure that I read the book quickly and, in many cases, I read much more than I planned. I dove headfirst into a project using LINQ while in the middle of reading the book, and I had no problems getting real work done with LINQ or the other topics I learned from the book. All of the code samples in the book were appropriate and easy to understand, which is fairly rare in the world of programming books. Also, I carefully looked over each code sample, and I didn't see any mistakes.

I do have a few minor complaints, though. The book has a few unimportant but obvious typos. And, one paragraph was misplaced by about two paragraphs. While I appreciated the "LINQ Everywhere" chapter, I think that discussing so many items that aren't stable probably was not helpful to most readers. Finally, I would have loved to have seen a few chapters devoted to a "LINQ Cookbook" with common "recipes" (say, tokenizing a string, some data validation, parsing a CSV file, etc.).

If you work with .NET (particularly C#) and know nothing or very little about LINQ, I suggest that you read this book at your earliest convenience. Even if you don't think that LINQ will be useful to your work, I'm sure that after reading it, you'll have at least one aha moment. If you already use LINQ, this book may be a little too basic for your needs. Although, because the authors do such a great job of providing critical base knowledge, if you learned LINQ in a "jump right in" mode, you may get real value out of Essential LINQ.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

---------------------------------------------------------------------------------------

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

4 comments
Justin James
Justin James

Are you using LINQ in your work? If so, what do you think of it? If not, why not? Frankly, I was a bit dubious at first, but I am now a complete convert, now that I see that it is for much more than just bypassing the DBA with LINQ to SQL! J.Ja

Tony Hopkinson
Tony Hopkinson

.Net 3.5 okayed. Legacy support for win2k installations.... I have plans though. One of the things I'm keen on is things like 'ad-hoc' (not writing shedloads of code) comparisons between xml documents and or internal list type classes. It's lovely abstraction for things like get me all the nodes in a document that match id with all these in a gerneric list.

Justin James
Justin James

Yeah, that's where I've started going nuts with it. Things like validation, set intersection... basically, using LINQ has removed a ton of loops in my code. All simple stuff, of course, but much less error prone when spelled out like LINQ is (where it will either compile or it won't) vs. imperative where I could have a dumb problem (usually fenceposting) that will hopefully get caught by testing or code review. J.Ja

Tony Hopkinson
Tony Hopkinson

Even piddly stuff like a basic Find delegate of a generic. Write it out in full, do anonymous function, you still have to define each one, then you start overloading them, then there a variations for sorts, nevermind grouping for totals and such. Masses of scaffolding and you've implemented and have to maintain, to produce five or six functions on a aggregate. Not to mention, the more generic your make the implementation the less readable it becomes. I could chop out 40% of our codebase with this stuff. Throw in extensions, which is another beauty.... May be this year.

Editor's Picks