Какие преимущества дает МОК по сравнению с программным кодированием?

Question

Возьмем, к примеру, следующую статью:

http://weblogs.asp.net/psteele/archive/2009/11/23/use-dependency-injection-to-simplify-application-settings.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+dotnetmvp+%28Patrick+Steele%27s+.NET+Blog%29

Я не понимаю, какая польза от подхода МОК в отличие от традиционного подхода мягкого кодирования. Может кто-нибудь сказать мне, что мне не хватает?

Спасибо

Answer 1

Сама статья в значительной степени отвечает на ваш вопрос:

Во время производства вводится зависимость и автоматически выдается мой экземпляр AppConfigSettings. Для тестирования я генерирую макет IApplicationSettings.

Вообще говоря, шаблоны проектирования, практики и подходы (IoC - это не образец) пытаются помочь вам, по крайней мере, в одном: минимизировать связывание и максимизировать сцепление . Когда вы непосредственно используете ConfigurationManager и все такое (Convert.ToBoolean и т. Д.), Вы:

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

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

Answer 2

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

Инверсия управления означает, что отдельные компоненты получают доступ друг к другу только через абстракции и не имеют права голоса при их соединении. Если вы читаете о компонентах в спецификации UML (глава 8 спецификации надстройки), то очевидно, что понятия IoC и «компонента» всегда должны идти рука об руку:

Важный аспект на основе компонентов развитие является повторное использование ранее построенные компоненты. Компонент всегда можно считать автономным блок в системе или подсистеме. Это имеет один или несколько и / или необходимые интерфейсы (потенциально через порты) и его внутренности скрыты и недоступны, кроме как предусмотрено его интерфейсами. Хотя это может зависеть от других элементы с точки зрения интерфейсов, которые необходимы, компонент инкапсулированы и его зависимости разработан так, что его можно лечить настолько независимо, насколько это возможно. Как В результате компоненты и подсистемы могут гибко использовать и заменять соединяя («проводку») их вместе через их предоставленные и обязательные интерфейсы. Аспекты автономии и повторное использование также распространяется на компоненты в время развертывания. Артефакты, которые компонент реализации предназначен для способен быть развернутым и перераспределен самостоятельно, для экземпляр для обновления существующей системы.

Answer 3

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

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

Answer 4

Для этого конкретного приложения IoC это означает, что вам не нужно знать строковые ключи везде, где вы используете настройки, только там, где вы их читаете.

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

Хороший вопрос, который можно задать: может Foo знать, как читать настройки конфигурации и использовать их?