Sorting List's the .Net 3.5 Way

Derik Whittaker — Sat, 29 Mar 2008 02:09:13 GMT

This post is another in the recent string of How-to's. But it is just so hard to resist. .Net 3.5 has so many cool features, it is just fun to explore them all.

Ok, so here is the issue we are going to solve today. We have a list of entities and we need to sort them. In this post I will show you 3 different ways to accomplish this task, all producing the same result, but using different techniques (hey Peter, go ahead and show me a 4th and better way :) ).

A little up front declarations. Each method will use the same list, so to save space I will declare this now.

List userList = new List
    {
        new User {FirstName = "Andy", LastName = "Tayler"},
        new User {FirstName = "Opie", LastName = "Tayler"},
        new User {FirstName = "Bee", LastName = "Tayler"},
        new User {FirstName = "Barney", LastName = "Fife"},
        new User {FirstName = "Goomer", LastName = "Pile"}
};

Sort Method 1 -- Using the Sort with IComarer

public void Sort_OldSchool()
{
    userList.Sort(new UserCompare());
}

// Sort class
private class UserCompare : IComparer<User>
 {
    public int Compare( User x, User y )
    {
    return x.LastName.CompareTo( y.LastName );
}

The above works, but requires you to create a custom class that implements the IComparer<User> interface to do the trick.

Sort Method 2 -- Using Lambda and extension methods

[Test]
public void Sort_UsingLambda()
{
	userList = userList.OrderBy( user => user.LastName ).ToList();
}

This way works great, it is clean and very readable.

Sort Method 3 -- Use Linq2Objects

[Test]
public void Sort_UsingLinq()
{
	userList = ( from u in userList
        	orderby u.LastName, u.FirstName
                select u ).ToList();
}

By using Linq you open yourself up to a whole new level of flexibility. You can not only sort (OrderBy), you can filter, return only a select number of rows, etc, etc. Basically you can do anything that Linq provides.

As you can see from the above, they all accomplish the same goal but method 2 & 3 are just more fun. Besides, if you are going to be using .Net 3.5 you might as well use the new features.

BTW, all the methods (except 3 since it sorts by LastName and FirstName) above produce the following output.
Barney Fife
Goomer Pile
Andy Tayler
Opie Tayler
Bee Tayler

Till next time,

Linq2Sql, my thoughts after a few hours of learning

Derik Whittaker — Thu, 13 Mar 2008 18:59:48 GMT

Today I started to play/learn the basics on Linq2SQL and I have to say, it is pretty cool. However, within the first 20 minutes I came to a cross roads, I was stuck. I am torn between the 2 different ways to connect to, and query from, a data source. I don't know which I like better.

Below are the 2 different ways to connect, as well as my opinions as to the pros/cons on each one. Please take into account I have NO real world experience using Linq, these are just my thoughts on the subject

Approach 1
The most common way I have seen to use Linq2SQL is to generate a custom DataContext class (.dbml class) via the IDE. This will generate all your DTO classes for you as well as the mappings between tables/objects.

Pros

Creates the DTO classes that map directly to your database tables for you. This can save you a bit of time versus creating the DTO's buy hand.
When the DB schema changes, you simply have to refresh the IDE and all the changes are brought down
No need to sprinkle your DTO's with attributes to allows Linq to use them. (ie [Table(Name="Sport")]

Cons

The generated code creates a lot of overhead. For example, the default set code will raise 4 events as well as set the new value. If you are using these events, great, but if not you have wasted cycles.
Gives you less control over your DTO objects
Would NOT work well if you are trying to back in Linq2Sql into an existing application

Approach 2
The second way is to create a standard DataContext and create the mappings on the fly. This way does NOT generate your DTO's you

Pros

You can use your existing DTO's (assuming you have some)
You have 100% control over how your DTO's are created/generated
No events are fired when you set properties, unlike the generated DTO's. This is assuming you don't WANT the events.
Would work well in the scenario where you are trying to back Linq2Sql into an existing application.
Because you have to hand wire the DTO's to the db tables, you become more aware of what is going one and are more able to fix 'odd' issues as the appear.

Cons

You need to sprinkle your existing DTO's with various attributes to all them to be mapped to you database tables.
When your DB schema changes, you need to update your DTO's by hand to reflect the changes.
You need to use the db.GetTable<EntityHere>() (db here is a DataContext instance) in order for the context to know about a given table.

Ok so there you have it, both ways to connect to the db using Linq along with my thoughts on pros/cons. At the end of the day, I think I like the idea of Approach 2 because I like to have more control over what my code does, although I have to admit I like the auto generation capabilities of Approach 1. I wonder if my attitude with respect to which approach to use will change over time, who knows:)

Till next time,

Derik Whittaker : Opinion, Linq

Sorting List's the .Net 3.5 Way

Linq2Sql, my thoughts after a few hours of learning