Рекомендуемый способ использования Ninject в нескольких проектах - PullRequest
0 голосов
/ 11 февраля 2020

Я только начинаю использовать Ninject впервые на довольно большом существующем. NET 4.7.2 проекте, который имеет центральный файл DLL, интерфейс MVC, консольное приложение, которое автоматически запускается сервер по расписанию для автоматизированных задач и проект модульного тестирования (которого пока не так уж много - одна из причин того, что мы начали использовать Ninject, состоит в том, чтобы сделать его более практичным для модульного тестирования).

Я пытаюсь обдумать лучший способ использовать Ninject и структурировать вещи. Насколько я могу судить, я хочу одну конфигурацию ядра для проекта MVC, которая, вероятно, будет такой же для EXE, а затем, по крайней мере, еще одну, если не намного больше, для перенаправления на макеты для модульного тестирования. У меня есть несколько вопросов по этому поводу.

Во-первых, я знаю, что в MVC я могу использовать класс DependencyResolver, но в консольном приложении, какой лучший способ структурировать вещи так, чтобы я не создает зависимость от Ninject? Можно ли использовать класс DependencyResolver в консольном приложении? Должно ли это быть так? Или лучше по какой-то причине создать собственную абстракцию? Должен ли он быть установлен как единое целое при загрузке приложения или восстановлен по мере необходимости?

Должен ли я иметь конфигурацию ядра Ninject для приложения MVC & console в DLL? Это кажется неправильным с точки зрения зависимостей, но кажется неправильным отделять его от точки зрения наличия дублирующего кода для поддержки.

Кроме того, в рамках проекта модульного тестирования должно ли ядро ​​Ninject быть сконфигурировано глобально, для каждого класса тестирования или для каждого метода? Что обычно является хорошей идеей?

...