Проблема IOC: слишком много абстрактных фабрик для классов, зависящих от данных времени выполнения - PullRequest
7 голосов
/ 08 июня 2011

Я недавно начал использовать DI в одном из моих проектов.Для классов, зависящих от времени выполнения, я создал соответствующие абстрактные фабрики.Следуя этой схеме, я получаю слишком много абстрактных фабрик, почти по одной для каждого моего класса.

При использовании IOC часто бывает слишком много абстрактных фабрик?

Сценарий: предположим, я получаю объект "Entity" из базы данных.Существует 10 различных вариантов использования, которые пользователь может выполнить для этого объекта.Для каждого варианта использования у меня есть свой класс для обработки.В некоторых случаях конкретный вариант использования может иметь подкомпоненты компонентов, которые также могут нуждаться в объекте сущности.Поскольку эти классы зависят от объекта сущности во время выполнения, мне пришлось создать абстрактную фабрику для каждого из них.Наконец я связываю инструкции по сборке в контейнере МОК.

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

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

Я хотел бы знать, что вы, ребята, думаете об этом подходе?

1 Ответ

7 голосов
/ 08 июня 2011

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

Возможно, вы сможете изменить дизайн своих интерфейсов, чтобы было меньше фабрик и больше команд .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...