Thanks Oren, there's always another injection point I haven't discovered yet. :) I've just spent a bit of time analyzing the behaviour of adding a handler selector, and it seems that it could be used to implement most of the possibilities that I suggested, although it can't be used to implement Krzysztof's original suggestion since it doesn't expose the dependency model. Chaining two conventions might be tricky, but I'll skate over that for now. Anyway, maybe I went into too much detail last time and distracted from the reason for the write-up. I agree completely that Castle is extremely configurable, the questions are more aimed at a) what is the behaviour "out of the box" and b) what conventions should come with the box? I think that's why there's so much interest in this on uservoice.
Thanks, Julian. 2009/5/20 Ayende Rahien <[email protected]> > Julian,That is all user configurable right now with the use of > IHandlerSelector > > > On Wed, May 20, 2009 at 2:38 PM, Julian Birch <[email protected]>wrote: > >> Okay, that should get people's attention. ;-) Krzysztof originally >> suggested this >> here<http://kozmic.pl/archive/2009/04/09/convention-based-dependency-injection-with-castle-microkernelwindsor.aspx>, >> and it's received a fair bit of support on User Voice. I said I'd write up >> the issue for the dev list. Now, the subject of convention over >> configuration is huge, but this is going to concentrate on one particular >> issue. I'd very much like the developers's opinions. >> Now, taking the example right at the start of Krzysztof's post, there are >> two things I want to discuss. The first is the behaviour when you call >> >> kernel["generator"] >> >> and the other when you call >> >> kernel.Resolve<IAlarmSender>. >> >> In the first, I'm going to say we're resolving an ambiguous dependency, in >> the latter, an ambiguous reference. (Sorry if I'm using the wrong terms >> here.) >> >> Now, there are a number of ways that we could resolve this: >> >> - First Registered (The current behaviour) >> - Use a convention on the basis of the parameter name (The behaviour >> Krzysztof >> suggests, only applicable to dependency resolution) >> - Select if a secondary (marker) interface is present. (Useful if one >> object aggregates the others, but not appropriate as a default.) >> - Throw An Exception (I actually quite like this idea. I'm pretty >> sure Krzysztof hates it.) >> - Something I haven't thought of. >> >> These behaviours could be chained (try parameter name convention, then >> marker, then throw an exception). Example syntax (for illustration only): >> >> container.Register(DependencyResolution.Using( >> X.ByParameterName, >> X.ByMarkerInterface<IAggregate>(), >> X.DontResolve >> )); >> >> I believe it wouldn't be too hard to support this with a patch to the ( >> believe, I haven't actually tried coding it yet... :) ). >> >> Questions: >> >> 1. Should the current behaviour of resolving ambiguous dependencies be >> changed? >> 2. If so, what should be the new default? >> 3. What's it going to break? >> 4. Same question again for ambiguous references. >> 5. Should we add in a syntax for pluggable behaviours for resolving >> ambiguous references/dependencies? >> 6. What conventions should we support? >> 7. What's the syntax for XML, Binsor? I'm assuming at the moment that >> we'd allow customization of behaviour through a built-in facility. >> 8. What constitutes an ambiguous reference/dependency? >> >> Obviously, the answers to some questions affect the answers to others. >> >> For clarity, my answer to 8) is: >> >> - Where there is no service override >> - Where there is no suitable parameter passed to Resolve >> - Where two components are registered for or forward the same service >> type >> - Implementations of the service type not registered as such are not >> counted >> - Implementations of the service type through proxying not >> registered as such are not counted >> >> Apologies if this isn't clear, or I missed an important aspect of the >> pipeline. >> >> Julian. >> >> P.S. I've come to the conclusion that my convention proposal on the >> UserVoice list is compatible with this one, I'll come back with that when >> I've got a more developed proposal. >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Development List" 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-devel?hl=en -~----------~----~----~----~------~----~------~--~---
