inline: 2010/1/21 Krzysztof Koźmic (2) <[email protected]>
> Alvin,
>
> Problem is this approach won't work when matching constructor
> parameters, and it changes semantics of the dependencies.
>
> when you specify just a name with string, you're being implicit about
> what kind of dependency it is (property or method argument) and let
> Windsor figure it out.
> Indeed depending on which constructors Windsor can satisfy, the same
> call can lead to having the dependency injected as ctor arg, and other
> time as property.
>
You mean that when registering, it does not matter if the dependecy is a
ctor arg or property, and that you want to keep it that way? I fully agree
with that.
>
> I think it's a great strength of Windsor, and I much dislike being
> explicit about it when dealing with some other containers. You could
> provide certain strongly typed helpers via extension methods but I'd
> vote for not including that in the core API.
>
Well the first link (on the using site) does indeed only work for properties
and then you get the difference between prop and ctor arg. I can understand
if you don't want to make that difference (and also don't want to encourage
property dependencies maybe). And therefore not include this in the core
MK/Windsor.
But the second link (google user group) does not make a distinction between
ctor arg and property. It does however rely on reflection during
registration, which IMO is not great. It would be nicer to streamline it
with string-based service overrides.
But really all it does is change this:
Component.For<Foo>().ServiceOverrides(ServiceOverride.ForKey("paramName").Eq("dependency"))
Into this:
Component.For<Foo>().ServiceOverrides(ServiceOverride.ForType<IDependency>().Eq("dependency"))
BTW this does blow up when having multiple dependencies of the same type.
But as long as you get a clear error message that should be fine.
>
> Krzysztof
>
> PS,
> thanks for improving the docs!
>
You're welcome!
>
> On 21 Sty, 16:40, alwin <[email protected]> wrote:
> > I would really like to configurate components more strongly typed than
> > using strings for parameters and service overrides.
> >
> > I've made stuff in the past but it's more bolted on top of MK than
> > nicely integrated into it:
> http://using.castleproject.org/display/IoC/Strongly+Typed+property+wi...http://groups.google.com/group/castle-project-users/browse_thread/thr.
> ..
> >
> > Something like this would be great:
> >
> > // Use registration model as value for service override
> > var dependency = container.Register
> > (component.For<IDependency>..config...)
> > container.Register(
> > Component.For<IConsumer>().ImplementedBy<TheConsumer>()
> > .ServiceOverrides(ServiceOverride.For<IDependency>().Eq
> > (dependency))
> > );
> >
> > or even:
> > // Easier discoverability when using intellisense?
> > container.Register(register =>
> > register.ComponentFor<IConsumer>().ImplementedBy<TheConsumer>
> > ()
> > .ServiceOverrides(s => s.For<IDependency>().Eq
> > (dependency))
> > );
> >
> > If you guys are into this I can try to provide some patches (no
> > promises...).
> >
> > On 21 jan, 15:32, Richard Fleming <[email protected]> wrote:
> >
> > > That was why in this case I would suggest creating a method to allow
> the
> > > user to register interface types which they would like to be their
> > > registerable interfaces, I wouldn't want to force that on users either,
> just
> > > in my case wasn't necessary since my interface exists in the same
> project as
> > > the functionality :) .
> >
> > > On Thu, Jan 21, 2010 at 8:29 AM, Ayende Rahien <[email protected]>
> wrote:
> > > > I wouldn't like to have something like this for the simple reason
> that I
> > > > want to avoid forcing people to implement my interface.
> >
> > > > On Thu, Jan 21, 2010 at 4:21 PM, Richard Fleming <
> [email protected]>wrote:
> >
> > > >> Just as an alternative method to a [Service] attribute I do
> something
> > > >> along the following in most of my projects now:
> >
> > > >> public interface IRegisterable { }
> > > >> public interface IRegisterableWithFactory : IRegisterable { }
> >
> > > >> public static class WindsorExtensions
> > > >> {
> > > >> public static BasedOnDescriptor FirstInterfaceOnType(this
> > > >> ServiceDescriptor serviceDescriptor)
> > > >> {
> > > >> return serviceDescriptor.Select((type, baseType) =>
> > > >> GetInterfacesOnType(type));
> > > >> }
> >
> > > >> private static IEnumerable<Type> GetInterfacesOnType(Type
> type)
> > > >> {
> > > >> var interfaces =
> > > >> type.GetInterfaces().Except(type.BaseType.GetInterfaces());
> > > >> return interfaces.Count() == 0
> > > >> ? (typeof(object).Equals(type.BaseType) ?
> null :
> > > >> GetInterfacesOnType(type.BaseType))
> > > >> : new[] { interfaces.First() };
> > > >> }
> > > >> }
> >
> > > >> public DefaultContainer
> AddRegisterableComponentsFrom(Assembly
> > > >> assembly)
> > > >> {
> > > >> return
> > > >> AddRegisterableComponentsFrom(assembly.GetTypes().ToList());
> > > >> }
> >
> > > >> public DefaultContainer
> > > >> AddRegisterableComponentsFrom(IEnumerable<Type> types)
> > > >> {
> > > >> Register(
> > > >> AllTypes.Pick().From(from t in types
> > > >> where !t.IsClass && typeof
> > > >> (IRegisterableWithFactory).IsAssignableFrom(t)
> > > >> select
> > > >> t).WithService.FirstInterfaceOnType().Configure(
> > > >> c =>
> > > >> c.Attribute("instance-accessor").Eq("Instance")));
> >
> > > >> Register(
> > > >> AllTypes.Pick().From(from t in types
> > > >> where t.IsClass &&
> !t.IsAbstract &&
> > > >> typeof(IRegisterable).IsAssignableFrom(t) &&
> > > >> !typeof(IRegisterableWithFactory).IsAssignableFrom(t)
> > > >> select
> > > >> t).WithService.FirstInterfaceOnType());
> > > >> return this;
> > > >> }
> >
> > > >> (DefaultContainer is my class inheriting from WindsorContainer where
> I
> > > >> configure facilities outside of configuration)
> >
> > > >> What I liked about this method was it allowed me to control
> > > >> auto-registration by having a custom interface defined (and
> typically
> > > >> creating an AbstractComponent or something of that sort which
> implements
> > > >> IRegisterable).
> >
> > > >> Just thought I would throw this out there as another alternative, I
> was
> > > >> thinking along the lines of possible if there was a way to register
> a
> > > >> interface type(s) as the "auto-registering" (IRegisterable in this
> case)
> > > >> within the container to make the functionality more general across
> multiple
> > > >> projects.
> >
> > > >> Thanks,
> > > >> Rick Fleming
> >
> > > >>> > - Consider adding attributes like [Service] - to make auto
> > > >>>> registration
> > > >>>> > easier.
> >
> > > >>>> +1
> >
> > > >>>> > - Convention based registration for fluent stuff
> > > >>>> > - IFoo -> Foo
> > > >>>> > - IFoo -> FooImpl
> > > >>>> > - IFoo -> FooService
> >
> > > >>>> - I'm not sure what you mean by that...
> >
> > > >>> contianer.AddAssembly("foo");
> >
> > > >>> - scan for all interfaces
> > > >>> - for each interface, look for a matching type based on the
> following
> > > >>> naming conventions, if exists, register it.
> > > >>> - same for types marked as [Service] that implement only one
> interface
> > > >>> - if there is more than one interface implemented, require a
> interface
> > > >>> parameter on the attribute.
> >
> > > >> --
> > > >> 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]<castle-project-devel%[email protected]>
> <castle-project-devel%[email protected]<castle-project-devel%[email protected]>
> >
> > > >> .
> > > >> For more options, visit this group at
> > > >>http://groups.google.com/group/castle-project-devel?hl=en.
> >
> > > > --
> > > > 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]<castle-project-devel%[email protected]>
> <castle-project-devel%[email protected]<castle-project-devel%[email protected]>
> >
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/castle-project-devel?hl=en.
> >
> >
>
> --
> 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]<castle-project-devel%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/castle-project-devel?hl=en.
>
>
>
>
-- 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.
