Должен ли я использовать файл или код Unity Config для регистрации типов и экземпляров?

Question

Наконец-то начали настраивать контейнер IoC!

Я использую Unity и настроил его для регистрации моих объектов с помощью файла конфигурации:

, например

      <container>
        <register type="ILogger" mapTo="Logger">
          <lifetime type="singleton"/>
        </register>
        <register type="IPdfWriter" mapTo="PdfWriter">
          <lifetime type="perthread" />
          <constructor />      
        </register>
</container>

Я дошел до того, что сомневаюсь, что это хороший подход к регистрации типов.

Например, мой класс зависит от ICacheManager из блока кэширования Microsoft Enterprise Library, и в него должно быть вставлено следующее:

EnterpriseLibraryContainer.Current.GetInstance<ICacheManager>()

и это не представляется возможным, используя только настройки конфигурации Unity.

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

Какой у вас опыт / совет по этому поводу?

Спасибо

Answer 1

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

И ответить на вопрос, который вы не задавали, - то, что вы хотите сделать, на самом деле возможно и довольно легко.Хитрость заключается в том, чтобы использовать один и тот же экземпляр контейнера для Enterprise Library и для всего остального.В своем коде запуска настройте экземпляр контейнера Unity и добавьте к нему EnterpriseLibraryCoreExtension (что вы можете сделать в config).Затем установите этот контейнер как ваш EnterpriseLibraryContainer.Current.Как только вы это сделаете, вы можете иметь тип с зависимостью от ICacheManager, и все остальное будет просто работать.

Примерно так:

В XML-конфигурации:

<unity>
  <namespace name="Microsoft.Practices.EnterpriseLibrary.Common.Configuration.Unity" />
  <assembly name="Microsoft.Practices.EnterpriseLibrary.Common" />

  <container>
    <extension type="EnterpriseLibraryCoreExtension" />

    <register type="IMyType" mapTo="MyImplementation">
      <constructor>
        <param name="cacheManager" />
      </constructor>
    </register>
  </container>
</unity>

(Вам, конечно, также понадобится ваша конфигурация entlib).

Затем при запуске вашего приложения получите такой код:

var container = new UnityContainer()
    .LoadConfiguration();

EnterpriseLibraryContainer.Current = new UnityServiceLocator(container);

Оттуда все должно просто работать,EnterpriseLibraryContainer.Current будет получать объекты из вашего контейнера, а объекты, разрешенные из контейнера, будут вводить объекты entlib как любая другая зависимость.

После того, как вы пройдете этот шаг, следующий - получить все ваши объекты entlib.через DI и отбросьте явные вызовы EnterpriseLibraryContainer.Current.

Answer 2

Пока что есть несколько хороших ответов.

Существует третий вариант: использовать оба.Когда вы настраиваете одно и то же дважды, второе определение перезаписывает первое.Это означает, что вы можете настроить разумные значения по умолчанию в коде во время разработки, а затем загрузить обновления времени выполнения из xml.

Также помните, что атрибуты в классах - это опция для определения обработчиков перехвата вызовов.Это может удалить весь этот раздел из вашей политики, будь то XML или C #.

Answer 3

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

Если вы просто используете Unity, чтобы упростить тестирование /уменьшите или удалите зависимости и не ожидайте замены деталей на производственном компьютере, а затем раскручивайте их в коде - это нормально.

Answer 4

По моему опыту, использование C # более выразительно и динамично, чем xml. Тем не менее, есть части установки, которые вы можете изменить во время выполнения, тогда вы можете сделать и то, и другое. Для настройки контейнера вы можете использовать как config, так и код.

Answer 5

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

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

Лично используя оба подхода, я предпочитаю соглашение по кодированию.Но если я был в проекте, который действительно должен был быть динамичным, тогда приступайте к настройке!