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. 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. Krzysztof PS, thanks for improving the docs! 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]> > > >> . > > >> 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.
