CodeThinked

IEnumerable ForEach extension method

Justin Etheredge — Thu, 08 May 2008 17:17:34 -0400

List<T> has a method called ForEach that takes an Action<T> delegate, and I wanted one for IEnumerable. I also had someone ask about it in my previous post. It wasn't hard to write, but I figured I would throw it up here for future reference and also in case anyone needed help getting theirs working. If anyone notices anything I did that was dumb you can give me feedback as well. I believe I actually implemented something similar to this a while back, but anyways... without further ado...

public static void ForEach<T>(this IEnumerable<T> enumerable, Action<T> action)

    if (enumerable == null)

        throw new ArgumentNullException("enumerable");

    if (action == null)

        throw new ArgumentNullException("action");

    foreach (T item in enumerable)

        action(item);

Hope it helps.

The Linq SelectMany Operator

Justin Etheredge — Thu, 08 May 2008 13:20:33 -0400

Most of you by now are familiar with LINQ, Microsoft's foray into crossing the code/data impedance mismatch. Most of what we see in Linq translates directly into our knowledge of SQL, since most LINQ queries use very similar semantics to SQL queries. There are certain operators though that don't look familiar because they either weren't present in our SQL lexicon or they were represented in a fundamentally different way. A little bit back I posted about one of these operators, the "let" operator, and how to use it effectively. I later followed it up with a post that dug a little bit deeper into the "let" operator so that you could get a peek at what was going on behind the scenes.

Today I introduce to you another one of these operators that is even a bit more foreign to those coming from a SQL background, it is the SelectMany operator. This operator doesn't have an explicit native syntax when dealing with LINQ queries, so we will first go over the operator using the LINQ extension methods and then we will show you how to achieve the same effect using the native C# LINQ syntax. Sound good? Good.

The SelectMany operator is described on MSDN as "Projects each element of a sequence to an IEnumerable<T> and flattens the resulting sequences into one sequence." Well, that is actually a pretty good description, but until you see it work, it is hard to visualize it. Well, at least it was for me!

In order to first give an example of this operator we will start off with the same list of names that I used in my previous post about the "let" operator and we will select the list with both the "Select" and the SelectMany operator to see what happens.

var nameList = new List<string>

                       "Matt",

                       "Adam",

                       "John",

                       "Peter",

                       "Owen",

                       "Steve",

                       "Richard",

                       "Chris"

};

var names1 = nameList.Where(n => n.Length == 4)

    .Select(n => n).ToList();

names1.ForEach(n => Console.WriteLine(n));

var names2 = nameList.Where(n => n.Length == 4)

    .SelectMany(n => n).ToList();

names2.ForEach(n => Console.WriteLine(n));

So, here you see the same two queries with only the Select and SelectMany swapped out. Then we write the results out to the console, so, what happens when this is executed (with a bit extra formatting code)?

What just happened there? The Select just returned the list of names that we filtered out. In fact, the select is entirely unneeded. If we left it off, then the query would execute identically, I only put it in there so you can see the difference. The SelectMany on the other hand got the list of names with four letters and since String is an IEnumable<Char> it then projects each String as an IEnumerable and then combines the results. So, as you can see, we got a single result with each character of each name in our list.

But how is this useful to us? Actually there are quite a few wonderful uses for this. Lets look at what we could do if we changed our example above to have several lists of names instead of just one.

var nameList = new List<List<string>>()

                       new List<string>

                               "Matt",

                               "Adam",

                               "John",

                               "Peter",

                               "Owen",

                               "Steve",

                               "Richard",

                               "Chris"

},

                       new List<string>

                               "Tim",

                               "Jim",

                               "Andy",

                               "Fred",

                               "Todd",

                               "Rob",

                               "Richard",

                               "Ted"

};

You can now see that we have two different lists of names and how do we get the list of names with only four characters now? Without using SelectMany we could do this:

var names1 = nameList.Select(l => l.Where(n => n.Length == 4));

foreach (var list in names1)

    foreach (string name in list)

        Console.WriteLine(name);

Hmmm. You see where we are doing a sub query to select the names from each list. We then have a nested IEnumerable<IEnumerable<string>> that we have to use nested loops in order to access our names. But with SelectMany we should be able to select our names from our list and avoid the nested IEnumerable.

var names2 = nameList.SelectMany(n => n)

    .Where(n => n.Length == 4)

    .Select(n => n).ToList();

names2.ForEach(n => Console.WriteLine(n));

Pretty easy! Here we are actually using the SelectMany operator first in order to flatten the lists and then we are filtering it using a Where statement. Again, the Select here is not required, but I have thrown it in to be more explicit. What I am doing above though may hide a little bit of what is happening. In order to better show that you are actually passing an IEnumerable into SelectMany I am going to show you an example where we are splitting up a few sentences about the people in our list above. What we are going to do is to have a list of sentences, and then split those sentences into words.

var sentences = new List<string> {"Bob is quite excited.", "Jim is very upset."};

This is our list of sentences, and now we need to get our individual words out of this:

var words = sentences.SelectMany(w => w.TrimEnd('.').Split(' ')).ToList();

Here we do a SelectMany on our list of strings, and then we are removing the period from the end of the sentence, and then we split them on a space and the result of the call to "Split" is what SelectMany then operates on. If we took the Split off then it would simply treat each item as a String and then we would end up enumerating over each character like we did in our first example.

I hope that this has cleared up the SelectMany operator for you, and so now we have just one last thing to do which is to show you how to do a SelectMany using the native C# LINQ syntax. But, how do you do a SelectMany if there is no native query operator for it? Well, you do it by chaining from statements. That may sound weird, but check it out, it actually works quite well.

var words = from s in sentences

            from w in s.TrimEnd('.').Split(' ')

            select w;

See? You are simply funneling the first "from" into the second "from". The reason why this works so well is that it lets you nest even further very easily. For example, what if we wanted each individual character from the above query.

var characters = from s in sentences

                from w in s.TrimEnd('.').Split(' ')

                from c in w

                select c;

Now all we did was split the words, and then select each character out of our list of words. Pretty sweet, and it can allow you to drill down into multiple levels of data very very easily. To me it also gives a good visual flow as to what is happening, but you don't get any indication that a new operator is being involved.

Well, I hope this helps clear things up a bit, and I hope that you get some good use out of this!

When technology attacks

Justin Etheredge — Sun, 04 May 2008 13:05:04 -0400

I am sitting here writing this blog post on my fresh new Vista x64 SP1 install, which was a debacle that took only 2 days to complete. I know you probably do not wish to be regaled with yet another tale of Vista install issues, but this is one that does an excellent job of construing the complexity that is modern technology and showing you that the old adage "the simplest explanation is the correct one" may not always be correct.

It all started a few months back when I purchased a new Dell M1530 laptop. I bought it with a tiny 5200rpm drive and 1GB of ram (which actually isn't even an option anymore) and I installed a nice 200GB 7200rpm drive (with a 16MB cache) and 4GB of RAM. By the way, before you start screaming "Mr. Moneybags" the RAM was about 80 bucks and the harddrive was about 170 dollars. This stuff is so cheap these days it is embarrassing. I loved the laptop, it is quite fast (and I have had several people comment on how fast it is), but I always had one problem... the freakin' thing ran as hot as the fires of Hades. The shell on it is all metal though, so I thought it was just acting like a giant heatsink. The key word here being "thought".

Everything ran fine though, I had no other complaints or problems at all. So, yesterday Vista SP1 finally popped up on my Windows Updates list and so I decided to install. The install started running and went through its usually paces until it restarted and drops to a black screen where it starts copying files. The files were counting up higher and higher until I suddenly get an error that looked something like "!! 0x00000c2 !!" with the name of the file that it stopped on "ExplorerFrame.dll". Great, I thought, SP1 hosed my system. I tried to reboot and it started through the process again, but it locked up again. By this time, with all of the file copying and hard drive activity my laptop was getting quite hot. I decided to go online and see if I could find anyone else having this issue. Well, I found quite a few people that were experiencing this problem. But the only solution was to do a restore back to the restore point that Vista SP1 creates.

So, I restarted my machine and went into the BIOS to configure it to boot from the DVD drive, and my laptop suddenly shut off. What? I rebooted and went back to the BIOS, this time successfully and then I popped in the Vista x64 DVD, booted up the computer and it started loading. But as soon as it finished loading and was supposed to pop into the Vista repair screen, my laptop turned off. What?

Yep, it just powered down. So I hit the power button to turn it back on and popped in the DVD and the same thing happened again. By this time though, the laptop was getting extremely hot. Why was it getting so hot? It wasn't any more hot than I had ever felt before, but I thought that maybe inside Windows there is more cooling management features that run to keep the CPU from running too hot? (I don't know, is there?) So, I decided to give my laptop a rest.

I let it rest for about an hour and I came back and booted the restore DVD and it worked. I got to the restore prompt, began running the restore and it locked up about 10 minutes into it. I let it run for about 30 minutes and suddenly the laptop cut off. How was I going to get my laptop restored? And these shutoffs looked exactly like it was an overheating issue, but I had never had any problems before. Well, I decided to go ahead and go the nuclear route first, and just restore from my backups (yes, I run Acronis TrueImage regularly. I am a paranoid person and it has *always* paid off). But I bet you can guess what happened next. First I had to install the latest version of TrueImage on another machine, since my laptop was the only one running version 11, so that I could create the restore media. Then I had to burn a cd and boot from it on my laptop. I completed this cycle only to have my laptop cut off on me right in the middle of my restore.

Okay, so now I had a totally hosed hard drive since it was half restored. I was now starting to worry a bit, but I decided that my laptop was just getting too freaking hot and it didn't look to me like the fan was coming on at all. So I went ahead and flipped my laptop over and do some surgery. (If you are from Dell, you can stop reading now) I popped off the cover where the RAM is, since that also exposes the CPU, Graphics card, and heatsink fan. I followed the wire from the heatsink and it went down the side of the fan casing and followed a copper tube that went from the CPU over to the GPU (or it could be the motherboard chipset). There were three different chips that this copped tube went over.

I followed the wires and I couldn't really see where they went, but then I saw what looked like a tiny fan connector with nothing plugged into it. I poked around under the copper tube and out popped a fan connected. Wow. The fan on my CPU had never been plugged in. I guess that is a testament to the heat management that is put into laptops these days, but I was a bit pissed off, because I'm sure that this has now shortened the life of my laptop. The only thing I can guess is that while running in windows that the CPU is slowed down or something to compensate for the heat. Not to mention the fact that I rarely use my laptop for periods of longer than a few hours. But I had seriously been running this thing with absolutely no active cooling for several months now, unbelievable.

I plugged the fan in and turned my laptop back on. I started up the Acronis recovery (which took about an hour) and halfway through the difference was stark. My laptop had been doing continuous file copying and processing for 30 minutes and it was barely warm (I could also now hear the very low hum of the fan). Well, I completed my restore, and I thought that maybe the Vista SP1 upgrade had failed because the laptop had overheated, so I decided to go ahead and run it again. I did a full backup first though, just to be safe.

Of course that wasn't my problem, it locked up again. So I went ahead and recovered my hard drive again. What was I going to do? I am not going to have Vista reminding me every 4 hours that I have updates which I am unable to install. That would drive me insane. But at the same time I don't want to set the updates to be ignored, because after a service pack is released I believe that updates for pre service pack installs stop. Not to mention that there are some important updates in SP1 that I want!

My next thought was that maybe something was screwed up on my hard drive. I had after all been running my laptop for several months under conditions that simulated the bottom of an active volcano. It wasn't out of the realm of reality that my hard drive had begun to fail. So I ran chkdsk and amazingly it found an error in the NTFS indexes on the exact file that my SP1 install was locking up on! So, I ran "chkdsk /F", rebooted and let it try to fix all my problems.

I then rebooted one last time into Windows, crossed my fingers, and ran the SP1 update one last time. And, as we both know, it succeeded. Otherwise you would not be getting this post right now and my wife would be getting a migraine. So, let this be a lesson to all those out there, before you start blaming Vista, OS-X, Linux, or whatever for your problems...it may not be quite that simple.

Oh, and Microsoft, why don't you just force a chkdsk run *before* you install a service pack? The SP already takes forever to install, what is an additional 20 minutes?

Dependency Injection Presentation

Justin Etheredge — Wed, 30 Apr 2008 23:18:31 -0400

For those of you that do not know, I gave a presentation last weekend at the Richmond Code Camp 2008.1. Yep, we have more than one Code Camp per year in Richmond, we are quite lucky! For those of you who could not attend my presentation I am putting up my slide deck and sample code, but I will also be turning my presentation into a series of posts. I wanted to do a screencast of the presentation, but Camtasia is about 300 dollars, so it is a bit out of my price range for free work. I feel like the posts will present the information better than a slide deck and sample code, but if you want to download the presentation anyways, feel free!

Update: I have now added a pdf version of the slides for those who cannot use the pptx file. The only issue is that the pdf lacks the notes that the powerpoint presentation has on them. So, it may be hard to tell what certain parts of the presentation mean. Hopefully though it will still be of some use to you!

Presentation Slides (pptx)

Presentation Slides (pdf)

Presentation Source

Immutability and tail recursion

Justin Etheredge — Sun, 27 Apr 2008 21:48:56 -0400

I was in Amanda Laucher's F# talk yesterday and I asked about whether F# was able to tell if a function was pure or semi-pure. (A pure function is simply a function with no side effects, and a semi-pure function is one that only modifies locals) I was just a bit curious if F# was able to tell if there were any immutable variables that had been introduced into method, or if any mutable variables had been changed during a method. Well, I got my answer and then I made a statement that I ~~probably~~ definitely should have shut my mouth on. I essentially asked if introducing mutable variables would cause the F# compiler to not do its tail recursion optimization.

Yeah, I don't know what I smoked that morning. So, if you know all about tail calls and tail recursion optimization, then feel free to stop reading now. Otherwise, you can continue on to learn just how dumb of a statement that was. First of all let me just say that I have actually found a few blog posts where people have made the same mistake, and that makes me feel at least a *bit* better. I guess it is the fact that tail recursion optimization is usually associated with functional languages, since they mostly do looping with recursion, you would run into a lot of problems with even relatively small loops if you couldn't find a way to remove the recursion. But that doesn't really excuse me for not thinking about my question before I asked it.

So, anyways, we all know what recursion is. It is just when a method calls itself (below is direct recursion, there is also indirect recursion. I can't find a good link for a definition, so suffice to say that indirect recursion is when method A calls method B which in turn calls back to method A. More than two methods can be involved, but they don't have to be.)

static void increment(int n)

    increment(n + 1);

Now, that method is infinitely recursive because we have no base case, but it is recursive nonetheless.

Some of us probably know what a tail-call is, it is when we make a call to a method at the very end of another method:

static void Method1()

    int i = 1 + 2;

    Method2();

static void Method2()

    Console.WriteLine("hello");

There are some optimizations that can be made when we are doing a tail call, mainly due to the fact that we can reuse the stack frame of the method we are calling from, since it is no longer needed. (Since there are no instructions after our method call).

Well, there is a little thing called tail recursion as well. And tail recursion is when your recursive call is a tail call. Our "increment" method above is actually tail recursive, since we are calling increment at the end of the method and there is nothing after it. But this method would be considered tail recursive as well:

static void increment(int n)

    if (n > 500000000)

        Console.WriteLine(n);

    else

        increment(n + 1);

And you may even be surprised to know that this is considered tail recursive, since after increment nothing else will ever be called.

static void increment(int n)

    if (n > 500000000)

        Console.WriteLine(n);

    else if (n > 1000000)

        increment(n + 2);

    else

        increment(n + 1);

To make it more clear, look at this in IL:

Now you can see that after each call to "increment" we are going to return. This way it is easy for the compiler to tell this is the last instruction we are going to execute. Now, the beauty of tail recursion, is that since the recursion happens at the end of our method, we can essentially eliminate the recursion by using a loop. This is why (as Amanda showed us in her F# presentation) the F# compiler will turn our original increment method into something that looks like this:

static void increment(int n)

    while (true)

        n++;

And when you run it in C# our original "increment" method will blow up with a StackOverflowException, right? Well, kinda. So, lets build our app and run it under Debug mode. Well, we quickly get this:

But, like a good programmer, we know that running things in Debug mode often disables many compiler optimizations. Sooooo, we change our build type to "Release" and try it again. Suddenly our app is now running, happily pegging one of my CPU's...

What is that you say? On your machine you still got a StackOverflowException? Well, maybe you should get a new machine, I think yours is broken! Ha ha, just kidding! There is a mystery afoot. What happened on my release build, that you are not seeing on your machine? Or maybe you are seeing it? Well, it happens that I am running Vista 64-bit, and if you are seeing this app run fine as well, then you too are running on 64-bit hardware. (In order to prove this to yourself if you are running on a 64-bit machine, you can switch your target CPU to x86, then run in release mode and the StackOverflowException will appear quite quickly!!)

As a side note, after I ran this and realized that I was getting tail recursion optimization, I set about to find out why. Since I did not write the .net runtime (although it would be cool if I did) I had to rely on info from a few different places, but a great one was this post by Jomo Fisher. A lot of the info below this point was gleaned from his post!

But why should that make any difference? Well, let us take a look at our compiled IL:

64-bit:

32-bit:

Hmmm, they look the same... I thought you said that the 64-bit release would optimize our tail recursion? Well, you have to remember that in managed code there is more than one chance for optimization. Optimizations can occur at build time when the IL is generated (hence what F# is doing) and optimizations can also be done by the JITer (Just In Time compiler) when the code is turned from IL into native machine code (which the 64-bit JITer is doing for us).

In order for us to tell that this is actually happening, lets add some code at the end of our method in order to stop the JITer from optimizing our tail recursion and see if we can get our StackOverflowException. So we add this change:

static void increment(int n)

    increment(n + 1);

    int i = 5;

    i = i + 2;

I had to add the second line because just putting in "int i = 5;" the compiler was smart enough to optimize it out because it wasn't being used. Tricky compiler. So, now that we have made this change our application now blows up with a StackOverflowException even when running under the 64-bit JITer!

So there you go, you can now see that tail recursion is completely useless in C#! Since the optimization is done by the JITer and not by the compiler, the code above will run on 64-bit machines, but will crash quickly on 32-bit machines. These are the stuff that nightmares are made of. Anyways, the F# compiler obviously had to do these optimizations for itself since tail recursion is much more prevalent in functional languages and they can't assume that you'll always be running under a 64-bit OS. Although you SHOULD be!

And with that, we are back to my original point for this article. Immutable types and tail recursion optimization have nothing to do with each other. There are some other optimizations that can be done when a method is pure (such as automatic parallelization), but nothing to do with tail recursion. Well, at least nothing that I could find, so please prove me wrong! Hope you enjoyed this post, and hopefully you aren't laughing at me too hard right now. :-)

Richmond Code Camp 2008 Tomorrow

Justin Etheredge — Fri, 25 Apr 2008 21:07:19 -0400

I am giving a talk at the Richmond Code Camp 2008 tomorrow, and I am really excited/nervous. Oh, and other people are giving some presentations as well. My friend Kevin Hazzard is giving two presentations. One on calling WCF services with no proxy (called "Look Ma! No Proxy!") and a Silverlight 101 presentation. I will definitely be attending the "No Proxy" session, but I'm going to have to skip the Silverlight session for Amanda Laucher's F# session. Sorry Kevin! I am extremely interested in F#, but I have not had a chance to dig my teeth in.

So, I have to admit that this is the first presentation that I have ever given. So, if you are in my session, please go easy on me. I don't get too nervous in front of people, but it is easy for me to say this right now. I am giving my presentation on DI (Dependency Injection) and I decided to give my examples in Spring.net and Ninject. I must give a shout out to Nate Kohari, who has helped walked me through Ninject (his brain-child) and who did an amazing job creating it.

So, if you have wondered at all what happened to my blog posts, then if you are near Richmond you can come tomorrow and see the fruits of my post-less-ness. And if you aren't able to attend tomorrow, you can bet that I will turn my presentation into a series considering the insane amount of time that I have put into it. Well, I hope you can attend, and if not, then I hope you enjoy the future blog posts!

Digging into the Linq "let" keyword

Justin Etheredge — Sat, 19 Apr 2008 00:50:56 -0400

In my last post I talked abou the Linq "let" keyword and showed you how it could be used to simplify linq queries. Well, this post was thrown up pretty quick and I didn't get to research the topic in the way that I normally do, and I quickly got called out by a few readers who pointed out that there are some implications with using the "let" keyword that may not be initially apparent.

In the last post I used a query that looked like this:

var names = (from p in nameList

            let vowels = new List<string> { "A", "E", "I", "O", "U" }

            let startsWithVowel = vowels.Any(v => p.ToUpper().StartsWith(v))

            let endsWithVowel = vowels.Any(v => p.ToUpper().EndsWith(v))

            let fourCharactersLong = p.Length == 4

            let fiveCharactersLong = p.Length == 5

            where

            (startsWithVowel || endsWithVowel) &&

            (fourCharactersLong || fiveCharactersLong)

            select p).ToList();

In this case the "let" keyword greatly simplifies what would have been an otherwise very ugly "where" clause. So, I started thinking, how can I show what happens when this query is turned into an Expression object? I first started off by using the Expression visualizer that ships in the samples with VS2008 (click for full size):

That might give you a hint as to what is happening, if you are familiar with compiler generated anonymous types, but otherwise that just looks like a bunch of gibberish. You have to open up the app in reflector to really see what is going on with these anonymous types. What this is essentially telling us is exactly what "Skup" in my last post was trying to tell me. That each time you use the "let" keyword it is just generating an anonymous type which wraps the variable assigned in the let statement along with the item being queried.

After thinking a bit I realized that just rewriting this query with explicit Linq methods would probably be the best way to explain this. There is no "let" query method, you have to accomplish all of this through select statements.

var names2 = nameList

    .Select(a => new { a, vowels = new List<string> { "A", "E", "I", "O", "U" } })

    .Select(b => new { b, startsWithVowel = b.vowels.Any(v => b.a.ToUpper().StartsWith(v)) })

    .Select(c => new { c, endsWithVowel = c.b.vowels.Any(v => c.b.a.ToUpper().EndsWith(v)) })

    .Select(d => new { d, fourCharactersLong = d.c.b.a.Length == 4 })

    .Select(e => new { e, fiveCharactersLong = e.d.c.b.a.Length == 5 })

    .Where(w => (w.e.d.c.startsWithVowel || w.e.d.endsWithVowel)

              && (w.e.fourCharactersLong || w.fiveCharactersLong))

    .Select(s => s.e.d.c.b.a);

So, as you can see, the "let" keyword cleans this up quite a bit. But you can also see what is actually happening. You can also see why Frans said in my last post that when you are running this against Linq to Sql it is going to generate a sub-query for each "let" statement. I hope that this helps a bit when trying to decide whether or not to use the Linq "let" statement.

The Linq "let" keyword

Justin Etheredge — Mon, 14 Apr 2008 22:38:38 -0400

I've been busy working on some presentations that I have coming up, and so I haven't had too much time to update, but I was messing around with Linq and I found myself using the "let" keyword quite a bit to make some of my queries more readable. So I decided to do a small write-up so that you can see the joy of using the "let" keyword.

Lets say we have a small set of data that looks like this:

var nameList = new List<string>

                       "Matt",

                       "Adam",

                       "John",

                       "Peter",

                       "Owen",

                       "Steve",

                       "Richard",

                       "Chris"

};

And we have a method where we need to return a list of names that start or end with vowels and are either 4 or 5 characters long. So, our inexperienced Linq developer quickly codes up a query that looks like this (yes, I know the "ToUpper" is ugly, but I'm not changing it now :) ):

var vowels = new List<string> {"A", "E", "I", "O", "U"};

var names = (from p in nameList

            where

            (vowels.Any(v => p.ToUpper().StartsWith(v))

            || vowels.Any(v => p.ToUpper().EndsWith(v))) &&

            (p.Length == 4

            || p.Length == 5)

            select p).ToList();

First we have to define our List of vowels, since we are using it twice. Then we code up our query just like we would if we were writing a sql statement. The only problem is that by just looking at this query it is pretty hard to tell what it is doing. But what if we had a way to break up the query so that we could make its purpose more clear? Well, thankfully we do!

var names = (from p in nameList

            let vowels = new List<string> { "A", "E", "I", "O", "U" }

            let startsWithVowel = vowels.Any(v => p.ToUpper().StartsWith(v))

            let endsWithVowel = vowels.Any(v => p.ToUpper().EndsWith(v))

            let fourCharactersLong = p.Length == 4

            let fiveCharactersLong = p.Length == 5

            where

            (startsWithVowel || endsWithVowel) &&

            (fourCharactersLong || fiveCharactersLong)

            select p).ToList();

Now, doesn't that look better? We define four intermediate variables that hold our vowels and booleans for our tests, then in the where clause we just check our boolean values. The result is a where clause that is very readable. There are tons more uses for "let", but I hope that you start using it in your queries to make them more readable.

Rob Conery's MVC Storefront Application

Justin Etheredge — Wed, 09 Apr 2008 08:43:00 -0400

In case you have not seen, Rob Conery is currently working on a screencast series about building a simple e-commerce app using the MVC framework. He has received a bit of harsh criticism about his use of TDD (especially on twitter) from a few outspoken people in the community, and so I wanted to throw this post up to show a little solidarity. He clearly stated he was not an expert, and now after harsh criticism he has reached out for help with the series. Rob dealt with this in a calm and professional manner, which is something that I'm not even sure I could have done after a few of the comments that I saw. So, if you haven't seen it yet, go check it out, and go let Rob know that you support his efforts and appreciate the hard work he is doing.

Grouping Linq Aggregates in C#

Justin Etheredge — Mon, 07 Apr 2008 21:06:12 -0400

Using aggregates such as "Count", "Average", "Sum" etc... is pretty easy in simple queries. Lets say we have a table like this:

So, if we want to query all of the products with the name "Bike" then our query will look like this:

var products = from p in db.Products

        where p.Name == "Bike" select p;

Then if we want to expand on that to just get the count of those products then we will create a query that looks like this:

int count = (from p in db.Products

    where p.Name == "Bike" select p).Count();

Or if we wanted to get the average price of those products we would do this:

decimal count = (from p in db.Products

                where p.Name == "Bike"

                select p.Price).Average();

Or if we wanted to get all of the names appended together:

string names = (from p in db.Products

                where p.Name == "Bike"

                select p.Name)

                .ToArray()

                .Aggregate((p1, p2) => p1 + " " + p2);

That last one was just thrown in for fun. It doesn't even really apply to this post. You'll notice though that I put a "ToArray()" in there, well, that is because I am using Linq To Sql and the Linq To Sql provider doesn't support the Aggregate operator. So anyways, lets get on to what we are really here for.

Now all of those were probably pretty clear, but what do we do if we want to group our products by name? Well, you would do something like this:

var groups = from p in db.Products

            group p by p.Name

            into g

            select g;

Okay, that looks pretty easy, but what exactly is put into "groups" when this statement is run? Well, it is an IOrderedQueryable, just like most Linq queries, but what is actually produced when it is executed? For example, what if we put a ToArray() on this statement, like we did in the statement above that used "Aggregate"? What would each item in the array hold? Well, there is an interface in linq called IGrouping which is defined as IGrouping<TKey, TElement>. IGrouping is what the array would be filled with. In our case it would be an "IGrouping<String,Product> since we are grouping on "Name" which is a string. IGrouping also implements IEnumerable, so you can do things like this as well:

var names = from p in db.Products

            group p by p.Name

            into g

                select

                (from c in g select c.Name)

                .Distinct().Single();

This allows you to do sub-queries on these groups that you have now formed. This query does in fact query the names out of each group and then filters out the duplicates, then it calls "Single()" to get a list of items rather than a list of IEnumerables with a single item in them. Seems kinda crazy to have to do all that to get the names of the groups that we grouped on, right? Well, it is crazy. There is a much easier way to do this:

var names = from p in db.Products

            group p by p.Name

            into g select g.Key;

So, as you can see our IGrouping interface has a property called Key that allows us to access the key that we are grouped on. Isn't that just great? So, now that we have a list of names, how do we get the count in each group? Well, as I stated earlier, IGrouping implements IEnumerable so we get access to all of our wonderful extension methods:

var groups = from p in db.Products

            group p by p.Name

            into g

            select new {Name = g.Key,

                        Count = g.Count()};

So there you have it, we now have a Linq query that is capable of grouping on a specific key and then return a count for each of our groups. Not the most straightforward thing if you are thinking in traditional SQL syntax, but you'll get used to it! Hope you enjoyed!

The Monostate pattern

Justin Etheredge — Sun, 06 Apr 2008 13:34:16 -0400

Most people are quite familiar with the Singleton pattern. This is probably one of the most widely used and widely abused patterns in existence today. The Singleton pattern forces its users to only access a single instance of a class. This is usually accomplished by making the constructor of a class private and then providing a static property or method through which this single instance can be accessed. A simple implementation would look like this:

public class Singleton

    private static Singleton instance;

    private Singleton()

    public static Singleton Instance

get

            if (instance == null)

                instance = new Singleton();

            return instance;

    public String DataItem { get; set; }

In this example I have included a single data member to show you that these are just normal instance members like you would have in any class. Then you can see that we have a static Instance property and a static instance private data member. You would consume this class like this:

Singleton single = Singleton.Instance;

single.DataItem = "value";

There are several complaints that people have about this pattern. First of all is the way in which it is instantiated. Calling Singleton.Instance to get your class is not exactly a standard, what happens when you one day decide that this class should no longer be a singleton? Well, you have to touch every part of your application that calls the "Instance" property. You'd probably be better off wrapping your Singleton creation inside of a factory method to begin with. At least then you won't have to change every part of your code that accesses your singleton.

Other complaints that people have involve memory leaks, holding onto resources that should be let go, global variables, testing, etc... There are quite a few people who feel very strongly about the fact that Singleton is actually an anti-pattern. Well, let me first say that Monostate will not make any of these people happy.

The Monostate pattern tries to accomplish something similar, but in a very different way. Generally speaking, the Monostate pattern attempts to hide the fact that a class is only operating on a single instance of data by using static data members. This way, consumers of this class will feel as if they are instantiating their own instance, but in fact will be accessing static data.

The Monostate pattern is nothing new. As far as I can tell, it was first described in the September 1996 issue of the now defunct "C++ Report" magazine. I will first start off by showing you how the Monostate pattern is instantiated and used:

var single = new Monostate();

single.DataItem = "value";

You may be looking at this and saying, well, he is just creating a new class. I'm not sure how this helps me with the Singleton pattern. And you have inadvertently unearthed the single biggest complaint that is unique to the Monostate pattern. You cannot tell when you are using a Monostate object other than to look at its internal implementation. This is how that above code would be implemented:

public class Monostate

    private static string dataItem;

    public string DataItem

        get { return dataItem; }

        set { dataItem = value; }

    public Monostate(){ }

As you can see, all we do is use instance properties with static private data members. It is quite the sneaky little pattern. Everyone who uses the class will not know that they are dealing with a single backing data item. This could be good or bad depending on how you look at it.

The Monostate pattern does not solve all of the problems that the Singleton pattern has, but it does provide an interesting way to keep single data values, while still allowing your classes to have multiple instances. Monostate classes are also easier to inherit from and modify than their Singleton counterparts, and can be swapped out for true instance classes without modifying any external code calling the class. Monostate also don't have quite as many multi-threading issues as Singleton classes, since there truly is no way to accidentally get multiple copies of the data with Monostate. A careless Singleton implementation could end up with several instances if called simultaneously from multiple threads. Both patterns require locking on their data members though.

One thing to also keep in mind when implementing a Singleton or Monostate pattern is that you want to make sure that you are using the pattern because the data requires that it not be copied in two places. If you are implementing Singleton because you want to save the cost of object instantiation, think again. If you are implementing either of them because it makes the logic more simple, then think again. The only reason to use these patterns is because your data dictates that it cannot be out of sync.

So, there you have it, hopefully another useful addition to your pattern tool belt. And like always, if you liked it, please kick it!