Ведение журнала, аспектно-ориентированное программирование и внедрение зависимостей - пытаюсь разобраться во всем этом

Я знаю, что журналирование является основным вариантом использования АОП. Кроме того, обертки журналирования также представлены как случаи, когда вы хотите использовать DI, чтобы классы не были связаны с конкретной реализацией журналирования. Однако некоторые считают обертки журналирования анти-шаблоном .В первую очередь, такое представление связано с тем, что в большинстве случаев оболочка имеет тенденцию быть упрощенной и удаляет многие особенности, характерные для среды ведения журнала. Если вы реализуете эти конкретные функции, почему бы просто не использовать фреймворк напрямую.

Мне известен фасад Common.Logging , который пытается абстрагироваться от большого количества функций log4Net, EntLib, NLog для вас. Однако даже здесь у нас все еще есть своего рода зависимость от Common.Logging. Не с помощью кода / модульного тестирования интерфейсов и т. Д., Но если проект умирает (с момента последнего выпуска прошло больше года) или вы хотите, чтобы последний переключился на неподдерживаемый регистратор, это может вызвать проблемы.

Тем не менее, , если ведение журнала достигается через АОП, необходимо ли вообще использовать DI для зависимости ведения журнала (т.е. почему бы просто не напрямую ссылаться, скажем, на NLog)? Да, эта часть кода АОП была бы тесно связана, но логика классов, которые нужно тестировать модулем, лишена зависимостей журналирования (по крайней мере, до того, как произойдет переплетение). На этом этапе я немного растерялся (я еще не пробовал АОП). После переплетения, не вызовет ли неиспользование DI для кода АОП проблемы для модульного тестирования тестируемого метода? Или можно провести единичный тест без переплетения кода АОП?

Если журналирование не является требованием пользователя программного обеспечения, я не уверен, насколько оно полезно для проверки того, что ведение журнала имело место с помощью имитаций. Я думаю, что бизнес-логика тестируемого метода - это то, что больше всего было бы интересно тестировать.Наконец, если кто-то хочет использовать TDD / BDD, не нужно ли использовать DI для зависимостей журналирования в коде AOP? Или просто не тест-драйв со стороны АОП?

Как видите, я пытаюсь понять, какой подход является наиболее практичным для разработки приложения, которое будет использовать как АОП для сквозных задач, так и DI для проектирования / тестирования. Поскольку АОП является относительно новым, а ведение журнала является наиболее распространенным примером, каков рекомендуемый подход?