Setting Up Your Project

For a while now I’ve been creating an Internal folder under the main project, which has folders for the Tools (NAnt, MbUnit, etc), documentation (if needed), libraries, etc. This has been working out well, but I’m probably going to switch the method used by many open source projects, where the top level directory has a src (for your actual source code), lib (for reference assemblies), and bin (for tools) folders. See the image at the right for my current layout.

Notice that those tools, NAnt/MbUnit/NCover/etc, are actually checked into the project. They’re not sitting in my Program Files directory or on some network share. Each project has a copy of all the tools it needs (and everything those tools need to run), which enables not only the build server to pull down everything it needs from source control, but new developers as well. One checkout command and they’re good to build and run the project. This is definitely a time saver, and, if nothing else, I highly recommend implementing this practice or one similar.

For reference, I’ll be using NAnt 0.85 (available here), MbUnit 2.4.197 (available here), NCover 1.5.8 (one of the last free versions available before they became a commercial product - and while this version doesn’t support some of the newer stuff in C# 3 as their commercial version does, it’ll work for our purposes - available here), and NCoverExplorer 1.4.0.7 (which is now also commercial and integrated into NCover, but I have the latest freely copy available here).

The Build Script

Create a file in the root of your project, to hold the actual NAnt configuration to build your project and run its unit tests. I usually name the file ProjectName.build.

Please note that all of the empty XML tags in the example below can be shortened to the normal <tag attribute="" /> format, but my syntax highlighter is being a butt and adding the closing tags no matter what I do, so I just added them in the proper place myself in this post. The code in the downloadable solution at the end of the post should be formatted normally.

A couple of quick pointers for working with NAnt:

1. The word artifacts, as in most build systems, refers to anything produced by the build system itself, such as reports, executables, installation files, documentation, etc.
2. Variable declaration/use:

3. Method declaration (normally called targets):

4. Outputting text to the screen:

You start a NAnt build script with <project /> tags, which specifies the project name and the default target (method) to run when one isn’t specified by the calling application:

Now for the meat of the build script. Let’s start off with a few basic parameter declarations:

These specify the path to the build directory, where the MsBuild executable is on the machine (which we’ll use in a later section), where the tools are located, and where to output various artifacts. All of these paths are relative to where your build script is located, so if you placed it in your root folder with your Visual Studio solution file, these paths should work out.

Next we’ll specify a four targets (methods); two to act as convenience targets that call out to other targets, one that cleans the current build artifacts, and the last one that compiles the project:

Notice that the build-server and full-build targets use the depends attribute, which will call out to each of the specified targets, in order. The build-server and full-build targets are identical except for the last target call, publishOutput. Discussed below, this target will copy the library’s build outputs to our file share for everyone to access. Since we only want to do this on the build server, and not when ran locally, we’ll name the target differently.

The clean target just deletes the bin directory if it exists, and the compile target will call out to the actual MsBuild.exe to compile the solution.

There are built-in NAnt tasks (or available in the NAnt Contrib project) that will compile solutions and do a few of the other tasks that I’m doing by hand, such as running NUnit and building installers. I prefer this method, though, for more control over what’s getting called and less breakage when upgrading various tools.

OK, so I go and say that, and now show you the unitTests target, which uses a custom NCover task. I made an exception for this step, since NCover normally requires a special COM object to be registered before it’s ran, which I had no interest of doing through a script. The custom task takes care of all that:

As the comment says, the NCover task will set itself up as needed, then call MbUnit to run through the unit tests, while it basically keeps an eye on what parts of your code are getting called. NCover then produces a report listing each function point (usually equal to a line in your code) that was hit while the unit tests ran. More function points being called == higher code coverage percentage.

This next target will call out to NCoverExplorer, which simply takes in the NCover report made in the previous target and generates a report of its own for use in its GUI app, along with a nice little HTML report for display in CruiseControl.NET’s interface later on:

Now we simply copy the project’s output (or in our case, the .dll from the extension library) to an output directory. I usually have it copy it to a commonly accessible file share for easier access:

An optional last step is to create a batch file in the root of the project which simply calls out to the NAnt executable, passing in your new build file as a parameter. This batch file can then be ran to kick off the full build script by calling build.bat full-build:

@MyExtensions\Internal\Tools\NAnt\NAnt.exe -buildfile:MyExtensions.build %*

Which runs through and results in a nice little “BUILD SUCCEEDED” message:

Gives me the warm and fuzzies every time.

Well, that’s pretty much it. A very basic build script, but it gets the job done. I’d recommend poking around the build scripts for more popular open source projects to get better idea of what these scripts are really capable of automating for you. Take a look at Ninject’s for building a public framework that targets different platforms, or Subtext’s for building a website solution.

A skeleton project setup with this build script, complete with the needed tools and everything, can be downloaded here.

In Part 3 I’ll go over setting up a basic build server using Cruise Control.NET. The build server basically just calls out to this build script, so, thankfully, the bulk of the job is already done.

Build Scripts

These are simply scripts that another program parses and executes to build your project, usually doing everything from wiping your build directory to running unit test and integration tests, to possibly creating and destroying test databases. Build scripts can range from simple batch files to more complex NAnt scripts.

Actually, you may not realize it, but you’re probably using build scripts already. Starting with Visual Studio 2005, MSBuild has been used behind the scenes to automatically build your solution when you hit Build -> Build Solution. MSBuild can also be used independently in much the same way as NAnt scripts, and in fact many people consider these two build systems to be the most mature/robust for the .NET environment. They both consist of a lot of XML, though, so put on your goggles before taking a gander at any examples. There’s also the Boo Build System (though I think its been renamed to Bake due to its original initials) that’s based on the Boo language, psake based on Powershell, FinalBuilder for a graphical approach, and rake that’s built on Ruby, among many others.

So build script are read by a build system, and executed. Complicated batch scripts, basically. They can be run locally, and many people actually opt to run these scripts instead of using Visual Studio’s build command once they get a good script setup, or they can be run automatically by other programs. I haven’t gotten to the point of replacing Visual Studio’s build command yet, but I can see its benefits.

Continuous Integration Servers

These little beauties generally run on their own box, and can either poll your source code repository (in whatever form it may come, be it Visual Source Safe, Subversion, Git, etc.) or run on a schedule, basically kicking off your build script whenever it sees changes. For instance, if you check in an update, the build server will see that update, clean its local copy of source code, do a full update of the source code locally, then run the build script you normally run on your box, building the code and running all sorts of tests. It can then go a step further and start copying the output to a staging server for your customers or testing folks to take a sneak peek at.

Continuous Integration (CI) servers come in quite a few flavors. One of the more popular in the .NET world is Cruise Control .NET (CC.NET), though it too has a heavy reliance on XML. JetBrains (the guys that make ReSharper) have released TeamCity as a free download (for up to 20 user accounts and build configurations, and 3 build agents), which has an awesome web interface and lets you get a server setup in no time. It has built in support for quite a few features, and even comes with a plug-in for Visual Studio that lets you run a fake build locally on your machine before doing a code check-in. There are quite a few other CI servers out there, but these are the only two I’ve had time to play around with.

Setting Up a Build Script and CI Server

New with C# 3.0 comes extension methods, which I’m sure everyone’s heard of, and I’m equally sure that everyone has a small collection of handy ones in some sort of extension library. This library is probably shared across projects, and any developer wishing to use it in their project needs to do a get latest from the source code repository, build the solution, find the compiled assembly on their machine, and copy the it into their project. This repeats if they want to update their project’s copy, too.

Seems like a lot of steps just to use or update the library, huh? Let’s tidy that up a little, by:

1. Setting up a build script using NAnt, which will:
• Clean the /bin folder
• Do a full recompile of the source code
• Run FxCop to check for out of place coding standards
• Run MbUnit (my testing framework of choice)
• Run NCover (using the latest freely available copy)
• Run NCoverExplorer, which will generate a neat little XML file you can use to graphically see your code coverage (again, using the latest freely available copy)
• Be able to run locally on each developer’s machine, if they so choose
2. Setting up a continuous integration server using Cruise Control .NET, which will:
• Both periodically poll the source control server for any new commits, along with just running at a set time every night
• Clean its source code copy and run an update from the source control repository
• Run the build script previously created
• Email any developer that checked in code during this run with an update on the fail/pass status of the build
• Allow any developer running a handy-dandy desktop app to instantly see the status of the build server (success, failure, building, etc)

Alright, alright, so this might not seem like it’ll really tidy up anything right now, just add a crap load of work to our plates, but trust me, it’s not as bad as it looks. A lot of this can be heavily templated across projects too, so once you cut your teeth on it, it’s tremendously easier to setup again going forward.

In Part 2, I’ll talk about setting up the build script using NAnt.

try
{
	SomeOperationThatThrowsAnException();
}
catch(Exception ex)
{
	throw;
}

Or:

try
{
	SomeOperationThatThrowsAnException();
}
catch(Exception ex)
{
	throw new Exception("Some Operation threw an exception");
}

Or anything else along those lines. They add nothing meaningful to the situation, and only aid to obfuscate the call stack when debugging. The only reasonable time you should catch an exception, in my opinion, is to somehow recover the operation, or add meaning and context to it. For example:

int userID = 20;   // Already a class member or passed in as a parameter.

try
{
	SomeOperationThatThrowsAnException(userID);
}
catch(Exception ex)
{
	throw new Exception("Couldn't do an operation on userID \"" + userID + "\".", ex);
}

Granted, there should probably be a logging facility setup to handle this type of stuff, or a more robust exception framework that will dump all needed local variables, but you get the idea. The exception is essentially being rethrown, but with more context to help debug the problem later on.

Also, remember that you can have a try/finally block with no catch. There’s no need to throw a catch block in there and rethrow just to get the benefits of cleaning up your resources. This is perfectly legal:

try
{
	SomeOperationThatThrowsAnException();
}
finally
{
	// Cleanup resources.
}

Here’s the entry, which got me a second place finish:

http://devlicio.us/blogs/sergio_pereira/archive/2008/07/07/doing-a-180-in-a-matter-of-months.aspx

After setting up a build script for the project and adding it to our continuous integration server (which I’ll blog about shortly), I found a few check-ins that were breaking old unit tests. Emails were automatically sent out, by the CI server, about the failed tests and broken builds, but it turns out too many of us were forgetting to run the unit tests before doing our check-in (obviously). We don’t have TestDriven.Net or Resharper - though we’ll likely be ordering copies of the later any day now - so we have no easy way of running the tests besides the standard MbUnit GUI. Yuck.

A few days later I ran into this helpful piece of information, I think perhaps from JP Boodhoo, though I’m not positive. Anyway, if you have a separate assembly for your unit tests, simply go to the property page of that project, click the “Build Events” tab along the left, and enter this in for the post-build event:

"$(ProjectDir)..\UtilityLibrary.Core\Internal\Tools\MbUnit\MbUnit.Cons.exe" "$(TargetPath)"

This statement assumes you have your project checked out to something like C:\MyProjects\UtilityLibrary, and under there you have UtilityLibrary.Core for your actual code, and UtilityLibrary.UnitTests for, well, your unit tests. This command starts in the UnitTests forlder, goes up a directory (into C:\MyProjects\UtilityLibrary) and right back into the Core folder, which has the MbUnit library/program in it. If your situation is at all different, you’ll have to adjust this command accordingly, but it’s a good start.

Now your unit tests will be ran as a step in compiling your solution, and the compilation will fail if any of the unit tests fail:

Useful for smaller utility projects like this, but I imagine it’d become a pain in the ass for larger projects that take a bit of time to compile on there own, never mind having to run the unit tests on top of that every time. Sometimes you just want to see if the code compiles, not necessarily run all the tests too.

They’re hard. Sure, they might seem easy at first glance, but they are both deceptively hard. This is especially true if you have any sort of background in your problem domain, and let’s face it, most of us do if we’re writing the usual problem tracking or invoice tracking applications. You know what I’m talking about: you start with an empty solution in front of you, tasked with creating your companies next, say, customer management system, and you start walking through the new application in your mind.

“Well,” you say to yourself, “I’m going to need a Customer object, a customer repository to store the object, a Job object, maybe an invoice object, tables and repositories for each of those, and I’m sure they’re going to ask for filtering next, so I might as well save myself the time and throw in a few specification and filtering classes.” This process goes on for a while and before you know if you’ve pumped out a few dozen classes and added all sorts of neat functionality.

Odds are, though, some, if not most, of those classes will end up either going unused or be heavily modified before the features are finished. Hence the above two principles (or ideas or whatever you want to call them). Wait until the last reasonable moment to add additional complexity to your application, but do so with a bit of judgment. Sometimes you simply know you’re going to need something, like a database back-end, so don’t start with text files just for the sake of keeping it simple. For the vast majority of decisions, though, you should use the simplest implementation until you find justifiable evidence that proves you need something more complex.

KISS and YAGNI go hand-in-hand with test driven development. Write your test, then write the simplest code you can to make the test pass. The code can always be refactored later to extract classes, interfaces, patterns, et cetera. I understand that your training as a developer is hard to resist - that urge to create things you’re pretty sure you’ll need while you’re working in a particular area. Resist it.

I’m starting on a new project at work, and it’s a particularly large project at that. It lends itself incredibly well to TDD, and so far the YAGNI ideal and TDD practice has proven themselves very versatile and helpful. As we’re unsure on how to split up the work load this early in the project, we’re working together (3 developers) on a machine with a projector. We’re constantly reminding each other not to over complicate things and toss in hooks and features we might someday need. Trust me, I literally mean almost every feature we add we’re reminding each other to go with the simpler implementation, because it really is that hard to overcome. We’re trying to stick to today, not tomorrow, by making it simple, making it fast, and making it easy to understand. I think we’re doing a great job of it so far.

We’re also well assured that the dozens and dozens of unit tests we have, along with the multitude of user generated acceptance/integration tests, will give us the safety net we need to refactor and introduce new features as we move forward. I, for one, am quite looking forward to what comes next.

So I figured I’d go ahead and implement some quick caching around this by storing the strings in generic static Dictionary, especially as the method itself was static. As I’m still trudging up the steep hill that is the learning curve of Test Driven Development (TDD), I thought I’d get a failing test in there first, then make it pass. An interface for dependency injection and a mock or two later and it works. All is good and well in the world.

Unfortunately, it didn’t take long for me to realize there were some serious threading issues going on. Whoops. So I started writing up a unit test to fail on the bug before I fixed it, and in the process of creating a bunch of worker threads to hit the method at the same time, I stumbled across a nifty feature in MbUnit: the ThreadedRepeate Attribute. Behold, a fake example:

[Test]
[ThreadedRepeat(5)]
public void Should_handle_multithreaded_access()
{
	Assert.IsNotEmpty(MyClass.GetExpensiveString());
}

Just like the normal [Repeat(5)] attribute, which would simply call the test 5 consecutive times back to back, the [ThreadedRepeat(5)] attribute will call the test 5 times in parallel, firing off a separate thread for each one.

Pretty freakin’ nifty if you ask me, and a whole lot easier than having to write your own code to spin up a bunch of worker threads.

public class Person
{
	// Original way:
	private string _name;
	public string Name
	{
		get { return _name; }
		set { _name = value; }
	}

	// New, automatic property, way:
	public int Age { get; set; }
}

Using the second example, the compiler will basically create a private Age member in the background and use in the generated getter/setter of the new property. If the it’s a numeric type, as Age is, it will default to 0. If it’s a reference type, such as another class or a Nullable type (i.e. int?), it’ll default to null.

Now for the semi-gotcha: strings are reference types, so they’ll default to null. This may not be a problem in your situation, but I personally like to default all of my string to string.Empty (unless the situation calls for a null, which I find isn’t very often). I just don’t like the hassle of dealing with null strings, though the string.IsNullOrEmpty() method helps mitigate that.

So there ya go. Take it for what it’s worth - something to keep in mind when using the new automatic property feature.

Do I think it was worth it, in terms of the time (7 AM to 6:30 PM on a Saturday with decent weather) and money (gas for a 100 mile round trip and lunch) invested? Well, lets take a look at each of the six presentations I attended and then at an overview of the whole event:

1. Why Ruby? - Joe O’Brien
   • Joe started off by saying this wouldn’t be a talk about specifics in Ruby or a 100 level intro, and he delivered on that. Instead, he focused on some neat features of Ruby that’d make a seasoned developer want to dabble with it and potentially jump ship. I’ve seen a bit of Ruby glancing through blogs and articles, and even wrote one or two very basic learning applications in it, so I was glad he skipped the syntax basics and instead focused on things such as catching missing methods and then relating that to O/RM and enterprise development uses.Ultimately, I thought this was a great talk. Joe was quite the funny presenter, kept me engaged the whole time, recovered very gracefully from a few presentation hiccups, showed some neat examples, and renewed my appetite for Ruby. It was a nice presentation to start out the day, for sure.
2. Introduction to Test Driven Development with the ASP.NET MVC Framework - Alan Stevens
   • Alan began with an intro to the ASP.NET MVC Framework and followed up with a few live coded unit tests. While I liked his presentation style (his excitement for this stuff was contagious), I wasn’t too impressed with the content. It was very solid information, but I had some higher expectations going in, and he only got around to doing basic unit tests to check the rendered view and such things. Nothing really new for me there, unfortunately, but it was still nice to hear the MVC architectural pattern explained from a different point of view.
3. Software Ninjitsu: Designing for Change - Nate Kohari
   • Focusing on the foundation of object design - cohesion and coupling - then moving onto the basics of Inversion of Control (IoC) using his Dependency Injection (DI) framework, Ninject (which I’ve looked at before and is actually pretty neat), Nate delivered an awesome presentation. Admittedly his first large one, he handled a failing projector halfway through the presentation with ease, and the room was packed with standing room only. He touched briefly on a few other aspects of his framework such as Aspect Oriented Programming (AOP), but he stuck to the basics of IoC very well and presented them, at least I thought, in a very logical fashion. His gratuitous use of ninja references was actually pretty funny (although you couldn’t expect anything less with a session title like that) and was a nice change of pace.The only thing I would have liked to see was some more live code. He stuck to Power Point (or whatever the Mac equivalent he was using was) pretty good, though a bit of Visual Studio and bigger examples might have helped a bit, I think. Overall it was a great presentation though.
4. Ouch, that hurt! Lessons Learned from an Agile Project - Michael Eaton
   • I was looking forward to this session the most. My team is currently shifting into a RUP/Agile methodology (and actually had a nice 2 hour discussion on this the Friday before this event), so I asked Michael if I could tape the talk with the hopes of showing it to the rest of my team when I got back to work. It was a good talk, reminding everyone about the major pain points in project management: communication, buy-in, estimating, etc. Some were client specific while some were more common. It spurred some interesting discussion from the crowd though, and Michael’s slide deck was a pretty funny addition. Also, while I could also see where he was coming from in the talk, the fact that he concentrated on one single job as an example, out of the many I’m sure he’s worked on, made parts of the presentation seem like a rant instead being informational.Unfortunately, in the end the presentation wasn’t exactly what I’d thought it’d be. While we did hit a lot of common pain points, to me they weren’t really related to, or caused by, any particular Agile methodology. They were just general issues that most everyone - including my team - has dealt with in the past. Helpful to be sure, but I was looking for issues relating specifically to a flavor of Agile, such as TDD acceptance, short iteration deliverables, pair-programming acceptance, stand-up meeting issues, planning problems, etc.
5. Data Access with NHibernate - Len Smith
   • Len started off with a quick intro to O/RMs in general and why you’d want to use one, then jumped into talking about various aspects of NHibernate interlaced with live code examples. His examples were pretty decent, using unit tests as quick code harnesses to show off various features like batch queries, lazy loading, SQL query inspection, etc. Pretty standard stuff, and I thought he did a good job explaining it, along with answering a few questions that popped up through the session such as the ability to use NHibernate along side current data access code during a transition period (to which Len just suggested rewriting your data layer). Like Nate Kohari’s talk, he used a lot of pirate and ninja references which I thought was pretty cool.
6. Intro to the IronPython Flying Circus - Sarah Dutkiewicz
   • Sarah began by making a case for Python then jumping right into some examples of IronPython, using gratuitous amounts of Monty Python references of course (Ni!). She showed a few basic features of Python and IronPython using the interactive command line tool, including how to use those little animated people from the Windows XP first install wizard. She did a really good job presenting a high-level overview of the features, I thought.

There’s a few other presentations that sounded really interesting and I would have loved to see, and in hindsight I should have floated between some of these sessions to get in a little more more material. I’ll have to keep that in mind for next time.

1. Silverlight in ASP.NET - John Stockton
2. IronRuby, the DLR and Silverlight - Carey Payette
3. A Look at F# - Amanda Laucher

Now, as for the event as a whole I’d have to give it a thumbs up. Everyone got a free, decent quality, tee-shirt upon sign-in, which was neat (standard logo + sponsors white tee). They were giving away books in nearly all the sessions for various reasons, and also gave out licenses to some nice software and an XBox 360 at the end, but I didn’t win anything

I met a few people there from the Akron area, though I wished I would have networked a bit more. As Michael Eaton put in his review, the small hallways and constant moving of hotel staff made it tough to talk to anyone between sessions.

Attending this event has also peaked my interested in presenting on a topic at some point, perhaps starting with one to my co-workers (though I sort of did one on Linq To SQL a while ago). I’d love to have something to present, and the ability to do it, at a future event like this.

Overall I thought the event was well worth the time and money invested (it being free and getting free swag sure helped). I met some nice people and picked up a lot of new information, and I’m looking forward to attending next year.

Too bad Cleveland is the nearest .NET user group, and they usually start at like 6 PM, as I’d love to attend a few of those but scheduling is usually too tuff. That’s why I’d like to get the ball rolling on the CantonALT.NET user group, so we can spark some local discussion and interest.

Say you have a method with some hard coded strings:

public string WrapWithSingleQuote(string text)
{
	return "'" + text + "'";
}

Now in your next iteration you’re asked to wrap any needed text in double quotes and/or parenthesis. Being the awesome developer that you are, you generalize the method like so:

public string WrapWithString(string text, string wrapper)
{
	return wrapper + text + wrapper;
}

See that? The wrapper parameter that allowed you to pass whatever you want to wrap the text in? That’s a simplistic and primitive example of the strategy pattern, but an example nonetheless. Now the method allows you to wrap the given text in whatever characters your heart desires.

Now for a bit more robust and real world example of the pattern. Let’s consider the .NET WinForm’s TextBox control. This control has auto-complete functionality built into it to, able to suggest completed entries based off the currently entered text from a variety of sources: file system, URL’s, a custom source, and more.

A few requirements come in stating that the users want auto-completion for the company text box in their mythical application, so you whip up the following user control:

public partial class CompanyFindTextBox : TextBox
{
	public CompanyFindTextBox()
	{
		InitializeComponent();

		this.AutoCompleteMode = AutoCompleteMode.Suggest;
		this.AutoCompleteSource = AutoCompleteSource.CustomSource;
	}

	public CompanyFindTextBox(IContainer container)
		: this()
	{
		container.Add(this);
	}

	protected override void OnKeyUp(KeyEventArgs e)
	{
		HandleAutoComplete(this.Text.Trim());
		base.OnKeyUp(e);
	}

	private void HandleAutoComplete(string searchText)
	{
		if(searchText != string.Empty)
		{
			using(DatabaseDataContext db = new DatabaseDataContext())
			{
				var matchingCompanies =
					from c in db.Companies
					where c.Name.ToUpper().StartsWith(searchText)
					orderby c.Name
					select c.Name;

				this.AutoCompleteCustomSource.AddRange(matchingCompanies.ToArray());
			}
		}
	}
}

Now, of course, the users want the same functionality on their job, candidate, contractor, and who knows what other text boxes. Looks like a refactoring is in order. Ah, but this time there isn’t a simple string to extract as a parameter to fix the problem! You need to generalize your LINQ statement, but each text box type is searching on different databases, fields, etc.

This where the power of the strategy pattern comes in. With it, you can tell the control/method how to go about executing a certain algorithm. Specifically, in C# we usually use delegates (which are nothing more than methods passed into other methods as parameters - or function points from lower level languages). Since C# 3.0 introduced lambdas (simply more concise ways to declare delegates), let’s go ahead and use those. Here’s a more generalized user control which uses the strategy pattern to pull out the specific database accessing code:

public partial class EntityFindTextBox : TextBox
{
	public Func AutoCompleteStrategy { get; set; }

	public EntityFindTextBox()
	{
		InitializeComponent();

		this.AutoCompleteMode = AutoCompleteMode.Suggest;
		this.AutoCompleteSource = AutoCompleteSource.CustomSource;
	}

	public EntityFindTextBox(IContainer container)
		: this()
	{
		container.Add(this);
	}

	protected override void OnKeyUp(KeyEventArgs e)
	{
		HandleAutoComplete(this.Text.Trim());
		base.OnKeyUp(e);
	}

	private void HandleAutoComplete(string searchText)
	{
		if(AutoCompleteStrategy != null && searchText != string.Empty)
		{
			this.AutoCompleteCustomSource.AddRange(AutoCompleteStrategy(searchText));
		}
	}
}

Notice how this implementation has a function property named AutoCompleteStrategy. This says we’re looking for a method that takes in a string and returns an array of strings. Now in the HandleAutoComplete method, we make sure this isn’t null and call it with the text box’s contents. This abstracts out the actual database searching algorithm so the new user control can be used with any type of entity the system needs, be it companies, jobs, contractors, etc. That’s the strategy pattern in all its glory.

After dropping the new control on a form, you might set it up for a company like so:

txtCompanies.AutoCompleteStrategy = (searchTerm =>
	{
		using(DatabaseDataContext db = new DatabaseDataContext())
		{
			var matchingCompanies =
				from c in db.Companies
				where c.Name.ToUpper().StartsWith(searchText)
				orderby c.Name
				select c.Name;

			return matchingCompanies.ToArray();
		}
	});

Now we’re setting the AutoCompleteStrategy property to a new lambda expression (think quick method declaration) that’s accepting a string parameter named searchTerm and using it in the same LINQ query from before, ultimately returning an array of company names which contain whatever was passed in. We could do this for a job text box just as easily, simply swapping out the LINQ statement for a new one (or even XML file searching, a web service call, whatever).

Simple enough, right?

A Data Transfer Object (DTO) is a plain old CLR object (POCO) mainly used to pass data between tiers and remote calls. They’re basically classes with getters, setters, and perhaps a constructor or two, but no methods. They’re dumb objects that simply hold data.

So why would you use these? A few reasons:

1. They flatten your data. DTO’s can contain information from a multitude of sources (database, XML, web service, etc) all neatly packaged together, including any large hierarchies of data from your relational (SQL) store.
2. They more easily allow parameters to be passed into and out of methods, especially expensive ones like web services. You’re not forced to break a web service’s signature if you need to add/remove parameters if you pass in a DTO. The DTO can change and clients aren’t forced to immediately update. They also help keep method signatures nice and tidy.
3. They help decouple your layers by remaining technology and location agnostic. If your relational data moves around, you simply have to modify your data layer (or your business layer if you’re passing DTO’s back for presentation reasons) to get the needed information. The consuming layer won’t care that the data is coming from somewhere else, they’re just looking at the DTO’s copy.

The setup

Let’s look at a simple scenario. We’re loading a business object and calling out to our data layer for the information, which we’ll get from SQL using LINQ to SQL. The following DTO will be passed back:

public class PersonDTO
{
	public string FirstName { get; set; }
	public string LastName { get; set; }
	public int Age { get; set; }
	public decimal HourlyWage { get; set; }
}

The code

Let’s look at the GetPerson method from the data layer, which uses LINQ to SQL to retrieve the needed information from SQL:

public PersonDTO GetPerson(int personID)
{
	using(DatabaseDataContext db = new DatabaseDataContext())
	{
		return (from p in db.Peoples
			    join pw in db.PeopleWages on p.PersonID equals pw.PersonID
			    where p.PersonID == personID
			    select new PersonDTO
			    {
					FirstName = p.FirstName,
					LastName = p.LastName,
					Age = p.Age,
					HourlyWage = pw.HourlyWage
			    }
			   ).SingleOrDefault();
	}
}

The key bit is the select new PersonDTO and its four accompanying lines. It might look a bit odd, but it’s the new object initializer syntax added to C# 3.0. The compiler is basically creating a constructor in the background, taking in the specified parameters, and setting their respective property values.

This keeps your simple select methods such as this visually clean. No need to return a LINQ object and set each property in a separate call. OK, not a huge positive, but hey, it’s the small things that count. I personally love clean, slick, code.

Also note the SingleOrDefault() call at the end, which will return a single object from the LINQ statement (which in this case is of type PersonDTO) or a default value for that object if one isn’t found (and since we’re selecting a reference type, it’d return null). SingleOrDefault() will throw an exception if more than one record is returned from SQL, but since we’re looking for a primary key here, it shouldn’t be a problem.

As a side note, one of the neat features of Visual Studio 2008 is the IntelliSense’s ability to filter the already assigned properties within the object initializer portion of the LINQ statement. For instance, notice how it’s hiding the FirstName property in the pop-up since I assigned it in the line above:

To wrap up, here’s the CreatePerson method, on the Person object in the business layer, that would consume the above GetPerson method:

public Person CreatePerson(int personID)
{
	using(PersonDTO personDTO = DataLayer.GetPerson(personID))
	{
		return new Person
		{
			FirstName = personDTO.FirstName,
			LastName = personDTO.LastName,
			Age = personDTO.Age,
			HourlyWage = personDTO.HourlyWage
		};
	}
}

Notice how it too is making use of the new object initializer feature.

So what’s up with the title? “Taller Code”? Well, it derives from two sources:

1. I’m on a personal journey of self betterment (relating to software development anyway). I want my code to get bigger, better, and “taller” in the metaphorical sense, and I want to drag as many of my peers as I can along with me.
2. I’m a bit over 6′4″, so some would say I’m pretty tall myself.

Retarded? Perhaps. Cheesy? Sure. The result of picking a name first and trying to think up an explanation for it afterwards? Definitely.

It works though, and I’m hoping it sets a tone for my future posts and gives me a bit of a goal to keep in mind while working on them.