Design
Design
Probably the single most misunderstood feature of Castle Windsor is regarding its lifetime management of components. Hopefully in this post (and the next one) I’ll be able to clear all the misconceptions. Why is Windsor tracking components in the first place? One of the core responsibilities of a container is to manage lifecycle of components. At a very high level it looks like in the picture on the right. The container creates the object, sets it up, then when it’s ready to go, it gives it to you, so that you can use it, and when...
I’ve blogged a bit in the past, more or less explicitly, about patterns and antipatterns of Inversion of Control usage. This is yet another post that will (possibly) spawn a series. We’ll see about that. Note that this post is not talking about any particular IoC container and what I’m talking about is generic and universally applicable to all of them. Historically we started to register and configure our components in XML (example is in pseudo syntax, not specific to any particular framework). <components>
...
What you’re seeing here, is a feature in very early stages of development. It’s very likely to change in the very near future, hopefully based on your feedback which I’m looking forward to. It is often the case with IoC containers, especially when registering components by convention, that you end up with misconfigured components, or with an exception saying that your component can’t be resolved. To aid working in these situations StructureMap provides methods like WhatDoIHave and AssertConfigurationIsValid. That’s the only container I know of that provides this kind of diagnostics. Windsor also has...
As I expected my previous post prompted a few questions regarding the Three Container Calls pattern I outlined. Major one of them is how to handle the following scenario: We create our container, install all the components in it. Moments later we resolve the root component, container goes and creates its entire tree of dependencies for us, does all the configuration and other bookkeeping, injects all the dependencies and gives us back the new fresh ready to use objects graph that we then use to start off the application. More often than not, this will...
Quite regularly I get asked by people how they should use IoC container in their application. I don’t think I can answer this question once and universally because every application is different, every application has different needs and every application has different opportunities for leveraging an Inversion of Control container.
However there are some general rules and patterns that I use and I thought I will blog about this instead.
While I use a concrete example of Castle Windsor, the discussion here is universal.It applies to all containers.
Inversion of Control means container does not exist
Basic difference between an Inversion of Control...
Continuing the topic from the previous posts. What would happen? Current behavior of Windsor is somewhat flawed. What it will do is it will resolve foo, and provide it with bar. The flaw of this behavior is that now when we resolve foo via any of the tree containers we’ll get the same instance (since it’s a singleton). This introduced two issues: component from childA (bar) will now be available via childB and parent while logically thinking – it should not. we have temporal coupling in our code. Depending on...
This is a follow up to my previous post. I deliberately didn’t discuss the issues that arise when using container hierarchies to get some feedback on usage first. So what’s the problem? Consider trivial scenario: We have two components, where foo depends on bar. The dependency is optional, which means that foo can be constructed even when bar is not available. Then we have the following container hierarchy: We have parent container where foo is registered and two child containers. In one of them we register bar. Both foo...
Continuing the theme of conventions in code; I talked about validating the conventions, but I didn't touch upon one more basic issue. What to base the conventions on? Short answer is - anything you like (as long as it’s black). Long answer is, well - longer. Strong typed nature of .NET gives us rich set of information we could use to build conventions on. Let's go over some of them. I will concentrate mostly on single scenario as an example - IoC container registration, but the discussion can be easily extrapolated to cover any other scenario. Location ...
I'm a big proponent of the whole Convention over configuration idea. I give up some meticulous control over plumbing of my code, and by virtue of adhering to conventions the code just finds its way into the right place. With great power comes great responsibility, as someone once said. You may give up direct control over the process, but you should still somehow validate your code adheres to the conventions, to avoid often subtle bugs. So what is it about? Say you have web, MVC application, with controllers, views and such. You say controllers have a layer...
Paul, whom some of you may know as the maintainer of Horn project, left a comment on my blog, that was (or to be more precise – I think it was) a continuation of series of his tweets about his dissatisfaction with the state of affairs when it comes to dependencies between various OSS projects in .NET space, and within Castle Project in particular. I must say I understand Paul, and he’s got some valid points there, so let’s see what can be done about it. Problems One of the goals of Castle Project...
C# 4.0 is just round the corner and along with it set of nice new additions to the language, including optional parameters. There’s been some historical resistance to add this feature to the language, but here' it is, and I’m glad it’s coming, or at least I was. In few words, optional parameters, have their default value specified in the signature of the method. You can then skip them when calling method, and the method will be called with their default values. So, what’s the deal? To simplify the current discussion I will refer...
Quiz Consider the following piece of code (it shows Castle MicroKernel, but since Windsor is built on top of MicroKernel, it works the same way): IKernel kernel = new DefaultKernel();
kernel.AddComponent("sms", typeof(IAlarmSender), typeof(SmsSender));
kernel.AddComponent("email", typeof(IAlarmSender), typeof(EmailSender));
kernel.AddComponent("generator", typeof(AlarmGenerator));
AlarmGenerator gen = (AlarmGenerator) kernel["generator"];
Considering AlarmGenerator has a dependency on IAlarmSender, which one of two registered components will it get?
The answer is: the first one.
In this case we registered SmsSender first, so it will get injected. If we switched the order of registration, EmailSender would get injected. It does...
Take this piece of code: public int Count(string text)
{
Console.WriteLine("Counting...");
// simulate some lengthy operation...
Thread.Sleep(5000);
return text.Length;
}
What’s wrong with it?
It’s not very obvious what the magic number 5000 means? Does it mean 5000 years? 5000 minutes? 5000 the time it takes to run around Main Market Square in Kraków?
Sure, you can hover over the invocation (if you’re in Visual Studio) and see the tooltip
and see that the number denotes milliseconds,...
I have a tendency to overcomplicate things sometimes. Unit tests, are one such piece of code, that you want to keep as simple and clean as possible, so that other developers can easily find out how your class-or-method-under-test is supposed to work. There’s a principle for that that says it very strongly – “Keep it simple, stupid.” Don’t make it flexible when it does not have to be (just … hard code it). For example, when I was working on IInterceptorSelector support for Castle DynamicProxy, I had to test proxies without target, where return value is set by an...
As developers from our first years we are taught by our masters: “Comment your code you should, my young apprentice”. I even found this article, that outlines 13 rules, on how you should comment your code. I only have two rules for that: Don’t comment what your code is doing. If you find it necessary, it’s a code smell, and you should start thinking about refactoring it, so that it’s obvious. Do comment why your code does what it does. Other than that, merry Christmas and happy new year everybody. ...
Creating multilingual applications is a huge topic. There are whole books devoted to it, and if you’re serious about it, you should definitely read those, because what you see on surface, is only the tip of an iceberg. If you only want to play with localization or need a quick reference, hopefully this post will help. Fist thing is, .NET is really well thought of if it comes to localization, so if you know what you’re doing, it’s pretty painless to create application that will be easy to translate to other languages (localization is a LOT bigger topic...
Accidently this post hit the wave of discussion on the blogosphere regarding Microsoft’s approach of keeping very big chunks of APIs internal, sealed, or otherwise unusable by users, and backward compatibility. To some extent I can agree with both sides, because as always, the truth is in the middle, and I believe we’re talking about the solution (keeping things non-public and non-extensible) instead of the actual problem (the way API is designed, that makes a lot of useless parts public, and useful parts non-visible). One ridiculous example I saw is the IlGenerator class. It’s...