Logowania, programowania zorientowanego na aspekt i iniekcji zależności-starając się zrozumieć to wszystko

Wiem, że logowanie jest głównym przypadkiem użycia AOP. Dodatkowo wrappery logowania są również przykładem przypadków, gdy chcesz użyć DI, aby Klasy nie były połączone z konkretną implementacją logowania. Jednak niektórzy uważają owijarki do logowania za anty-wzorzec. Przede wszystkim taki widok jest spowodowany tym, że w większości przypadków owijka jest uproszczona i usuwa wiele cech specyficznych dla frameworka logging. Jeśli zaimplementujesz te konkretne funkcje, dlaczego nie użyć framework bezpośrednio.

Jestem świadomy wspólnego.Logging fasadę, która próbuje wyodrębnić dużą ilość funkcji log4Net, EntLib, NLog dla Ciebie. Jednak nawet tutaj mamy pewnego rodzaju zależność od wspólnego.Logowanie. Nie w sposób testowania kodu / jednostki w odniesieniu do interfejsów itp., ale jeśli projekt umrze (minęło ponad rok od ostatniego wydania) lub chcesz przełączyć się na rejestrator nieobsługiwany, może to powodować problemy.

To powiedziane, jeśli logowanie jest osiągane przez AOP, czy w ogóle konieczne jest użycie DI dla zależności logowania (tzn. dlaczego nie tylko bezpośrednio odwołać się do NLog)? Tak, że część kodu byłaby ściśle powiązana, ale logika klas, które chcemy przetestować, jest pozbawiona logowania zależności (przynajmniej przed splotem). W tym momencie jestem trochę zagubiony (jeszcze nie próbowałem AOP). Czy po utkaniu, nieużywanie DI w kodzie AOP spowoduje problemy w testowaniu jednostkowym badanej metody? Czy może jedna jednostka testować bez tkania kodu AOP?

O ile logowanie NIE jest wymogiem użytkownika oprogramowania, nie jestem pewien, jak przydatne jest testowanie, czy logowanie miało miejsce za pomocą mocks. Myślę, że logika biznesowa testowanej metody jest tym, co większość byłaby zainteresowana testowaniem. Na koniec, jeśli ktoś chce używać TDD/BDD, czy nie musiałby używać DI do logowania zależności w kodzie AOP? A może po prostu nie test drive Po stronie AOP?

Jak widzisz, staram się wyczuć, jakie jest najbardziej praktyczne podejście do tworzenia aplikacji, która będzie używać zarówno AOP do przekrojowych problemów, jak i DI do projektowania/testowania. Ponieważ AOP jest stosunkowo nowy, a logowanie jest najczęstszym przykładem, jakie jest zalecane podejście?