Я попытаюсь объяснить это так же, как я могу.
Согласно Autofac's docs, RegisterSource
позволяет вам регистрировать заводы, о которых вы не знаете или не рассматривали. Это будет очень поздно связывать типы с правилами, которые их предоставляют.
Как это применимо здесь?
Если вам нужен экземпляр класса, такого как LoggerSettings
, из контейнера, autofac проверит все правила, которые вы указали у разных регистраторов зависимостей, которые есть у nopCommerce, и он попросит источник регистрации: Эй! Мне нужен экземпляр LoggerSettings, вы знаете что-то об этом? RegisterSource проверяет его и говорит: «Да, он реализует ISettings
, здесь у вас есть правило для инъекций (в этом случае лямбда, которая извлекает экземпляр настроек из общего репозитория), сохраните его, в следующий раз вам не нужно будет спрашивать ». Обратите внимание, что оно вернет правило создания экземпляра, а не сам экземпляр.
В качестве альтернативы, возможно, вы можете сделать это, сканируя все сборки, но для большой системы с такими плагинами это будет больно. Вы также можете зарегистрировать каждый конкретный класс, но в этом случае это невозможно.
Чтобы увидеть это, установите пару точек останова при двух методах SettingsSource и внутри делегата и запустите проект.
Чтобы сделать это с помощью Ninject, вам нужно будет воспроизвести это поведение.
Мне любопытно, почему вы хотите заменить Autofac? Есть ли что-то, что он не дает вам, что делает Ninject? – DavidG
@Steven У меня уже есть фабрика настраиваемых контроллеров (NinjectControllerFactory) и NinjectDependencyResolver как мой дефолт по умолчанию. Сейчас я работаю над настройкой и кэшированием. – DeathWish
@DavidG Это просто, я не привык к Autofac. Я использую Ninject, но я все еще не нахожусь на промежуточном уровне, когда речь заходит о Ninject, я думаю :) – DeathWish