Внедрение зависимостей в методы расширения объекта домена

Question

Я создаю систему веб-CMS на основе узлов в asp.net mvc.

Прочитав несколько книг по внедрению зависимостей, я разделил свое решение на несколько проектов и использовал абстракции (абстрактные классы и интерфейсы).

Я не могу понять, как решить следующий тип кода в моем веб-проекте:

myDomainObjectNode.GetChildNodes<SomeSubNodeClass>();

Я мог бы сделать это, если бы у объекта домена была ссылка на INodeRepository.но это означало бы, что я должен носить эту зависимость во всех объектах домена, что создает трудности, особенно когда приходится создавать новые экземпляры.Является ли наличие зависимостей (в основном репозиториев) в вашем доменном объекте плохой вещью?

Моя другая идея - добиться этого с помощью методов расширения.Однако методы расширения являются статическими для статического класса, который сам не может быть создан с использованием IoC.Я мог бы решить это, используя Singleton для INodeRepository и установив его в IoC.

Это не похоже на элегантное решение ... у вас есть другие идеи или предложения?

Спасибо!

Answer 1

Я обычно избегаю предоставления объекту домена доступа к репозиториям и максимально скрываю любые проблемы с сохранением.

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

Я бы, вероятно, отбросил универсальный тип для фильтрации коллекции и просто использовал Linq, ваша коллекция дочерних узлов может вернуть IEnumerable<BaseNode>.

Конечно, вы можете дополнить его различными стратегиями отложенной загрузки и кэширования, что может помочь вам в типичном ORM.

Если вы решите использовать репозиторий из вашего доменного объекта, я бы предпочел добавить его черезконструктор.Это делает зависимость явной, и вы выводите ее область действия.

Answer 2

В итоге я решил эту проблему, используя MVC DependencyResolver, чтобы получить INodeService внутри метода расширения в веб-проекте MVC. Работает как шарм, и я не думаю, что сломал какие-либо серьезные OO-паттерны.