Резервный контроллер DryIOC WebAPI

Согласно документации Microsoft:

Внедрение зависимостей в ASP.NET Web API 2

Если метод GetService не может разрешить тип, он должен возвращать значение null. Если метод GetServices не может разрешить тип, он должен вернуть пустой объект коллекции.

Не создавать исключения для неизвестных типов.

Реализации этого интерфейса должны делегировать базовому контейнеру внедрения зависимостей предоставление зарегистрированной службы для запрошенного типа. Когда нет зарегистрированных служб запрошенного типа, платформа ASP.NET MVC ожидает, что реализации этого интерфейса вернут null из GetService и вернут пустую коллекцию из Получить службы.

Когда веб-API создает экземпляр контроллера, он сначала вызывает IDependencyResolver.GetService, передавая тип контроллера. Вы можете использовать этот хук расширяемости для создания контроллера, разрешающего любые зависимости. Если GetService возвращает значение null, веб-API ищет конструктор без параметров в классе контроллера.

Вы можете переопределить преобразователь по умолчанию самостоятельно

public static class ResolverHelper {
    public static void OverrideResolver(this HttpConfiguration httpConfiguration) {
        var innerResolver = httpConfiguration.DependencyResolver;
        var resolver = new MyDryIocDependencyResolver(innerResolver);
        httpConfiguration.DependencyResolver = resolver;
    }
}

и в вашем пользовательском преобразователе произойдет сбой, как вы хотите.

Фрагмент из MyDryIocDependencyResolver

public class MyDryIocDependencyResolver : IDependencyResolver { 
    IDependencyResolver innerResolver;

    public MyCustomDependencyResolver(IDependencyResolver innerResolver) {
        this.innerResolver = innerResolver;
    }

    public IDependencyScope BeginScope() {
        return this;
    }

    public object GetService(Type serviceType) {
        try {
            return innerResolver.Getservice(serviceType);
        } catch (Exception ex) {
            //TODO: Log resolution error
            return null;
        }
    }

    public IEnumerable<object> GetServices(Type serviceType) {
        try {
            return innerResolver.GetServices(serviceType);
        } catch (Exception ex) {
           //TODO: Log resolution error
           return new List<object>();
        }
    }

    public void Dispose() {
      // NO-OP 
    }
}

В вашей регистрации вы можете переопределить его

//...other code
Startup.IocContainer.WithWebApi(config);
Startup.IocContainer.RegisterWebApiControllers(config);
config.OverrideResolver();
//...other code

Таким образом, если/когда DryIocDependencyResolver не сможет разрешить тип службы, вы все равно будете знать, что не было разрешено, поймаете это и вернете значения по умолчанию, как указано в предлагаемых рекомендациях. Лучшее обоих миров.

надеюсь, это поможет

Еще один способ проверить проблемы с разрешениями контроллера со всей возможной информацией — использовать метод IContainer.VerifyResolutions.

Например:

var container = new Container().WithWebApi(config);
var errors = container.VerifyResolutions();
Debug.Assert(errors.Length == 0);

Дополнительные сведения см. в вики.

Примечание. Единственная загвоздка с контроллерами в том, что текущий DryIoc.WebApi регистрирует реализацию контроллера с конкретным типом контроллера и всеми его реализованными типами в качестве типов служб. Таким образом, для одного неразрешенного метода class MyController: ApiController {} метод VerifyResolutions вернет 3 одинаковые ошибки:

• один для MyController
• один для ApiController
• и один для IHttpController

Вы можете сгруппировать результаты проверки errors по Factory.FactoryID, чтобы получить более компактный вывод.