Hi guys,
We've started using the Castle Windsor IoC container recently in our company's application framework, which was quite an improvement (coming from a Unity v2.0 background). You have some interesting features there, I must say! It makes things a bit more "smooth"; we were also already using Castle Dynamic Proxy for our object proxying needs, so integrating this with Castle Windsor to automagically proxy the classes we want to proxy is quite easy. Anyway, I have an interesting issue which I have looked for in the documentation but not found, yet... As you know, you can inject services to a component either by using constructor injection or property injection. Both has its pros and cons; traditionally, we've used constructor injection (since that's the only thing that works with Unity AFAIK). I did some playing around with MEF a while back, which uses property injection instead (but their injected properties must be decorated with [Import] statements). What I like about property injection (and dislike with constructor injection) is scenarios when you have a service reference being stored in a base class (making it available to child classes). With constructor injection, you have to take this service in as a parameter to the constructor and pass it on to the base class (using the base(svc1, svc2) syntax). This is quite ugly IMHO, and also, it has a more serious drawback: it adds the risk that you create breaking changes in your versions, if you modify the base class dependencies to require more/less services. All child classes need to be updated, which is just plain bad, as I see it. This means that I think for those scenarios, property injection is superior. But, there is a slight disadvantage with property injection, namely: the injection is voluntary, it is not seen as a mandatory dependency. Is there any way, whatsoever, to change this? By means of an attribute I can decorate the property with, perhaps? If not, this would definitely be a great feature to have in an upcoming version of Castle Windsor. I understand the point and the rationale behind the default behaviors, but as we know, defaults work in maybe 90-95% of the scenarios and in the other scenarios, it's nice to be able to tweak your way around... Any comments on this would be highly interesting! Best regards, Per Lundberg -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
