Вход в API

Question

Когда я пишу сборку API для кого-то другого, было бы полезно иметь возможность ведения журналов, чтобы помочь диагностировать проблемы клиентов, используя ее.

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

Я не хочу изобретать велосипед, написав собственную структуру регистрации.

Какой лучший способ решить мою дилемму?

Edit: я полагаю, я мог бы потребовать, чтобы конкретная версия log4net, которую я использую, была установлена ​​в GAC, чтобы избежать столкновения версий с клиентом, но это сделало бы API-интерфейс толстым, что требует установки вместо удаления в сборе.

Answer 1

Посмотрите, как SpringFramework решает эту проблему. Он использует Common.Logging, который затем может быть сопоставлен с log4net или любым другим пользовательским каркасом регистрации через файл конфигурации. Вы можете найти более подробную информацию на сайте Common.Logging , но в основном вы делаете следующее:

• ссылка Common.Logging в вашем классе используется, как log4net
• потребитель вашей платформы настроит Common.Logging для использования log4net следующим образом:

  <configSections>
    <sectionGroup name="common">
      <section name="logging" type="Common.Logging.ConfigurationSectionHandler, Common.Logging" />
    </sectionGroup>
    <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
  </configSections>

  <common>
    <logging>
      <factoryAdapter type="Common.Logging.Log4Net.Log4NetLoggerFactoryAdapter, Common.Logging.Log4Net">
        <arg key="configType" value="INLINE" />
      </factoryAdapter>
    </logging>
  </common>

  <log4net>
.... normal log4net configuration goes here...
  </log4net>

Если клиент также использует SpringFramework или Common.Logging напрямую, конфликт все еще возможен, но его шансы значительно уменьшены по следующим причинам:

• Команда Common.Logging старается обеспечить обратную совместимость будущих версий с предыдущими версиями. Например, 2.0 полностью двоично совместим с 1.2.
• Common.Logging меняется реже, чем log4net, по крайней мере, в теории

Answer 2

Используйте System.Diagnostics.Trace. Тогда шансов на столкновение версий нет!

Answer 3

Используйте Enterprise Library . Он достаточно гибкий и использует как встроенные регистраторы, так и свои собственные. Это было довольно совместимо с версионом. Он достаточно настраиваем, чтобы в случае конфликта с конкретным компонентом его можно было легко заменить, просто изменив конфигурацию.

Answer 4

Это то место, где внедрение зависимостей является вашим другом - вам, вероятно, не нужно использовать весь log4net, а некоторые его небольшие кусочки. Поэтому напишите класс ILogger в своем приложении, который предоставляет ваши функциональные возможности, а затем напишите реализацию для любого регистратора, который вы хотите использовать. Например, средство ведения журнала Debug.Trace () отлично подходит для разработки или отладки, в то время как для производства может потребоваться драйвер log4net. Затем используйте внедрение зависимостей, например StructureMap, чтобы вставить экземпляры вашего регистратора в производственный код.

Answer 5

Если вы хотите передать информацию журнала извне людям, использующим ее, возможно, стоит воспользоваться услугой, подобной 3scale (отказ от ответственности, я там работаю) - она ​​позволяет вам записывать журналы и информацию о трафике предоставьте разработчикам интерфейс для просмотра статистики, ошибок, API-ключей, ограничений скорости, которые они могут достигать, и т. д. Он также объединяет эти данные для вас, поэтому у вас есть одно место.

Answer 6

используйте внедрение зависимостей (Unity, Castle Windsor и т. Д.), Чтобы указать, что dll log4net использовать таким образом, если клиент использует более старую версию, вы можете просто подключить туда версию log4net, если у нее ее нет затем предоставьте свой собственный.