-
On frameworks and libraries A logging framework helps you log what's happening in your application. A UI framework helps you render and animate UIs to the user. A communication library helps connecting parts of a distributed system. All of these tasks and concepts are pretty easy to understand. They...
-
Us, developers, are a bit like that comic strip ( from always great xkcd ): We can endlessly debate over tabs versus spaces (don't even get me started), whether to use optional semicolon or not, and other seemingly irrelevant topics. We can have heated...
-
About conventions I’m a big fan of using conventions when developing applications. I blogged about it in the past ( here , here and later here ). I also gave a talk about my experience with this approach and how I currently use it at NDC last week (slides are available here , video should be posted...
-
Now that Windsor 3 is released I can concentrate on some of my other ideas and projects. While working on one of them, called Cartographer , I encountered an interesting API design problem. I have a class (a builder to be precise) that has a task of setting up a central object (an IMapper implementation...
-
I already blogged about the topic of validating conventions in the past ( here and here ). Doing this has been a fantastic way of keeping consistency across codebases I’ve worked on, and several of my colleagues at Readify adopted this approach with great success. Recently I found myself using...
-
Something is rotten in the state of Development. It seems to me we (developers) either ignore testing altogether, leaving it to the Q&A team when we throw them the app over the wall, or we concentrate on unit tests only. Let me make one thing clear before we go any further – unit tests are...
-
When it comes to working with Models in MVC, I’ve tried many approaches, some good, others not so much. I’ve ended up settling on ViewModels, whereby the Model I submit is dictated by the View I’m working with. This allows me the flexibility of displaying or gathering only the information...
-
…of course, you’d need to have the song ABC from the Jackson Five in your head for that title to be remotely amusing. Single Responsibility Principle is such a simple principle. It states that a class should only have one responsibility. One responsibility. Not two, not three, one. Such...
-
This is a follow up to my previous post . If you haven’t yet – go and read that one first. I’ll wait. So where were we? Aha… In the last post I said, that Windsor (any container in general) creates objects for you, hence it owns them, ergo its responsibility is to properly end their lifetime when they...
-
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...
-
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...
-
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...
-
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...
-
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...
-
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...