198

I'm a long-time Windows developer, having cut my teeth on win32 and early COM. I've been working with .NET since 2001, so I'm pretty fluent in C# and the CLR. I'd never heard of Castle Windsor until I started participating in Stack Overflow. I've read the Castle Windsor "Getting Started" guide, but it's not clicking.

Teach this old dog new tricks, and tell me why I should be integrating Castle Windsor into my enterprise apps.

RBT
  • 24,161
  • 21
  • 159
  • 240
David Hill
  • 4,102
  • 2
  • 23
  • 19
  • 1
    Read up on Inversion of Control. It's very useful for helping you decouple dependencies, which will help you a lot in writing unit tests, for starters. – Dan Csharpster Oct 22 '13 at 17:48

5 Answers5

375

Castle Windsor is an inversion of control tool. There are others like it.

It can give you objects with pre-built and pre-wired dependencies right in there. An entire object graph created via reflection and configuration rather than the "new" operator.

Start here: http://tech.groups.yahoo.com/group/altdotnet/message/10434

Imagine you have an email sending class. EmailSender. Imagine you have another class WorkflowStepper. Inside WorkflowStepper you need to use EmailSender.

You could always say new EmailSender().Send(emailMessage);

but that - the use of new - creates a TIGHT COUPLING that is hard to change. (this is a tiny contrived example after all)

So what if, instead of newing this bad boy up inside WorkflowStepper, you just passed it into the constructor?

So then whoever called it had to new up the EmailSender.

new WorkflowStepper(emailSender).Step()

Imagine you have hundreds of these little classes that only have one responsibility (google SRP).. and you use a few of them in WorkflowStepper:

new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()

Imagine not worrying about the details of EmailSender when you are writing WorkflowStepper or AlertRegistry

You just worry about the concern you are working with.

Imagine this whole graph (tree) of objects and dependencies gets wired up at RUN TIME, so that when you do this:

WorkflowStepper stepper = Container.Get<WorkflowStepper>();

you get a real deal WorkflowStepper with all the dependencies automatically filled in where you need them.

There is no new

It just happens - because it knows what needs what.

And you can write fewer defects with better designed, DRY code in a testable and repeatable way.

Community
  • 1
  • 1
Matt Hinze
  • 13,577
  • 3
  • 35
  • 40
  • 33
    AWESOME! Well written! NOW I'm excited about it. – David Hill Sep 24 '08 at 12:45
  • 2
    Thanks. There's a lot more to it. I picked a very simple and painfully concrete example. You can use interfaces to switch out implementations. You can auto-configure entire assemblies. You can specify lifecycles like singleton or per-http-request, etc. Keep going - it will change your work. – Matt Hinze Sep 24 '08 at 17:19
  • 6
    And to help the Java folks: This is Guice for .NET ;-) – Mark Renouf May 16 '09 at 22:10
  • I use windsor with NHibernate and the WCF facility - once you start playing with it and you see what you can do with so few lines of code - you never look back it cleans up your codebase too and makes it more readable as there tends to be less wiring and messing about and you're left with the real nuts and bolts :) –  May 05 '10 at 14:51
  • 7
    I find that in my experience it is harder to debug because where are the objects initialised?? - In a large project it is hard to find the root of initialization. I prefer the old fashioned way of using `new`, I know where everything is then. I also don't like the idea of using reflections and it is really a black box, code we do not own and therefore do not fully understand. – Luke T O'Brien Mar 23 '16 at 12:21
  • Well written, thanks! One remaining question: how does `Container.Get();` work? Where is this object configured such that it doesn't need a `new` statement? – Matt Jul 07 '16 at 14:00
  • @LukeTO'Brien you are obviously not writing unit tests much/at all. Without using IoC/DI writing unit tests is virtually impossible. – bytedev Sep 22 '16 at 15:26
  • 1
    @nashwan Yes I am writing unit test, but the principles of IoC/DI can be applied without Castle Windsor or any third party framework, to me it just adds another dependency, that was the point of my comment. I just don't see the advantages to Castle Windsor. – Luke T O'Brien Sep 23 '16 at 18:04
  • @LukeTO'Brien totally agree with you. Thought you mean you werent using IoC/DI at all (even without Windsor) :-) – bytedev Sep 26 '16 at 08:53
  • Hi, is this still relevant in 2021? Does .net core built-in core suffice the requirement? – Kishor Tiwari Aug 04 '21 at 07:54
4

Mark Seemann wrote and excellent book on DI (Dependency Injection) which is a subset of IOC. He also compares a number of containers. I cannot recommend this book enough. The book's name is: "Dependency Injection in .Net" https://www.manning.com/books/dependency-injection-in-dot-net

IUnknown
  • 559
  • 6
  • 12
3

I think IoC is a stepping stone in the right direction on the path towards greater productivity and enjoyment of development team (including PM, BA an BOs). It helps to establish a separation of concerns between developers and for testing. It gives peace of mind when architecting which allows for flexibility as frameworks may come in and out.

The best way to accomplish the goal that IoC (CW or Ninject etc..) takes a stab at is to eliminate politics #1 and #2 remove need for developers to put on the facade of false understanding when developing. Do these two solutions not seem related to IoC? They are :)

Michael Socha
  • 1,748
  • 1
  • 16
  • 17
3

Castle Windsor is Dependency Injection container. It means with the help of this you can inject your dependencies and use them without creating them with the help of new keyword. e.g. Consider you have written a repository or a service and you wish to use it at many places, you need to first register your service / repository and you can start using it after injecting it on the required place. You can take a look at the below tutorial which I followed to learn castle windsor.

link.

Hope it will help you.

Rakesh Burbure
  • 1,045
  • 12
  • 27
1

Put simply. Imagine you have some class buried in your code that needs a few simple config values to do its job. That means everything that creates an instance of that class needs to get those dependencies, so you usually end up having to refactor loads of classes along the way to just pass a bit of config down to where the instance gets created.

So either lots of classes are needlessly altered, you bunch the config values into one big config class which is also bad... or worst still go Service Locator!

IoC allows your class to get all its depencencies without that hassle, and manages lifetimes of instances more explicitly too.

andrew pate
  • 3,833
  • 36
  • 28