Tech News, Tech Resources, Technology Articles, Gadget News, Computer News » LINQ

Improving Performance With LINQ

admin — Thu, 29 Oct 2009 15:58:36 +0000

While the title of this article may seem misleading, you actually can achieve incredible performance gains by updating your web application to use LINQ. This article will dispell some common myths about LINQ and demonstrate how LINQ can practically increase performance. The examples in this article will be using LINQ to SQL, but the principles apply to LINQ to Entities as well.

First of all, it’s important to realize what LINQ is and what it isn’t. LINQ is a language feature you’ll see in Visual Studio 2008 (Visual Studio Orcas) and beyond. It’s not dependant on any particular .NET language as you can use it in C# or VB.NET. LINQ stands for “Language Integrated Query”, but its usage goes beyond language capabilities alone.

It is true that the language speeds up development by allowing you to use a simple query-syntax in C# or VB.NET to query data from a HashTable, XML file or SQL Database. And it’s also true that you can have Visual Studio 2008 write tons of code for you to build classes for your data tables (or even to build SQL tables from your classes). However, this article will demonstrate runtime performance gains you’ll see by using some built in features that come with the language as well.

The benefits we’ll discuss are:

Intelligent query translations (such as faster data pagination).
Redundant query checking to prevent needless data hits.
Redundant update checking to ensure minimal data transfers.

Intelligent Query Translations

One of the built-in benefits of using LINQ is that methods that are deemed “best practice” are used in the underlying technologies. For instance, if you were to use a standard ASP.NET 2.0 SqlDataSource, and you bound that data to a GridView with pagination turned on, you might not realize that you’re transferring your entire data table just to use a few rows at a time in your paginated GridView. This results in some heavy queries, heavy data transfers and often times slow page loads.

The best place to do pagination would be on the SQL server itself. That way you are only transferring the few rows that are desired, saving you much network bandwidth and time. Ultimately, LINQ isn’t doing anything that you couldn’t do yourself, but most developers do not know how to do Pagination In SQL Server 2005, or they may not have time to change all of their queries to do so.

Again, if you take that simple “SqlDataSource” example above, but this time bind two ASP.NET controls to it (let’s say a GridView and a DropDownList), then you’ll be hitting your SQL server twice, and download all that data twice. This brings us to the next performance gain in LINQ.

Redundant Query Checking

Some of the biggest performance gains that I’ve benefited from by switching to LINQ is it’s ability to look at the “context” of your request to determine if it needs to hit the database again. If you’ve already started to use LINQ yourself, but you don’t know what I’m talking about, then you’ll probably have a new appreciation for LINQ in a few minutes.

LINQ uses a “DataContext” object to determine what connection string to use, what objects to map to and other internal things. But you should be careful not to think of the LINQ data context class as you would think of a traditional “SqlConnection”. If you are transitioning from using SqlConnections and SqlCommands you’ll probably code something like this:

// Example of doing your own straight SQL query:
public static IEnumerable GetMyData()
{
using (SqlConnection myConnection = new SqlConnection(myConnectionString))
{
using (SqlCommand myCommand = myConnection.CreateCommand())
{
myCommand.CommandText = “SELECT * FROM dbo.myTable”;

using (SqlDataAdapter myAdapter = new SqlDataAdapter(myCommand))
{
DataTable resultTable = new DataTable();

myAdapter.Fill(resultTable);

return resultTable.Rows;
}
}
}
}

If you translated the above method into LINQ, then your method might look something like this:

// Example of using LINQ to query the “Clients” table:
public static IEnumerable GetMyData()
{
using (MyDataContext myContext = new MyDataContext())
{
return from myRow in myContext.Clients select myRow;
}
}

This at first seems like an acceptable conversion from using a SqlConnection to using LINQ, but you’re missing out on so much (which you’ll see in a minute).

This is pretty much a 1 to 1 switch from writing your own SQL query to writing a query in LINQ. It is noteworthy that it takes a lot less code to query a database. However, these two code blocks will do the same thing, and you won’t gain any performance from calling the LINQ method instead of calling the straight SQL method. Even if you call both of these functions twice in a row, you won’t gain any performance because we are not utilizing the LINQ context correctly.

If we extend the range of our context to last for the entire web request (not just for the life of the function call) then we will begin to see performance increases. Before we examine how to do that, let’s look at this next example that should help explain how the context works. We’ll change our above method, “GetMyData”, so that we can pass in our own context. Here’s the code:

// Change the GetMyData method to take in an existing context.
public static IEnumerable GetMyData(MyDataContext myContext)
{
return from myRow in myContext.Clients select myRow;
}

// This will demonstrate how we are going to gain performance with LINQ:
protected void Page_Load(object sender, EventArgs e)
{
// First, we create our data context just like we did before.
MyDataContext myContext = new MyDataContext();

// Calling this function the first time will hit SQL and query the data.
GetMyData(myContext);

// LINQ is smart enough to realize that we’ve already used this query
// against this data context, so it won’t hit SQL again. Instead it will
// simply return the same result set as last time.
GetMyData(myContext);

// This is a bit ridiculous, but you get the idea.
for (int i = 0; i < 100; i++)
{
GetMyData(myContext);
}
}

The way to achieve the performance benefits of using the same data context during the entire page request is to store your data context instance in the HttpContext Items collection (which is alive for the duration of the thread). We’ll make a static property that will give us a data context instance, but because we are using the current HttpContext, we won’t have cross thread issues. You can read a little more about the HttpContext in this article: Connect Your Site With HttpContext Items. Let’s look at the code to see how to achieve this:

public static class DataAccessLayer
{
// This object is a “key” to the HttpContext Items dictionary.
private static object _eelsContextKey = new object();

// This will always return an instance of the MyDataContext
// (which was created by a LINQ wizard in Visual Studio 2008). It
// will return the SAME instance if you call it twice during the
// same HTTP request.
private static MyDataContext Context
{
get
{
if (HttpContext.Current.Items.Contains(DataAccessLayer._eelsContextKey) == false)
{
MyDataContext context = new MyDataContext(“Connection String Here…”);

HttpContext.Current.Items.Add(DataAccessLayer._eelsContextKey, context);

return context;
}
else
{
return (MyDataContext)HttpContext.Current.Items[DataAccessLayer._eelsContextKey];
}
}
}

// Now we can make very simple DataAccessLayer functions like these:

public static IEnumerable GetClients()
{
return from myRow in DataAccessLayer.Context.Clients select myRow;
}

public static IEnumerable GetProjects()
{
return from myRow in DataAccessLayer.Context.Projects select myRow;
}

public static IEnumerable GetThePoint()
{
return from myRow in DataAccessLayer.Context.You_Get_The_Point select myRow;
}
}

Let’s now look at the last area of performance gain from using LINQ that we will discuss.

Redundant Update Checking

The last place where you can see performance gains is with writing back to your data source. The LINQ data context not only remembers if you have already queried some data before, but it also keeps track of any changes that are made. This means that if you call the “save” function, but no changes were made first, then LINQ will ignore the request to save. Likewise, if you only change one property (such as “FirstName”), then LINQ will build an UPDATE statement that only contains that one column (again saving time and bandwidth).

That’s a Wrap!

New technologies may sometimes seem dauting (or even pointless). Hopefully this article has helped you to appreciate the clear benefits of using LINQ. Download Visual Studio Orcas (beta 2 at this point) and try out some of the examples in this article. I hope you grow to love LINQ as I have.

Source:singingeels.com

Share and Enjoy:

Learn The Basics Of LINQ

admin — Thu, 29 Oct 2009 15:48:50 +0000

LINQ (Language INtegrated Query) is a powerful but misunderstood new language feature brought to us in the .NET framework version 3.5 (C# 3.0 and VB 9). Even though this is a new feature, it already has some huge misconceptions (such as thinking LINQ is a replacement to SQL). This article will teach you how to use LINQ (the language itself), where LINQ can save you a lot of time and will cover some basic concepts of Extension Methods and Lambda expressions.

The Need for LINQ

At first, when I didn’t understand LINQ, I couldn’t appreciate why we needed (or why anyone wanted) it. LINQ seemed very limited in usefulness, and I, like many of my colleagues, bashed it in ignorance. Now, due to understanding the semantics and benefits of the language, I’ve come to love it and wonder how I lived without it.

LINQ does not allow us to do anything new, as far as functionality goes. Really, if you wanted to make the argument of a ‘real programmer’, you could do all of this same functionality by writing encyclopedias of C code (heck, might as well just write it in assembly for “performance” reasons). But, LINQ does create a new way of looking at enumerations of data, and gives out-of-the-box functionality for them.

I realize that the above paragraphs might seem vague, so I’ll get right into real examples that I have used as well as some odd examples that you might not have thought about as being ‘queryable objects’.

Baby Steps – Basic LINQ Queries

Let’s look at some very simple examples of LINQ so that we can have a basis to grow on. Let’s pretend that we have a user control that has a variable amount of TextBoxes added to it (based on some database query or whatever). Our user control might have other controls (Buttons, Literals and the like), and we want to disable all of the TextBoxes if the user doesn’t have security permissions to edit these controls. Please keep in mind that this is a hypothetical scenario at this point just so we can see some basic LINQ (in this case, LINQ to Objects).

Now, you can do this a few ways. Because the number of TextBoxes is dynamic we would possibly do something like this:

// Loop through all of the controls.
foreach (Control myChildControl in this.Controls)
{
// Make sure the control is a TextBox.
if (myChildControl is TextBox)
{
// Cast that “Control” object to a TextBox and disable it.
((TextBox)myChildControl).Enabled = false;
}
}

The above code isn’t really that bad, but I for one don’t like that I have to loop through all of my controls, check the type, cast it to the type that I just checked for, and then set my property. So, let’s see how LINQ will not only “pretty up” my code, but will also make more sense to us programmers:

// Define a enumeration only containing child TextBoxes.
var myChildTextBoxes = from myChildControl in this.Controls
where myChildControl is TextBox
select myChildControl;

// Loop through my TextBoxes.
foreach (TextBox myChildTextBox in myChildTextBoxes)
{
// Disable the TextBox.
myChildTextBox.Enabled = false;
}

This LINQ approach is much cleaner. It’s clear from the start that you want to work with a list of TextBoxes only. Secondly, you aren’t type checking, then re-type casting. Now, you might argue that you could avoid the second type-cast by using an “as” keyword and checking for nulls, or you could say that you don’t like how many lines of code this takes. Those are some valid claims, but if you are thinking that, then apparently you have a short attention span (as I mentioned above that this is just to get you a little familiar with the language syntax).

Step Two – Querying Unconventional Data Sources

Once you begin to use LINQ a bit more in you’re C# (or VB), you’ll begin to think of ‘data sources’ in a different way. For instance, you may see a directory (a folder on your computer) as a data source of files. You can even start to look at your list of running processes as a data source. Really, no enumeration is safe!

What if you were to make a web application that allowed you to upload and download files from your home machine? Let’s say you had a DropDownList that would show a list of the files in the specified directory, perhaps with a button that lets you download it. How would you go about populating that DropDownList with clean file names for the “Text” property and perhaps the path for the “Value” property? I’ll go a step further and say that this is what you’re DropDownList looks like in ASP.NET:

<asp:DropDownList ID=”MyFilesList” runat=”server”
DataTextField=”FileName” DataValueField=”FullPath” />

Well, you could create you’re own custom class that has a FileName property and a FullPath property. Then you could make a generic list of that class, loop through the files in a Directory.GetFiles method, add an entry for each file, set the list as the DataSource of the DropDownList and data bind. That’s a whole lot of nasty that I’m not even going to show the code for (really, because I never want to write nasty code like that again). Here’s what I would do using LINQ:

// Set the DataSource of our DropDownList to an enumeration of a new
// “anonymous type” (meaning a class that is being built on the fly)
// that contains the file names and full paths in our directory.
this.MyFilesList.DataSource = from file in Directory.GetFiles(somePath)
select new
{
FileName = Path.GetFileName(file),
FullPath = file
};

// Call the “DataBind” method
this.MyFilesList.DataBind();

All I can say after that is “Go LINQ GO!” and of course “case closed!”

Extension Methods and Lambda Expressions

One more part to LINQ is the heavy use of Extension Methods and Lambda expressions to accomplish this beautiful language enhancement. If you remember our original example of disabling the TextBoxes, then you’re going to love one of the 50 STANDARD OPERATORS that are brought to you just by including a reference to the System.Linq namespace! Check this out:

// Loop through my TextBoxes.
foreach (TextBox myChildTextBox in this.Controls.OfType())
{
// Disable the TextBox.
myChildTextBox.Enabled = false;
}

Don’t check you’re MSDN… there is no method called “OfType” on the ControlCollection class. But, because the ControlCollection class implements the IEnumerable interface, it automatically gets all of the extension methods that LINQ has kindly given to any enumeration (such as “OfType” which I am using above).

LINQ can be done one of two ways (or a combination of both): query expressions or method expressions. The difference between the two is only a syntax difference, as they ultimately compile into the same thing. Example:

// This line of code…
var textBoxes = from control in this.Controls
where control is TextBox select control;

// is the same thing as this.
var textBoxes = this.Controls.OfType();

Lambda expressions come into play when you want to perform another standard operation such as “SUM” or “MAX”. Here’s an example that I have used recently. I wanted to make a property that displayed the “TotalBill” of an object that had child “orders” in it. Here’s how lambda helped out:

public decimal TotalBill
{
get
{
// Keep in mind that “Orders” is just a list of
// ‘Order’ objects and has no special functionality.
return this.Orders.Sum(order => order.Price);
}
}

If you’re not quite familiar with lambda as of yet, you can get a better explaination of the above in a blog post I made not long ago: LINQ, Lamda and Extension Methods Work Together!

Conclusion

There is much more to say about LINQ, but I hope for now you have a basic understanding and appreciation for it. As I get more time, I’ll talk about some deeper subjects with LINQ such as how to use it in an enterprise level application and how to gain performance and improve multi-developer cohesion with it.

Source:singingeels.com

Share and Enjoy:

Self Sorting GridView with LINQ Expression Trees

admin — Thu, 29 Oct 2009 15:47:16 +0000

The GridView control in ASP.NET 2.0 is lacking some major (yet common) functionality – sorting. This article will show you how to create a “self-sorting” GridView using LINQ expression trees.

First, it’s important to explain what I mean when I say that the GridView doesn’t have sorting capabilities. You’re probably saying to yourself – “I know the GridView has sorting built in because it has a ‘Sort’ method and ‘Sorting’ and ‘Sorted’ events.” And that’s true, but those are merely placeholders that allow you to write your own sorting code.

Also, if you use the designer to build your GridViews, and bind them to SQL data sources, then you might also be confused about the above statements. But rest assured that the sorting magic is all happening in the terribly inefficient SqlDataSource control, and not the actual GridView itself.

If you’re not already familiar with the basics of LINQ, then you might want to first read this article: Learn The Basics of LINQ. To sum up LINQ in one sentence (for the purpose of moving on) I would say: “LINQ is a language feature in .NET that provides a ton of out-of-the-box functionality for querying data.”

The Problem – Why The GridView Can’t Sort

So why is it that the GridView control doesn’t have the ability to sort by default? The problem lies in the fact that the data source is very dynamic, could be of any type and could even be just a paged subset of the ultimate source.

Another problem is performance. If your data source was from a SQL table, then you would want to pass the sorting functionality on to the SQL Server itself to gain the most performance. Because the GridView doesn’t know what your source will be, it can’t really provide the needed functionality.

The Solution – LINQ

Since LINQ provides querying capabilities on a generic level, the above problems are no problem. Because LINQ to objects can handle *any* enumerable objects, and LINQ to SQL is smart enough to pass the sorting logic on to SQL Server, you win no matter what.

For example, imagine if the data source was a collection of MembershipUsers (via the Membership.GetUsers method). Here’s how easy it would be to sort using LINQ and the OrderBy method:

// Using LINQ to sort by a user’s name.
myGridView.DataSource = Membership.GetUsers()
.OfType()
.OrderBy(user => user.Name);

That was very easy to do, but that’s because we know the data type of our source at compile time. But if we are going to make a generic “self sorting GridView”, then we have to build our functionality with the limitation of not knowing the data type of the data source or the name of the field that is being sorted. So we’ll need to reconstruct this functionality at runtime by building “expression trees” (the power behind LINQ).

Step One – Build Our GridView Control

To begin with, let’s build a basic control that inherits from GridView , and stub out a placeholder to put our sorting logic.

public class SelfSortingGridView : GridView
{
protected override void OnSorting(GridViewSortEventArgs e)
{
// Our code below is going to live here…
}
}

Now that we have our custom GridView control ready to go, we can move on to step two.

Step Two – Creating an Expression to Sort With

As was stated earlier, we need to build an expression that will tell LINQ how we want to sort our data source. There are a few tricky issues here that we need to identify and overcome. If we try to copy the example found in this blog post to reproduce our sorting example at the top of this article, we would get half-way there:

// Using a custom LINQ expression to sort by a user’s name.
var param = Expression.Parameter(typeof(MembershipUser), “user”);

// By the way, if you don’t “box” the return type into an object,
// you’ll get a runtime error when you try to sort by a value type.
// So instead of doing this (which would be expected):
var sortExpression = Expression.Lambdaobject>
(Expression.Property(param, “Name”), param);

// I’m going to do this:
var sortExpression = Expression.Lambdaobject>
(Expression.Convert(Expression.Property(param, “Name”), typeof(object)), param);

// And then I can sort my data source:
myGridView.DataSource = Membership.GetUsers()
.OfType().OrderBy(sortExpression);

So we’ve solved one issue – that of finding the property to sort with by it’s name. The “Expression.Property” method above did that for us. Now, we have to solve the second issue – not knowing what the data type of the data source will be until runtime. To solve this in the fewest lines of code, I’m going to make a custom generic class that will create the sort expression for us so that we can simply supply the type at runtime.

public class GenericSorter
{
public IEnumerable Sort(IEnumerable source, string sortBy)
{
var param = Expression.Parameter(typeof(T), “item”);

var sortExpression = Expression.Lambdaobject>>
(Expression.Convert(Expression.Property(param, sortBy), typeof(object)), param);

return source.AsQueryable().OrderByobject>(sortExpression);
}
}

Beautiful! Notice that because we are using a generic class, we can tell the compiler that we want to use the type “T” (whatever “T” will be at runtime, we don’t care)! So, if I wanted to create an instance of my GenericSorter class at runtime, passing in a type that I won’t know until runtime, and then call the “Sort” method, I would just do some simple reflection as will be shown below.

For simplicities sake, the data source is stored in a variable called “_data”. You can download the whole source code at the end of the article to see exactly how it’s done. Here’s a sample of the code:

// Give me the data type of the GridView’s data source.
Type dataSourceType = _data.GetType();

// Determine the data type of the items in the data source at runtime.
Type dataItemType = typeof(object);

if (dataSourceType.HasElementType)
{
// Get the element type if the data source is an array.
dataItemType = dataSourceType.GetElementType();
}
else if (dataSourceType.IsGenericType)
{
// Get the element type if the data source is a generic list.
dataItemType = dataSourceType.GetGenericArguments()[0];
}

// Create an instance of the GenericSorter class passing in the data item type.
Type sorterType = typeof(GenericSorter<>).MakeGenericType(dataItemType);

var sorterObject = Activator.CreateInstance(sorterType);

// Now I can call the “Sort” method passing in my runtime types.
this.DataSource = sorterType.GetMethod(“Sort”, new Type[] { dataSourceType, typeof(string) })
.Invoke(sorterObject, new object[] { _data, e.SortExpression });

this.DataBind();

Conclusion

At first glance, it may seem like we’re doing a lot of code just for sorting functionality. You may even be thinking that this is an extremely convoluted way of sorting a GridView, but really it’s not. Once you understand what LINQ is doing, and how to build your own expression trees, you’ll really appreciate this new language feature in .NET.

I’ll include a web project that has the full source code and some examples of different objects that can be sorted here. If you first don’t understand what all is going on, I’d recommend that you download the source code and step through it in the debugger.

I hope this article has excited you about LINQ and expression trees. If you’re not excited, I hope your informed. If you don’t feel informed, I hope at least that you’re not now afraid of LINQ.

Here’s the source code and sample project: SingingEels_LinqSelfSortingGridView.zip

Source:singingeels.com

Share and Enjoy:

Extending LINQ – Specifying a Property in the Distinct Function

admin — Thu, 29 Oct 2009 15:26:03 +0000

The “Distinct” function in LINQ is definitely one of the top 10 most used functions, but it’s probably one of the top 10 most incomplete as well. This article will show how to extend the IEnumerable interface to allow a very easy way to specify what property makes your list unique (or ‘distinct’).

If you are already familiar with the standard query operators in LINQ, then you have no doubt tried to do something like this:

// Make a unique list of customers from the big list!
var uniqueList = bigList.Distinct(item => item.ID);

// Do something with the unique customers…

The problem is, the “Distinct” function doesn’t let you specify a property by which you call your object ‘unique’. In other words, if you have a collection that has the same customer data in there twice… calling “Distinct” will not remove the duplicate. Note – this statement requires the following VERY IMPORTANT DISCLAIMER:

It’s highly important that you read what I just said above correctly. I said “the same customer *data*”… I did NOT say “the same customer *object*.” Why is that significant? – You will learn the answer to that question further in the article.

How Does LINQ Implement the Distinct Function

Before we can solve the problem explained above by extending LINQ, we have to understand why the method currently does not remove duplicates in all cases. To understand that, we have to understand how it is removing duplicates at all. – Hopefully I haven’t lost you yet

To explain in short – the Distinct function will iterate through an IEnumerable one item at a time and perform the following pseudo-code:

Get the hash code of the current item using the GetHashCode() method which *all* objects in the .NET Framework have.
Check to see if this hash code has been seen before (by checking in a private dictionary hidden from our eyes).
If the hash code is not already in the dictionary, then we simply add the current item to the dictionary and return the object.
If that very same hash code has already been found, then we compare the current item with the last item with that hash to double check uniqueness and return the object if it is unique.

Here is what that code *could* look like (but it’s not exact):

var hashedItems = new Dictionary<int, T>();

foreach (T item in this.Items)
{
int currentHash = item.GetHashCode();

if (hashedItems.ContainsKey(currentHash) == false)
{
hashedItems.Add(currentHash, item);

// We’ve never seen this item before… return it!
yield return item;
}
else
{
if (item.Equals(hashedItems[currentHash]) == false)
{
// We thought we’ve seen this item, but guess not… return it!
yield return item;
}
}
}

By the way, did you catch the reason why two objects that represent the same data will not be de-duped? The reason is that step 1 is to use the “GetHashCode()” method to do a quick test. The here problem is that you may not consider these following objects to be different, but LINQ would:

var personOne = new Person(123, “Timothy”, “Khouri”);
var personTwo = new Person(123, “Timothy”, “Khouri”);

The reason why those two objects would be considered ‘different’ is because different instances of an object will have different hash codes, even if the ‘data’ is the same. Now that we understand enough of what LINQ is doing, we can extend it to meet our simple needs.

Extending IEnumerable

So, how do we add our functionality to everything that LINQ is already extending? – Very easily, extend the only interface that LINQ is extending! As a side note, I recommend putting your code in the “System.Collections.Generic” namespace so that once you add a ‘using’ (or ‘Imports’ in VB) to that namespace, you’ll automatically tap into your extensions too.

// I feel like I’m working for Microsoft when I use this namespace…
// will I get paid for this article? – Probably not
namespace System.Collections.Generic
{
public static class MyIEnumerableExtensions
{
public static IEnumerable Distinct(this IEnumerable source,
Funcobject> uniqueCheckerMethod)
{
// Extension code here…
}
}
}

So, now that we have our method stub that extends any list (array or collection) by letting the developer specify how he considers an object to be unique, we need to fill in the contents of our function.

Because the “Distinct” LINQ extension has an overload that accepts an ‘IEqualityComparer’ object, we already have half of the code written for us! So, what we are going to do is create a generic ‘comparer’ class and use that to do our filtering. Here is what our extension will look like:

public static IEnumerable Distinct(this IEnumerable source,
Funcobject> uniqueCheckerMethod)
{
return source.Distinct(new GenericComparer(uniqueCheckerMethod));
}

And, our “GenericComparer” class will be as follows:

public class GenericComparer : IEqualityComparer
{
public GenericComparer(Funcobject> uniqueCheckerMethod)
{
this._uniqueCheckerMethod = uniqueCheckerMethod;
}

private Funcobject> _uniqueCheckerMethod;

bool IEqualityComparer.Equals(T x, T y)
{
return this._uniqueCheckerMethod(x).Equals(this._uniqueCheckerMethod(y));
}

int IEqualityComparer.GetHashCode(T obj)
{
return this._uniqueCheckerMethod(obj).GetHashCode();
}
}

Now, I can filter the following list like so:

var people = new List();

people.Add(new Person(123, “Timothy”, “Khouri”));
people.Add(new Person(124, “Bob”, “Dole”));
people.Add(new Person(123, “Timothy”, “Khouri”));
people.Add(new Person(125, “Gill”, “Bates”));

foreach (var person in people.Distinct(p => p.ID))
{
// Only the 3 unique people will be displayed!
Console.WriteLine(person.FullName);
}

Download the Source File

While the source for this article is very simple (and is spread throughout the article), you may want to download it and test it out for yourself. This project (compiled for Visual Studio 2008 – .NET 3.5 SP1) has a simple Console app that demonstrates the code above. I encourage you to put some break-points in the code to see how it’s all working. Here’s the code: SingingEels_ExtendingLinqDistinct.zip

Source:singingeels.com

Share and Enjoy: