Yes, it does...and I don't disagree with your premise that there should be some definitive discernable way of identifying what is and what is not a component.
I was hoping to upgrade to Windsor 3 sooner, but I guess we will need to hold off until we solidly identify all the places/types where we are currently relying on the LazyComponentLoader. On Sep 14, 5:24 pm, Krzysztof Koźmic <[email protected]> wrote: > I guess my point still stands. Even if you do use a LCL you should still > be able to identify the types you want in by using some sort of > architecture-based convention. > It all boils down to consistency. Do you think that would work in your case? > > HTH, > Krzysztof > > On 15/09/2011 12:52 AM, Jeff N wrote: > > > > > > > > > Yes, I have. Load of each assembly is approximately 50ms - 300ms > > depending on the number of classes and on how "warm" the OS is. > > > Calling assembly.GetTypes() is 20ms to 200ms depending on the number > > of types in the assembly and on how my computer feels > > > Trying to go through all relevant assemblies and scan I get: > > > Loaded 14 assemblies for component scanning in 1115ms (loading all the > > assemblies I need components for) > > Created 223 components for types in 14 assemblies in 4232ms (this > > number is inflated by the time spent loading dependent assemblies - > > below) > > Loaded 34 dependent assemblies from file system in 2227ms (this is a > > count of automatically loaded assemblies from before I start created > > components until after) > > > The number of assemblies loaded is higher than the number of component > > assemblies because even if I don't need components for that assembly, > > calling GetTypes() on it will force load of all referenced assemblies. > > So, for assembly MyApp.Web, calling GetTypes will automatically load > > System.Web, System.Web.ApplicationServices, DevExpress.XXX, etc. > > > Performance aside, it's mainly a LOE concern to make sure we correctly > > identify all of the types that require DI. > > > On Sep 14, 1:23 am, Krzysztof Koźmic<[email protected]> > > wrote: > >> You can come up with any convention for that, not just based on > >> attribute, but for example based on name as well > >> (Name.EndsWith("ViewModel")) > > >> scanning assemblies is usually relatively fast. Have you measured it? > > >> Krzysztof > > >> On 14/09/2011 12:27 AM, Jeff N wrote: > > >>> 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 > > ... > > read more >> -- 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.
