That's how it works already kernel.Register(AllTypes.FromAssembly(asm) .BasedOn<IController>(...) .BasedOn<IIFilter>(...)
all in 1 iteration of assembly On Thu, Jan 21, 2010 at 10:05 AM, Ken Egozi <[email protected]> wrote: > The convention based registration works great for us, and it is of great > value I believe. > > However I do get a slow startup time, because of repeatedly iterating over > the assemblies' GetExportedTypes collections, once for MR components, once > for the convention configurations, and more. > what could be great is some kind of a way to hook into a single iteration > over an assembly types collection, and supplying an action for every one (if > it's a MR controller/filer/etc, if it's a Service that implements IService, > etc.) > > > > 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. >> >> 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]> >> <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. >> >> >> >> > > > -- > Ken Egozi. > http://www.kenegozi.com/blog > http://www.delver.com > http://www.musicglue.com > http://www.castleproject.org > http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם > > -- > 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.
