Стоит ли изучать Dependency Injection для тех, кто обычно выполняет только небольшие проекты (5-20 тыс. Строк)?

Question

Я просто делаю заявления для себя как хобби. Похоже, что DI-фреймворки имеют большой импульс в сообществе, поэтому я подумал, что, возможно, мне стоит изучить его, чтобы улучшить свои навыки кодирования. Из того, что я понимаю, это, кажется, больше ориентировано на большие проекты. Это все еще хорошая идея использовать его, например, в проекте 5k линий?

Answer 1

Я использую DI для всего кода, который пишу, независимо от размера.

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

Размер базы кода на самом деле не имеет значения. Имеет значение ремонтопригодность . DI обеспечивает слабое сцепление , что снова обеспечивает ремонтопригодность. Для всех проектов, кроме одноразовых, это ценно.

Answer 2

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

Answer 3

Да, при условии, что вы будете рады превратить свои линейные проекты от 5 до 20 тыс. В линейные от 3 до 10 тыс.

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

Да, если вы хотите оценить, поможет ли DI стать лучшим программистом.

Answer 4

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

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

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

Answer 5

По сути, внедрение зависимостей (DI) приводит к некоторым «накладным расходам сложности» (а также к сравнительно небольшим накладным расходам), что может показаться не стоящим усилий в небольших проектах. Однако есть много прямых и косвенных преимуществ от знакомства с DI и использования его при необходимости. В частности:

Подробнее

• Это обеспечивает слабую связь компонентов / модулей в рамках проекта. Следовательно, содействие повторному использованию кода и шаблонов (из предыдущих проектов)
• Это помогает с тестированием, упрощая введение классов / модулей, которые заменяют (имитируют) реальные зависимые типы.

Косвенно

• Он способствует использованию интерфейсов: каждый определяет различные параметры методов API в терминах интерфейсов (или абстрактных классов), а не конкретных типов.

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