2012-06-08 2 views
4

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

ответ

4

Есть три причины, которые я знаю:

  1. форс-мажора

    Некоторые 3rdparty код (над которыми вы не имеете никакого контроля) создает классы по имени с помощью отражения. Затем эти классы должны сами позаботиться о своем составе в конструкторе.

  2. Постепенное рефакторинга

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

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

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

  3. Днем без DI

    У вас уже есть базовый код без инверсии управления, что вы довольны, вы просто хотите добавить одну или несколько точек расширения. Или, возможно, вы уже используете шаблон Service Locator вместо инъекции зависимостей.

-1

Обычно, когда вам нужно динамически загружать только один экспорт. Например, динамически зависит от некоторого ввода.

Существует множество сценариев, в которых импорт, который жестко закодирован в принимающий класс, не работает.

Один пример - время жизни. С GetExport/GetExportedValue я могу попросить репозиторий базы данных И УТИЛИТЬ ИТ вне времени жизни объекта. Это полезно для элементов, которые могут или не нуждаются в репозитории, и если им нужно избавиться от него, не избавившись от всего класса;)

Тогда есть сценарий типа службы, который я часто использовать. У моих серверных приложений есть службы, которые НЕ ИНИЦИАЛИЗИРОВАНЫ ДО НАЧАЛА РАБОТЫ - что, очевидно, означает, что Импорт не может работать, что создает всю структуру объекта при создании службы, а не в запуске службы;) Есть веские основания для этого - например, что конфигурация может раскрыть, какие службы запускаться на определенной машине, а некоторые из моих услуг - это тяжелая память (вытаскивание гигабайта или двух или десяти кэшированных данных при запуске), поэтому, когда он не запущен ... он лучше даже не существует ,

+0

Объекты 'IDisposable', полученные с помощью' GetExport', принадлежат контейнеру. Контейнер будет повторно использовать их для множественного импорта (если вы не указали «PartCreationPolicy».NonShared') и будет рассеивать их при размещении контейнера. Поэтому вы не должны распоряжаться ими сами. Лучшим решением для управления временем жизни является импорт 'ExportFactory '. Для отложенной инициализации вы можете импортировать 'Lazy '. –

+0

Все еще действует. У меня есть сценарий, в котором рабочий поток будет загружать драйверы. Он накапливает их до тех пор, пока не закончит каждые 16 тыс. Пакетов. BU он не хотел, чтобы все возможные драйверы были созданы. – TomTom

Смежные вопросы