Practical .NET

Not Using LINQ Yet? Here's a Few Reasons Why.

Peter Vogel introduces a new column on application development in the real world, and begins by advocating for Language Integrated Query.

Microsoft and magazines like this one have been telling you to adopt LINQ and Entity Framework for what seems like years. The main reason that you haven't done so is, probably, because you're smart. Smart developers build up a body of what I call "programmer lore" -- all the knowledge that you accumulate while you build applications in a particular technology. This includes all the standard solutions you keep in your mental toolbox, the generalized code you use in multiple applications, the cut-and-paste code you move from one program to another, and more. Programmer lore is knowing what the compiler's error messages really mean.

When it comes to data access, you've probably built up a working knowledge of SQL -- you can pretty much get SQL to do what you need. You've probably assembled a personal toolkit with some combination of writing raw SQL, a graphical tool for building SQL and ADO.NET. Your fingers can probably automatically type out the five or eight lines of code to create and open a connection, define a command object, call the ExecReader method and loop through the retrieved records.

And you know that you'll need to learn a bunch of new stuff to really use LINQ. During that period your productivity will be reduced, but your deadlines won't change. Finally, there are surely things you'll want to do in LINQ that, currently, your fingers won't type out automatically.

I'm here to help. It's time to give up ADO.NET and SQL and commit to the potent combination of LINQ and Entity Framework. Instead of writing all that ADO.NET code, line by painful line, you'll declare what you want with LINQ, and LINQ/Entity Framework will write the code for you.

The code that's generated by the LINQ/Entity Framework combination is, effectively, code written by the people who designed .NET and ADO.NET. I don't know if these people are smarter than me or you (though I have my suspicions), but they do know a great deal more about how those underlying technologies work. Trust me, you want their code.

Check out my Practical .NET column, Why You Really Should Be Using LINQ, for more on this compelling data access technology.

About the Author

Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.

comments powered by Disqus

Featured

  • Kubernetes for Developers

    Microsoft's Dan Wahlin previews his introductory "Kubernetes for Developers" session at Visual Studio Live! San Diego 2026, explaining how developers can get past the Kubernetes learning curve by starting locally, mastering Pods first, and using Services to make containerized applications reliably accessible.

  • VS Code Keeps Eye on Costs in v1.126 Update

    Visual Studio Code 1.126 adds session-level Copilot cost information, continuing Microsoft's recent focus on helping developers monitor and manage usage-based GitHub Copilot billing.

  • Open VSX 1.0.0 Puts Focus on Open Extension Registry for VS Code Ecosystem

    Eclipse Open VSX has reached 1.0.0, highlighting its role as a vendor-neutral registry for VS Code-compatible extensions.

  • Infragistics Puts MCP Toolchain at Center of Ultimate 26.1

    Infragistics Ultimate 26.1 introduces the Ignite UI Enterprise MCP toolchain for AI-assisted app development across Angular, React, Web Components and Blazor.

Subscribe on YouTube