If you have Visual Studio 2008 installed, you can find the samples in this directory: C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033.  Then extract the file CSharpSamples.zip.  The sample will be found at CSharpSamples\LinqSamples\DynamicQuery.

From the sample you will see that you can do perform things like this:

var query =    db.Customers.Where(         "City == @0 and Orders.Count >= @1", "London", 10).
   OrderBy("CompanyName").
   Select("New(CompanyName as Name, Phone)");

All of the heavy lifting happens in the Dynamic.cs file that has 11 classes.  The interface happens through DynamicQuery static class, which extends the IQueriable interface with new Where, OrderBy, and Select methods.  To use these extensions you have to include this line in your code: using System.Linq.Dynamic; along with the Dynamic file in your project.

I don’t have a use for this quite yet, but I think its time will come.

Where it led me was to re-investigate Partial Mocks in Rhino Mocks.  My original misunderstanding of Partial Mocks was that they would only mock Abstract Classes.  A partial mock will mock ANY class — but only the Partial mock will only mock abstract methods.  That small misunderstanding has caused me to loose untold amount of hair and good will towards all men.

So I’m going to re-implement my class methods.  Here you go:

public class MyClass
{
    public int Foo()
    {
        // stuff happens here
        int i = Bar();
        // do more stuff here    
        return i + 5;
    }
    public virtual int Bar()
    {
       // do some logic
       return 1;
    }
}

A few changes here.  First, I removed the delegate and renamed BarInternal back to Bar.  Second, I marked the Bar method as virtual. 

They key point about a virtual method is that you can provide an implementation, and then a inherited class can completely override that method.  That is what the Partial Mock is allowing us to do.

So how do I write my tests?  If you don’t like using Rhino Mocks you do this:

[Test]
public void FooTest()
{
    int expected = 7;
    int result = 0;
    MockRepository mock = new MockRepository();
    MyClass c = mock.PartialMock<MyClass>();

    using (mock.Record())
    {
        Expect.Call(c.Bar()).Return(2);
    }
    using (mock.Playback())
    {
        result = c.Foo();
    }

    Assert.AreEqual(expected, result);
}

Obviously, now my test is referencing the Rhino Mocks library.  The variable mock is the Mock Repository.  Now the big change is that I don’t create MyClass directly, but through the Rhino Mocks PartialMock method.

Next, I tell the mock repository to expect a call to c.Bar, and when called return 2.  That is what is happening in the using (mock.Record()) section of the code.  Then, in the mock.Playback section, I call Foo().

One other quick note, if we were to rewrite Foo such that it no longer called Bar this test will fail.  The Expect.Call part tell the mock repository that the method Bar will be called, and if it isn’t there is a problem.  There are ways around that as well, but that is a topic for another day.

Where does that leave us now?  Aside from the odd “virtual” keyword thrown into our production code, this is the code as you would have originally written it, even without TDD.  I don’t like making API changes just to satisfy testing, but I am very OK with this change.

But what about that new kid on the block?  You know, Moq.

I still love Rhino Mocks, but I can’t help but want to play with a new toy.  So here is the same thing, but in Moq:

[Test]
public void Foo_moq_test()
{
    Mock<MyClass> mock = new Mock<MyClass>();
    mock.Expect(x => x.Bar()).Returns(2);

    MyClass c = mock.Object;
    int result = c.Foo();
    Assert.AreEqual(7, result);
}

So as you should be able to see, Moq is a very different animal than RhinoMocks.  There is no Record or Playback (the web site calls those confusing, I disagree, but still), and the Expect happens with a anonymous delegate (in the form of the Lambda Expression “x => x.Bar()” where x is of type MyClass).

The cool part is that you can get the same results with less code using Moq.  That has been the main advantage all along.  My informal testing also reveals that Moq is just a hair faster than Rhino Mocks (but not fast enough to warrant switching frameworks).

Before:

IEnumerable<TDomainEntity> domainEntities = Repository.Find(criteria);
IEnumerable<TDto> dtos = Assembler.DomainToService(domainEntities);
return new List<TDto>(dtos);

return Repository
           .Find(criteria)
           .ToList()
           .ConvertAll<TDto>(Assembler.DomainToService);

Comparing the VS2005 vs VS2008 files showed that the only thing changed in those files was the “solution version” info from 8 to 9 – just the basic “you’re a now VS2008 project” information, but nothing vital. So, if nothing changed in the files, and we’re still targeting the .NET 2.0 framework, why would the program break? Shouldn’t the VS2008 output be identical to VS2005?

The answer is: nope.

Even if you are targeting the .NET 2.0 framework, Visual Studio 2008 will still use the C# 3.0 compiler and those .NET 3.5-based tools to do it’s thing. In fact, you can even use all of that C# 3.0 syntax in your .NET 2.0-targeted projects without any problems: so “var,” anonymous types and properties, and lambda expressions all can be used. The C# 3.0 compiler just generates standard 2.0 IL for those things.

The only thing you can’t do is use those .NET 3.0 / 3.5 features that rely on libraries provided by the newer .NET versions – LINQ, Func<T>, all that functionality that is included in the newer assemblies – well, you have to have the assemblies for that to work.

The project I used to see this for myself is attached - sometimes the best way to understand something is to do some empirical research, boil an issue down to something that you could test, write a prototype for, or just slap a new project together.

Point LINQPad at a SQL Server database and then you can write your LINQ queries right in the tool.  No having to deal with DataContext objects or any messy stuff like that.  It also works with LINQ to Objects and LINQ to XML; plus it comes with about 200 samples.   It reminds me a bit of the HQL Query Analyzer of Ayende’s — just a lot simpler to use.  The main point is that you can get nearly instant results from your query, which defiantly helps in that critical “getting to know you” stage with a new technology.

The only gripe I have with it right now is that intellesense isn’t implemented yet.  That is kind of like flying blind these days.  But who is to complain over a free tool like this.

Note:LINQPad  was written in conjunction with the book C# 3.0 in a Nutshell.

He also gives us a glimpse of what it is like to live your life visiting other people’s development shops. Did you know source control is stil optional in some organizations?

Chris is a true code craftsman and this shows in his clear explanations of some very advanced programming concepts. If you haven’t played with Lambda expressions, anonymous delegates, or LINQ, start with this podcast.

Download the episode MP3

Lets start with the standard model for creating and firing events.

Step 1: Create the event

public eventEventHandler<EventArgs> OnLoadData;

My current method is to always use the generic EventHandler<> instead of the old-school EventHandler.  I think it makes for better-looking code IMHO.

Step 2: Fire the Event (Old Skool)

   1:  if(OnLoadData != null)
   2:  {
   3:  OnLoadData(this, null);
   4:  }

Step 3: We can do better

There is a cool feature that you get with extension methods: you can call an extension method on null base object!  So you can now do things that were impossible – like removing a null check when firing an event and just fire the event!

Step 4: Create an extension method

To start you have to create a static class and … oh forget it, here is the code.

   1:  using System;
   2:   
   3:  namespaceMyNamespace
   4:  {
   5:      public static classMyExtensions
   6:      {
   7:          public static voidFire<TEventArgs>(
                     thisEventHandler<TEventArgs> myEvent,
                     objectsender, TEventArgs e)
                     whereTEventArgs: EventArgs
   8:          {
   9:              if(myEvent != null)
  10:  myEvent(sender, e);
  11:          }
  12:      }
  13:  }

Step 5: Refactor Step 2

   1:  OnLoadData.Fire(this, null);

Done.

Step 6: Profit

Well, I will as soon as I figure out how.  I mean really, I save 3 friggen lines of code here.  Big deal–right?  Well, There are some moral victories in this. 

1. I simplified the firing of events ever so slightly by removing previously mandatory logic.
2. It is reusable.  The Fire extension method can be used with any event that we create with the generic EventHandler.
3. I have added an ever so small amount of clarity to what the code is doing.  Granted, this will only clear things up for the extreme noob or clueless manager who wants to see the code…but still. Let’s not be snobby about this.
4. I figured out a grand way to use and abuse Extension Methods in a useful way.  It makes me feel special.  What can I say.
5. And I like it.  Something about always having to check if the EventHander was null -EVERY SINGLE TIME I WANTED TO JUST FIRE A FREEKING EVENT- bugged me for some inexplicable reason.  This little hack sets my soul at ease.  So there.

First note: I wrote this in a couple of hours.  Most of the coding took 30 minutes, then about three to four hours to test and tweak.  Also, after you see the main code, I’m then going to rewrite it with .Net 3.5 in mind — using an Extension Method.

The hardest part of the project was figuring out what SubSonic object to use, then how to pass a generic reference to the method.  Because of SubSonic’s heavy use of generics, that did get interesting.  In fact, the primary method looks like this:

public string CreateCsvData<ItemType, ListType>(

           ActiveList<ItemType, ListType> list)

           where ItemType : ActiveRecord<ItemType>, new()

           where ListType : AbstractList<ItemType, ListType>, new()

To decipher for the non-generically inclined: the method name is CreateCsvData.  You can pass in any SubSonic generated collection object as they all inherit from ActiveList.  What makes the code a bit ugly is the fact that ActiveList is a generic object that takes two other objects types in the declaration.  This is where having the source code handy really helps.

Understandably, there is a bit of code to doing this, so you can download it:

SubSonic Export To CSV for .Net 2.0

And if you are using .Net 3.5, here is an extension method version:

SubSonic Export To CSV for .Net 3.5

Using the code

First step is to hook up SubSonic to you database (of course).  I use the AdventureWorks LT database myself for most samples, which has a Customer table.  One of the generated SubSonic objects you will get is a CustomerCollection object. 

public string CreateCsv()

{

    CustomerCollection customerList = GetCustomers();

    SubSonicToCsv csv = new SubSonicToCsv();

    return csv.CreateCsvData(customerList);

}

Here is the code again, but this time using the .Net 3.5 extension method

public string CreateCsv35()

{

    CustomerCollection customerList = GetCustomers();

    return customerList.CreateCsvData();

}

You can debate which version you like better yourself but I like the .Net 3.5 better myself.  It is cleaner, and integrates into the SubSonic API beautifully.

Now I just have to replicate this for LINQ For SQL.

While generics are easy (just start playing with List<> in System.Collections.Generic and feel the love), anonymous delegates and predicates take some getting used to.  Mostly because they are not as easy to explain and they look funny.

The basics are this: Anonymous Delegates allow you to pass code into an existing method.  You will see specific examples of anonymous delegates in the form of Predicates and Comparision.

The best place to see this in action is in the previously mentioned generic list class "List<T>".  The generic list basically make a dynamic array/collection that is strongly typed to whatever type you give the generic list.  So if you want a collection of integers you type:

List<int> myList = new List<int>();

And off you go.  But as you go, you should notice a few little gems in the List class.  Things like Sort, Find, and Exists.  If you lookup the definition of Exists (to pick on at random) you will see something like this:

public bool Exists(Predicate<T> match);

A predicate is a specific anonymous delegate that take an object and returns a boolean.  Its declaration looks like this:

public delegate bool Predicate<T>(T obj);

Remember what I said earlier: a predicate allows you to pass in code to an existing method.   The delegate Predicate defines what that code must look like.   A method that takes an object (as defined by the type passed into the list) and return a boolean. Here is how you use it.

myList.Exists(delegate(int obj) { /* do something cool here */ })

The most common use for an Exists method is to find if a particular value exists in the list.  For our case…say the number 5.  You would then write this:

myList.Exists(delegate(int i) { return i == 5; })

So where is the anonymous delegate I was just talking about?  Here it is all by itself:

delegate(int i) { return i == 5; }

It should look vaguely like a function declaration if I write it slightly different.  Compare an anonymous delegate to a method returning a boolean:

Don’t be fooled to thing we can just see if one value is the same as some other arbitrary value.  You just have to return a True or a False.  If you want to know if any value is greater than 700, not a problem.  Just return True or False.

What does this buy us?

While showing the use with a List of integers does make things nice and simple, what if we are dealing with a list of objects?  If you have a customer object with a FirstName and LastName, how do you sort it?  More importantly, how would a generic list object know how to sort it?  It can’t.  Not until that ESP module finally gets finished anyway.

What this buys us is flexibility to perform our esoteric business logic on complex objects.  That is where anonymous delegates really start to shine.

Caution in the wind

Now that I’ve talked about the wonders that anonymous delegates can be, please use with caution.  When misused they can turn into a 3 headed, fire breathing monster.  Specifically I’ve seen many a developer try to write their own methods that take anonymous delegates to pursue the DRY (don’t repeat yourself) principle to ends unknown. 

For example: if you are writing an anonymous delegate to save yourself a ‘for’ loop, you might be a redneck — wait, that came out wrong.  But you will have developers give you dirty looks once you check in, ok.

If you want an example if this, Jason Grundy wrote about this a while back. 

Back to C# 3.0

What does this have to do with C# 3.0?  Everything that is Lambda and LINQ.  Lambda is nothing but a cleaner way of writing anonymous delegates.  Really.  That is it.

My previous example moves from

myList.Exists(delegate(int i) { return i == 5; })

to a lambdaified (lambdaified: not a word yet, but it will be)

myList.Exists( x => x == 5)

Simple, clean, elegant.  The lambda version is anyway.  Now, if you don’t understand the x => x == 5, that is pure Lambda, and you will hearing a lot more about that in the near future.