Действительно ли это - хорошая практика для создания обертки по сторонним компонентам как предприятие MS Библиотека или Log4net?

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

Для ведения журнала уже есть что-то подобное Common.Logging .

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

Преимущества упаковки

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

Недостатки упаковки

• Дополнительные разработки.
• Возможная дополнительная документация работа (как пользоваться новой библиотекой).
• Подробнее вероятны ошибки в упаковке код, чем зрелая библиотека. (Внедрение исправлений ошибок может стать большой головной болью!)
• Разработчики нужно изучить новую библиотеку (даже если очень простой).
• Иногда может быть сложно обернуть всю библиотеку чтобы избежать утечки реализации интерфейсы. Эти типы обертки классы обычно не представляют ценности другие чем обфускация. например MyDbCommand класс обертывает некоторые другие DbCommand class.

Я раньше упаковывал часть Enterprise Library и не думал, что это принесет большую пользу. Я думаю, вам было бы лучше:

• Документирование передового опыта и использования
• Обеспечение эталонной реализации
• Проверка соответствия (проверка кода и т. д.)

Использование интерфейсов обертывания действительно делает модульное тестирование намного проще, но, что не менее важно, оно позволяет использовать макеты.

Например, структура PRISM для Silverlight и WPF определяет интерфейс ILoggerFacade с простой метод под названием Log . Используя эту концепцию, вот как я определяю фиктивный логгер (используя Moq ) в своих модульных тестах:

var loggerMock = new Mock<ILoggerFacade>(MockBehavior.Loose);

loggerMock.Setup(lg => lg.Log(It.IsAny<string>(), It.IsAny<Category>(), It.IsAny<Priority>()))
  .Callback((string s, Category c, Priority p) => Debug.Write(string.Format("**** {0}", s)));

Позже вы можете передать loggerMock.Object тестируемому объекту через конструктор или свойство ,

Это это скорее субъективный вопрос, но IMO это хорошо - обернуть любое использование конкретного приложения / библиотеки в дизайн модели обслуживания, который имеет хорошо продуманные интерфейсы, чтобы вы могли легко использовать DI и более поздние версии, если вам когда-либо понадобится переключиться с, скажем, приложения данных EntLib Заблокируйте NHibernate, вам не нужно переделывать архитектуру всего приложения.

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

Я не знаю, что существует огромное количество таких библиотек. риск напрямую ссылаться на них / вызывать их, поскольку они определенно являются зрелыми проектами (по крайней мере, EntLib и Log4Net), но наличие оболочки изолирует вас от путаницы, связанной с изменением версии и т. д., и дает вам больше возможностей в будущем при довольно низком уровне стоимость.

Я думаю, что лучше использовать оболочку лично, просто потому, что это вещи, которые вы не хотите запускать при запуске модульных тестов (при условии, что вы unit также тестирование).

Да , если возможность замены реализации является требованием сейчас или в разумном будущем

Нет в противном случае.

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