- Recent
- Popular
- Tags (0)
- Subscribers (1)
- A small excerpt from the IoC Container docYesterday
-
Twitter followers probably know that I’ve been working on an IoC Container document for my team. It goes over several aspects – including why in my view “DI” is a wrong term and should be banished – from history to features and scenarios. I got permission to release some bits of it in the future. The following however is an excerpt I thought I should share.
Another important aspect of common use of IoC Containers lies on the fact that the components that make up an application play no role in defining or constraining the implementation that can satisfy a dependency. The minimal safety is provided by strongly typed contracts, but it ends there. All binding is left for an external entity – the application host.
Given that the ultimate goal is to reduce coupling and promote reuse, this approach makes a lot of sense as it allows components to be used anywhere, with or without a container.
The component can express what is required or optional using natural OOP idioms. For example, multiple constructors will allow the IoC Container to call the one it can satisfy the most arguments. Also public writable properties are considered optional dependencies for most containers. Note that the container is just playing the role of a user of the class, checking constructor overloads and properties that they can provide values for, absolutely no different from a human interacting with the same class.
By sticking with these natural idioms a class wi
- Some Castle related newsJanuary 5
-
During the holiday – and between Wow quests and dungeons – I’ve managed to apply a bunch of patches and to fix some outstanding bugs on the Components and Windsor projects.
Another interesting accomplishment is some contributions finally made in and Castle.Core, Castle.MicroKernel and Castle.Windsor are now Silverlight ready.
Last but not least, I recently applied a patch that made Castle.DynamicProxy 2 also available for Silverlight.
The pending items now are:
- Fix the build so the bits targeting SL will be correctly build and made available through our build server
- Change Windsor to use the SL version of DynProxy.
Thanks for all the patches, people. Keep them coming!
- Again on internalsDecember 9 2008
-
Dave (he’s a dev on our team) outlines how some things work here, and how difficult it is to decide in favor of openness by default.
- Castle Windsor and the WCF FacilityDecember 2 2008
-
If I recall correctly, Ayende started the WCF Facility several months ago and Craig took over and have been improving it almost daily since then. As a completely ignorant on WCF, I have no idea on how it works and how to use it.. so Mike’s post sure came handy
Given the amount of changes in Craig’s last commit there’s a lot to blog about..
- On internalsNovember 12 2008
-
I hate internals and privates and lack of extension points. Really! Many times I’ve wondered ‘what’s wrong with these people that hide all this stuff from me? are they concerned I wouldn’t know how to use it?’
Being on the other side now, and trying to slowly change the culture, I have to say that I understand why MS is so reluctant to make things more open by default. And all comes down to the fact that we don’t make breaking changes.
If we were to open a poll and ask developers what they would prefer: more open and extensible API vs no breaking changes, I’d guess you would go with open/extensible. And later act surprised when a new version of the framework broke your app, forced you to make changes on your code in order to get it compiling, and so on.
That doesn’t mean that openness is forbidden and extension points are evil. Just that we think very - and I mean _very_ - carefully about those. Once we ship it, we can’t remove it. We can’t change it. Ever!
That being said, I think we are going slowly but surely in the direction of open-closed principle and composition over inheritance, at least on my team, and this is enough to make me happy (for now).