It would be simpler...but it would not perform better since the line below would force this assembly and all referenced assemblies to be loaded up into memory right at startup and would add the cost of reflecting over all types in that assembly.
I could have the LCL check for a [Component] attribute and only register if present...but that's still a major breaking change and would require locating and annotating hundreds of types. >From a design standpoint I understand that it's desirable to have components registered up front....but having to explicitly declare every kind of component you want kind of adds a lot of overhead I think (not just in terms of performance). On Sep 13, 3:59 am, Krzysztof Koźmic <[email protected]> wrote: > If you already have an attribute > > [NotifyPropertyChanged] > > Why are you not using this information to register those types upfront. > You have all the information you need. > > Container.Register(Classes.FromThisAssembly.Where(t=> > HasTheAttribute(t).Configure(HoweverYouWant)); > > Wouldn't it be nicer and simpler? Not to mention it performs better and > is easier to diagnose too. > > I really think you're abusing LCL here. > > Krzysztof > > On 08/09/2011 8:33 AM, Jeff N 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.
