If I'm going to implement this myself, would you suggest inheriting from DefaultDependencyResolver and putting logic in Resolve to check if Kernel.GetAssignableHandlers == null?
On Sep 9, 10:17 am, Jeff N <[email protected]> wrote: > Any thoughts on this? I'd really like to adopt Windsor 3 to get rid of > our WeakReference memory leak that we have now. > > Thanks. > > On Sep 7, 6:33 pm, Jeff N <[email protected]> wrote: > > > > > > > > > The goal for my lazy loader is never to resolve services (in the > > semantic sense of the word service). Those are always interfaces with > > internal implementing classes (to avoid accidental directl > > instantiation)...so they are (and must be) explicitly registered in > > the container at startup. > > > It's only for proxy/interception support that the lazy loader is > > really necessary. Let's take the example of my search args class. The > > proxy automatically implements INotifyPropertyChanged....but do I > > really need/want to do the busy work of registering all of these > > simple classes as components? I feel like not... Plus let's say a > > developer that doesn't really know anything about DI to interception, > > but does know to add [NotifyPropertyChanged] wants to create a new > > class. Should they really need to go into the Bootstrapper and > > register it? Or add it to a white list? It seems kind of unnecessary > > in terms of friction... > > > Plus, on a completely unrelated note, registering all these types for > > proxying means startup of the client application will slow down > > substantially. Loading up all those assemblies where the types live > > (like 10 of them) adds 2 or 3 seconds to startup. If I scan the > > assemblies for types annotated with [Component] attribute or try to > > register all types in the assemblies, startup performance becomes even > > (much much) worse. > > > So back to your point...in terms of white listing...adding all those > > components to be proxies to a whitelist is kind of a big friction > > point from a development standpoint. > > > I hope I've expressed my concern clearly. Let me know if not. > > > Thanks. > > > On Sep 7, 6:06 pm, Krzysztof Ko¼mic <[email protected]> > > wrote: > > > > I agree the loader is fragile and sooner or later something will fall > > > through the cracks with this approach. > > > > What if instead of blacklisting types (thou shall not be resolved) you > > > give it a whitelist or a whitelisting predicate. > > > Only resolve types from "Foo.Services" namespace, or similar. > > > > In general that's the goal for using lazy component loaders, to narrow > > > down their scope as much as possible, rather than making it a catch-all. > > > > What is the goal of your lazy component loader? > > > > Krzysztof > > > > On 08/09/2011 2:32 AM, Jeff N wrote: > > > > > Yes, that does work (filtering the service at the LazyComponentLoader > > > > layer)....and that's what I've done in the interim to test other > > > > things: > > > > > private static readonly Type[] ExcludedTypes = new[] { typeof(object), > > > > typeof(ControllerBase), typeof(Person) }; > > > > > if (ExcludedTypes.Contains(serviceType)) > > > > { > > > > return null; > > > > } > > > > > in the lazy component loader. > > > > > But, I'm really concerned about having to identify all the places that > > > > are bad candidates for lazy loading (there are literally hundreds of > > > > places I'd need to check). Further, I might run across an assembly > > > > that isn't visible to my loader....so essentially the loader becomes a > > > > god class. > > > > > If you can bake in some way of controlling the behavior, I'd really > > > > appreciate it. If something is baked in, I guess it would have to be > > > > done at the Kernel itself, not in the loader, right? Because even if > > > > my loader changes it's behavior to ignore optional dependencies, the > > > > other loaders might not know that I want to do so (LazyOfTLoader, > > > > DelegateFactoryLoader, etc.)... > > > > > I know it was a bug, but in my thinking, the old behavior really makes > > > > more logical sense - lazy load something only when it's really > > > > necessary....but of course I can appreciate the opposite perspective > > > > too. > > > > > Thanks. > > > > > Jeff > > > > > On Sep 7, 9:05 am, Krzysztof Ko¼mic<[email protected]> > > > > wrote: > > > >> What about adding some filtering to your lazy component loader? > > > > >> WIth this example you gave here I suspect you would never want Person > > > >> as > > > >> a service anyway, hence applying some filtering based on structure > > > >> might > > > >> solve that. > > > > >> - if requested type is in Acme.Services resolve it > > > >> - otherwise (and I suppose Person would be in Acme.Domain or similar > > > >> namespace) skip it > > > > >> I don't think we have a setting to disable it currently, although if > > > >> the > > > >> above does not solve that for you I might look into introducing some > > > >> way > > > >> of controlling that behaviour... > > > > >> HTH, > > > >> Krzysztof > > > > >> On 07/09/2011 10:55 PM, Jeff N wrote: > > > > >>> That will solve the issue with MVC Controllers...but there are tons of > > > >>> other places that rely on more intelligent setting. > > > >>> For example: > > > >>> public class SearchArgs > > > >>> { > > > >>> private Person _personToSearchFor; > > > >>> public Person PersonToSearchFor > > > >>> { > > > >>> get { return _personToSearchFor; } > > > >>> set > > > >>> { > > > >>> if (value != _personToSearchFor) > > > >>> { > > > >>> // do some relevant stuff: this breaks now > > > >>> because it's automatically set to an empty, default instantiation of > > > >>> person as soon as the args is resolved. > > > >>> } > > > >>> } > > > >>> } > > > >>> } > > > >>> Is there no way I can inherit from the DefaultKernel and disable this > > > >>> globally? This completely prevents me from upgrading. > > > >>> Thanks. > > > >>> On Sep 7, 3:01 am, Krzysztof Ko¼mic<[email protected]> > > > >>> wrote: > > > >>>> Ignore all base-class properties on Controllers when registering > > > >>>> Krzysztof > > > >>>> On 07/09/2011 1:41 PM, Jeff N wrote: > > > >>>>> I understand that in Windsor 3 the design was changed so that > > > >>>>> optional > > > >>>>> dependencies try to get resolved via an ILazyComponentLoader > > > >>>>> I have a basic ILazyComponentLoader that does > > > >>>>> Component.For(serviceType).Named(key) > > > >>>>> This change breaks a TON of things in the solution, including all > > > >>>>> ASP .NET MVC controllers (since an object property type (Model) on > > > >>>>> the > > > >>>>> ControllerBase class is now injected with the wrong type. > > > >>>>> Any suggestions on how to work around this? Essentially I just want > > > >>>>> to > > > >>>>> revert to the old behavior by which optional dependencies are not > > > >>>>> lazily loaded. Is there any way I get get the dependency being > > > >>>>> resolved in context of my lazy component loader, so I can check if > > > >>>>> it's optional and return null if true? > > > >>>>> Thanks. -- You received this message because you are subscribed to the Google Groups "Castle Project Users" 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-users?hl=en.
