Как далеко я должен идти с IoC?

Question

Я только что использовал IoC в очень маленьком проекте с одним объектом, который мне нужно было проверить.Сейчас я начинаю реализовывать его в более крупном существующем проекте, и я в чем-то не уверен.

Скажем, у меня есть два бизнес-объекта Student и Teacher, оба имеют внедрение конструктора для интерфейса, называемого IUnitOfWork у которого есть конкретные экземпляры SQLUnitOfWork или InMemoryUnitOfWork.

Так что, если я использую эту библиотеку, я могу использовать IoC для создания своего объекта, не беспокоясь, но что происходит, когда я хочу использовать один внутриДругой?Скажем, я лениво загружал свойство Student.Teacher и мне нужно получить новый объект Teacher, как мне это сделать?

Что-то не так в использовании контейнера IoC для достижения этой цели, нотакже не имеет конкретных объектов.Использование IoC для каждого используемого объекта кажется чрезмерным.

Answer 1

Я обычно избегаю использования IoC на уровне домена - вы хотите попробовать получить доступ к ядру только на уровне приложений (где, да, вы можете получить доступ к ядру довольно часто).

Для моих проектоввсе мои бизнес-объекты, как правило, представляют собой POCO с небольшими зависимостями от чего-либо, кроме фреймворка.

Уровень обслуживания обычно имеет много зависимостей, но не очень часто напрямую обращается к ядру.

Возможность этого зависит от вашего выбора ORM и т. Д. И, конечно, от существующей архитектуры проекта.

Если у ваших бизнес-объектов есть зависимости, которые необходимо разрешить, то вы либоВам нужно будет использовать ядро ​​для их разрешения или изменить свой проект, чтобы удалить зависимости.

Answer 2

Вместо того, чтобы иметь зависимости в ваших классах Ученика и Учителя (UnitOfWork), создайте слой обслуживания с зависимостями, который ссылается на классы Ученика и Учителя.

Таким образом, ваши классы сущностей могут быть POCO и легко поддаваться проверке в тестахи т.д.