Unity中InjectionConstructor与InjectionFactory懒加载差异及注册时机问询

Great question—let’s break this down clearly, starting with the lazy loading differences between InjectionConstructor and InjectionFactory, then digging into your specific registration code.

Let’s start with the core lazy loading distinction between these two Unity injection features:

• InjectionConstructor:

  • This is used to explicitly define constructor arguments during type registration. The critical detail here is that any direct values or resolution calls you pass as arguments are evaluated immediately at registration time—there’s no inherent lazy loading. If you pass Container.ResolveAll<ITYPE>() directly to InjectionConstructor, that resolution happens the moment you call RegisterType, not when you first ask for a SOMETYPE instance.
  • To get lazy behavior with InjectionConstructor, you’d need to wrap dependencies in Lazy<T> or pass a factory method as an argument, but that’s not the default behavior.

• InjectionFactory:

  • This is a delegate that runs only when the container first resolves the target type (and again later if your lifetime manager allows multiple instances). This is inherently lazy because the factory logic doesn’t execute until someone actually requests the type.
  • Any resolution logic (like ResolveAll<ITYPE>()) placed inside the factory delegate will run at resolve time, not registration time. This is where you get true lazy loading for your dependencies.

Looking at your specific code:

Container.RegisterType<SOMETYPE>(new ContainerControlledLifetimeManager(), new InjectionConstructor(Container.ResolveAll<ITYPE>()));

The Container.ResolveAll<ITYPE>() call executes during registration, not when you first resolve SOMETYPE. Here’s the breakdown:

• In C#, method arguments are evaluated before they’re passed to a constructor. So when you create the InjectionConstructor instance, ResolveAll<ITYPE>() runs immediately to generate the argument value.
• This means all ITYPE implementations are resolved and collected at app startup (when you register SOMETYPE). If you add new ITYPE registrations after this line, they won’t be included in the SOMETYPE instance—since the collection was already built during registration.

The timing difference leads to some important practical distinctions:

• Dependency freshness:

  • InjectionConstructor with direct ResolveAll: The collection of ITYPE instances is fixed at registration time. No updates later will affect it.
  • InjectionFactory with ResolveAll inside the delegate: The collection is built when SOMETYPE is first resolved, so it includes any ITYPE registrations added after the initial RegisterType call.

• Startup overhead:

  • If ITYPE implementations are resource-heavy to instantiate, using InjectionConstructor adds that overhead to your app’s startup phase (when registration runs).
  • InjectionFactory delays that overhead until the first time SOMETYPE is actually used, which can help with faster startup times.

• Flexibility:

  • InjectionFactory lets you add dynamic logic (like conditional resolution) that runs at resolve time, which isn’t possible with a static InjectionConstructor argument.

For example, if you want lazy loading and dynamic dependency collection, here’s how you’d rewrite your registration with InjectionFactory:

Container.RegisterType<SOMETYPE>(new ContainerControlledLifetimeManager(), new InjectionFactory(container => 
    new SOMETYPE(container.ResolveAll<ITYPE>())
));

In this case, ResolveAll<ITYPE>() runs only when SOMETYPE is first resolved, so it picks up any late-registered ITYPE implementations.

内容的提问来源于stack exchange，提问作者mike00