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

Question

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

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

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

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

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

Answer 1

Ведение журнала - это не услуга, это сквозная проблема .Поэтому его лучше всего реализовать с помощью Decorator .Однако добавление большого количества декораторов только для того, чтобы включить ведение журнала различными службами, может привести к нарушению DRY , и в этом случае вы можете затем превратить эти декораторы в один перехватчик.

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

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

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

Если вы хотите узнать больше о AOP и DI, вы можете просмотреть онлайн этот доклад, который я дал в GOTO Copenhagen2010 .