Удалить зависимость от кода регистрации

Question

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

Это не модульный, в основном это псевдо-объектно-ориентированный код. Он содержит жестко закодированные зависимости, никаких интерфейсов, множественные обязанности и т. Д. Просто беспредел .

Среди прочего он содержит большое количество внутренних вызовов к классу Audit , который содержит такие методы, как Log, Info, LogError и т. Д. Этот класс должен быть настроен в Конфигурация приложения для того, чтобы работать, иначе это сбой. И это главная боль для меня. И, пожалуйста, давайте сосредоточимся на этой проблеме в ответах, а именно , делающей клиентский код независимым от классов / решений / каркасов логирования .

А теперь я хотел бы, чтобы те классы, у которых этот Аудит зависел от класса, жестко закодированы, реорганизованы для получения нескольких преимуществ:

1. Во-первых, нужно красиво извлечь их из разных сборок, поскольку мне понадобятся некоторые функции, доступные в других приложениях (например, для генерации кода вложений - назовем его AttachmentsGenerator класс, который до сих пор был характерен для одного приложения). , но теперь этот код можно использовать во многих местах)
2. Удалите внутренние зависимости, чтобы другие приложения могли использовать мой класс AttachmentsGenerator без необходимости добавлять ссылку на другие
3. Сделайте магический трюк, чтобы позволить AttachmentsGenerator классу сообщить некоторую информацию аудита, следы и т. Д. Но я не хочу, чтобы он имел жестко запрограммированную реализацию. На самом деле, я не хочу, чтобы это было обязательным, поэтому можно было бы использовать AttachmentsGenerator без настройки внутреннего ведения журнала и без необходимости добавления клиентским кодом ссылки на другие сборки в Для того, чтобы использовать логирование. Итог: если клиентский код хочет использовать AttachmentsGenerator , он добавляет ссылку на сборку, которая содержит этот класс, затем он использует оператор new и все.

Какой подход я могу использовать с точки зрения шаблонов проектирования и т. Д. Для его достижения? Я был бы признателен за некоторые ссылки на статьи, посвященные этой проблеме - поскольку может потребоваться много времени для разработки идей в ответ. Или, если вы можете предложить простой интерфейс / класс / эскиз сборки.

Большое спасибо, Paweł

Редактировать 1: Поскольку мой вопрос не совсем понятен, я перефразирую его еще раз: Это мой план, есть ли другие интересные способы сделать это?

Answer 1

Кажется, что самый простой способ сделать это - использовать внедрение зависимостей.

1. Создание общего интерфейса ILogger с методами ведения журнала.

2. Создать конкретную реализацию ILogger, которая просто ничего не делает для всех методов (например, NullLogger)

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

4. Используйте инструмент DI (пружина, карта структуры и т. Д.), Чтобы внедрить соответствующую реализацию в зависимости от того, хотите ли вы включить ведение журнала.

Answer 2

Реализация ведения журнала (и любых других сквозных задач) в качестве декоратора . Это намного больше SOLID , чем необходимость вставлять какой-либо интерфейс ILogger в каждый сервис (что нарушает принцип Single Responsibility и DRY ).