Что должно быть введено как параметр C'tor в соответствии с принципами DI?

Question

Я пытаюсь понять, какие объекты должны быть введены в объект, а какие должны быть созданы внутри.

1. Если у меня есть List<int> (как поле данных), в котором хранится информация, собранная во время выполнения. кажется, что я должен инициировать его в c'tor, а не вводить его.

а как насчет аппаратного класса, который связывается через COM-порт.

разрешить ли классу HW инициировать SerialPort или добавить его?

2. Если вышеупомянутый SerialPort должен быть введен; какой лучший способ сделать это?

создать его вручную:

SerialPort port = new SerialPort(name, baud ...);

HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));

или с использованием контейнера Unity

SerialPort port = conatiner.Resolve<SerialPort>(...);

HWClass hwClass = container.Reolve<IHWClass>("HWClass", new InjectionConstructor(port));

или я должен инициировать его внутри HWClass C'tor?

Adiel

Answer 1

Домен-управляемый дизайн различает Службы и другие объекты Домена ( Сущности и Объекты значения ). Даже если вы не подписаны на DDD, это различие очень полезно.

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

В вашем случае и SerialPort, и IHwClass звучат очень похоже на сервисы, потому что они представляют внешние ресурсы, поэтому я бы определенно внедрил их через Внедрение в конструктор .

Тем не менее, вы действительно получаете преимущество слабой связи , только если внедряете абстракцию. IHWClass выглядит хорошо, потому что это интерфейс, но SerialPort выглядит как конкретный класс, так что вы не получите много пользы от его внедрения. Извлечение интерфейса из SerialPort (скажем, ISerialPort) и внедрение этого вместо этого будет лучше.

Answer 2

Мое общее правило заключается в том, что если у объекта может быть изменено его состояние за пределами вашего класса, или вы хотите иметь возможность предоставлять альтернативную реализацию либо в ходе тестирования, либо в какой-то момент в будущем динамически, вы должны внедрить его.Если класс используется и изменяется только внутри, а реализация зависит только от содержащего класса, тогда создание зависимости внутри, вероятно, нормально.Чтобы использовать ваш пример, я бы вставил SerialPort, но не List<int>.

В качестве отступления, теперь, когда я делаю TDD (Test Driven Development), я обнаружил, что я действительно тоже не волнуюсьмного об этих решениях.Вы довольно быстро достигли той точки, когда вы знаете, какие классы нужно вводить, чтобы разделить ваши классы и упростить тестирование.Даже если вы сначала не поняли это правильно, в течение нескольких тестов вы обнаружите, что ваш код естественно развивается в этом направлении.