Действительно ли изучение Внедрения зависимости стоит того для кого-то, который обычно только делает маленькие проекты (5-20k строки)?
Я просто обычно делаю приложения для меня как хобби. Похоже, что платформы DI имеют большой импульс в сообществе, таким образом, я думал, возможно, что я должен изучить это для улучшения моих навыков кодирования. Из того, что я понимаю, это, кажется, приспособлено больше к большим проектам. Это - все еще хорошая идея использовать его, например, в 5k проекте строк?
5 ответов
Я использую DI для всего кода, который пишу, независимо от размера.
Однако следует помнить, что DI не требует контейнера DI . Контейнер DI, безусловно, помогает (особенно в больших проектах), но вы также можете написать независимый от контейнера код , используя принципы DI.
Размер кодовой базы на самом деле не имеет значения. Важна ремонтопригодность . DI разрешает слабую связь , что снова обеспечивает ремонтопригодность. Это ценно для всех проектов, кроме разовых, одноразовых.
Да, внедрение зависимостей способствует слабой связи и тестируемости, что полезно для проекта любого размера, а накладные расходы на настройку относительно невелики.
Если вы не используете внедрение зависимостей, то почти наверняка вы не используете имитацию фреймворка для своих модульных тестов или, возможно, вообще не проводите модульное тестирование. Одна из приятных особенностей модульного тестирования заключается в том, что в конечном итоге оно побудит вас использовать более совершенные шаблоны проектирования, включая внедрение зависимостей. Если вы этого не сделаете, вам будет очень сложно протестировать свой код.
Вопрос о том, нужно ли учиться использовать инфраструктуру DI для приложений вашего размера, остается открытым. Добавление любого внешнего кода в ваш проект добавит некоторых сложностей, и, честно говоря, я пока не нашел его достаточно убедительным для моих проектов. В то же время, однако, в какой-то момент я создавал все свои макетные объекты вручную, и после перехода на RhinoMocks я редко использую макетные объекты вручную, и я чувствую, что моя продуктивность улучшилась. Контейнеры DI являются следующей технологией в моем списке вещей, которые нужно изучить, но я еще не собрал проект, чтобы опробовать ее.
Мое предложение, поскольку вы, кажется, открыты для этого, было бы попробовать пару фреймворков DI и посмотреть, насколько хорошо они работают для вас. Если вы не нашли достаточного значения, попробуйте выполнить инъекцию вручную - если вы не на этом этапе, если да, то вернитесь к нему.
Да, если предположить, что вы были бы счастливы превратить свои линейные проекты от 5 000 до 20 000 в линейные проекты от 3 000 до 10 000.
Да, если вы хотите писать меньше тестового кода при тестировании большей части вашей кодовой базы.
Да, если предположить, что вы хотите оценить, поможет ли DI вам стать лучшим программистом.
По сути, внедрение зависимостей (DI) вводит некоторые "накладные расходы на сложность" (а также относительно небольшие расходы на размер), которые могут показаться не стоящими усилий в небольших проектах. Однако существует множество прямых и косвенных выгод от знакомства с DI и его использования в подходящих случаях. В частности:
Более прямое
- Это обеспечивает свободное соединение компонентов/модулей в рамках проекта. Это способствует повторному использованию кода и паттернов (из предыдущих проектов)
- Это помогает в тестировании, облегчая внедрение классов/модулей, которые заменяют (имитируют) реальные зависимые типы.
Косвенно
- Это способствует использованию интерфейсов: Различные параметры методов API определяются в терминах интерфейсов (или абстрактных классов), а не конкретных типов.
В результате вы можете обнаружить, что даже если вы не используете DI в данном проекте или в отдельных его частях, знакомство с DI и связанными с ним концепциями и паттернами помогает структурировать проект, используя больше абстракций, меньше "жестких" точек зависимости и в целом более четкие, более самодокументирующиеся объектные модели.