Artykuł

sxc.hu sxc.hu
kwi 25 2013
0

Biblioteki warte poznania w C# - NLog

Zawód programisty to jeden z tych, w których powiedzenie nie warto wymyślać koła od nowa nabiera szczególnego znaczenia. Tworząc oprogramowanie niejednokrotnie stanąłem przed problemem, który został przez kogoś już wcześniej rozwiązany, dlatego tylko jeśli na czymkolwiek się zatnę to od razu sięgam do wujka Google. Podobnie sprawa ma się w przypadku pewnych schematycznych rozwiązań.

Tworząc specjalne klasy do obsługi logowania, bazy danych, czy kolekcji, trzeba liczyć się z tym, że ktoś już coś podobnego wcześniej zrobił. Jeśli określone rozwiązanie (w naszym przypadku biblioteka) istnieje na rynku dostatecznie długo, to możemy być całkiem pewni, że będzie to rzecz przynajmniej warta naszej uwagi (oczywiście przy założeniu, że potencjalne koszty użycia biblioteki są niższe niż w przypadku gdybyśmy podobne rozwiązanie napisali sami).

Nie bez powodu zacząłem ten tekst od podkreślenia znaczenia bibliotek. Tym wpisem chcę właśnie rozpocząć nowy cykl im poświęcony, w którym postaram się Wam udowodnić, że warto je stosować. Na pierwszy ogień dzieło naszego rodaka, czyli świetny NLog wspierający logowanie.

Charakterystyka i zastosowanie

NLog to bardzo ciekawa polska biblioteka do logowania danych, na co zresztą wskazuje sama nazwa. Obecnie rozwiązanie skierowane jest dla platformy .Net, Silverlight oraz Windows Phone.

Główną cechą NLoga jest obsługa wielu wyjść. Skorzystać można m.in. z następujących opcji:

  • Pliki - jeden/wiele na raz
  • Log systemowy - lokalny i zdalny
  • Bazy danych - wszystkie wspierane przez .Net
  • Sieć - z użyciem protokołów TCP, UDP, SOAP oraz MSMQ
  • Konsola
  • Email
  • Asp.Net trace

Powyższa lista to tylko najbardziej popularne opcje, a warto wspomnieć, że każda z nich występuje w wielu wariantach.

Bibliotekę konfigurujemy zasadniczo na dwa sposoby:

  • Za pomocą pliku konfiguracyjnego
  • Programowo

Rozwiązanie wybieramy według własnych preferencji.

Kiedy warto zastosować NLoga?

Oczywiście zanim zdecydujecie się zastosować bibliotekę, warto sobie zadać pytanie czy w danym przypadku warto. Jeśli Wasza aplikacja zawiera pięć klas na krzyż, a NLog ma być użyty do prostego zapisywania do pliku, to w takim w przypadku jest to gra nie warta świeczki. W tej sytuacji lepiej napisać prosty kilku liniowy kod, który zrobi to samo bez całej biblioteczki, która kilkukrotnie podniosłaby rozmiar całego programu.

NLog najlepiej się sprawdzi w dużych i średnich projektach w sytuacji, w której chcemy logować dane do kilku różnych wyjść.

Przykład praktyczny

Korzystanie z NLoga jest banalnie proste, co dobitnie pokaże poniższy przykład. Cała operacja zasadniczo składa się z 3 prostych kroków:

  1. Podpięcie biblioteki do projektu
  2. Dodanie pliku konfiguracyjnego NLog.config do projektu
  3. Napisanie kodu wykorzystującego rozwiązanie

Do pracy NLog wymaga podpięcia tylko jednej DLLki, która w moim przypadku ważyła koło 400KB. Musimy więc dodać referencję do pliku NLog.dll do projektu.

W kolejnym kroku musimy dodać plik konfiguracyjny. Jeśli zainstalowaliście NLoga korzystając z dostarczonego przez twórcę instalatora, to zintegruje się on z Visual Studio. Dzięki temu będziecie mogli wybrać odpowiedni plik korzystając z ekranu dodawania nowego elementu. W domyślnym pliku konfiguracyjnym znajdziecie podstawowe opcje zapisu do pliku.

Jeśli macie tylko samą DLLkę, to również nie jesteście na straconej pozycji. W takim przypadku wystarczy dodać do projektu plik NLog.config, który jest najzwyczajniej w świecie XMLem.

WAŻNE: Dla dodanego pliku konfiguracyjnego należy zmienić właściwość Copy to Output Directory na Copy Always lub Copy if Newer

Poniżej przykładowa zawartość pliku NLog.config:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <targets>
    <target name="LogFile" xsi:type="File" 
            fileName="Log/${date:format=yyyyMMdd} NLogTester.txt"
            layout="${longdate}|${level:uppercase=true}|${message}" />
  </targets>
  <rules>
    <logger name="*" minlevel="Info" writeTo="LogFile" />
  </rules>
</nlog>

W tym przypadku kluczowe są sekcje targets oraz rules. Pierwsza z nich określa gdzie mają trafić zapisy przeznaczone do logu. Zdecydowanie najczęściej używaną formą jest w tym przypadku plik, ale tak jak pisałem wcześniej - możliwości jest znacznie więcej.

Każdy target ma swoją nazwę, typ, layout, a w tym przypadku także ścieżkę do pliku. Warto zwrócić uwagę na różne zmienne. W tym przypadku plik logu zostanie ulokowany w katalogu Log i zawierać będzie dzisiejszą datę. Layout również składa się ze specjalnych zmiennych. Ich znaczenia można się domyślić, ale po więcej odsyłam do dokumentacji.

Drugim ważnym elementem pliku konfiguracyjnego są reguły. W tym przypadku określamy element logger. Jeśli będziemy korzystać tylko z jednego, to warto zostawić mu nazwę w postaci * (jest to domyślna nazwa). Należy również wyraźnie zaznaczyć do jakiego elementu logger ma zapisywać. Chodzi oczywiście o atrybut writeTo w którym definiujemy element docelowy (target).

Na koniec musimy to wszystko przetestować. Spójrzmy na prozaicznie prosty program:

using System;
using NLog;

namespace NLogTester
{
    class Program
    {
        static void Main(string[] args)
        {
            LogManager.GetCurrentClassLogger().Info("Testowa informacja!");
            Console.ReadKey();
        }
    }
}

W tym przypadku wybieramy domyślnego loggera (nie zadziała jeśli damy mu inną nazwę niż *) by zapisać za jego pomocą informację. Powyższy krótki program spowoduje wygenerowanie nowego pliku w podkatalogu Log, który będzie mieć mniej więcej taką zawartość:

2013-04-25 21:57:04.1096|INFO|Testowa informacja!

Prosto, prawda:-)?

Co myślicie o nowym cyklu? Zainteresowani kolejnymi odcinkami?

Data ostatniej modyfikacji: 30.05.2013, 16:13.

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus