Satisfying A Pair of Same-Typed Dependencies with Autofac

We'll take a break from the series on Windows services this week and cover some more Autofac / IoC / DI material. I hope to finish the services series with the final part next week.

Back in December I wrote a rather long post about the different Autofac relationship types. I covered what I considered to be the big ones, but there were a few that I didn't cover: IIndexed, and Keyed. I had an objection to these types that prevented me from examining them any further.

My Initial Objection

It's pretty simple. I don't want to have to reference the the IoC container framework in my classes. Accepted wisdom on IoC container usage is that you shouldn't reference the container, and I viewed this as an extension of that. Indeed I prefer to avoid referencing such infrastructure frameworks in core code wherever possible.

I feel the same way about the BCL's TypeConverterAttribute, and the XML serialization attributes, for example. It's an insidious form of coupling, and I really prefer to avoid having these little signposts sprinkled throughout the code of what framework I'm working with. Especially if they represent things that I can't sub out for testing, as is usually the case with the BCL.

In addition to the framework reference objection, I felt that this was just not a responsibility that belonged to the subject class. Using special parameter types or the like to denote such information was "cheating", akin to service location, and undermined the principle of Inversion of Control.

The purist in me had dug in on two separate fronts, and was ready for a fight. But recently I had an experience that taught me the value of these relationship types: I found I needed to inject two different implementations of the same service in the same place. I initially shied away from these relationship types. Instead, I decided I could solve the problem with a clever registration/configuration. After all, deciding who gets what implementations is what that's all about, though typically in a more generalized sense.

The Problem

My situation was that I had needed two different runtime instances of an image cache. One for full-size images, and one for thumbnails. And most commonly I needed to reference both of them in the same scope. If the two use cases existed in different contexts, I could possible use Autofac's nested container support to identify each one appropriately when needed. But in my scenario, I actually had a couple of classes that needed to make use of both caches. I gave the constructor for that class two parameters for injection, both having a datatype of the cache interface type. Then I went to work setting up the registration.

Without a major redesign, the solution has to involve attaching some metadata to each of two separate instances registered with the container. The container needs some way to differentiate between the instances. Since Autofac provides it, there's really no reason at all not to use the keying facility for registration. Given an interface ICache and an implementor Cache, the registration would look as below.


Now let's introduce another class that needs to use both of these caches.


Again, my instinct is to say that the class shouldn't have to say anything else. It's the container's job to figure out how to fill those dependencies. But what information does the ImageBrowser class expose that the container registration could use to determine which argument gets which instance of ICache? Well right now, there's not much there. Pretty much just the argument names. Can we use those to assign the ICache instances? Yes, but it ain't pretty.

OnPreparing1

The way to access the parameter names for resolution is to hook the OnPreparing event, as seen here:


Our implementation of OnPreparingImageBrowser then looks like this:


This looks harmless enough, if a bit verbose. But is a problems. We have encoded parameter names in strings in our registration code. If we ever have to change those parameter names, or add more dependencies to the constructor, this registration code for ImageBrowser will be broken, but it will still compile. So unless you have some pretty magnificent tests for your IoC registration (which it seems is not easy to do), this is a regression bug waiting to happen. Furthermore, this code is very likely useless even if we have another class with these same dependencies. If the constructor arguments are named differently, we'll need another delegate for that set of constructor arguments.

So obviously argument names aren't the ideal way for the subject to communicate information about multiple dependencies of the same service type. And even using the argument names undermines my objection in spirit. It just does it implicitly, rather than explicitly. So let's just accept that we've already taken the first step and go the rest of the way. How can we communicate the necessary information in a sustainable way, that doesn't require us to go mucking around in the registration code if we shuffle things around a bit in ImageBrowser?

Three options spring to mind. One would be to use an attribute applied to the arguments of the constructor. But there's no native support for recognizing these in Autofac, so we'd have to write our own registration and resolution conventions. While it would be more resistant to change than the named parameter mechanism, it would require even more code on the registration side of things, to set up a convention-based registration that keys on the attributes. Not to mention having to define the attributes. This actually sounds like a fun exploration for another day. But today, we just want to get this working with a small amount of intuitive code.

Autofac has two mechanisms which we can use to reduce the amount of code we need here: IIndexed and Meta.

IIndexed<TKey, TComponent>2

Using Autofac's IIndexed mechanism is a simple change from where we are now. It involves a small change to the constructor of ImageBrowser, and removing code from the bootstrapper. That's right, a net reduction in code, without losing functionality. And there's nothing better than a good codectomy. So grab the scalpel and sculpt our new bootstrapper.


Note the removal of the OnPreparingImageBrowser method, and the reference to it in the ImageBrowser registration. That's the only change here. It's completely unnecessary code. The cache registries don't need to change because the IIndexed mechanism hooks right into the keyed registration just like our old strategy did.

The ImageBrowser constructor needs to change a bit to trigger resolution using the keyed registration. Here's the updated class:


The only change here is that we consolidated the separate cache arguments into one dictionary-style argument.

Meta<TComponent>3

Autofac's Meta mechanism works a little differently in that it allows you to attach data to a registration, and then to express a dependency on that metadata, in the subject class. The data takes the form of name/value pairs. If we wanted to use this, it would change our registration as follows:


We've replaced the call to Keyed with a call to WithMetadata. We also are essentially passing a name-value pair. There's also the option to attach an actual custom metadata object, and use the property names and values as the name/value pairs. Since we only need the one value, and it's not going to be changing at runtime, we can just directly assign the name and value easily.

Once again our constructor will need to change, of course. Here's the version that uses the metadata:


Here we're using the IEnumerable relationship type to get all the metadata objects, and then explicitly picking out the ones with the two with the values we're looking for. The CacheTypeChecker method is just a little comparison delegate generator that saves a bit of repeated code in the constructor.

The Lesser of Two Evils

Now this isn't necessarily the problem that Meta or IIndexed are meant to solve. It's really more meant for cases where the needed component is going to depend on runtime conditions. In that case, a simple service finder/locator is sometimes exactly what you want. There are often other ways to get the job done even then however, for example using lifetime contexts and contextual state objects to give the container all the information it needs.

In our case though, the dependency that's actually being injected bothers me a bit. It's sort of a limited service locator. The problem with that is that the specific dependencies aren't explicit. ImageBrowser is basically saying, "Er, I can't tell you exactly what I want, but if you give me everything like this, I'll pick out the ones I want". That is definitely not a pure inversion of control in this case, because we need exactly 2 instances of a very particular type.

We're basically limited to choosing the lesser of two evils. Do we couple to constructor argument names, or take a dependency on a service locator? I'm not sure I feel more strongly about either one. But the IIndexed option is definitely the least code, so that's the one I'll go with. And you can bet that if I run across a situation where the decision of which instance I need is made at runtime, I'll look to these solutions first.

Somewhere down the line I'll investigate that attribute convention option I mentioned in passing. I tend to dislike attributes, but if it's our code (rather than framework code) that does both the defining and the consuming... then maybe I can live with it.


GitHub Source Code References
  1. Keyed registration with OnPreparing resolution
  2. Keyed registration with IIndexed<TKey, TComponent> dependency
  3. Metadata registration with Meta<TComponent> dependency

Anatomy of a Windows Service - Part 2


This post contains gist code samples. My experiments indicate that these do not display in Google Reader, so if you are reading this there, you may want to click through to the post.

Last time, we dissected a Windows service template project to get a handle on the different moving pieces.  We identified an installer class, as well as two run-time configured installer objects, a service class, and the framework injection point for spinning up a service.

The template is a very simple project, and it gets the job done.  There are some deficiencies though.  From an architectural standpoint, the design doesn't lend itself well to testability, or composability.  It also doesn't provide any good place to bootstrap an IoC container for the installer portion, which would be beneficial to have if we want to have any custom behavior happening at install.  From a feature standpoint, there's no logging, and no worker thread to separate the service control events from the actual behavior of the app.

Let's start out by improving the composability, which will put us on a good footing for testability as well.  The biggest obstacle to that in the template project was all of the direct instantiation and configuration of objects.  For example, in the template project, the ProjectInstaller class's constructor, which is an entry point that is triggered directly by msiexec or installutil, was responsible for creating and initializing the sub-installers.  In our application, we'll defer to an IoC container, rather than construct these objects directly.

Let's add a reference to my personal favorite IoC container, Autofac, and then create a bootstrapper that will do the registration necessary for the installer portion of the app. We'll leave it empty to start, because we haven't established what we'll need from it yet.


Now lets create the ProjectInstaller.  The constructor, since it's an application entry point, will have a direct reference to the IoC container.  We'll leave out the needless code we identified last time, but don't forget the crucial RunInstaller attribute.  The constructor is left responsible for setting up the Installers collection.  If we assume that we'll be registering all our installers with the IoC container, then Autofac makes this easy for us with the IEnumerable relationship type, which will resolve all implementors of the specified service that are available at the resolution location.  Let's put all that together and see what we get.


Compared to the template project, we've eliminated some explicit object instantiation, but we've also lost some explicit configuration.  That has to be exported to somewhere else.  There are a couple of options for re-creating this functionality with our IoC container in place.  One is to give these exact configuration responsibilities, i.e. the setting of properties after construction, to the IoC container.  This is not a strong-point of most containers--even Autofac.  It can be done, but it's not really straightforward.  It results in complex registration code that doesn't communicate well what's going on.

Alternatively, we could move these responsibilities into factories.  I've used this strategy before, and it can be advantageous if there are classes that will have dependencies on the factories themselves.  But in this case, the only thing that would need to know about the factories is the IoC.  So instead, I'd recommend deriving special-purpose sub-classes of the desired installer base classes, and putting the configuration in those constructors instead.  Here's what that looks like.



Simple, straightforward, self-contained, and single responsibility.  Now we just need to update the IoC registration to include them, and they'll get picked up automatically by the ProjectInstaller constructor.  We could take advantage of Autofac's fluent registration API and auto-wiring to do this without referencing the individual types.  But I have these two classes in separate namespaces (the service installer is in the same place as the service, because these must come in pairs), and the ProjectInstaller derives from the same base, it would actually take more code to deal with these special circumstances.  So explicit registration it is.


Note also here that we've registered these as InstancePerLifetimeScope, because there's really no reason more than one of either of these should be floating around.

That covers the install portion of the service.  We now have separated the three installation components into their own separate places.  Changes to the configuration of any one of them are isolated in their own locations in the code.  And as a bonus we've made the ProjectInstaller constructor trivially simple.

Let's shift gears and take a look at the service portion of the application.  We'll set up a blank bootstrapper for this portion as well. I'll refrain from posting the code as it's essentially identical to what I showed you for the other one.

The remaining two significant pieces that need to be implemented to replicate the functionality we saw in the template project are the service class itself, and the program mainline.  The mainline is going to be simple just like the ProjectInstaller.  In fact it's structure mirrors the installer very closely, just with different type names in a few strategic places.


I've chosen to request an IEnumerable, even though we only have one implementation.  Maybe we'll add more services to this assembly some day, and maybe we won't.  To make a decision on that basis triggers my YAGNI reflex.  I used an IEnumerable resolver just for my own aesthetic sense, because the framework runner takes a collection anyway.

Next let's look at the service class itself.  This is another class that, in the template project, had a lot of noise that we identified as unnecessary.  So in this iteration, it's going to be comparatively short and sweet.


There's very little to see here, and that's very much as it should be, since our service doesn't actually do anything yet.  We just cut out the noise and were left with something trivially simple.  So let's move on to the last piece left to put in place: the service bootstrapper.


We're just blasting through code files here, as this one is another very simple one, with just one registration.  We'll add more, but for right now we have completely matched the functionality of the template project.

Before we put the project to bed for another week, though, there's a small refactoring we can make that will make a nice little illustration of the benefits of how we've organized the project.  You may have noticed that we have some hard-coded strings in the constructors of the service and the service installer.  And particularly, there's one that's intentionally repeated, since it has to be the same in both places.  We can eliminate the hard-coded string and make sure that the values in both locations always match, by using the setting injection pattern I described a few months ago.

With just a few lines of code we can set up the necessary setting dependency.



With this class and interface in place, we can add a dependency to the constructors of the installer and the service.



And finally, in order to support the dependency injection, we just add one new registration to each of the bootstrappers.


That's the end of our work for this week.  We have replicated the template project's functionality, such as it is, and run through a lot of simple little snippets of code.  Structurally, the Solution Explorer doesn't look a ton different, but I think the code is simpler and more straightforward.  Plus we have built a good foundation on which to add the functionality that people expect of a service.  All the code for the project we worked on in this post can be found on GitHub at https://github.com/cammerman/turbulent-intellect/tree/master/HelloSvc.

Next week, we'll add logging to an event log, and we'll make it actually do some work.  Finally, we'll figure out how that work needs to get done, inline, or in one or more worker threads.

Anatomy of a Windows Service - Part 1

div.aside { color: #A0A0A0; margin-left: 2em; margin-right: 2em; }

This post contains gist code samples. My experiments indicate that these do not display in Google Reader, so if you are reading this there, you may want to click through to the post.

I recently had to estimate the effort for creating a one-off Windows Service for massaging some document indexing data as it passed between a capture system and an ECM system. I was quite confident in my ability to code up the "massaging" part, but the service part was unfamiliar territory. So I decided to do some investigation and figure out just what it takes to get a service set up, what special considerations need to be made for logging and injecting configuration, and how to preserve good design sensibilities through it all.

The easiest way to create a Windows service is to use the associated project template in Visual Studio. I specifically wanted to work in .NET 4.0 for the investigation, as I would be on the actual project, but unfortunately I don't personally have a license for the full version of Visual Studio 2010, and VS Express 2010 doesn't have a project template for Windows services. Fortunately, I do have VS 2008, and the BCL infrastructure for services hasn't changed between 3.5 and 4. So I decided to generate what I could in VS 2008, add some googling, and use the combined information to create a service from scratch in VS Express.

This week, we'll analyze what VS will give us for free with the project template and special code-generating actions. We'll identify the purpose of the different pieces of code, and make note of how we can use this information to build our own service, complete with installers, from scratch.

So to start, let's take a look at the structure that the project template creates for us. Here's a shot of what the initial solution looks like in a brand new Windows Service project.

Note the two structural differences between this template project and a blank or console project. There's an extra reference to System.ServiceProcess.dll, which we'll need to remember, and there is an extra component class called Service1. There's also a .Designer.cs file for Service1, but this is really just because Visual Studio automatically adds these any time an item that is a subclass of

Component

is added to your project, either via a template, or the "Add New Item" command.

Before we take a look inside the service class itself, we should see how the Program class differs from other types of project templates. Here's the Program class.

There are a few differences to note here. The biggest difference is obviously that the main method contains some generated code. It actually looks similar to what is generated with the new Windows Forms project template. We have the service class, representing the actual core of the program, being instantiated and then passed to a runner method provided by the framework that handles spinning up the appropriate context.

Now lets take a look at the service class. It comes in two parts: the main class file, and the designer file. First the main class file.

The most prominent features here is the base class,

ServiceBase

, and the two override methods, OnStart and OnStop. ServiceBase is, of course, the common base class that all .NET windows service classes must derive from, in order to take advantage of the framework support. The overrides are two of the possible entry points into the service. They correspond directly to the actions that you can take on a service in the Services control panel. OnStart is where you would place the code that processes the arguments, spins up workers, etc. Naturally OnStop is the other end of things, where you'd put your cleanup code to prepare for termination. There's also a call to InitializeComponent in the constructor, which is typical of generated Component-derived classes. We'll see if there's anything interesting happening there next, in the designer file.

There's a bunch of generated code here, but there's actually less going on. So what is all this doing? We can easily see an implementation of a Dispose idiom, which is disposing of any components contained inside this one. But when we look back at the InitializeComponent method, the Container is constructed and then left empty. The only significant code here is the assignment of the ServiceName property. We'll need to remember this for when we create our own service class from scratch. Everything else in this file could be dropped. The ServiceName initialization could just as easily be put directly into the constructor.

What we've seen so far is the absolute minimum service. If you put some behavior into the OnStart method, you could run from the command-line, and it would operate. But it wouldn't show up in the Services control panel, because it doesn't have an installer to register it. And that means you couldn't Stop it once it was started.

What does it take to register a service with the OS? VS offers a shortcut to generate the code for this as well. If you right-click the service class Service1.cs in the solution explorer, the context menu has an "Add Installer" option, which adds a new class to the solution, called ProjectInstaller. This is the last piece of our example puzzle, and it's another two-parter. First the base class file.

There's not much code here either. Like the service, we see this is a Component-derived class, by way of

Installer

) with an InitializeComponent method called in the constructor. We'll take al ook inside there in a moment. First, make note of the attribute on the class. The RunInstaller attribute is a signpost for the InstallUtil.exe installer tool that comes with the .NET Framework, or for the VS Setup Package Custom Action Installer. The Boolean true argument tells the installers that that they should indeed invoke this installer class when they find it in the assembly.

The attribute is important, but it's not the meat of the class. That's found in the designer file.

The form of this file is very similar to that of the service's designer file (and any designer file, really). Once again we see the disposal idiom, and once again, the container that it disposes is never populated with anything. The body of the InitializeComponent method is concerned with creating and initializing two more installer objects. One is a

ServiceInstaller

, which is a class that knows how to install a particular service in the registry and such, given a ServiceBase representing it. The

ServiceProcessInstaller

handles install tasks common to all services, and so there should be only one inside a given project installer.

The MSDN documentation  doesn't go into any more detail about what the responsibility differences are between these two types of installer, or why they are peers, as far as the main Installer is concerned. But it is clear about

how

they should be used. The installer objects need to have properties initialized to indicate how the install should proceed, and then they must be placed in the Installers collection. This also could just as easily be done in the constructor, eliminating the need for the designer file.

One important thing the documentation highlights is that the ServiceName property on the ServiceInstaller must match the same property on the service which it is associated with, since this is the only thing that links the service registration with the actual implementation. We'll examine the other installation-guiding properties, on both objects, in detail when we put together our own service from scratch.

For now, we've covered everything in the project template. What we have here is a complete, spartan service that does nothing. It will install, simply by compiling the executable, and then running InstallUtil.exe from the .NET framework folder against it. And it will run from the service control panel... but it has no visible side-effects.

Next time, we'll get to work replicating the moving pieces of this solution in a spanking new, blank C# 4 project. It will look a little different, structurally, but all the prominent features will still be there.

P.S. All the code that appears in this series will be available on my github page. For now, I have it in this repo:

https://github.com/cammerman/turbulent-intellect

. The code for this post in particular is found here:

https://github.com/cammerman/turbulent-intellect/tree/master/ServiceExample35

. I expect to reorganize this a bit in the future, but I'll update this link when I do so.

New Domain!

Just a little off-schedule post today to alert anyone who didn't notice the redirect: I've changed the URL of the blog to be its own domain.  I purchased the domain a couple years ago, when Blogspot's support for custom domains was... primitive.  It's a lot better now and was a breeze to set up.  So here we are!  Blogspot says the old URL will continue to redirect to the new location, if you don't feel like changing.

Now back to normalcy. Expect a post on Tuesday as usual.

Glints of Profession

Recently I caught a few tweets from Patrick Welsh where he briefly mentioned pair-programming with his young daughter while she was home sick from school. In particular the second one referenced being "green", as in all tests passing. It struck me on a couple of different levels, even beyond the "awww" factor.

(Let me not understate the "awww" factor. Stories like this set anticipation brewing in me. I can't wait to be able to share my passion for programming with my own son or daughter. Hopefully she listens better than I did when my dad attempted to enact the rituals of fatherhood with me at his workbench, under the hood of the car, and in the kitchen. Sorry Dad! If I could do it again, I'd pay attention this time around.)

This brief snapshot of their interaction conjured visions of the apprentice at the elbow of the master craftsman, absorbing subtle waves of well-worn trade wisdom. We're talking about more than just "measure twice, cut once" type of stuff here. The equivalent of that might be "fail fast". Very good, very fundamental advice, to be sure. But testing and TDD are at least one level above that.

At the level of TDD, we're dealing with explicable, transferrable techniques. Not just muscle memory, but practices. Practices that, when followed, guide the hands of the initiate on the path toward skill, consistency, and quality. To me, this is a huge indicator of mature and professional behavior on the teacher's part. And such things are themselves markers of the continuing evolution of programming from simply a job to a profession.

Compare these types of hallmarks to the ad hoc, piecemeal, on-demand way that most programmers still learn the tricks of the trade. Most of us are still tossed into the job without mentorship to speak of. We're lucky if we've been taught theory in school, but this is incomplete knowledge at best. (This is like the difference between knowing how a car works, and being able to build one.) But a relevant degree is not the path most commonly arrived by for programmers anyway. Most programmers learn through the work alone, maybe supplemented by online information gleaned from Stack Overflow questions, or blog posts where people have documented their own unique travails. Lessons are gleaned through individual trial and error, with the occasional vicarious horror story of warning.

This story is still common. Though happier alternatives are becoming more common. Many of us make quite a show of seeking to make programming a true profession. There's a Craftsmanship Manifesto. There are apprenticeships. There are actual, literal journeymen, as well as prolific, sough-ought masters. But these are all bright trappings, and it is quite easy to lose track of substance.

Profession is not found in titles and roles, or documents of good intent. Profession is not even found in the practices themselves, for TDD does not a craftsman make. Profession is found in the fact that there ARE practices which are known to improve the quality and consistency of work. Profession is found in the wisdom that is passed on by mentors, in concert with the mechanical skills of the job. Profession is found in the common platform of discipline, integrity, and mutual education upon which quality work, worthy of pride, is built.

I haven't seen what happens in Obtiva's apprenticeships, or in Uncle Bob's classes, or when Corey Haines pairs with his hosts. I trust that they do bear forward, at least in part, the evolution of our chosen trade. But in the words and excitement of Patrick Welsh's little apprentice, I can see for myself the rough diamond of profession glinting in the light.

Throwaway Projects

A big obstacle in my learning of new technologies, patterns and methods, has been my reluctance to do throwaway projects. I have a really hard time with them. Always have, in all their many forms. At times I have even actively disdained them as a useful way to learn, for various reasons.

There have been a lot of things I've been curious about and wanted to learn. I'm a programmer, so that really goes without saying. And goodness knows that, relatively unencumbered from social obligations, as geeks tend to be, I've had enough free time in my life that I could have dedicated some of it to working on some little test or toy projects to get a handle on these things. But I've always managed to convince myself it wasn't necessary, or even that it was a waste of time. Usually I accomplish this by claiming that I learn more and better from doing "useful things". Throwaway projects don't impress real constraints on you, and so they let you take liberties or make compromises that wouldn't fly when trying to actually get something done. And I was convinced that this meant the knowledge gained would be less useful or applicable to real problems.

Today I had the revelation that I couldn't possibly have been more wrong.

I was faced very recently with a number of opportunities to work on some new things, to "get stuff done", involving some technologies I'm not really at all familiar with. I initially thought to myself that this is a great opportunity to finally ramp up on some things I've been wanting to learn. But after a bit more thinking, I found myself in one case completely unsure whether I could accomplish the goal on the necessary timeline, and in the others quite certain there was no way that I could.

That's when it hit me. I realized what teachers of all stripes have known for centuries. While I've learned an awful lot about programming on the job, those fundamental lessons that my knowledge are rooted in were very rarely learned in the active pursuit of an important functional goal.

Let's first acknowledge the obvious and ubiquitous example of homework. Homework is nothing but throwaway problems. I learned the value of homework (finally) when I moved from high school, where I breezed through on in-class osmosis, to college, where info came so fast and furious that I couldn't absorb it in the desk.

In grade school, I did rote program transcription in Apple Basic. In middle school I messed around for hours, daily, in QBasic on my parents' desktop. There I played with graphics and sounds. I poked and prodded at parts of the QBasic games that were packaged with DOS. In high school I moved on to trigonometry, large-number math, a text-based RPG in the vein of LORD, 3D wireframing, and even created a graphing calculator that would automatically scale to fit one cycle of a sinusoidal function.

One useful thing I did do in QBasic was to write a file chunker that would split a file into either a particular number of pieces, or pieces of a particular size. The goal of that was to more easily share games that wouldn't fit on a single floppy, or that would take several hours to transfer over 14.4kbps modem. So, okay that was functional, and I learned a bit about file access in QBasic from it, but nothing much. Until I started to learn C++ in college, when the very first thing I did was to port my file-splitter from QBasic. I did this knowing that not only was it not very useful, but there were many freeware apps that did it better than mine. But I learned about the fundamentals of C++ syntax, style, and common pitfalls. It gave me a starting point and saved me from what would have otherwise been embarrassingly slow, trial-and-error progress on the first project of my internship.

What I missed was the now-obvious truth that being free to take liberties and make compromises that you wouldn't do in production is the perfect sandbox for making mistakes, which is a crucial part of the learning process. I had it just plain backwards.

So here I sit. Mind blown. Feeling like an idiot. I still hate doing throwaway projects, but now I know I can't afford not to. I just need to man up and fight that voice in my head that nags at me saying, "why are you writing the world's millionth blog engine when you could be working on real problems that are actually still in need of better solutions?" Because the truth is that before I can reinvent banking, for example, there are a few things I need to learn before I'll even know where to start. And the best way to do that is to play in the sandbox for a while.

Dependency Relationships and Injection Modes: Part 2

Last time, I wrote about primal dependencies and the constructor injection mode. I also mentioned that in Part 2 I would cover "the other mode". In contemplating this other mode, however, I came to the conclusion that there are in fact two other modes. I'll cover both of them here in Part 2, but first we'll tackle mutator injection and optional dependencies.

Mutator Injection

Let's get the terminology out of the way first. By mutator, I mean a property or method on a class or object that is used to change some bit of state in that class or object. By optional dependency, I simply mean one which is not required in order for the object to accomplish its primary purpose.

In most code you'll read, mutator injection is ubiquitous. However, I would argue that most are misused because the usage, the need, or both, do not fit the above description of an optional dependency. So what are people doing with dependency mutators that they shouldn't be? And what should they be doing instead? Most people use mutation when they are presented with an apparent hurdle to using another, preferable injection mode. Often this comes down to an inconvenient design choice external to the class that creates an environment where it is hard to do the right thing. The appropriate response is of course to fix the context, whenever possible.

Why You Should Prefer Alternatives

Often, a dependency mutator is used to handle post-construction initialization of a primal dependency, where the appropriate dependency instantce is not known or available when the consumer is constructed. I would argue that this is very rarely an inevitable state of affairs, and is commonly due to a dependency cycle between two layers of the architecture. (I.e. an object in one layer depends on an object in the layer below it, and another object in that layer depends on an object in the first layer.)

Intra-layer dependency cycles are almost always a bad idea, not just because it makes it tough to avoid mutator injection. Maintaining a single direction of intra-layer knowledge also helps to prevent unnecessary coupling, and it aids in keeping each layer cohesive. But an extra benefit of fixing this situation is that it will typically allow for the primal dependency to be created or retrieved when it is needed for the constructor injection, rather than by the consumer or a manager object.

Why does this matter so much? Most simply, because mutator injection is a state change. And state changes are big potential points of failure. It's also well-established that it's easier to reason about immutable data structures. I've found this to be true in my own experience as well. It's easier to compose behavior out of pieces that exhibit immutability because it simplifies the interaction graph. Furthermore, when things go wrong fewer state changes means a shorter list of possible places where the bad state may have been triggered. So when designing my classes, I avoid mutators wherever I can, and that means preferring constructor injection and site injection over mutator injection whenever possible.

The other way that mutator injection is mis-used is in a situation I briefly mentioned in Part 1: when only a subset of the operations on a class actually make use of the dependency. Mutators are often seen as convenient in this situation because they cut down long constructor argument lists, which are seen as messy or complex. The fact that the object has at least a limited use without the dependency makes it possible to get away with setting it later.

In Part 1 I said that the situation itself is often due to a violation of the Single Responsibility Principle. It would be facile to cite this reason for all instances of mutator injection. Sometimes it's true and sometimes not. When it really isn't true, there are a couple of other options available before you have to resort to mutator injection.

The first option is again to drop back to constructor injection, but to do so with a sort of lazy proxy in its place. The lazy proxy exists for the sole purpose of deferring the resolution of the actual service dependency until it's needed. This is its Single Responsibility. It can then either provide an instance on demand, or it can be more transparent and just implement the same interface and delegate to the underlying object.

In a static language like C#, this isn't always possible either. Sometimes there's no interface, and some of the members are not virtual, so they can't be overridden in a derived class. If you control the code of this object, I highly recommend refactoring to an interface to resolve this problem. But if you don't, it might be time to look at the third injection mode: site injection.

Temporal Dependencies and Site Injection

Site injection is a fancy name for a method argument. It describes the use of a service as an argument to the operation for which it will be used. Such a dependency, that is passed directly to an operation, and for which no reference is maintained after that operation completes, is called a "temporal dependency". The reference is fleeting, and not actually part of the state of the object that depends on it.

There are a couple consequences of this type of injection. First is that the calling object or objects become the primary dependents of the service. It may or may not be easier to manage the dependency there. Hopefully it is, but sometimes it isn't, especially if there are many different objects that may call on this operation.

The other consequence of site injection is that it can add noise to the interface/API. If there are multiple operations in the subset of the dependent object that make use of the service, the repeated passing of the service into the objects can feel like unnecessary overhead. Not performance-wise, but in terms of keeping the code clean and readable. Expression of intent is paramount here. If the extra arguments communicate the true relationship between these two pieces of your architecture, then it's not truly noise. Instead it's a signal to readers of what's going on, and who's doing what.

There are lots of places where site injection and temporal dependencies are very natural. So many that you probably use them without even thinking about it, and it's often the most appropriate thing to do.

Truly Optional Dependencies

That's probably enough about what isn't an optional dependency. So what is? I would argue very few things are. Usually an optional dependency crops up as something that can be null when you want to do nothing, or can have an instance provided when you want to do something. For example, one step of an algorithm template, or a logging or alert solution with a silent mode. Often, even these can be treated as primal dependencies from the consumer's perspective, with a bonus of avoiding null-check noise. Just provide a Null Object by default, and make a setter available to swap the instance out as necessary. If you can say with certainty that this is not appropriate or feasible, then you may have a truly optional dependency.

A Good Start

I believe these three dependency relationships, and the injection modes associated with them, cover most of the scenarios that you'll encounter. And I've found that the advice I've included for normalizing to these modes has helped improve the design of my code in a very real and tangible way. But I'm certain my coverage isn't complete. There are surely more dependency relationships that I haven't identified here, especially if you dig into the nuances. I'd love to hear about other types of dependency relationships you've encountered if you're willing to share them in the comments.

Dependency Relationships and Injection Modes: Part 1

This week I'm going to continue my trend of adding to the cacophony of people talking about IoC and DI. There's a lot of talking, and a lot of it is noise. Not inaccuracy, mind you. Just an awful lot of shallow coverage, one step beyond assumptions and first principles, with not a lot of real analysis. So let me bring a bit of deliberate consideration and analysis to the table, and hopefully improve the signal to noise ratio.

What's different this week from the recent past is that I am specifically going to talk about DI for once, rather than IoC in general. The particular topic I want to address is something that I've seen addressed a few times, but usually in passing reference in the context of some other argument. And most often it's being both taken for granted and dismissed out of hand, by the respective debaters.

In most languages there are essentially two injection modes available: via a constructor argument, or via a mutator such as a property setter or method. I've found that each option is most appropriate in different situations. A constructor argument dependency expresses a relationship that is very different than that expressed by a mutator.

Conveniently, there are also two broad types of dependencies that map fairly well to these two modes. The first is sometimes termed a "primal dependency". (I'd love to credit the inventor of this term, but all i can find in a Google search is Jimmy Bogard, Tim Barcz, and Steve Harman all using the term as if it already existed.) The second type of relationship is most often called an "optional dependency", which is a much less evocative term, but it's a descriptive one nonetheless.

The relationship that is being evoked by the term "primal dependency" is one of raw, fundamental need. A primal dependency is one that must be satisfied in order for the class to even begin to do its duty. When a primal dependency is unfilled, the dependent object is essentially incomplete and nonfunctional. It's in an invalid state and can't properly be used.... At least not if the SRP, or Single Responsibility Principle (PDF link), is being obeyed.

The SRP is one reason why I advocate using constructor injection for primal dependencies. Constructor injection makes it explicit and unavoidable that a given dependency is a requirement for proper functioning of the object. If a dependency could be provided via a mutator without affecting the post-construction usefulness of the object, then really you have one or both of two situations. Either it's not really a primal dependency, or your object is responsible for more than one thing and this dependency is only required for some of those things. Using constructor injection avoids the possibility of this signal being hidden behind the guise of post-construction initialization.

When people oppose constructor injection, it's often on the claim that it puts an undue burden on the object performing the instantiation. While it's true that a burden is being transferred, I'd argue that it's not undue. Construction and initialization of an object into a fully valid state should be considered to be two parts of the same operation, the same responsibility. Furthermore, this responsibility is separate from the primary purpose for the existence of the object itself, and so it doesn't belong to the object itself. This is what DI is meant to resolve. Yet, the logic must be taken a step further.

If construction and initialization is truly a multi-step process pulling from different domains, and/or which can't cleanly be handled in one place, then it's a responsibility that's complex enough to base on entire object around. In short, you should strongly consider setting up a factory or builder object to handle this task. The only extra burden this leaves is on the brain of the programmer who is unfamiliar with the pattern. But trust me: just like with any exercise, the burden gets lighter with repetition.

I have a confession to make: I had never actually used the builder pattern until I came to this revelation. I didn't really understand what the benefit was over a factory. And I'd only taken the most rudimentary advantage of factories, for implementing concrete implementations of abstract base classes. But now each is as clear, distinct, and obvious of purpose to me as a screwdriver and a hammer. You'll find they come in quite handy, and really do clean up the consuming code, once you acknowledge that construction and initialization should often be a proper object responsibility all on its own.

In Part 2 of this topic, I'll address optional dependencies and the mutator injection mode. Like today's topic, they're deceptively simple to describe. But there is just as much, if not more, nuance to be found in the manner and purpose of their implementation.

Data Plus Behavior: A Brief Taxonomy of Classes

When I was first learning about classes and object-oriented design in college, classes were explained to us cutely as "data plus behavior". This is oversimplified and inadequate in the same way as would be an explanation of the Cartesian Plane as "a horizontal axis plus a vertical axis". This neat package doesn't begin to encompass all that the Cartesian Plane is, especially compared with its constituent parts.

Through my own work and experience, I've found it useful to break classes down into four different categorizations that better express the continuum of data/behavior relationships. Each category serves a different class of needs, and each interacts with other classes and categories in consistent ways. The four categories, as I have identified them, are data, algorithms, stateful algorithms, and models. Let's take a look at each of these in turn. We'll go over the traits that qualify each, the roles they serve, and their typical relationships with other classes.

Data

Data classes are quite straightforward. They are "pure" data, with little to no behavior attached. Your typical "data transfer objects", primitives, structs, event argument classes, etc. fall into this category. There are few, if any, methods defined on this type of class. When a data class does have methods, they will typically be related to type conversion or projection, simple derived value calculation, or state change validation. However, methods offering complex mutability or interactions with other objects would push a class out of this category and toward the "model" category.

Classes in this category are most often composed completely of other data classes. When I was initially considering other qualifications, I thought immutability would a be a big one, but I've found that's not necessarily true. Rather, it's dependency on services (especially stateful algorithms) that almost certainly indicates that a class is a model rather than a data class. Data classes very rarely have more than a passing dependency on external behavior, though they may have multiple dependencies on external state, made primarily of other data classes. This makes sense, since the most common thing to do with algorithms, stateful or otherwise, is to compose them into more complex behavior.

Data classes are the quanta of information in your application. They will be passed around and between other classes, created and processed by them in various ways. They exist first and foremost to be handled. They are rarely seen as dependencies except indirectly via configuration layers, but rather show up most commonly as state, or as operational inputs.

Algorithms

An algorithm is a class that is essentially functional, at least in spirit. A strong indicator that you have an algorithm on your hands is when a development tool such as Resharper suggests that methods, or the class itself, be made static. This generally indicates a near-complete lack of state.

One common application of algorithm classes is as a replacement for what would be a method library in a language which allows loose methods. For example a string library, or a numeric processing library. In fact, data processing in general is one big problem space that lends itself to algorithm classes. Also, many of the methods seen on primitives in languages such as C# could very easily be extracted into algorithm classes.

Algorithms rarely have public properties and almost never have public setters. In general algorithm classes have the potential to be expressed even without private properties, i.e. as truly functional code. Usually this means handling data that would otherwise be stored in properties as arguments instead. But often the realities of memory and processing power limitations mean that this isn't actually possible. So complex algorithm classes do often have some private state.

Depending on the amount of internal state required for performant execution of the algorithm, such classes may be expressed as either static/singleton, or by instance. For algorithms requiring no internal state, I prefer a container-enforced singleton pattern (as described in my post on lifecycle control via IoC containers). Static classes encourage tight coupling, and are very difficult to sub out for testing, even with a powerful isolation tool such as Microsoft's Moles,Telerik's JustMock, or TypeMock Isolator. As such, I avoid statics like the plague.

Instanced algorithm classes are usually lightweight and treated as throw-away objects, repeatedly created and disposed. Some may also choose to implement them with a reset/clear mechanism to allow reuse of the same object for different inputs. However, given the memory and garbage collection power currently available, I view this as an optimization, and avoid it unless it provides clear, needed performance benefits. Otherwise, it simply adds complexity to the implementation and muddies the interface with methods that don't directly relate to its purpose.

Algorithm classes often have dependencies on other algorithms. Data dependencies, however, are usually just another form of argument for the algorithm. Something that affects the output of the work from one instance to another, but is likely constant within one instance. Usually this is data that simply isn't going to be available at the call site where the algorithm will be triggered. Environmental state is one example. Mode switches are another. Anything more complicated or mutable than this is an indicator that you might in reality have a stateful algorithm on your hands.

Stateful Algorithms

The simple explanation of a stateful algorithm is that it is a bundle of behavior with a limited reliance on internal or external state. It differs from a pure algorithm in that the internal state isn't necessarily directly related to the processing itself. The most common application of a stateful algorithm is a class whose primary purpose is to expose the behavior of a model, while internally managing and obscuring the state complexities of that model. The goal of this being to encapsulate in a service layer all the concerns that the other layers need not worry about explicitly.

IO services are common instances of these types of classes. Some examples include file streams, scanner services, or printer services. Any time a complex API is wrapped so as to expose a simple interface for bringing in or flushing out data in the natural format of the application, a stateful class is the most likely mechanism. Looking at the file stream example, the state involved might consist of a buffer, a handle to the endpoint of the output, and parameters regarding how the data should be accessed (such as the file access sharing mode).

Stateful algorithms may take dependencies on any other type of class, but more commonly pure or stateful algorithms. Stateful algorithms are more likely to interact with data classes and models as arguments, or internally in the course of API wrapping.

Models

Models are a diverse, messy bunch. They're probably the closest to fitting the classical "data plus behavior" description. A class in this category will have intertwined state and behavior. The state will typically be of value without the behavior, but the behavior exists only in the context of the state. Most often, a model class comes about not because extracting the behavior and state into separate classes is impossible, but rather because it muddies the expressiveness of the design. Domain models, UI classes, and device APIs are the places where the model category of classes tend to serve best. Note, however, that these spaces also tend to attract convoluted coupling, inscrutable interfaces, unintuitive layering, and a host of other design pathologies.

These warts proliferate because it is difficult to make generalizations or rules about models. The foremost rule I keep in dealing with them is to try to avoid them. Not in the "model classes are considered harmful" sort of way. If you look at a program I've written, you won't find it devoid of model classes. In fact, they aren't even particularly rare. When I say I try to avoid them, all I really mean is that before I write a model class I make sure that the role I'm trying to fill isn't better addressed by some at least relatively simple combination of the other categories.

It's common for the behavior of a model class to depend on some private aspect of the state. Separating the behavior from the state would thus also mean dividing the state into public and private portions, to be referenced by the consumers of the model, and the model's services, respectively. This can be a nightmare to maintain, and the service implementor must often make a decision between downcasting a public data interface to a compound public/private one, or internally mapping public state objects or interfaces to their associated private state objects or interfaces. You see this type of thing crop up repeatedly in ORM solutions, where the otherwise internal state of the change and identity tracking is pulled out of the model and maintained by the ORM.

This separation is difficult and messy to make. If you find yourself facing this choice, you can be fairly certain that a model solution is at least an acceptable fit for the role. There are benefits to the separation, but often the cost of implementation is high, and should be deferred until necessary. But beware as you forge ahead with the consolidated model, because every model is different. I find that the cleanest way to incorporate a model into a project is to establish a layer in which that model and its service classes will live, and make heavy use of data transfer objects and projections to inter-operate with other layers.

A model can, and often does take dependencies on any category of class. Because of the varied roles models can serve and the many ways that state and behavior may be mixed in them, it's very difficult to identify any patterns or rules as far as how dependencies typically arise and how they should be handled. Any such effort would likely hinge on further subdividing the categories into common roles and basing the rules and patterns at that level instead. I'll leave that as an exercise for the reader, for now. =)

A Guideline

As I've said, I find these categories to be a useful guideline in my own programming efforts. It's quite easy and natural to mix state and behavior together in most every class you write, simply because it's convenient on the spot to have behavior neighboring the state it's relevant to. But, it tends to be far easier to reason about the first three categories in the abstract than it is to do so about models. This is likely because the former tend to enable and encourage immutability, which minimizes and simplifies a whole host of problems from concurrency, to persistence, to testing. For this reason I try to identify places that lend themselves well to the extraction of a data class or an algorithm class.

This strategy seems to make my code more composable, and my applications more discrete in terms of purpose and dependency. Which in turn makes the divisions between the different layers and functionality regions more clear and firm. This not only discourages leakage of concerns, but also makes the design more digestible to the reader. And that is always a good thing, even if the reader is just yourself 6 months later.

What Your IoC Container Won't Tell You About Inversion of Control

As I've written about recently, the term "Inversion of Control" has come to be closely associated with "Dependency Injection". Indeed many people tend to use the two terms interchangeably. The reality is that DI is just one way of achieving one kind of limited IoC.

It's worth considering that something cannot be inverted without there being an original, un-inverted state. So what is that state, and why did it become so important to invert it? According to Martin Fowler's Bliki post on IoC, the state in question is which code is in control of the flow of the program within a particular scope. Fowler credits Ralph Johnson and Brian Foote's 1988 paper Designing Reusable Classes, with originally identifying the boundaries between system layers, or between a framework and the consumer of that framework, as being particularly valuable places to invert control.

The goal of the inversion, as stated by Fowler, Johnson, and Foote, is essentially to let a service remain in control of the pieces of its execution, rather than to micromanage it from the outside, like a boss who insists on being kept "in the loop". I would say this is dramatically different from what IoC has come to mean in the common parlance today.

IoC in its common usage has become divorced from the Hollywood Principle, which was about allowing a service to retain control of its own execution. Instead it has been married to DI, which is about a service divesting responsibility for ancillary concerns. The latter is equally important. But only equally. When they are brought together, they enhance each other and the resulting clarity of the design is more than the sum of its parts.

There is a duality here that is important to keep in mind when designing classes and interfaces. A duality of scope, a duality of perspective, a duality of responsibility, a duality of control. There is both give and take. By giving one thing, we take another. IoC is not just about giving up control and responsibility for choosing and creating dependency implementations. It's also about taking control and responsibility for the cohesion of the solution, the algorithm, and the facade that's offered by a service, a framework, or a layer.

It is far too easy, when one first delves into DI, especially aided by the power tool that is an IoC container, to forget this other side of things. We become satisfied that as long as we don't have a "new" in our constructor, we must be on the right track. But sooner or later you will end up in a situation where the discipline of DI becomes very difficult to maintain. Without the context of where DI came from, the limits of its purpose, and the parallel concerns that were meant to be addressed alongside, it won't be clear what is the proper way to proceed. You may realize that it's time to "break the rules", but you won't know what new rules then take over.

Speaking from experience I can tell you that this way lies madness. Or at least messiness. Potentially maddening messiness. Far too many people simply shed the rules as they pass this boundary and revert back to wild and woolly frontier-style programming. But the truth is that you aren't passing from civilization into the wilderness. You may be leaving one regime, but you're also entering another. And the guiding light of this new regime isn't just "whatever works". Most likely it's simply time to broaden your perspective beyond the issue of class dependencies and Separation of Concerns.

Start to look at the surface of the layer, model, framework, or module that the problem classes are a part of. Consider all of its responsibilities, dependencies, entry points, hooks, and outputs. If you are encountering problems making DI work, it's very possible that a mess has begun to accrete in one of these other aspects. If you step back to get the broader perspective, it may be easier to identify the problem as a flaw in the cohesion of it as a whole.

In particular, look at the ways your objects are working together, and the way the whole layer interacts with its consumers. A clear story should show up somewhere. Yes you may have a hundred small classes running around taking care of little chunks of the work. But someone should be "conducting" these bits as they work together to accomplish the goal, and that someone should be chosen and designed deliberately.

It's a common mistake to break responsibilities down into bits and then just toss them all together with no real clear roadmap emerging from the noise. This is a real problem, and the cause is a proliferation of delegation in the interest of decoupling, combined with a failure to take the reigns of regional control that ensures cohesion. Weaving together the dual needs of decoupling and cohesion is what Inversion of Control is really about.

On the Dimensions of My Ignorance

Yesterday I posted what some may view as a rant, on how troublesome it is to get started with REST web services in .NET. It wasn't intended to be a rant so much as a cathartic walk through the research I had done and the decisions I had made, over several hours of trying to find an easy on-ramp to REST on .NET.

One of the things I mentioned was the fact that I downloaded the OpenRasta source, but was unable to build it due to a couple compiler errors. I had been in loose contact with Sebastien Lambla, the author of OpenRasta, about this situation over Twitter. Yesterday he read my post and, not undeservedly, jabbed me about not trying to fix the bug myself, instead opting to waste time "touring frameworks" to find what I need.

I got defensive, of course. I felt like I clearly conveyed my situation, and why I went "touring", rather than just settling on one and pushing through the hurdles. But looking back I can see that information is distributed throughout the post, and a skimmer would likely see only that I had looked at, and whiningly dismissed, each option in turn. Which is factual, though not really complete.

So here I will reiterate that I am:
  1. A REST noob
  2. A web services noob
  3. An ASP.NET noob
  4. An OSS noob
  5. A Git noob

And that doesn't even consider Sinatra, which brings to bear the additional facts that I am:
  1. A Ruby noob
  2. A Linux noob

I know my limitations. Or rather, I know where my knowledge ends. The reason I went "touring" is because I have ideas and I want to start to make them real. I didn't want to go burrowing into some rabbit hole not knowing if it was even the right one. I want to find a framework that minimizes the number of dimensions of my ignorance that are likely to limit or undermine my ability to produce something minimally functional.

There are a lot of things I am experienced with and good at, but the list above consists of things that I don't know enough about to know when I am making a mess for myself. Without guidance, I don't even know where to start. When OpenRasta wouldn't build, I didn't even bother to look at the code, because I didn't want to get lost in the weeds due to my multiple dimensions of ignorance. It turned out to be something that I probably could have handled, so shame on me for not at least taking a closer look. I'll take responsibility for that and tuck the critique away for future growth potential.

It's tough enough to be a noob about one thing. But ignorance compounds and grows exponentially. So it's downright painful and demoralizing to be on a path where, every time you hit a roadblock, you don't even know which of the multiple gaping holes in your experience is the culprit. It's far too easy to end up chasing down red herrings or just plain make matters worse for yourself in that situation. And I just want to get stuff done.

Fortunately for me, Sebastien says that the OpenRasta stable branch is actually stable now, so I can take another bash at that. I also learned just an hour after my last post went up that there are two more .NET REST frameworks to check out. RestPoint appears to be a young, attribute-based framework. And Nina claims to be a mature, Sinatra-inspired, lambda-based framework.

I'll admit that I really don't like attribute-based APIs, but compared to the challenges I'd face with all the other options I've looked at, I can probably stomach it. But I am a big fan of lambda-based APIs, and I'm still stoked about the Sinatra approach, so I'm pretty excited to take a look at Nina. It looks like it might just be what I was hoping Nancy would be.

And on a parallel track, I plan to start filling in at least one of my other knowledge gaps: Git. I have the PragProg book on Git, but I think I may also invest in the TekPub videos on Git to get started.

.NET REST Frustrations

I've had a frustrating few days, and I'm going to vent about it a little bit here, because the experience has been something that I think many programmers have to deal with from time to time.

This weekend I found myself with 2 evenings home by myself, while my wife works her new 2nd shift job. While I miss having my evenings with her, part of me had been looking forward having some evenings all to myself, to really dig into some extra-curricular programming projects.

I'm in an unusual position right now. Unusual for myself anyway: I have a lot of ideas of things to work on. Some are for myself, and some are for work, to get a little extra satisfaction out of the job, and to make things more tolerable during the 9 to 5 when I'm on the hook for some less-than-enjoyable tasks. One thing most all of these ideas have in common is that they revolve around creating web services. Which is something I've never done before.

A few weeks back I wrote a meandering rumination, documenting my thoughts as I ventured into the web services world... Specifically, the REST world. I found myself leaning toward a particular approach, and this weekend I had an the time and opportunity to attempt to start down that road. Unfortunately, I hit some roadblocks. OpenRasta is just not going to work for me right now, I'm afraid. If I'm lucky that will change in the near future, but for now it's the state of things. So today I went back to the drawing board. Starting with whether I should persevere on the goal of using REST.

I didn't spend much time back at the very beginning here. I know that it is fairly easy to whip up an RPC-style web service with WCF. But I also know that RPC is (for most use cases) becoming a far less appropriate option. I've been doing a lot of reading on REST, and it is starting to make some fundamental sense to me. It's a paradigm I *want* to work in because it feels natural in so many ways. But I look at all the resources on REST in WCF and think to myself that it really just seems like a lot more work than it needs to be. Not to mention the fact that the whole point of WCF is to be protocol-agnostic, which is of course the opposite of REST, which embraces the HTTP protocol. Using WCF for REST seems like a frivolous waste of resources: a framework for its own sake, rather than for any value derived from the generality. So, I really wanted to avoid WCF for the learning curve and for the design conflict. But what are my other options?

I've read about how awesomely intuitive and simple the Sinatra framework is for REST, but I don't know Ruby, and really have zero comfort with Linux from a programming, admin, or server standpoint. So Sinatra really just has too many hurdles at this point. That's a lot of learning I'd have to do before I can make a simple hello world web service. Not sure I am willing to wait so long before I get some ROI. I'll learn Ruby properly, eventually. But preferably not when I'm also trying to learn 4 other things from scratch.

There are a couple of .NET frameworks around that claim to be heavily inspired by Sinatra. First there was Martin, and now Nancy. Unfortunately, I can't really find any recent activity on or around Martin. Maybe it was just a whim that didn't get the necessary care and investment.

Nancy looks more promising. It looks like a really nice start. I hope it will be a viable platform in the future, and I'll be keeping an eye on it. But right now it's brand new and not ready for production usage. Which puts it out of the running for all but my personal projects. It seems like a train I'd want to be on, and I'd love to contribute to the effort. But well, here I've got a couple more hurdles. Once again, I'm a web services n00b. I have my sense of design and elegance, and not much else. No real appreciation for the realities and complexities of the problem space or the underlying technologies. This is a journey I'm now looking to embark on for the first time. I'm far from ready to try blazing a trail for others. The second hurdle is that it's hosted on Github, and alas I'm still a Git n00b as well. I have successfully installed Git on one machine, and haven't actually successfully used it a single time yet.

What's left for REST? OpenRasta again. Which I've already established won't work. But why? It looks so... right. I can't just give up, can I? OpenRasta looks really nice in a lot of the same ways as Nancy, except that it's a far more mature product. And the author, Sebastien Lambla, has a ton of OSS experience. It's on Github too, like Nancy, but given a stable branch/build that shouldn't be a problem. But here's where things go bad. The stable binaries seem to have vanished from the place they are supposed to be, at ohloh.net. And the two ostensibly stable branches are currently in a state of... instability... as in they won't build. None of which contributes to a n00b-friendly situation. So here we are indeed back to the same obstacles I have with Nancy.

It's important for me to say that I don't begrudge Sebastien or his OSS compatriots for this situation. He's got a lot of irons in the fire with his OSS efforts, and a lot of people with more important complaints than mine are looking for their issues to be attended to. But it makes me sad, because this seemed like my best bet, and I feel like it's hanging there taunting me just outside my reach.

So... I'm coming out of the weekend very discouraged. I have all these things I want to do, and I feel like I'm being foiled at every turn by a combination of my own ignorance and unfortunate circumstance. My ideas are frozen until I can overcome some of these challenges, but right now I feel like I really need the motivation of progress on these ideas to propel me through the work of ramping up on... well, on anything. I have enough other things to do with my time that it's a challenge to prioritize learning new tech if I won't also be making progress toward producing something.

I feel like I have to make a choice between doing things the way I want and having to spend a long time digging through the muck of learning unfamiliar territory compounded with the pitfalls of immature tools, or I can compromise my design sense and go with WCF in the interest of making some material progress on my ideas.

At least WCF is a place to start where there is an established "on ramp" with controlled unknowns. I could get some preliminary, controlled exposure to the problem space and the technology stack while learning WCF, while still preserving a safety net of sorts, in the form of MS's mature and thorough framework support. Then once I have cleared those learning curves, I can revisit the question and do things the way I'd prefer to next time. So alas, that is probably what I will do.

It's just very discouraging to end up back at the place I started. The one place I didn't want to be. But that's life. Sometimes you can't fight the constraints. Sometimes you have to accept them and just do what you have to "ship", even if it means choosing a technology you'd rather not rely on.

Taking IoC beyond DI with Autofac Part 2: Relationships

In my last post I began to discuss the applications of Autofac as a tool for accomplishing true Inversion of Control, beyond just simple Dependency Injection. Specifically, last time I focused on creation strategies and lifetime control.

This week I want to talk a little more about lifetime control, and a lot more about categories of dependency, also known as relationship types. Nicholas Blumhardt, the principal author of Autofac, has a great blog post on what he calls “the relationship zoo” which I think goes a long way toward covering this space. I was originally going to do something similar, but his post is far more authoritative, and I’m quite certain I couldn’t do better. So instead, I'll abstain from the explanation and code samples and stick to analysis and rumination. So go read his post, then please do come back here and I’ll expand on it with some of my own thoughts.

…

The reality is that I take issue with some of the dependency abstractions provided by Autofac. It can be quite dangerous to your design to rely on some of them without very good reason. Used properly and prudently, they can absolutely address some particularly painful problems, especially when the dependencies consist of code you don't own and can't change. But it’s also easy to let them creep in wherever they appear to be convenient, and severely corrupt your design and architecture by doing so.

Let me start with the warnings, and then I’ll move on to extoll some virtues that I think Nicholas neglected to identify.

The first relationship type to be wary of is Lazy<T>. The intended purpose, as Nicholas explains, is to avoid expensive operations or construction until or unless it’s necessary. The idea of a lazy object is an old one. It’s a pattern that has been around for a while. My opposition to the usage of this relationship type is primarily that the need for laziness is usually a function not of the usage by the dependent class, but rather of the implementation of the module that is depended upon. Where possible, the consumer should be ignorant of implementation details of its dependencies. Let’s recognize that expensive operations are rarely truly transparent or ignorable, but the fact remains that the responsibility for this situation lies with the module being depended on, not on the consumer.

I strongly believe that if the code of the module that will be resolved for this dependency is under your control, then it behooves you to wrap the laziness around this functionality elsewhere... either building it into the implementation, or wrapping it with some sort of facade. Where Lazy<T> comes in handy is when you don’t have control over this code, and the class poorly encapsulates its functionality such that it can’t sufficiently be wrapped in a facade. At that point the consumer cannot pretend to ignore the situation, and may benefit from delegating the responsibility for the laziness to the container.

I’ll attach my second warning to the Func<T> relationship. I’m wary of the plain Func<T> because it overlaps a great deal with both Lazy<T>. It shares the same issues as Lazy<T> while adding the sin of looking suspiciously like a service locator. Service locators can be dangerous because they subvert the goal of inverting control. A service locator hands control back to the consumer by saying, “just call when you need X”, rather than handing off the dependency and saying “I know you need X so here, use this for that”. This is very rarely the appropriate way of expressing the relationship. The exception would be in the case that the consumer knows for certain that it will require multiple instances of the service it depends on.

Let’s spin things back to the positive by looking at Func and the like. How does adding the extra generic arguments change this from a smell to proper IoC? It expresses a very particular type of dependency. Specifically, it says that this class depends on at least one instance of T, but which instance or instances are needed is a function of a few arguments which won’t be known until each instance is actually needed. This is useful if you have a service which must be constructed for each use and requires some primitive types to guide its behavior, such as an encryption object which requires a key at construction. Or if you have a few different implementations of the a service which are mapped to different run-time states, such as a set of logging mechanisms for different error severities.

The IEnumerable<T> relationship is similar to this last scenario in that it offers a way to say “I depend on all implementations of T, no matter what they are”. This is probably a rarer scenario. Usually a service will have one key implementation, or a couple with very specific and differing purposes which will be used separately in different places. The most likely way for an inclusive but generalized need like this to arise is in an add-on or plug-in scenario. And in that case, you’re likely going to need some up-front processing to get things loaded up before the implementations can be passed off as dependencies to other objects.

I should note that it is probably not all that unusual for IEnumerable arguments to show up in constructors. But more often than not, this will be in data classes which will be instantiated directly, or a single step removed via a factory method, rather than resolved by the container. These aren’t truly “services” and are very unlikely to be registered with the IoC container. The factory may be a service, but what it creates in this case is more of a data structure than anything. Data structures mean state, and usually highly contextual ones at that. Autofac more context-sensitive than many IoC containers, but even it has its limits. With data structures, usually the best solution is either a direct constructor call, or a light factory.

One more small step along the path is Meta<T, M>. This is relationship type that specifies a dependency not only on a service of type T, but on some piece of metadata of type M about the module that will be provided at runtime. This metadata may be used to decide whether or not to go through with making use of the service, or how to do it. In fact, metadata is a great way to handle the special considerations a consuming object may need to make for a lazy service implementation involving a long-running operation. Maybe 90% of the time, the app can simply halt for an operation, but for certain implementations of the service, it’s more prudent to display a friendly “please wait” message and a progress bar. Attaching metadata at registration is a great way to enable these types of decisions intelligently without hard-coding a universal expectation one way or the other.

The final relationship type to address is Owned<T>. This one can be quite handy. At first blush it seems like this might violate the same principles as Lazy<T>, but if you think about it, they are actually quite different. Owned<T> indicates that the object expects to be solely responsible for the fate of the dependency passed to it. This tells the programmer, “I’m going to use this up, and it won’t be any good when I’m done with it, so just clean it up afterward.” Believe it or not, this fits in perfectly with the recommended implementation pattern for the .NET IDisposable interface. That is, that at some point, some object takes ownership of the resources, and responsibility for calling IDisposable, absolving all other transient handlers of the same. Ownership is sort of the dual, or inverse, of a constructor dependency. The constructor dependency says “I know I’m going to need this object”, and the ownership claim says “when I’m done with it, it can be tossed out.” And Autofac happily obliges, releasing the dependencies when the consumer itself is released, calling IDisposable.Dispose as appropriate.

After a twitter conversation with Nicholas himself, it became obvious to me that Owned<T> is probably the better solution to my qualms about InstancePerLifetimeScope. By establishing that the consumer “owns” its dependencies, we have essentially established exactly the limited and definite lifetime context that I was asking for! Behind the scenes, a lifetime scope is spun up when the object is instantiated, with nested resolution rules being applied as a matter of course. And when the object is released, then so is the lifetime scope and anything that was resolved as a new instance in that scope. However, we do have a symmetrical limitation here. Both the creation and the destruction of the context are tied to this object. Once the context is created, it can’t and/or shouldn’t be shared with anything either above or adjacent to this object in the dependency graph, or the deterministic disposal Autofac prides itself on will subverted and become unreliable.

In these past two posts, I’ve covered the whole continuum of dependency creation, lifecycle, and relationship strategies that go beyond simple Dependency Injection to fill out the breadth of what Inversion of Control really means. And they’re all available via Autofac to be handled (for the most part) separate from the implementation of the consumer, and without writing boilerplate factory classes or resource management classes to make it work. I hope that in reading these posts some people may see that IoC is a broad space of patterns and solutions, and that IoC containers are powerful and useful and far beyond the naive use and even abuse that people put them to for simple DI.

Taking IoC beyond DI with Autofac Part 1: Lifecycle Control

People who have to listen to me talk about programming know that I’m a big proponent of Inversion of Control (IoC) containers and what they can do to clean up your code. Most people get introduced to IoC containers via Dependency Injection (DI). DI is another great way to clean up your code. It’s hard to argue against it, really. It decouples your code in a big way. Not only does this make it more testable, but because it aids in separating concerns/responsibilities, this also makes it easier for you to track down bugs when they do show up. But people rightly point out that you don’t need an IoC container to use DI and get these benefits.

I’m usually both happy and sad to hear that argument. On the positive side, it means that people are acknowledging the benefits of DI, which is great. The more people are using DI, the less god classes full of spaghetti code there are out there for me to unearth in future maintenance efforts. Another reason I’m happy to hear that argument is because it means that people aren’t confusing the means for the end. DI is a good thing, for the reasons I established above, not because, as some people seem to think, IoC containers are good and DI is what IoC containers do.

That last sentence there leads into the reason that I’m sad to hear people dismiss IoC containers as being unnecessary for DI. The problem is, DI isn’t the only benefit of IoC containers. DI isn’t what IoC containers do. IoC containers, as their name would indicate, invert control. They take a number of concerns that have traditionally been assigned to the class under consideration, and extract them out to the context in which that class is used. That context may be the immediate consumers of the class, or it may be coordinating code, infrastructure, data access, or any number of other locations in the application. But the point is that the responsibilities are removed from the class itself and given to other classes whose business it is to know what should be created, when, with what initialization, and how it should be disposed of.

A good IoC container does more than just wire up constructor dependencies. It goes beyond that and lives up to the breadth of this definition of IoC. And that is why I laud and evangelize the glories of IoC containers.

Lets take a look at one particular container that I’ve come to know and love: Autofac. It’s an amazing framework that offers an answer to nearly everything that the principles of IoC ask of it. Autofac has features for lifecycle control, object ownership, and deterministic disposal. It has features for nested scoping, contextual dependency resolution, and varied construction mechanisms. These are all concerns that are a function not of the consumer of a dependency, but of the cloud of code and functionality that surrounds it, of the nature and design of your application as a composition. And Autofac gives you ways to deal with them on those terms.

Autofac boasts strong support for robust lifecycle control. In the project wiki you’ll find it laid out under the topic “Deterministic Disposal”, but it’s about creation as much as it’s about disposal. When you register a module with an Autofac container, you have the opportunity to specify a scope strategy. This strategy will determine whether a new instance is created upon the request, or whether an existing one is pulled from the container. Furthermore, it will also determine when references to the instance or instances are released and Dispose called on IDisposables. I’ll be doing some explaining, but if you want to do your own reading on the available strategies, you can do so here: http://code.google.com/p/autofac/wiki/InstanceScope

The two simple lifetime scopes that everyone tends to be conceptually familiar with are found n Autofac’s SingleInstance and InstancePerDependency scopes. The former is roughly equivalent to the function of a singleton pattern implementation, while the latter corresponds to a factory pattern implementation. Autofac goes well beyond this, however, and gives you two more scoping strategies that let you manage creation and disposal of your components in a more nuanced and more powerful way.

Both of the two more nuanced scope strategies depend on Autofac’s support for “nested containers”. A nested container is essentially a scoping mechanism, similar to a method or class definition, or a using block. Nested containers are useful for establishing the architectural layer boundaries of your application. For example, in a desktop application you may have many windows coming in and out of existence, all operating on the same domain objects, persisting them via the same handful of repository classes. These windows may be created in nested container contexts that are spun up as needed, and disposed when the windows are closed. Some objects will be created new each time this happens, while others are unique and shared across the entire UI. The nested container is what allows Autofac to make the appropriate distinction.

Imagine you are writing a file diff’ing application. You have to show two documents at once in side-by-side windows. They are the same thing, in terms of functionality and data, and so could just be two different instances of the same object.... But they will share some dependencies, and have references to their very own copies of certain others.

Lets pick out a few pieces of this puzzle and tie them to Autofac’s features. You will probably have a file access service that allows you to operate on the files that you have loaded. There’s no reason to have more than a single copy of this in the entire app, so it can effectively be a singleton. The way you would express this to Autofac is via the registry.

Given the class and interface definition:

You would register the component as a singleton like this:

The run-time behavior you would see based on this registration is that only one instance of the FileAccess component will ever be produced by the container. Subsequent requests will just return the one that’s already constructed.

The next layer on top of that is the UI. You decide that you may want to be able to have multiple comparison windows open at once, without having to run separate instances of the app. But each of those windows is still essentially a full instance of your apps interface. They’re not exactly singletons, but they should be unique within their separate stacks. Whatever sub-context they are in, there should be only one.

Given the class and interface definition:

You would register the component using the InstancePerMatchingLifetimeScope strategy, like this:

One weakness of Autofac for this use case is that in order to establish the proper resolution contexts, you have to refer directly to the container. In this case it’s probably okay, since you can be fairly certain you’ll only ever need a Left context and a Right context. So you can probably create the lifetime scopes up front, store them away somewhere, and explicitly resolve these objects from the separate contexts when needed. A sample setup for this can be seen below.


Then you’d need to make sure that the LeftContainer and RightContainer were used explicitly to resolve the left and right ComparisonWindow components.

This works for us in this situation. But it’s not at all difficult to imagine a scenario, maybe even in this same app, where the contexts aren’t predetermined and static. For example, you may want have a worker thread pool, where each thread has its own resolution context. In fact this is a situation addressed explicitly in the Autofac wiki. Even there, it seems to be accepted that an explicit container reference in the thread pool is necessary. It doesn’t seem like there’s a great solution to this challenge at this time, though I will surely be keeping an eye out for one. This is messy, concern-leaking infrastructure code that I would really prefer not to have to write.

There’s another scoping type that’s related to this one. In fact it’s use is a bit simpler. This is the InstancePerLifetimeScope strategy. Note the subtle lack of the “Matching” adjective in the name. What this indicates is that the context is implied rather than explicit. The behavior specified by this strategy is that at most one instance will be created within the resolution context where the resolution happens, at whatever level of nesting that happens to be. Functionally, this differs from InstancePerMatchingLifetimeScope in that it doesn’t search the context stack for one particular context in which to do the resolution.

This strategy can be effective when you have a set architecture with a trivial tree structure. Well-defined layering is crucial. All the leaf nodes of your context tree need to be at the same depth in order to be certain when a new instance will be created and when not. For example, a website where you have a base layer for the whole web app, and a leaf layer nested within for each individual web requests. In our diffing app, if we can be certain that we need no more deeply nested containers beyond our LeftContainer and our RightContainer, and all significant service resolution will happen at those layers, then we may have a use for this strategy for the dependencies of our Left and Right windows and controllers

The registration for this strategy is very similar to the others. Given a class and interface definition such as this:

The registration would look like this:

The final scoping strategy is InstancePerDependency. As noted before, the behavior is roughly equivalent to an implementation of a factory pattern. Every resolution request for a service registered as InstancePerDependency will result in the creation of a new instance. In our diffing app, we may find use for this strategy with something like an alert dialog. There’s no need to keep an alert around when it’s not being shown, and in fact it should almost certainly *not* carry any state from one alert to the next.

So given a class and interface such as this:

The registration would look like this:

That covers most all of Autofac’s lifecycle control functionality. There are four strategies available: SingleInstance which approximates Singleton, InstancePerDependency which approximates Factory, and the more subtle and, honestly, difficult to use, InstancePerLifetimeScope and InstancePerMatchingLifetimeScope which are heavily contextual. I really wish that these last two were more manageable and directable. If they were, I think that Autofac could claim to easily address most any lifecycle control need with very little overhead and requiring few concessions to the framework. This would be a very noble goal. But as it is, their behavior will tend to be circumstantial rather than controlled and intentional. And the only hope of improving that situation lies in taking great pains to organize your design to account for the container’s shortcomings and then go on to break the rule of not referencing the container.

Despite these shortcomings, I believe there are many benefits to be found in relying on Autofac for lifecycle control where it’s possible and not overly problematic. Certainly I’ve saved myself some headaches in doing so. And we haven’t even begun to explore the dependency relationship patterns that Autofac supports out of the box. We'll dive into to those next time!

A Noob's Scattered Thoughts on REST

Note: I hope you'll bear with me as I meander through my still very disorganized thoughts on the topic. This post is very much for myself, with the goal of distilling the information floating around in my head into something more concrete and which I can actually make use of...

I have a few projects on the horizon, both at work and on my own, which will involve web services in some form or another. I have to admit, I've never been much of a "web guy" before. My career to this point hasn't demanded that this change, but it looks like it's time for me to move off the desktop at least part-time. So I've dived into web services.

I develop for .NET at work. So while I may explore something else for my personal projects, for work I have to focus on .NET frameworks. Of course REST is all the rage these days, so it's obligatory that I research that. So I've read a number of blog posts describing what REST is about. My assessment of the REST is that it seems like a nice idiomatic design philosophy for a web service that deals primarily with persistent data entities and operations over them.

It seems clear to me though that there must be problems which might be addressed via a web service which aren't necessarily natural to model using REST. Of course the fallback, if one were to decide that the barrier is too great, would be to use some sort of RPC style. RPC comes natural to us developers, of course, because it's essentially just a web-enabled version of the idioms we use ubiquitously in code.

My own feelings about RPC as compared to REST are less critical than many. I understand the philosophical imperative to maintain the webbishness of services operating over the web. However, I also hold very strong to the opinion that solutions should be created using metaphors that lend themselves naturally to the problem space. REST, as defended by many, seems to me to be less about the problem space than it is about the mechanism the solution is built on.

However, if REST can be said to consist of two pillars, resource-orientation and mapping operations to the HTTP verbs, then it seems the later is really the part that seems limiting. After all, a resource is not so different from the "objects" that permeate our code as programmers. But imagine if, in your object-oriented design, you were allowed only 4 methods per object, and each of them had to fit one of four very specific patterns. That feels arbitrarily limiting, doesn't it? It does for me.

Now, having said that, I do see value in keeping things simple. The web is already a high level abstraction. And building convoluted metaphors on top of it that don't map easily to the mechanisms that underly it can cause a lot of unnecessary headaches. I also believe that it may not be unfair to compare RPC-heavy designs to the old style of procedural programming. That is, that they have all the nasty kinds of coupling and inertia, and few of the good kinds. Especially when the data entities involved are mutable.

That last point hits home hard for me, though. And I think it will end up strongly informing how my designs play out. The reason for this has largely to do with how my overall coding style has evolved over the past couple of years. I've found lately that, with the exception of DTOs and the primary domain objects in my solutions, a great many of the objects I work with tend to be immutable. And the algorithmic bits that operate on them tend to come in nuggets of functionality that are highly composable. This strikes me as being fairly compatible with REST's resource-oriented design.

Another factor I have to consider is the frameworks that are available to me. Comparing what I can find on the web about WCF and ASP.NET, the primary non-REST web service frameworks, and OpenRasta.... I have to say that the code and configuration of OpenRasta solutions seems to be much simpler, more elegant, and clearer of intent. This appeals to me greatly. It seems like it would be much easier not only to spin up something from scratch into a working solution, but also to evolve smoothly from my first fumbling attempts through to a final product that still has clarity of structure and intent. If I've learned anything in my career so far, it's the importance of that.

So my initial forays, at least, will likely be based in OpenRasta. If it turns out that OpenRasta can't give me what I need, or that there's too much friction, I'll look for help of course. But I also won't be afraid to try to weave some RPC into my design if it's called for.

Clean Injection of Individual Settings Values

The Setup

Today I again encountered a challenge that I have dealt with numerous times while working on the product I develop for my employer. It's not insurmountable an insurmountable challenge. Honestly, it's not even all that challenging. But it has been an irritant to me in the past because all the solutions that I have come up with felt unsatisfactory in some way.

That challenge is the injection of simple settings values into the classes that need to refer to them. By simple I mean single-value settings embodied by an integer, a string, or a floating-point, for example. This seems like a simple problem. And honestly, I thought this was going to be a short and sweet post, until I realized that there is value in delineating all the dead ends I've followed on the road to my current favored solution. As you'll see, I've put a fair amount of thought and analysis into it.

Being a hip programmer, I use an IoC container to constructor-inject all my complex dependencies. And my IoC container of choice, Autofac, is only too happy to auto-wire these so I don't have to worry about them. But mixed in among these are the simple settings values that guide the functionality of certain classes. A component/service model doesn't really apply to these values. No one string value is implementing the "string" service. The values can't be easily auto-wired because unlike the complex classes there is certain to be more than one important value floating around for the primitive type in question.

Our app processes image. Large files, and large volume. And worse, the working sets are very large, so we can't handle things piecemeal. We have a serious need in a few different places for disk caching of "active" entities that are still very much in flux. Having multiple caching points necessarily means that there are several parameters that may need to be tweaked to keep things optimized. For each cache we want to be able to set the disk location for the cache and the in-memory entity limit, just to start.

Taking a simple case with two cache points, we have two string settings and two integer settings. So already we are in a position where in order to inject the values, we'll need to do some sort of "switching". Some run-time decision of which string and which integer go where.

Pitfalls and Red Herrings

As I noted in my opening, I have solved this in several ways in the past. One is to hook into the IoC via Autofac's "OnPreparing" event, where I can supply values for particular constructor parameters. This is nice, because it means I can avoid setter injection. But it complicates the IoC bootstrapper by adding exceptions and special handling for particular classes. Just as undesirable, it couples the IoC bootstrapper directly to the settings mechanism.

What about setter injection? Autofac provides a post-construction OnActivated event that is perfect for setter injection, but this is subject to the exact same disadvantages as the pre-construction event. We could leave the setters alone and let some other object fill them in, but that leaves us with a couple different problems. First, there's just as much coupling, it's just outside the IoC, which may or may not be a marginal improvement depending on how it's implemented. If you end up with some class that must be aware of both the app settings mechanism and the class(es) that receive those settings then this is really not much of an improvement.

But beyond that, refraining from providing the values until after the components are obtained is undesirable for yet a few more reasons. First and foremost, it means that your services will exist in a state of incomplete initialization. The risk of getting hold of an incompletely initialized service makes calling code more brittle. And protecting against the possibility makes it more complex. Furthermore, setter injection for these particular types of values is undesirable because it implies they are variants. The truth is that the last thing you want is for some errant code to change the cache location on disk after a bunch of files have been stored there. And putting in protection against such post-initialization changes is pathologically unintuitive: it subverts the very nature and purpose of a setter.

So we've established that these direct injection routes are problematic in a number of ways. Let's move on to indirect injection. What does that mean? Basically it means putting a provider object in the middle. Our classes can take a dependency on the setting provider, which can wrap the settings mechanism itself, or act as a facade for a bundle of different mechanisms.

The option that at first appears simplest is to have a single settings provider object through which all the app's settings can be accessed. The classes can all depend on this object, which the IoC can provide with a singleton lifecycle if we desire, for maximum consistency. But now what we have essentially done is created a service locator for settings. This is another thing that's good to avoid for two reasons. For one, it creates a huge common coupling point, and for two, it violates "tell, don't ask". Why should my dependent class have to depend on a generic interface and worry about asking for the appropriate thing, when all it cares about is just that one thing?

This is especially dangerous if the app-side interface to your settings keeps them grouped just as they are in the user-side (i.e. the config file), as the build in .NET config mechanism is wont to do. The needs of the user for the purpose of managing settings individually or en masse are vastly different than the needs of the application whose behavior is driven by those settings. While a user likely thinks the most intuitive arrangement is for all the 15 of the paths to be bundled together, it's highly unlikely that any particular class in the application is going to care about more than one or two individual paths. And if the class doesn't need them, then they shouldn't be offered to it.

A Light in the Dark

So where do we go from here? If you can believe it after all this meandering and rambling, we're very close. From here we take a little tip from the DDD community: eschew primitives. If you think back to the beginning, the whole problem centers on the fact that primitives are just too darn generic. The type doesn't mean something specific enough for it to be an indicator of what exactly the dependency is. How do we fix this? Encapsulate the individual setting in a type specific to that need. Given that the explicit purpose of these classes will be to provide particular settings to the classes that need them, it is appropriate for these to couple to the configuration mechanism, whatever that may be, and more importantly, encapsulate it in useful bite-size chunks. And because the providers will themselves be injected where needed, the coupling is one-way, one level, down the layer hierarchy, which is arguably the best kind of coupling.

Show Me The Code

Enough talking. Now that I've set the stage, here's some code to furnish and light it.

First, the setting providers. As you can see, they tend to be nice and short and sweet.

Next, the caches that depend on them. Note how the setting providers are used in the constructors.

Finally, I'll show just how easy it can be to wire these up. If you bundle all your setting providers in one namespace, you can even safely auto-register them all in one fell swoop!

Objections?

There are a few things that I can anticipate people would object to. One is the potential for proliferation of tiny classes. I don't see this as a bad thing at all. I think it's fairly well established that small classes, and methods, with laser-focused responsibilities are far easier to maintain, evolve, and comprehend. I can say from personal experience that I am utterly convinced of this. And if anecdote isn't good enough for you, I'll add an appeal to authority to it =) Go read up on what the most respected programmers out there today are saying, and you'll see them express the same sentiment, and justify it very well.

Another thing I expect people to object to is that when taken as a whole, this pile of small classes looks like a bit of a heavy solution. And it is heavy in this context, where none of the actual app code is surrounding it. But nestle it inside a 50K line desktop app with hundreds of classes and it will start to look a lot better. For one, those classes and their namespace create sort of a bubble. It's a codespace that has boundaries and purpose. You know what's inside it, and you know what's not. It's a goal-oriented mental anchor to latch onto while you code, and that's a darn useful thing.

Community Service

As I see it, programming questions tend to take one of two forms:
  1. How do I do X?
  2. How do I do X in a clean, maintainable, and elegant way?
Matt Gemell has a great response to questions of the first form. I have nothing to add to his excellent post on that topic.

But I think it's crucially important to make a distinction between the two forms. The second form is a far more difficult question, asked far less commonly, and to which good answers are even rarer. When questions of this form are asked in forums, people are usually given a link to a page describing a pattern, or if they are really "lucky" a page with a sample implementation of that pattern. To be fair, patterns usually are the answer to these types of questions. But what we find written up on the web, or even in books, is most commonly pathetically oversimplified, without context, and often even without guidance on what support patterns are necessary to obtain the benefit or when alternatives may be preferable.

Essentially, most developers are left with no choice but to apply Matt's answer to form 1, to questions of form 2, in a much less information-rich environment. I contend that, while it may be one of those proverbial activities that "build character", it is ultimately more likely to be harmful to their immediate productivity--possibly even to their continued professional growth.

What we end up with is a pandemic of developers trying to hack out pattern implementations, being discouraged by the fact that the pattern seems to have no accounting for any possible deviations or complications in the form of the problem. Worse, developers are often dismayed to find that the one pattern they were told to use is merely the tip of a huge iceberg of support patterns without which the first may actually be more problematic than an ad hoc solution. Most often the developer in this position will end up determining that their deadlines will never allow them to go through the painful trial and error process on every one of these patterns, and accordingly drop back to the ad hoc solution.

It's time that we acknowledge that software development, whether you consider it an engineering discipline, an art, or a craft, has a history--albeit a short one. Things have been tried. Some work, some don't. There do exist "solved problems" in our problem space. To say that every developer should try and fail at all these efforts on their own ignores and devalues the collective experience of our community. Worse, it stunts the growth of the software development industry as a whole.

Yes, one can learn these things by trial and error. Yes, the understanding gained in this way is deeper and stronger than that gained initially by being tutored on how to apply the solution. And yes, there's a certain pride that comes with getting things done in this way. But this is not scalable. Putting each person forcibly through this crucible is not a sustainable strategy for creating experienced, productive, wise programmers. Every hour spent grappling in isolation with a question of "why won't this pattern do what I've been told it will" is an hour that could be spent creating functionality, or heaven forbid solving a new problem.

That is why those of us who have managed to obtain understanding of these "solved problems" must be willing to shoulder the responsibility of mentoring the less experienced. Being willing to explain, willing to discuss specifics, mutations, deviations, exceptions. Willing to discus process, mindset, methodology. These are the things that make the distinction between a programmer and a software developer, between a software developer and a software engineer.

The internet may very well not be the appropriate place to seek or provide this type of mentoring. I suspect it's not. And unfortunately, there are too many development teams out there buried in companies whose core competencies are not software, and consisting solely of these discouraged developers, lacking an experienced anchor, or even a compass. There are online communities that attempt to address the problem at least partially. ALT.NET is one such, for .NET technologies. But there really is no substitution for direct, personal mentorship.

So I would encourage young developers out there to seek out more experienced developers, and ask them the tough, form 2 questions. And I would even more strongly encourage experienced developers to keep a watchful eye for those in need of such guidance. Maybe even consider proactively forming a local group and seeking out recruits. Be willing, able, and happy to provide this guidance, because it benefits all of us. Every developer you aid is one less developer creating an ad hoc solution which you or I will be condemned to maintain, overhaul, or triage somewhere down the line.

Incidental Redundancy

A note: I originally composed this blog post in June 2008, but lost it in my backlog and it never got posted. In the interim, Robert C. "Uncle Bob" Martin has addressed the issue in his Clean Code Tip of the Week #1. He describes the issue and the dilemma far more concisely than I have here, and even provides a strategy for dealing with it. By all means feel free to skip my post here and consider him the "official source" on this topic. =)

I am a big fan of "lazy programming". By that of course I mean avoiding repetition and tedium wherever possible. I mean, that's what most programming is really about, right? You have a problem: some process that is annoying, unwieldly, or even impossible to perform with existing tools. And the solution is to write a program that takes care of all the undesirable parts of that process automatically, based on a minimized set of user input or configuration data.

The realities of programming on an actual computer rather than in an idealized theoretical environment rarely allow this ascending staircase of productivity to be climbed to the top step. But it is nevertheless a goal we should always strive for.

Hence Jeff Atwood's recent post about eliminating redundancies.

Anything that removes redundancy from our code should be aggressively pursued
An honorable goal, to be sure. But no rule is without exception, right?

I humbly submit to you the concept of "incidental redundancy". Incidental redundancy is a repetition of code syntax or semantics that tempts the programmer to refactor, but if carried out the refactoring could damage the elegance and discoverability of the program.

The difference between incidental redundancy and regular redundancy in code is that the redundancy does not arise because of any substantive, or at least relevant, similarity between the two problems in question. Here are two ways I can think of off the top of my head for this to happen:

  1. The solutions you have come up with to this point for each situation just happen to have taken a similar form. Given a different creative whim, or even just an alternative refactoring, the commonality may never have arisen.
  2. The problems are, in fact, similar at some level. But the level at which they are similar is far above or below the level where you are working, and so not truly relevant or helpful to the immediate problems you are trying to solve.
The first situation should be acceptable enough to anyone who has spent a decent amount of time programming. Sooner or later, you will spend some precious time carefully crafting a solution to a problem only to later discover that a year and a half previous, you had solved the same exact problem, in a completely different and maybe even better way.

The second situation may sound a little incredible. But allow me to point out an example from the world of physics. Please bear with me as this is an area of personal interest, and it really is the best example that comes to mind.

There are four forces in the known universe which govern all interactions of matter and energy, at least one of which I'm sure you've heard of: the electromagnetic, weak nuclear, strong nuclear, and gravitational forces. It is known now that the first two of those apparently very different forces are in fact two different aspects of the same phenomenon (the electroweak force), which only show up as different when ambient temperature is comparatively low. Most physicists are pretty sure that the third force is yet another aspect of that same phenomenon that splits off only at even higher temperatures. And it is suspected that gravity can be unified with the rest at temperatures higher still.

The point of all this is that there are four different phenomena which in fact bear undeniable similarities in certain respects, and these similarities continue to drive scientists to create a generalized theory that can explain it all. But no one in his right mind would try to design, for example, a complex electrical circuit based entirely on the generalized theory of the electroweak force.

The analogy to programming is that, were we to try to shift up to that higher level and formulate an abstraction to remove the redundancy, the effect on the problem at hand would be to make the solution unwieldly, or opaque, or verbose, or any number of other undesirable code smells. All at the cost of removing a little redundancy.

What we have in both physics and in our programming dilemma, is noise. We are straining our eyes in the dark to find patterns in the problem space, and our mind tells us we see shapes. For the moment they appear clear and inevitable, but in the fullness of time they will prove to have been illusions. But making things worse, the shadow you think you see may really exist, it's just not what you thought it was. That's the insidious nature of this noise: what you see may in fact be truth in a grander context. But in our immediate situation, it is irrelevant and problematic.

This concept is admittedly inspired heavily, though indirectly, by Raganwald's concept of "incidental complexity", where a solution takes a cumbersome form because of the act of projecting it upon the surface of a particular programming language, not unlike the way the picture from a digital projector becomes deformed if you point it at the corner of a room.

The real and serious implication of this is that, to put it in Raganwald's terms, if you refactor an incidental redundancy, the message your solution ends up sending to other programmers, and to yourself in the future, ceases to be useful in understanding the problem that is being solved. It starts sending a signal that there is a real and important correlation between the two things that you've just bound up in one generalization. When in fact, it's just chance. And so when people start to build on top of that generalization with those not quite correct assumptions, unnecessary complexities can quite easily creep in. And of course that inevitably impacts maintenance and further development.

Noise is ever-present in the world of programming, as in other creative and engineering disciplines. But it doesn't just come from the intrusive environment of our programming language or our tools as Raganwald pointed out. It can come from our own past experience, and even come from the problem itself.

So be wary. Don't submit unwittingly to the siren song of one more redundancy elimination. Think critically before you click that "refactor" button. Because eliminating an incidental redundancy is like buying those "as seen on tv" doodads to make your life "easier" in some way that was somehow never an issue before. You think it's going to streamline some portion of your life, like roasting garlic or cooking pastries. But in your quest to squeeze a few more drops of efficiency out of the tiny percentage of your time that you spend in these activities, you end up out some cash, and the proud owner of a toaster oven that won't cook anything flat, or yet another muffin pan, and a bunch of common cooking equipment that you probably already own.

So remember, redundancy should always be eliminated, except when it shouldn't. And when it shouldn't is when it is just noise bubbling up from your own mind, or from the problem space itself.

The First Rule of Extension Methods

Extension methods are a tremendously useful feature of C# 3. Briefly, they allow you to bundle new behavior into an existing class that wasn't included by the class's original author, but without opening up the implementation internals of the class. In a very general sense, this is useful if you come up with useful behavior related to a class and the best place for it is IN that class, but you don't want to bend or break encapsulation by inheriting. I won't spend any more words on an introduction, but rather offer a caution, for those of you who have seen their usefulness and would like to start taking advantage.

Before you even begin to think about whether a particular behavior belongs on an existing class, or as a service, or what have you, you should internalize one cardinal rule of dealing with extension methods. Thankfully this First Rule of Extension Methods is nothing like the First Rule of Fight Club, because if it were, I wouldn't be able to help you at all. No, the First Rule of Extension Methods is: DO NOT export extension methods in the same namespace as your other public classes.

The reason for this is very very simple: odds are very good that if you have come up with an idea of including a particular new behavior on an existing class, someone else has or will as well. There will only be a finite number of relevant names to give this new method, which means that if it's a simple method, especially one without parameters, there's a decent chance that the signatures of your method and this other programmer's will be identical. And if both you and this other programmer happen to include the method on public static classes in a namespace with other functionality the user needs, then someone trying to use both libraries could very likely run up against identifier collisions with the two methods.

Note that the rule begins with "do not export..." This is important, because you can be 100% certain to save your users any collision headaches if you just don't export your extension method. Why wouldn't you export your extension method? Well, there's a very good chance that just because you found your extension method to be useful and, dare I say, clever (Tyler Durden: "how's that working out for you?"), that doesn't mean the consumer of your library will. So consider carefully whether you should even make the method public at all, or rather just keep it internal.

If you decide that your method is just so darned handy that to keep it locked up would just be sadistic, then make a separate namespace for each batch of related extension methods you want to export. If the user decides they'd like to use them too, they can import the namespace as necessary. This will minimize the chance that they will need to fully qualify the namespaces of the other library with the identically named method whose author wasn't as responsible as you were and polluted their namespaces with extension methods.

This tactic won't guarantee anything, because there's always a chance some other library could use the same namespace identifiers as well. But with each additional namespace, you dramatically increase possible naming permutiations, and proportionally decrease the chance of collisions.

Useful Extension Methods 1 through 3 of N

Quite often when I'm writing code I'll notice a very small bit of logic that keeps popping up all over the place. It's usually something so trivial that most people barely notice it. But it's also usually something that shows up so often that, despite being small and ignorable, it constitutes a fairly constant level of noise in the code. By noise I simply mean something that takes up more characters than it needs to, obscuring the real meat of the logic of your code. Common functionality like this that everyone knows and understands should just get out of the way, fade into the background, and let the unique logic stand out.

You may have also heard of this noise idea by another name: accidental complexity.

As Reg Braithwaite has pointed out, looping syntax is one of these things. With the ubiquity of IEnumerable and the advent of extension methods in C#, there is almost never a good reason to write an explicit for loop anymore. Looping is a ubiquitous bit of logic that nonetheless takes up quite a lot of characters. Even the vaunted foreach loop is now officially more verbose than it very often needs to be.

Microsoft made it easy to get rid of the explicit loop when what you are doing is essentially a mapping operation, with the inclusion of the IEnumerable.Select extension method.

Say your Foo class has a static function taking a Bar and returning a Foo, and you want to use this function to take a collection of Bars and create a collection of Foos.

You could do this:
IEnumerable<Bar> bars = GetAllBars();
List<Foo> foos = new List<Foo>();

foreach (var bar in bars)
foos.Add(Foo.FromBar(bar));

Or you could do this, which is obviously much more concise:
IEnumerable&lt;bar> bars = GetAllBars();
IEnumerable&lt;foo> foos = bars.Select(Foo.FromBar).ToList();

Note that the Select function completely takes care of the looping logic. Once you know that, this code reveals itself as being extremely elegant. But what if the action you're taking doesn't return anything? You're "stuck" writing an explicit loop, right? Not at all.

Take this code:
IEnumerable<Foo> foos = bar.GetAllItems();

foreach (var foo in foos)
PrintToScreen(foo);

To start removing the noise, first define an extension method for IEnumerable called ForEach. This is extension method #1.
public static IEnumerable<X> ForEach<X>(this IEnumerable<X> lhs, Action<X> func)
{
foreach (X x in lhs)
{
   func(x);
   yield return x;
}
}

Then rewrite:
bar.GetAllItems()
.ForEach(PrintToScreen)
.ToList();

Now there's just the issue of that nasty little ToList call. Right now, we need that in order to force the collection to be iterated. The yield return syntax essentially causes a function's execution to be deferred until an element is actually requested. This is actually potentially useful even if none of the things you need to do will return values. You can chain together a bunch of actions on the collection by chain-calling ForEach with different delegates. But it's still silly to create and throw away a List just to do this.

So we create an Evaluate function that does a simple explicit iteration and nothing more, to force the iterator to be evaluated. This is extension method #2.
public static void Evaluate<X>(this IEnumerable<X> lhs)
{
 foreach (X x in lhs) ;
}
And now you can replace ToList with Evaluate, which will iterate the collection without allocating a new List.
bar.GetAllItems()
.ForEach(PrintToScreen)
.Evaluate();

This is nice, and is going to be useful if we need to chain ForEach calls. But when we don't need that there's still that Evaluate call at the end that's going to be repeated every time we want this functionality, which could be an awful lot. So, let's get rid of that too.

To do that we define a Visit function (named for the Visitor Pattern), that will call ForEach with the given delegate, and then Evaluate as well. This is extension method #3.
public static void Visit<X>(this IEnumerable<X> lhs, Action<X> func)
{
  lhs
      .ForEach(func)
      .Evaluate();
}

Now we can finally get all this done in a single function call:
bar.GetAllItems()
  .Visit(PrintToScreen);

This takes some getting used to. But it really has the potential to condense your code. It isn't readily apparent looking at one bit of code, but once you start talking about nested loops or consecutive loops, you'll see the difference. Not to mention the total effect it will have across your codebase. Loops are everywhere. Shave off 50 characters from each one and your talking about a lot of characters in aggregate.

For my part, after I determined to avoid explicit loops whenever possible, the comparatively verbose explicit looping syntax became almost painfully extraneous to my eyes. I feel like function calls are much more elegant.