From the course: .NET Essentials: Working with LINQ

Why build a query engine in a programming language? - .NET Tutorial

From the course: .NET Essentials: Working with LINQ

Start my 1-month free trial Buy for my team

Why build a query engine in a programming language?

“

- [Instructor] Microsoft spent years building LINQ into the .NET Framework. They also modified their major programming languages to make it easy to query data from within the C-Sharp, Visual Basic and other .NET languages. The name itself reflects that type language integration, language integrated query. That investment paid off. LINQ was released in 2007, and is used by .NET programmers everywhere, every day. Still, it's good to step back and ask ourselves, why have a query language in a programming language? I'll address that question in this video. To be clear, LINQ has been around for a long time. You may not need an answer or explanation about this question. If so, and you just want to look at the LINQ code, then jumped to the next video, otherwise let's continue. Programmers love to code. So it seems likely that providing a way for programmers to write queries directly in their favorite language is a bonus. Since it's language based, you get the goodness of strong typing and you get help from the code IDEs like Visual Studio. Another benefit is query language consistency, regardless of what data source we need to query. What kind of data do you use in your applications? If your application is like most modern apps, your data is not limited to databases. It's a given that all programmers work with many kinds of data sources. Here's a sampling of some common .NET data sources. We've got framework specific sources like arrays, collections and dictionaries. We work with relational and NoSQL databases. We work with data abstractions, like object relational mapper frameworks, and .NET specific data classes. And we wrap our data in markup languages, for example, XML and JSON. Before LINQ was released .NET programmers had to work with each set of data with different query techniques. For the arrays and collections, we'd use the for or for each loops. Relational databases required their own special tools like structured query language, also known as SQL, and stored procedures. .NET includes a lot of data specific classes like the DataSet, DataTable, and other data related classes. Once again, programmers had to learn the correct techniques to work with those classes. For XML and other markup languages, we would use a parser and work with the-tree nodes in the resulting graph. This disparity motivated the LINQ team to build a universal query system. With LINQ, your query code is the same, independent from the underlying source. This is one of the powerful features of LINQ, consistency of query syntax. You don't have to understand how individual LINQ providers work. While it's true the majority of the query syntax is the same, each provider has some nuances to grasp. Here are the LINQ providers for .NET. First on this list is LINQ to objects. That is the focus of this course. Basically this is a way to query and manipulate data in collections. LINQ to XML is a LINQ enabled in-memory XML programming interface. This exists so that you can query and manipulate the data in an XML DOM. I'll cover this in another LinkedIn course. There are three LINQ providers that work with database data. This is a fascinating part of .NET that I'll cover in a database specific LinkedIn learning course. Each of these areas, LINQ to objects, LINQ to XML and the database LINQ areas are built upon a provider model. This is extensible, so anyone can build a provider for a different type of data source. I've been using LINQ since it was released. In most situations, I find it simplifies my code and makes it more understandable. Let's review a few of its benefits. LINQ queries are composable. You can combine them in multiple ways and one query can be used as the building block for an additional query. That composable feature of LINQ makes it easy to break complex problems into a series of short, comprehensible queries that are easy to debug. Speaking of debugging, the integration of queries into the .NET languages makes it easy for you to step through your queries with the integrated debugger. Finally, by using query expressions, it is easier to understand the intent of the query code. Here's an example of query programming before LINQ. The goal is to take the source collection and filter it, sort it and output to a new list. For this example, we have a list of web colors, which is a custom class. Look at line 31, that's where we populate the list with a call to CourseLib dot ColorSource dot GetColors. We want to filter the list based on its HSL dot Saturation value, and sort it by its ColorName property. We have to use a for each loop to filter the list. That's shown on lines 33 through 39. On line 40, we call the sort method and use a comparison lambda. This example code is fairly readable, but it would get harder to understand when you add more clauses to the query. Now look at this LINQ query expression. It's more compact, and it's easier to understand the intent of the query. Line 46 replaces the for loop shown on the previous slide, and line 45 replaces the call to the sort method. What do you think? Is this easier to read and comprehend? To sum up what we've seen, LINQ is a functional based system for building query expressions in the .NET programming languages.

Contents