Czytam sobie dokumentację, a w niej rekomendacja aby logi z aplikacji podawać do klasy którą można uzyskać poprzez Dependency Injection. Przyznam szczerze że jest to trochę niewygodne, w każdej klasie w której chciałbym coś logować muszę dodać przynajmniej 3 linijki (globalna deklaracja, parametr w konstruktorze, przekazanie parametru do zmiennej w klasie). Ponadto w testach jednostkowych muszę mockować Loggera. Tak się zastanawiam: co stoi na przeszkodzie żeby klasa Logger była po prostu statyczna? Tym bardziej że w aplikacjach konsolowych C# taka rzecz funkcjonuje w postaci Debug.Write("Message");
0
1
Ja tam robię middleware w któym obsługuje wyjątki i tam mam też zapis logów.
0
Im mniej statyków tym lepiej. Luźne powiązania za cenę tej małej niewygody potrafią odwdzięczyć się z nawiązką.
Ale nikt ci nie broni zrobienia statyka.
0
iteredi napisał(a):
Ponadto w testach jednostkowych muszę mockować Loggera. Tak się zastanawiam: co stoi na przeszkodzie żeby klasa Logger była po prostu statyczna?
To główna zaleta - dzięki temu możesz sobie tego przetestować wywołania Loggera. PM będzie szczęśliwy, jak mu pokrycie testami wzrośnie. A szczęśliwy kierownik to szczęśliwy pracownik. ;)
Jeszcze fajniej jest, jak IoC nie może takiego loggera zainicjalizować - i aplikacja wypieprza się podczas startowania, a Ty nie wiesz czemu, bo przecież nie masz loggera. :)
Ja nie piszę w Core, ale w NLogu mam po prostu private static logger = LogManager.GetCurrentClassLogger(); i żyję od lat. I jeszcze nigdy nie było tak, żeby coś nie zadziałało.
Tym bardziej że w aplikacjach konsolowych C# taka rzecz funkcjonuje w postaci
Debug.Write("Message");
No ja bym jednak tego nie porównywał.