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
-~----------~----~----~----~------~----~------~--~---
