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 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.
