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].
For more options, visit this group at http://groups.google.com/group/castle-project-devel?hl=en.

Reply via email to