-
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...
-
I’ve been giving talks for quite a while now on best practices, unit testing and other things that aim to make our lives as developers easier. Having myself suffered and lived in a World where nothing was put through automated testing, QA was usually delegated to our customers, and having faced...
-
Recent conversation I had with someone the other day: Jack : Yes, but we can’t do it like that. The business does not work that way. Me : Why does it not work that way? Jack : It’s a fundamental aspect of the business. We can’t change that. Me : And I accept that, but have you thought...
-
The Dependency Inversion Principle states: A. High-level modules should not depend on low-level modules. Both should depend on abstractions. B. Abstractions should not depend upon details. Details should depend upon abstractions. (Source WikiPedia). Throw that at a terrible programmer , and all you’ll...