There and Back Again : LINQ

Managing Command Line Arguments

hdierking — Thu, 26 Jun 2008 23:40:32 GMT

I've been spending many of my recent developer cycles writing console applications to perform various tasks in an ETL process. And yes, before you ask, I had started out initially modeling my ETL process with SSIS - and while I could eventually get it to do what I wanted, at the end of the day, regular code was a more direct and expressive syntax for describing my process.

Anyway, one of the recurring things that I found myself having to do as I was writing these little command line apps was parsing various command line arguments - whether they were positional parameters, optional (named) parameters or switches. I refactored that args-managing logic out into its own class and wanted to share it with you in the case that you find yourself rewriting similar code in your applications. One of the things that you'll notice is that the error handling code is pretty sparse, and I could have made it even more robust by supporting different arg formats instead of hard-coding the delimiter characters. Perhaps one day...

internal class CommandLineArgs
{
    private readonly IEnumerable<string> _args;

    public CommandLineArgs(IEnumerable<string> args) {
        _args = args;
    }

    public bool GetSwitch(string switchName) {
        var swt =
            _args.FirstOrDefault(
                a =>
                a.Equals("/" + switchName, StringComparison.InvariantCultureIgnoreCase) ||
                a.Equals("-" + switchName, StringComparison.InvariantCultureIgnoreCase));
        return !string.IsNullOrEmpty(swt);
    }

    public T ParseParam<T>(string param) {
        var paramString = _args.FirstOrDefault(s => s.StartsWith(string.Format("/{0}:", param)));

        if (string.IsNullOrEmpty(paramString))
            throw new ArgumentException(
                "The requested argument was not found in the command line arguments.", param);

        var paramValueString = paramString.Split(':')[1];
        return GetTypedVal<T>(paramValueString);
    }

    public T GetArgAt<T>(int position) {
        var val = _args.ElementAt(position);
        return GetTypedVal<T>(val);
    }

    private T GetTypedVal<T>(string val) {
        try {
            return (T) Convert.ChangeType(val, typeof (T));
        }
        catch (Exception ex) {
            throw new ArgumentException(
                "Argument value [" + val + "] could not be parsed into type [" + typeof (T).Name + "].",
                ex);
        }
    }
}

Last Old Blog Code Update

hdierking — Fri, 07 Mar 2008 10:12:00 GMT

Ok - after posting this update, I'll consider myself caught up with regard to picking up the pieces of my old blog. This is the updated code sample for creating custom mapping types in NHibernate. The updated sample provides a loose example of implementing the type object pattern - a pattern where one object instance serves as the type for a set of other object instances. Here, for the sake of simplicity and expediency, I have designed the types such that the type object is also the value container - hopefully when you look at the code, you can see it's a pretty simple process to go a step farther and implement the full pattern.

Anyway, similar to my last post, I've updated the code to use the latest version of NHibernate, and I've added in some LINQ goodness. And of course, all demoware disclaimers apply.

Old TDD Demo Blog - Digest and Code

hdierking — Sun, 02 Mar 2008 10:24:00 GMT

Several of you have emailed me over the past several months asking if I had a copy of the blog text and/or code that I had mentioned in a much earlier blog entry. As it turns out, a good friend of mine found some old archived versions of the site on an Internet cache and set them over to me. Therefore, I have taken the web pages and compiled them into an XPS document so that you can see the thought progression that went along with building a small application, TDD style.

Additionally, I've updated the code samples a bit. Specifically, I've upgraded the version of NHibernate to 1.2.1.GA - and as such, dropped the use of Ayende's NHibernate Generics library. Also, as I was going through my NHibernate mappings, I realized that I had been pretty lazy with regard to semantic accuracy for collection types - I had pretty much completely used <bag> mappings instead <set> mappings for unordered collections so that I could use IList<T>. Therefore, I cleaned that up a bit. Other than that, the only other thing that I did was update some of the looping and conditional code to use LINQ.

Finally, let me emphatically throw out the "Demoware Disclaimer" - The point of the blog and the code samples was to illustrate the thought process and corresponding code behind using TDD to design a domain model. As a result, everything else in the code is the simplest thing that could be implemented to support the overall goal - and nothing more.

Wow - That Was Annoying

hdierking — Mon, 19 Nov 2007 05:18:53 GMT

So I'm in an awkward place right now when it comes to programming. In addition to the fact that I no longer program on a day-to-day basis (which is starting to bug me a little more than it used to as I'm afraid I'm starting to atrophy a bit), I'm also now up on Visual Studio 2008 - which is really great in a lot of respects - but at the same time is kind of bumming me out. I'm not bummed because of anything inherent in Visual Studio - I'm bummed because Resharper just doesn't really work all that great in it. Don't get me wrong - R# works - but the semantic analysis tools don't yet work with a lot of the C# 3.0 language enhancements - and as much as I tried to ignore the R# compiler errors on things like Linq queries, I finally just got tired of it an uninstalled R#, impatiently awaiting the 4.0 release.

Firstly, let me just say that not having R# is miserable from a refactoring standpoint.

Secondly, losing R# led me down the path to another headache (which is the subject of this post) - I no longer have a VS add-in runner for NUnit. Yes, I know - I could (and probably should) go back and download TD.NET - but instead, I was curious to see how easily it would be for me to just convert my NUnit tests to VS 2008 unit tests. In short, it's not terribly difficult, but getting there was a frustrating journey.

Why? Because unlike NUnit, where a test fixture is explicit in code (and only in code) via the TestFixture attribute, VS tests rely on a second piece of metadata in order to have them run via the VS test manager/test runner. That metadata is not found in the *.vsmdi file - instead, it's actually a property in the project file of your unit test project.

Therefore, if you started from a regular class library project and need to have it recognized by VS as a "test project", open the *.csproj file in notepad and add the following to any PropertyGroup.

The first Guid identifies your project as a test project (the second is the language I believe - feel free to correct me if I'm wrong).

Linq-i-fying My Existing Projects - Part 1

hdierking — Wed, 14 Nov 2007 19:09:39 GMT

To be honest, I don't know how many parts there will end up being - since the longer I'm away from day to day developing, the fewer projects I have to go back through. However, I can think of a few more off the top of my head - so I still think that "Part n" is a fair statement.

Anyway, for a sample golfing application, I have the following hierarchy (fragment).

Now, ignoring for the moment the fact that I didn't make Round a generic and thereby avoid the need for it, the following method in Round validates that either Players or Teams can play a round of golf, but not a mixture of both (e.g. - a single player cannot go up against a team).

private void ValidatePlayerTypeConsistency(Player[] players) {

foreach (Player player in players) {

if (!player.GetType().Equals(_expectedPlayerType))

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

Using a C# 3.0 Linq query, the imperative structure of the foreach loop can now be replaced with a more declarative one as follows.

private void ValidatePlayerTypeConsistency(Player[] players) {

bool hasUnexpectedPlayers = (from p in players select p)

.Any(p => !p.GetType().Equals(_expectedPlayerType));

if(hasUnexpectedPlayers)

throw new ArgumentException("Player was not of the expected type ('" +

_expectedPlayerType.FullName + "')");

}

A couple of quick things to notice here:

In the Linq query, the C# 3.0 language extensions do not cover the entire breadth of Linq functionality (e.g. - the "Any" quantifier). When you run into cases like this, remember that it is perfectly acceptable to mix the language extensions syntax with the standard extension method/lambda syntax. You can do this by simply enclosing the language extensions syntax block in parentheses and then calling additional methods on the result.
My Linq query syntax didn't really reduce my total line count and the declarative syntax is arguably harder to read. To this, I can only say a) this is a really simple example and b) like anonymous delegates and generics, you get used to it. That said, this example should illustrate that you should take a pragmatic approach to incorporating new features like Linq into your applications.

A final note here - I am ONLY able to do this type of code replacement because I have a great set of unit tests backing me up. In fact, when I first tried out the Linq approach, my test failed. DO NOT make changes like this to working applications without having good tests to back you up.

Hopefully, I'll bring you some more complex examples soon.

Lambda, Lambda, Lambda!

hdierking — Fri, 19 Jan 2007 01:47:08 GMT

When I first heard about lambdas, I was highly skeptical primarily because I haven't seen or thought about these things since my computer science classes in college. If you need further evidence for my general skepticism, please see the definition of lambda expressions on Wikipedia. However, I was forced to look at them while researching the Linq project, so I decided to spend a bit more time with them and have a deeper look. And as it is with so many things, the more I surrounded myself with them, the more I kind of started to like them. Therefore, I'll spend a few seconds going over how I see them and you can use them.

At the core, a lambda expression is simply a function. You give it inputs, it gives you output. These expressions can then be linked together to build very complex programs. For the mind-numbing explanation, please see the Wikipedia article listed above. Anyways, in .NET terminology a lambda expression is a function that is fulfills the signature requirements specified by a delegate. For a little refresher, consider the following delegate that is defined in the .NET Framework 2.0.

public delegate bool Predicate<T> (T obj)

By the way, if you haven't gotten used to generics yet, I would start now as use of them is dramatically increased in the .NET Framework 3.5. Anyways, the predicate delegate is used by standard .NET collection classes to enable searching by arbitrary criteria. For example, let's say I define the class Person as follows.

public class Person { 
  public Person(string name, int age) { 
    Name = name; 
    Age = age; 
  } 

  public string Name; 
  public int Age; 
}

If I create a list of Person objects, I can filter that list to find all people with an age greater than 10 by creating an instance of the Predicate delegate and passing it to the FindAll method on my List class. The code would look as follows.

   1:  public static void Main() {

   2:    List<Person> people = new List<Person>();

   3:    people.Add(new Person("howard", 29));

   4:    people.Add(new Person("jennifer", 30));

   5:    people.Add(new Person("hannah", 8));

6:

   7:    List<Person> oldPeople = people.FindAll(ageGT10Filter);

8:

   9:    foreach (Person p in oldPeople)

  10:      Console.WriteLine(p.Name);

  11:  }

12:

  13:  static bool ageGT10Filter(Person p) {

  14:    return p.Age > 10;

  15:  }

When the FindAll method is called (line 7), it iterates through my List object and calls my delegate instance (ageGT10Filter - line 13), passing it the Person object at that point in the list. If the delegate instance returns true, that Person object is added to the list returned by FindAll.

C# 2.0 extended this pattern of delegate passing with the introduction of anonymous methods (therefore, when looking at lambdas, I would expect that the concept will initially seem more familiar to C# developers as anonymous methods were not supported by VB.NET in VS 2005). By using anonymous methods, the code block above would look more like the following.

   1:  public static void Main() {

   2:    List<Person> people = new List<Person>();

   3:    people.Add(new Person("howard", 29));

   4:    people.Add(new Person("jennifer", 30));

   5:    people.Add(new Person("hannah", 8));

6:

   7:    List<Person> oldPeople = people.FindAll(delegate(Person p)

   8:      { return p.Age > 10; }

   9:    );

10:

  11:    foreach (Person p in oldPeople)

  12:      Console.WriteLine(p.Name);

  13:  }

As you can see, the delegate method instance is replaced by an inline method declaration (lines 7-9). This provides 2 major benefits to the previous approach: 1) fewer methods and smaller code, and 2) the constant declaration of 10 could be replaced with a user supplied value such as the following.

List<Person> oldPeople = people.FindAll(delegate(Person p) 
  { return p.Age > iValue; });

So now let's look at this implementation in C# 3.0 using lambda expressions.

List<Person> oldPeople = people.FindAll(p => p.Age > 10);

The first thing that I want to point out here is that the argument required by the FindAll method has not changed at all – it still requires a Predicate delegate instance. The lambda in this context is used as a shorthand way of defining the delegate instance. If we then look at the structure of the lambda expression itself, we'll see that it's really very simple.

p	=>	p.Age > 10
inputs (delegate parameters)	Lambda operator	Expression to be evaluated – expression return must match delegate return value type

Now, at this point, you're probably saying, "big deal – this is just a slightly shorter way to do something that I could already do in C# 2.0" – and if this was the only benefit that lambdas brought, you would be correct. However, there is something much, much cooler about lambdas in C# 3.0. This is that they can be treated as data and reinterpreted by other code (metaprogramming anyone?).

Rather than delve into an esoteric description, let's just see an example. Say that I wanted to be able to develop a generic query language – one that would be based on native C# code, but could be translated to all sorts of data sources, like SQL Server (starting to sound familiar??). For example, we would want our database query to look just like our previous in-memory query.

SQLEntityProvider.FindAll<Person>(p => p.Age > 10);

For the purposes of this example, we're going to assume a TON about the mapping relationship between the object and the database. Our generic provider might look something like the following.

   1:  public static IEnumerable<T> FindAll<T>(

   2:    Expression<Predicate<T>> filterExp) {

3:

   4:    StringBuilder sb = new StringBuilder();

   5:    sb.Append("select * from tbl" + typeof(T).Name);

   6:    sb.Append(" where ");

7:

   8:    BinaryExpression expBody = filterExp.Body as BinaryExpression;

9:

  10:    if (expBody.Left.NodeType == ExpressionType.MemberAccess)

  11:      sb.Append(((MemberExpression)expBody.Left).Member.Name);

12:

  13:    switch (expBody.NodeType) {

  14:      case ExpressionType.GreaterThan:

  15:        sb.Append(" > ");

  16:        break;

  17:      case ExpressionType.LessThan:

  18:        sb.Append(" < ");

  19:        break;

  20:      case ExpressionType.Equal:

  21:        sb.Append(" = ");

  22:        break;

  23:      case ExpressionType.NotEqual:

  24:        sb.Append(" <> ");

  25:        break;

  26:    }

27:

  28:    if (expBody.Right.NodeType == ExpressionType.Constant)

  29:      sb.Append(((ConstantExpression)expBody.Right).Value);

30:

  31:    Console.WriteLine(sb.ToString());

32:

  33:    return null;

  34:  }

When the program is run and we examine the console output, we see the following.

select * from tblPerson where Age > 10

Now when you step back and think about it, this is actually REALLY cool – and what enables this coolness is the fact that lambda expressions, in addition to being directly executable, can also be treated as data. This is what enabled me to look through the expression tree and convert the lambda expression elements into equivalent SQL statement elements. So how do you control whether your lambda expression is treated as code (delegate) or as data? Simple – either pass it to a parameter expecting a delegate instance (as in my first case) OR pass it to a parameter expecting a object of type Expression<TDelegate>. The Expression generic type has special meaning in C# 3.0 and parses the lambda expression into a data structure rather than generating IL executable code.

So now that you have a general idea of how this new language feature works, what can you do with it? As is always the case – whatever you want! Personally, I would love to see somebody write an extension to NHibernate to allow use of Linq queries in the place of HQL – so if anyone's looking down that path, please let me know! However, even if you're not running to the bleeding edge to start implementing your own lambda based solutions, I hope that this article has given you just a bit of insight into how Linq works, and how we are just scratching the surface on what we can do with this powerful new language feature!