inline 2010/1/21 Krzysztof Koźmic (2) <[email protected]>
> About your ideas, inline > > On 21 Sty, 13:57, Ayende Rahien <[email protected]> wrote: > > Now that a new version of Windsor is out, Krzysztof has brought to my > > attention the need to plan the next version. > > I thought about this for a while and I think that this is my initial list > of > > things that I would like to see in the next version of Windsor. > > > > - InjectMembers(instance) - resolve dependencies on an existing > instance > > without registering the type in the container > > That would be useful for situations where the instance is created by > > someone else (like the Page instance in ASP.Net WebForms). > > I'm not a fan of this, but if there's demand... > > I think it is a useful thing to have, and I have needed it a time or two in the past. > > - Add something like StructureMap Registries, just to allow > standartized > > approach to configue the container. > > - inherit container ? > > - facilities ? > > - The goal here is just to have a standard recommended way of doing > > it, rather than putting it in Application_Start > > - with convention based fluent API, I don't see it as an issue. And we > do have > already ways of abstracting it, most notably IWindsorInstaller that > work like > Autofac's Modules and SM Registries AFAICT > > I like the idea of IWI, my point is that we need to communicate that it is the standard way of doing this. > > - 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. > > - Generate proxies to match up lifestyles of components that have > > different life styles. > > I thought about this as well, but then we bump into limitations of > proxies plus that works only for interfaces. > > I think we are better with the limitation than without it. Moreover, that would allow us to throw when you are using narrow scoped dependency on wider scope dependency. I run into some interesting bugs when I didn't caught that. > > - So if I am singleton and depends on request scope stuff, I get a > > proxy that match that up. > > - Global settings - make it nicer to: > > - Default Lifestyle setting > > - Default disposable tracking setting > > +1, we might also make it inheritable from parent container. > > > - Consolidate the Windsor & MicroKernel assemblies, I don't see a good > > reason why we still have this split between them. > > +1. In this case there's no good reason to keep Core and DynamicProxy > apart any longer either (main reason for this IIRC was so that > MicroKernel does not depend on DP). > Also do we want to really keep having two containers, or do we make > IWindsorContainer inherit IKernel and merge DefaultKernel with > WindsorContainer? > > I am in favor of doing that, yes. Please note that this is a breaking change. I think we should consider this to be a 3.0 version, and accept the potential breaking changes. That would also allow us to perform the cleanup for the API. > > > > Thoughts? > > -- > 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.
