I've been spending more and more time thinking about how we over-engineer solutions and even libraries.  Currently my feeling is that NuGet and OpenWrap are only going to make this problem worse and not better.  The basic problem with buy versus build is that it's posing the wrong choice.  Of course buy is cheaper than build.  But it's like trying to chose between sparkling and still: the correct answer is tap. A number of years ago I built a system that used Binsor for configuration.  Here were the benefits (to me): Concise syntax ...

Sometimes i think I spend my time on this blog just trying to explain the thinking of people much smarter than me.  This is definitely one of those cases.  I've probably learned more about programming from reading the Retlang source code than any other.  It's both remarkably free of compromises and easy to read.  Sometimes you learn not from any individual snapshot, but from the evolution of the code base.  For instance, here was the process context factory in Retlang 0.3: public interface IProcessContextFactory : IThreadController, IObjectPublisher { ...

.NET has a lot of IoC containers.  This is undoubtedly a good thing: diversification is a sign of strength in the ecosystem.  MEF is showing how specialization can be used to solve specific issues.  I'm going to try to set out one vision of how IoC containers should evolve.  This is not my opinion of how they all should evolve, it's simply my vision of what I would like from one of the many containers. I've argued for some time that containers are all about configuration.  If you don't believe that, then you should consider why Yadic isn't your...

Over past few years, I've spent a lot of time thinking about dependency management, usually in the context of NHibernate and Castle Windsor.  The truth is that the problems these projects have are the problems any sufficiently complex open source project has.  So, having been playing with Clojure for several days I've got some thoughts about how the other half lives: For the most part, the JVM has been phenomenally stable for the last few years, so there's no analogue of the multiplicity of versions of .NET and Silverlight just isn't a problem for them.  Another way of saying...

You’ve probably never heard of Yadic.  It’s the smallest DI container I’ve seen.  I’ve linked directly to the only source file because it’s a good read, even if Google Code can’t do syntax colouring for F#.  It’s more opinionated than a party political conference and has some neat ideas.  One of them is the concept that you can specify that a service be decorated. Let’s just run through that again: you can take a service and stick a decorator on it.  Now, you may be thinking that you can already do this in most containers, and you can but it’s slightly...

I have to admit, when I read Uncle Bob’s post about dependency injection, I really didn’t expect the response it would get since it struck me as being relatively uncontroversial.  So Davy’s reaction rather surprised me.  Davy had two major objections to the original article: The contention that IoC containers aren’t always appropriate. The advocating of the use of abstract factories. Now, when I teach constructor injection to developers around my company, I always teach it in the manner Uncle Bob describes: just pass things into the constructor.  Sooner...

I once took advantage of the published source code of the Microsoft Enterprise Library Data Access Block to make some firm-specific modifications.  One of those changes that only really makes sense in the target environment, nothing particularly general.  The Data Access Block, for those of you who aren’t familiar with it, is basically an improved version of the ADO.NET API, with some pretty useful support for stored procedures.  It’s not NHibernate, but it’s better than coding the API in the raw. While I was there, I decided to rip out the stuff we didn’t use.  That turned out to...

If you're writing SOLID code, you're going to be doing a lot of wiring.  Typically, this wiring only changes in response to business change.  Some wiring is going to be static for years.  If you're building a car, you won't suddenly wire the clutch to the CD player, as entertaining as it would be when your brother-in-law tried to drive it. On the other end of this spectrum, there's stuff that changes all the time.  Every machine you use, it needs to change.  This is actual configuration information.  The rest of it can, frankly, be hard wired.  True configuration...

I wanted to write something about the concept of a "configuration class", which Emanuele touched on in a discussion about the singleton pattern.  Let me start by explaining what I mean by a configuration class.  It's a relatively common "pattern", although you'll never find it in any books.  I'm going to argue that this is because, like Singleton, it's the wrong solution to the problem. The Problem .NET has an incredibly flexible XML-based configuration API.  However, for the purposes of this discussion, we can concentrate on the bit that most developers use: AppSettings.  This is basically just a string hashtable with delusions...

Probably the most C# common interview question in London is "What's the difference between an abstract class and an interface?".  Let's be clear: if you use the word contract in your answer, you're not getting a job if I'm asking the question.  Contracts are a concept that doesn't directly correspond to any code construct in C#, abstract classes and interfaces are your fundamental building blocks of well written code. Here's the one word answer:  Code.  Abstract classes can have code, interfaces can't.  C#, like Java, doesn't allow you to pull code from two sources, so you can only inherit from...

This is just me documenting a particularly weird behaviour of ASP.NET MVC.  Usually, it doesn't matter, but if you used your own controller factory, like with MvcContrib, it's a pain to diagnose.  Basically, if you re-use a controller, the ModelBindingContext's values are cached.  This is, to say the least, freaky, especially since you can see that the url has changed.  So, you fire up one page, move to another id and get back the first page.  In short, register controllers as transient explicitly.  If you're wondering how I found this out, consider that AllTypes in Castle Windsor registers services as...

I couldn't quite leave this code alone.  I have to admit, the whole reason I wrote the AutoGen stuff in the first place was out of frustration at the amount of plumbing factories I was having to write in a recent project.  Well, the plumbing of event wiring was getting at me as well, so I decided to do something about that as well. Let me explain the problem I wanted to solve, first.  I recently had to modify a program that took one fix connection to handle one or two, depending on the deployment scenario.  Now, obviously, handling...

Since adding convention over configuration features is the second most popular suggestion (after actually shipping) on the Castle User Voice site, I figured I'd chip in my own thoughts.  Impressive as Krzysztof's approach is, I'd rather that we didn't modify the runtime behaviour of Castle in order to get these kind of features.  Instead, I'd rather make the registration API more powerful.  The AllTypes code shows us a way forward on this, and the fluent NHibernate code has a good model for convention over configuration. So, here's a syntax that I would like to see just for auto-registration.  You'll note...

I was recently reading a fairly detailed comparison by Andrey Shchekin of the various injection containers out there in the .NET space.  I found it interesting that the last feature he regarded as important was the ability to tell the container to mock a particular object.  Now, when I wrote an article about evaluating IoC containers, it didn't even occur to me to include this.  Now, Andrey includes many points that I haven't covered, like the fact that Castle hasn't had a stable release in well over a year, but on this point I think it's best left out....

So, my patch got rejected for a variety of good reasons.  One is the standard problem of not having checked everything: I spent so much time making sure that the nant build worked I missed that I hadn't included the relevant csproj files.  Of course, I have any number of problems getting castle to build at the best of times, but I've started to regard this as a constant of the universe. Another is the Castle coding standards.  Now, trivial coding standards are important, by which I mean that whilst it doesn't matter if tabs are two or four spaces,...

In the previous post, I dealt with the standard .NET config file.  It would be lovely if all we needed to deal with was appsettings and connection strings.  Sadly, the world is more complex than that.  Now, quite a few of the systems listed below (pretty much all of the XML-based ones) give you the option of including their config in the app.config or in a separate file.  I can't say as I see it makes a blind bit of difference.  Each of them has their own XML schema and I doubt you wish to write a diff tool for...

One of the nice things about finally finishing a major project is that you get to do some work on side projects you find entertaining.  So, today, I finally finished a rather ugly merge and got a new version of AutoGen for Castle out.  Obviously, it isn't hard to implement the Common Service Locator in Windsor.  However, since the idea of AutoGen was to allow you to use your own abstraction for DI, and so implementing Microsoft's seemed like a good stress test.  I'll take a crack at NServiceBus next... :) I shamelessly ripped off Ayende's tests for the CSL...

Mauricio Scheffer asked how AutoGen differs from the TypedFactory Facility already in Castle.  (An equally valid question is why the code is five times the size.)  The answer is that it doesn't in essence, but it does in detail.  However, the details matter, in that AutoGen addresses common use cases, whereas the TypedFactoryFacility is only going to save you 6 lines of code.  The principal differences are: Configuration Constructor Arguments Handling Keys Disposal Handling Multiple Methods How TypedFactoryFacility is used Let's take...

I recently published a tool called AutoGen for Castle.  You can check it out at Google Code.  In essence, it auto-generates factory objects for you and adds them to your container.  This is an extremely useful thing to be able to do.  I do, however, find it a bit hard to explain, so bear with me. A relatively good rule of thumb these days is that a class should instantiate objects or do something with objects but never both.  Miško Hevery has written a lot of good stuff on this subject, and I don't propose to mangle his thinking here. ...

I thought I'd write a bit about how I understand the philosophy of IoC containers.  I realize I'm actually building up to something that I started talking about a while ago.  I'm probably not saying anything that Martin Fowler didn't say before, but I have my own slant on it.  To start off with, I'd like to just review what we actually mean by various terms: Inversion of Control (IoC) is a general name for the pattern where an object isn't responsible for managing the lifecycle of the services it uses.  The simplest way to implement this (in .NET)...