Anything similar to Simple Injector's ConstructorResolutionBehavior?

[cnshenj]

Simple Injector has this very useful extension point. Why I need this for my interception scenario:

• It provides a predicate parameter to determine which type is supported.
• It provides a resolver parameter to do the custom constructor resolution.

Thus, I don't have to register this custom behavior for each supported type. I only need to do it once. Like this:

// Note the predicate and the resolver takes the *implementation* type as input, NOT *service* type
var predicate = /* return true if a type supports the custom constructor resolution */
var resolver = /* return a proper constructor based on the type */
useCustomConstructorBehavior.AddResolver(predicate, resolver);

// As long as TypeFoo and TypeBar satisfies the condition of the predicate, a custom constructor will be provided by resolver
container.Register<IFoo, TypeFoo>();
container.Register<TypeBar>();

Anything similar in DryIoc?

[dadhi]

@cnshenj

TLDR; Yes, look at one of the Made.Of overloads.

DryIoc supports multiple ways to select Implementation Type, its constructor or any factory method.
Look here for the brief intro https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/SelectConstructorOrFactoryMethod.md
Or here https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/ExamplesContextBasedResolution.md

Or provide your concrete example. I will help you.

[cnshenj]

Yes I have read these. However, they all seem to have the similar patterns that don't work with my scenario.

• They all require a specific type (as generic parameter), while my predicate takes any type and return true if it is supported by my factory.
• They all choose the factory (provide constructor) based on the "service" type. While I need to check the "implementation" type instead.
  If the implementation type matches predicate, then I'll use the custom factory.

This is why Simple Injector calls it customization, but not normal dependency registration. It is NOT registrations for certain types, it is a general customization that can work on any type.

Let's assume we have these registrations:

container.Register<IFoo, Foo>();
container.Register<Bar>();

And then we can add customization like this:

var predicate = (Type serviceType, Type implementationType) =>
    implementationType.GetCustomAttributes<SpecialAttribute>().Any();
var resolver = (Type serviceType, Type implementationType) =>
    SpecialHandling.GetSpecialInstance(implementationType);
container.AddCustomResolver(predicate, resolver);

Then we only need to decorate the type when we need special handling

// Registration Foo will now get special handling, no need to change the registration call
// Registration Bar not impacted because type Bar doesn't have the attribute
[Special]
public class Foo {}

It has similarities to wrappers. But in the wrapper scenario, the consumer is explicitly asking for the wrapper. In my scenario, the consumer is not aware of the customization, it will look like a normal dependency:

public class Consumer
{
    // The Consumer will get a special Foo if the customization is enabled
    // The Consumer only knows it's getting an IFoo.
    public Consumer(IFoo foo) {}
}

[dadhi]

@cnshenj You can do that in DryIoc for all types. There is a whole DryIoc.MefAttributedModel extension that implements the resolution and registration compatible with MEF based on the Export/Import attributes. And believe me, it is a quite complex and quite different from the default DryIoc behavior.

Give me some time, I will find the docs and the example code for that

[dadhi]

@cnshenj For now, you may look into the MefAttributedModel implementation and how it is wired to the container rules
https://github.com/dadhi/DryIoc/blob/master/src/DryIoc.MefAttributedModel/AttributedModel.cs#L62

[cnshenj]

Actually the predicate can be just internal details of the resolver. I only need the container to support something like:

container.AddCustomResolver(resolver);

The resolver can use a predicate to determine whether it wants to add special handling or just use the default resolution behavior. What DryIoc is missing is a customization that I can apply to all registrations.

If global customization is against DryIoc's design principals, that's okay. My library works fine with Simple Injector, I just want to add an option to my library to use DryIoc which is fast and feature-rich.

[cnshenj]

Asked ChatGPT, and it recommends WithFactorySelector - seems to be a good solution. Trying it now...

[cnshenj]

After some experiment, I couldn't find any solution in DryIoc that can do what IConstructorResolutionBehavior does in Simple Injector. Because my implementation type is a dynamically generated type based on the registered implementation type, and I still want to get all the built-in processing from the DI library. In Simple Injector, it works like this (SI means it is Simple Injector's standard process):

Resolve implementation type (SI) -> dynamically create a new type based on the implementation type and return its constructor (custom) -> Use the constructor to create an instance (SI) -> Resolve any dependency of the constructor if needed (SI).

You can see all steps are provided by Simple Injector, and I only need to plug in my custom logic in one step, and only do it once for all supported types.

[dadhi]

Because my implementation type is a dynamically generated type based on the registered implementation type.

Is it similar to the proxy or the interceptor mechanism?
If so, you may look at interceptors https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/Interception.md

Or you may consider DynamicRegistrationProviders https://github.com/dadhi/DryIoc/blob/master/docs/DryIoc.Docs/RulesAndDefaultConventions.md#dynamicregistrationprovider