I would profile it to start with, to see if it's really a performance cost or not - I doubt it is, or if it is then you could probably look at alleviating this by switching lifestyles or altering the classes so there is not such a big hit on construction - i.e. initialise the class if it's not already initialised within the body of the classes methods/properties (so the initialisation hit is on first-call).
Probably the simplest approach of managing this would be the break the class up into multiple classes. Lastly I know there was some discussion in the past around lazy loading dependencies i.e. you could have your class injected with proxies, and on first call to any method of the proxy have it request the underlying dependency from the container, and forward the method call on. I think the general consensus was it's a bad idea, and avoids some of the more desirable "fail-fast" behaviour you see in a container when resolving a component... but again, it's a thought. Cheers, - Alex On Thu, May 7, 2009 at 2:22 PM, scott_m <[email protected]> wrote: > > Lets pretend that I have a class that has up to 5 external > dependencies to be resolved by the DI container. > > Some of the public class methods require 1 injected dependency, some > require 5 injected dependencies. Is there a good methodology for > avoiding injecting extra dependencies based on how the class is being > used? So far I have just been using injection via class constructors > and noticed how this might add some overhead during class > construction. > > > > 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 -~----------~----~----~----~------~----~------~--~---
