Ayende @ Rahien

Derick Bailey commented on Dependency Injection doesn't cut it anymore

Mon, 22 Oct 2007 21:27:56 GMT

Can you provide some detail on how the magical automatic registration works? I've got a very basic IoC container that I wrote (long before I knew of the existence of Windsor) and I use reflection and a custom attribute to automatically register my dependencies. does Windsor do something similar? or something a bit more "magic"?

Mike D commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 15:57:30 GMT

Please dig deeper into the feature benefits, real-world pain, you are writing some great posts and for the first time I just might give Windsor a try. Thanks…

Steve commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 12:24:00 GMT

It is the facilities that really bring the value to the table for me as well. Eventwiring, Startable, Interceptors, etc... If there is any growth for Castle Windsor for me it would be to include more facilities! (I'd still like to see a good ADO.net facility!) I've used the facilities in some applications, and it adds tremendous value!

Nick commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 08:34:54 GMT

But for special cases, you've still got to handle them somewhere... Don't get me wrong though, I still think "foreach (Type component in ...)" is the best thing since sliced bread, and I use it for 95% of the classes I register.

Ayende Rahien commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 08:14:56 GMT

> What do you think is the scalability problem? The fact that you need to reference a lot of assemblies from a central place? Not assemblies, code. The need to define a delegate per component, and maintain it. As I said, I have about 250 components in my app now, I would be surprise to see it crossing to several thousands.

Nick commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 08:09:12 GMT

Hi Ayende, The problem for me with setting the value through the instance is that it will have to be resolved first, which is fine in the example we're talking about but might not always be. There is definitely more than one way to skin the cat though. What do you think is the scalability problem? The fact that you need to reference a lot of assemblies from a central place? I agree with that entirely, but I'm seriously wooed by the Binsor concept, which can handle that problem dynamically. If spaghetti is a concern, well - I think that can happen whether working in C#, Boo or XML ;) Would love to hear more of your thoughts on this, I think putting dynamic configuration/extensibility back inside the realm of the primary programming language is going to be a continuing theme in .NET 3.5+ and I can't wait to see where IoC configuration in particular goes. Cheers, Nick

Scott Bellware commented on Dependency Injection doesn't cut it anymore

Sun, 21 Oct 2007 01:24:28 GMT

Well... this'll be a one-sided dialog until you attract someone who's done some serious work with Ruby in non-trivial apps...

Ayende Rahien commented on Dependency Injection doesn't cut it anymore

Sat, 20 Oct 2007 21:10:07 GMT

Nick, I would rather do it something like: IoC.OddController.TheDateValue = date.Parse("15/10/2007"); The problem with handling the special cases via code is that it simply does not scale when you have many services.

Ayende Rahien commented on Dependency Injection doesn't cut it anymore

Sat, 20 Oct 2007 21:07:57 GMT

AOP Samples run from the common [Transaction], to logging method calls to [UserInterfaceMethod], which move the call to the UI thread.

Nick commented on Dependency Injection doesn't cut it anymore

Sat, 20 Oct 2007 21:01:37 GMT

Just a footnote - having delegate-based component creation doesn't preclude a container from also providing reflection-based creation. In most instances using the reflection-driven model is most convenient. E.g. if all of your controller objects bar one require the same transaction provider, register them all through reflection then override the special case using: container.Register(() => new Controller(oddTransactionProvider)); You get all the features of your programming language at your disposal, and can avoid questions like "how do I specify a constant DateTime in a config file?" or backwards-looking tricks like bijection. (I've been working on a container like this for C# - while it has miles and miles to go before being a tool for everyone, I'm convinced that there is more fertile ground to explore here.)

Gabriel Schenker commented on Dependency Injection doesn't cut it anymore

Sat, 20 Oct 2007 20:27:19 GMT

I can confirm every single word! Coming from the "dark" side (i.e. no IoC container) through the jungle (i.e. CAB) I now am using Windsor for my projects and really do NOT want to miss it any more. Especially because it's a light weight container (in contradiction to CAB) and it's so easily extendable (facilities, etc.) I swear like it very very much. Regarding AOP I'm not there yet. Oren, could you be more specific on that, that is give some working examples as you always do with other stuff (e.g. NHQG). I know the theory of AOP very well... but I feel I could need some more practice... Keep on writing!