Внедрение зависимостей: как внедрять при использовании многопроектного решения

Question

надеюсь, что этот вопрос не слишком глуп, я пытаюсь овладеть более продвинутыми принципами программирования и, таким образом, пытаюсь привыкнуть к внедрению зависимости с помощью Ninject.

Итак, моя модель разбита на несколько разных .dll-проектов. Один проект определяет спецификации модели (интерфейсы), а несколько других реализуют эти интерфейсы. Все модельные проекты должны использовать какую-то систему баз данных, поэтому им нужен доступ к еще одной .dll, которая реализует всю мою логику базы данных. Однако важно, чтобы все они имели доступ к одному и тому же экземпляру моего объекта базы данных, поэтому, если бы не достаточно было просто создать один экземпляр для каждой модели.

Хотя я не совсем уверен, как этого добиться, используя внедрение зависимостей. Моей первой мыслью было создание отдельного DI-проекта и привязка всех интерфейсов к их соответствующей реализации, поэтому DI-проекту требовались ссылки на все другие проекты (модельные интерфейсы и реализации, системы баз данных и т. Д.). С другой стороны, моделям потребуется доступ к проекту DI, поскольку, например, им нужно будет запрашивать систему баз данных у системы DI (Ninject). Конечно, это создаст круговую ссылку (привязку проекта DI к модели и модели к проекту DI), поэтому это невозможно.

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

IModel1 -> Model1
IModel2 -> Model2 (different project)
IDatabase -> Database (different project)
Model1 -> request IDatabase -> get Database instance
Model2 -> request IDatabase -> get the same Database instance

Был бы рад получить пару предложений, на данный момент я застрял и без идей;) Спасибо!

Answer 1

моделям потребуется доступ к проекту DI, поскольку, например, им потребуется запросить систему баз данных у системы DI (Ninject)

Когда вы используете внедрение зависимостеймодель не должна иметь доступа к структуре DI, поскольку она внедряет зависимости.Объекты модели не должны запрашивать контейнер DI.Когда ваши объекты запрашивают у контейнера зависимости, это называется не инъекцией зависимости, а локатором службы.Service Locator считается анти-шаблоном .

Моей первой мыслью было создание отдельного DI-проекта

Когда у вас есть одно приложение(т. е. веб-приложение), обычно нужно полностью сконфигурировать контейнер DI в конечном приложении как можно ближе к точке входа приложения.Это называется Composition Root .

Все проекты моделей должны использовать какую-то систему баз данных, поэтому им всем нужен доступ к еще одной .dll, которая реализует всю мою логику базы данных

Попробуйте создать объекты модели / сущности POCO (простые старые объекты CLR) или, по крайней мере, убедиться, что эти объекты не должны ссылаться на какой-либо другой проект, что значительно упрощает вашу архитектуру (и тестирование).

Answer 2

Используйте Ninject с шаблоном Register Resolve Release из корня композиции .

Answer 3

Клиентское приложение будет использовать Ninject для внедрения фактической реализации базы данных и модели.

Следовательно, клиентское приложение должно ссылаться на проекты базы данных, базы данных, модели и модели.

База данных ипроекты базы данных должны ссылаться на проект модели, так как методы будут возвращать объекты модели или коллекции объектов модели.Взгляните на шаблон репозитория .

Ваша модель не должна ссылаться ни на один из ваших проектов.