1 voteunder review · 4 comments · Official Castle Project feedback forum · Flag idea as inappropriate… · Admin →
The more I think about this, the less I'm confident there's a good way to solve it, other than having a whitelist of well known (internal) components that we know are meant to be only used with factories (like the TypedFactoryInterceptor)
Every misconfigured component may be resolved via a factory
I do agree it is kind of noisy. I'm not sure though If creating a new category is the best approach. Perhaps just marking these in some special way would suffice...
Does that affect anything functionality wise? Does it give us any additional capabilities? Why do you think time spent doing this is well spent?
...because it still has its place and there are people relying on it.
Instead of transient/singleton I would actually lean more towards supporting the following:
transient and scoped.
Scoped would be tied to explicit scope object, that would be responsible solely for caching the instance, hence it would be far more lightweight than nested container, and not introduce the issues container hierarchies have.
I have plans to achieve this goal, via installers, but in a slightly different way. I'll update this with a link when I have a working prototype.
Generally what this means is something like in this post: http://igorbrejc.net/development/c/windsor-castle-auto-wiring-using-parameter-names
This will be part of v3. Tangible ideas, preferably in form of runnable proof-of-concept implementations welcome.
I agree with most of your feedback, and as a matter of fact most of the methods on the IWindsorContainer (and IKernel), all the Add* are obsolete. I didn't deprecated the indexers, but I think I will do it, just for clarity and to have one way of doing things.
Thanks for your feedback!
Let me know of all the other ideas you have.
Thanks for your input on this.
I agree that Windsor's API is not very discoverable and it's too verbose. That's why I created this suggestion in the first place.
There are some things I like about Autofac's API, but there are some I dislike.
I've had in mind idea you might find similar in some regard to what Autofac is offering. Once I get some time to actually start working on it, I'm gonna create a branch and I'll be looking for feedback.
What exactly do you like about Autofac's API as compared to what Windsor provides now?
Logging is already released…
We'll release Transaction facility this month. IIRC that was the only thing holding NHibernate facility back, right Tuna?
How do you plan to go about implementing this?
Startable Facility is different - it points to a method which will be called upon start/stop.
Registration API points to "dependencies" without specifying what kind of dependencies they are - .ctor parameters, properties...
This is one of things I have in mind for vNext. We accept patches.
so, to make sure I understand your suggestion - you want us to provide generic base implementation of IWindsorInstaller? Not a bad idea.
This is gonna be pretty work consuming, postponed for vNext. We accept patches.
Mauricio - are you sure? If that's the case, we can close it as by-design
We would appreciate if someone wants to contribute to this…
Dynamic Proxy already supports silverlight (version 2.2, currently in beta)
Release date is set to January 2010, unless some critical issues are found (we're looking for your feedback!).
No breaking changes are expected unless necessary to fix critical issues (which is unlikely)
you are very much right about it. Would you be interested in contributing to this effort?
This might get implemented as part of v4, depending on time.
The main difference is that wrapping would not be inheritance based. This is something that is not currently possible with Dynamic Proxy. This gives it some great powers, but also limits it to non-type based scenarios (WPF databinding, ASP.NET MVC controllers, C# 4.0 'dynamic' etc).
We would appreciate help in getting all tests to pass on Mono and testing