Какой смысл вырубки фасада? [закрыто]

Существует множество различных библиотек журналов на выбор, каждая из которых имеет свои особенности и преимущества. (Примеры .Net: log4net, System.Diagnostics.TraceSource, nLog и т. Д.)

Естественная склонность состоит в том, чтобы абстрагироваться от этих причуд и использовать лесозаготовительный фасад. (Примеры:Castle.Services.Logging, Common.Logging, Простой лесозаготовительный фасад) Таким образом, если используемая вами среда ведения журналов устарела или в моду вступает другая, вы можете просто поменять реализацию и оставить код без изменений.

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

 Nick Van Brunt29 сент. 2010 г., 22:18
 Howiecamp06 янв. 2016 г., 20:35
@ Брайан Я не уверен, что ваше предположение о естественной склонности людей верно. Настаивайте, что большинство разработчиков даже не думают об этом.

Ответы на вопрос(9)

тобы говоритьuse Some3rdParty.dll and MyPlugingApi.dll Я бы только документальноMyPlugingApi.dll, Интерфейс журнала фасадов предложит и задокументирует некоторое использование, которое, вероятно, приведет к читаемым журналам и достаточно хорошей производительности журналирования. И, конечно, внесение изменений не приведет к изменениям в API плагина.

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

Я также написал еще одинфасад который дитя мыслей в этом ответе.

что делает Один (уровень абстракции) магическим числом здесь то, что Ноль слишком мало, а Два слишком много.

Перестановка регистратора за фасадом регистратора (количество уровней: 1) может привести к некоторой выгоде для пользователя, например, новый регистратор может сделать то, чего не может старый регистратор. Я могу представить, что это может быть производительность, поддержка определенных типов приложений и т. Д.

Гораздо сложнее представить пользователю выгоду от замены фасада регистратора (количество уровней: 2).

(И если количество уровней равно 0, то это, вероятно, просто плохой объектно-ориентированный дизайн: в вашем коде будут тысячи мест, на которые ссылается регистратор, и что будет, если в следующей версии регистратора произойдет серьезное изменение. )

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

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

Зачем?

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

Когда все ваши журналы проходят через интерфейс, а не конкретный класс, становится очень легко предоставить фиктивный объект с интерфейсом журналирования (выберите, как вы это делаете, внедрение зависимостей и т. Д.), Чтобы записать все регистрация вызовов, выполненных во время определенного тестового сценария.

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

Если бы NLog или log4Net предоставили интерфейс для их регистраторов, мне не пришлось бы прилагать усилия для обеспечения интерфейса и класса-обертки, поскольку я мог бы просто высмеивать их интерфейс для тестов.

В моем проекте я используюSystem.Diagnostics.Trace.TraceError(...), System.Diagnostics.Debug.Print(...) как фасад для лесозаготовок. Для организации (записи) журналов я использую NLog, то есть в app.config у меня есть конфигурация для NLog и перенаправление трассировки .net в NLog.

<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <targets>
     <target name="file" xsi:type="File"
      layout="${longdate:universalTime=true}Z [${threadid}] ${pad:padding=5:inner=${level:uppercase=true}} ${logger} ${message}"
      fileName="${basedir}/App_Data/logfile.txt"...
   </targets>
</nlog>
<system.diagnostics>
  <trace>
    <listeners>
      <add name="nlog" type="NLog.NLogTraceListener, NLog" />
    </listeners>
  </trace>
</system.diagnostics>

Это не связывает меня с любым регистратором. Когда я отправляю свои компоненты клиентам, они могут использовать любой регистратор, который им нравится. Использование определенного регистратора в приложении может вызвать проблемы, то есть вы можете использовать nlog, но ваши клиенты используют log4net.

чтобы иметь возможность поменять регистратор.

Какое дополнительное преимущество даст вам возможность поменять свой фасад лесозаготовок?

 Christopher Edwards29 сент. 2010 г., 22:05
:) Верно, но ИМХО ЯГНИ, и в любом случае иногда вы должны признать, что на каком-то этапе в будущем вам просто придется запустить редактор кода и внести некоторые изменения. Тем не менее, если вы думаете, что вам нужно, то сделайте это. Но я никогда не хочу видеть сторонний проект фасада фасада ...
 Brian29 сент. 2010 г., 21:52
Если бы появился лучший лесозаготовительный фасад или если проект лесозаготовительного фасада устарел, я мог бы поменять его.

написание библиотеки, Внедрение зависимостей в библиотеку - это всегда то, что требует некоторой осторожности, а журналирование - еще более.

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

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

Недостатком, как вы сказали, являются особые способности. Если вы используете их, напишите только свой фасад.

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

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

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

Например, нашему приложению не нужно «сообщение» для сопровождения события; вместо этого наш «регистратор» будет принимать перечисления, определяющие тип события и объекты состояния, представляющие специфику (например, отметки времени или другие значения), и будет сериализовывать их, чтобы упростить отчеты, анализ производительности, метрики стоимости бизнеса и т. д., все в дополнение к поддержке традиционных судебно-медицинская экспертиза. (Мы признаем, что на самом деле мы немного усложняем традиционную экспертизу в пользу простого в использовании и понятного интерфейса ведения журналов, который увеличивает вероятность того, что мы будем его использовать и использовать чаще).

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

Последовательный, специально разработанный интерфейс облегчение инструментовки (в отличие от просто традиционной регистрации, как обсуждалось выше)Поддельные контрольные точкиРеализация инъекционного логгера подходит для всего, от локальной разработки до соединений AWS S3 или DB, в зависимости от развертывания (наше приложение использует Autofac с внедрением зависимостей в конструктор)Заменяемые каркасы логгера что позволит нам в будущем перейти на другую платформу логгера, если мы этого захотим. (Между прочим, мы не предвидим этого, поэтому сами по себе не убедили бы нас использовать фасад.)

И, наконец, 0 фасадов утратили бы эти преимущества, а 2 фасада не добавили бы ни к одному из этих преимуществ, поэтому 1 фасад - это то, что нам нужно.

Отличный вопрос, @brian! :)

Решение Вопроса

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

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

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

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

Если вы недавно начали проект, вы могли бы изучить каркасы журналирования и, возможно, сузить его до двух финалистов: log4net и NLog. У каждого есть аргументы в свою пользу. Ясно, что log4net является фаворитом, вероятно, фаворитом тех, кто высказал свое мнение. NLog предоставляет очень похожие возможности. Судя по популярности, log4net может быть очевидным выбором. По возможностям они кажутся очень похожими. Основываясь на «недавних действиях» (о чем свидетельствуют регистрации в их репозиториях исходного кода по активности блогов или их отсутствию), NLog будет четким выбором. Если бы вам пришлось выбирать год назад, вы могли бы использовать log4net, поскольку это был бы «безопасный» выбор. Не было ясно, когда NLog выпустит. За прошедший год NLog прошел довольно значительный цикл разработки, выпустив бета-версию всего несколько дней назад.

Какой выбрать год назад? Какой выбрать сейчас? Был ли тогда явно лучший выбор? Один из них лучший выбор сейчас?

Одной вещью, которую получает абстракция, является способность откладывать решение о том, какой из них выбрать (вам даже не нужно выбирать КОГДА-ЛИБО, хотя, вероятно, вы захотите, если вы планируете поставлять инфраструктуру ведения журнала вместе с вашим продуктом). Вы можете протестировать диск один, а затем другой и почувствовать, как они работают с вашим приложением, с вашей командой, в вашей среде. Используя что-то вродеCommon.Logging или жеSLF позволяет вам начать писать код сейчас, кодировать в некоторый интерфейс / API регистрации и получить ваш код регистрации на месте. Если вы считаете, что интерфейс / API, предоставляемый абстракцией, достаточен для вашей работы (и почему бы и нет, поскольку он по сути такой же, как интерфейс / API, предоставляемый log4net и NLog), тогда не так много Опасность в использовании абстракции. Когда вы проходите цикл разработки, вы можете обнаружить, что одна или другая структура лучше соответствует вашим потребностям. Закодировав абстракцию, вы можете сделать этот выбор в любой момент, вплоть до того момента, когда ваш продукт появится на рынке.

Вы можете даже подумать, что вы могли бы написать библиотеку журналов с нуля. Опять же, если вы считаете, что интерфейс / API log4net и / или NLog достаточен, вы можете реализовать свою библиотеку журналов с аналогичным API. Если вы в это верите, это может быть еще одной причиной для использования абстракции. Опять же, вы можете начать писать код (для вашего продукта, а не для вашей библиотеки журналов) сегодня, регистрируя с помощью какой-либо другой инфраструктуры журналирования, до тех пор, пока ваша библиотека журналов «с нуля» не будет готова. Может быть, вы действительно хотите использовать System.Diagnostics.TraceSource иUkadc.Diagnostics (чтобы получить возможности форматирования вывода, аналогичные log4net или NLog), чтобы вы могли получить «лучшую» интеграцию с журналированием, которое Microsoft реализовала на некоторых своих платформах с использованием TraceSources. Было бы довольно легко написать «регистратор» в терминах TraceSources, а затем написать абстракцию, чтобы вы могли подключить его к Common.Logging или SLF. (Если интерфейса / API достаточно, вы могли бы просто написать «регистратор» в терминах интерфейса библиотеки абстракций и не создавать дополнительный уровень абстракции).

С такими убедительными аргументами, как эти, почему бы никому не использовать абстракцию? Ха-ха, шучу!

Если абстракция хороша, стоит ли писать свою или использовать уже существующую? Если вы пишете один самостоятельно, то вам, очевидно, придется написать его. Как это сделать? Ну, вы можете просто определить интерфейс и обернуть один фреймворк (будьте осторожны и оберните его правильно!). Позже, если вы решите, что хотите переключиться, оберните эту структуру. Если вы осторожны, вам не нужно менять код приложения, за исключением, может быть, места, где вы на самом деле создаете объекты базовой платформы. Может быть, это хорошо. Вы избежали зависимости от какой-либо сторонней абстракции за «маленькую» цену реализации одной оболочки над одной платформой. Тем не менее, есть стоимость. Пока вы не написали свою абстракцию, вы не сможете действительно написать много кода приложения, в котором есть вход, если у вас нет хорошей стратегии для перехода на вашу абстракцию. Также становится сложнее протестировать два или более фреймворка, чтобы решить, какой из них лучше для вас. Каждый фреймворк, который вы хотите «попробовать», требует другой работы по переносу. Если вы хотите легко переключаться между фреймворками (по крайней мере, во время цикла разработки), у вас есть работа, чтобы сделать это легко. Сторонние фреймворки предоставляют это из коробки.

Вот Это Да! Теперь я продан! Дай мне запись абстракции, или дай мне смерть!

Все ли абстракции логирования в соусе? Есть ли обратная сторона? Они не могут ЭТО здорово, не так ли?

Ну, как всегда, когда вы «покупаете» что-то или получаете что-то бесплатно, вы получаете то, что доступно. Регистрация абстракций ничем не отличается. Ни Common.Logging, ни SLF не предоставляют хотя бы один очень важный набор возможностей log4net / NLog - возможности контекста ведения журнала (GDC, MDC, NDC). Это может быть ключом к получению адекватной информации, зарегистрированной и отформатированной, чтобы вы могли получить максимальную отдачу от вашего. SLF не предоставляет абстракцию TraceSource. Он также не предоставляет функции IsXXXEnabled. Common.Logging предоставляет абстракцию TraceSource. Castle.Logging ДЕЛАЕТ GDC / MDC / NDC для log4net и NLog. Он также предоставляет абстракцию TraceSource. Абстракция TraceSource в Castle также улучшает ведение журнала TraceSource, предоставляя возможность «иерархического» именования, аналогичную предоставляемой log4net и NLog. Это выглядит довольно круто!

Кроме того, все эти проекты являются открытым исходным кодом той или иной формы. Поэтому, в зависимости от абстракции, разработчики могут быть более или менее заинтересованы в том, чтобы обновлять их и добавлять новые функции. Common.Logging прошел через несколько версий и используется, AFAIK, в Spring.Net. Кажется разумно активным, по крайней мере, исторически. Castle.Logging используется в рамках Castle. Таким образом, они, очевидно, имеют «настоящих» клиентов и пользуются «реальным миром», что, как мы надеемся, будет способствовать внедрению новых функций. SLF, насколько я могу судить, не используется как часть «реальной» платформы разработки, поэтому трудно сказать, насколько она задействована.

Не ясно, какова дорожная карта для этих платформ. У Common.Logging есть некоторые предстоящие функции, перечисленные на их веб-сайте, но нет четкого указания, когда они будут доступны. На сайте написано «июнь», но какого года? Как часто осуществляется мониторинг списка рассылки? Для SLF, как часто контролируется их кодовый комплекс? Где приоритет этих "бесплатных" проектов оценивается по сравнению с оплачиваемой работой разработчиков? Можете ли вы позволить себе какую-то стороннюю абстракцию для реализации нужной вам функции? Будут ли они восприимчивы, если вы реализуете что-то, а затем отправляете это на рассмотрение для включения в продукт?

С положительной стороны, все источники для всех этих абстракций доступны, так что вы можете просто взять на себя ответственность за это и внести любые исправления или добавить любые улучшения, которые вы, без необходимости тратить время и энергию на создание абстракции из царапина. Вам нравится Common.Logging, но вы действительно хотите log4net / NLog GDC / MDC / NDC? Получить реализацию Касла и добавить ее в Common.Logging. Вуаля! Абстракция журналирования, которая содержит почти 100% API журналирования log4net / NLog. Вы предпочитаете SLF, но хотите, чтобы IsXXXEnabled? Не так много работы для реализации этого. Идите вперед и выберите GDC / MDC / NDC, пока вы на нем. Тебе нравится Касл? (Я не очень знаком с этим, не уверен, насколько легко использовать за пределами Касла, если это имеет значение) Будьте осторожны, я не использовал его, но, глядя на исходники в git, похоже на регистратор NLog абстракцияможет не сохранить информацию о вызове сайта.

Этично ли брать части нескольких проектов с открытым исходным кодом и объединять их в один «супер» проект (для использования вами или вашей компанией)? Разве плохо брать Common.Logging и дополнять его реализацией Castle GDC / MDC / NDC? Я не знаю. Я позволю кому-то еще ответить на это.

Я почти закончил ...

Некоторые сторонние абстракции журналов предоставляют другие возможности. Вы можете использовать библиотеку, которая реализована в терминах, скажем, log4net. Возможно, вы не захотите использовать log4net или, по крайней мере, не захотите быть привязанным к нему. Common.Logging (и, возможно, SLF) позволяет относительно легко захватывать сообщения журналирования log4net и перенаправлять их через абстракцию, чтобы они были захвачены в потоке журналирования базовой структуры протоколирования абстракции. SLF может предоставить что-то подобное. Конечно, вы можете сделать что-то подобное с существующими каркасами ведения журналов, либо из коробки, либо написав пользовательский log4net Appender, NLog Target или System.Diagnostics TraceListener. Эти особенности не были достаточно высокими в моей конкретной оценке того, использовать или нет стороннюю регистрационную абстракцию в моем проекте, потому что я в основном заинтересован просто в аспекте абстракции.

Итак, где я стою? Я думаю, что имеет смысл сохранять код вашего приложения изолированным от конкретной среды ведения журналов. Для меня Common.Logging выглядит как удачный выбор абстракции, хотя некоторые важные функции отсутствуют (GDC / MDC / NDC) и не совместимы с Silverlight. Было бы здорово, если бы эти функции стали доступны в ближайшее время. Я чувствую себя комфортно с внедрением GDC / MDC / NDC, если мне нужно. Чтобы сделать его совместимым с Silverlight, возможно, потребуется больше усилий, в первую очередь потому, что я не особо разбираюсь в C # / .NET / Silverlight. Пока эти проблемы не будут устранены, мы сможем написать большое количество кода приложения с помощью Common.Logging. Мы можем потратить время на разработку нашего приложения, а не на разработку еще одной библиотеки журналов или библиотеки абстракций. Если бы мы в конечном итоге сами добавили эти недостающие функции, нам бы пришлось многое сделать, если бы мы сами реализовали библиотеку журналов или библиотеку абстракций.

 LosManos15 апр. 2015 г., 09:07
FWIW: я недавно наткнулся наLibLog который является просто файлом, а не зависимостью.
 julealgon21 февр. 2014 г., 15:46
Такой массивный пост! Я согласен со всем, +1 там, конечно, но, возможно, это можно было бы немного упростить / отформатировать? Например, я вижу множество вещей, заявленных несколько раз. Кроме того, так как это очень старый, есть ли у вас более новое понимание этого? Что-то изменилось за это время, что потребовало бы обсуждения снова?
 wageoghe07 мар. 2014 г., 18:22
У меня нет ничего, чтобы добавить, так как мой оригинальный пост. В то время, когда я писал это, я пытался узнать как можно больше о лесозаготовках. В случае моей организации мы остановились на использовании подхода фасада регистрации, в частности Common.Logging для .Net. Мы также остановились на NLog как нашей базовой системе ведения журналов, хотя из-за внешнего вида мы не зависим напрямую от NLog.

Ваш ответ на вопрос