Нови стандартни .NET механизми. Част 3. Регистрация

Това е малка поредица от статии за новите стандартни механизми в .NET. Заедно с пускането на .NET Standard, Microsoft пусна голям брой обвързвания, които трябва да подредят част от зоопарка от използвани технологии.

В първата статия (IoC контейнер) говорихме за това защо е страхотно да има изпълнение по подразбиране на DI контейнер и защо в повечето случаи трябва да го използвате. Също така написахме проста реализация на обвързване на атрибути.

Във втория (Конфигурация) говорих за недостатъците на стария начин за конфигуриране на приложението (чрез app.config/web.config) и как те са отстранени в новия подход.

В този трети, нека да разгледаме стандартния интерфейс за регистриране и да прикачим познатия NLog към него.

IoC контейнер.
Конфигурация.
Регистрация.

Регистрация

Защо да се занимавате с нов инструмент за регистриране?

Вече имаме NLog, log4net, Serilog. Всичко това са чудесни инструменти, но е много тъжно, когато всички те се обединят в голямо решение. След това трябва или да преведете всичко в едно, или да видите в някаква абстракция. Все още не е много добре да използвате конкретно решение без слой в разпространяваната библиотека, защото това отново ще доведе крайните потребители до необходимостта да използват вашия инструмент (а те може вече да използват друг).

Вече имаме Common.Logging, ако искаме да отделим от определен инструмент (например в библиотеки). Common.Loging е добре, но не е задължително крайните потребители на вашата библиотека да искат да го използват. Друг голям недостатък е, че няма да използвате Common.Logging по подразбиране навсякъде, много по-често просто вземате NLog и забравяте за проблема, докато той изскочи.

Microsoft.Extensions.Logging решава тези проблеми перфектно. Това е Common.Logging, което се използва по подразбиране в Core приложения, което ни води до факта, че ние точно ще използваме този метод. Сега не абстракцията се адаптира към инструментите (като Common.Logging), а инструментът към абстракцията.

Нека да видим как работи. Създайте конзолно приложение .NET Core и инсталирайте пакетите:

И напишете следния код, за да разберете какво става.

Тук използваме най-лесния начин за инициализиране и използване на регистриране.
Първо се създава LoggerFactory. След това доставчиците се добавят чрез методите за разширение AddConsole (изход към конзолата) и AddDebug (изход към конзолата за отстраняване на грешки). Параметрите задават предиката за писане на дневници на доставчика. В случая на AddConsole предадохме ламбда, която взема низа на съобщение и ниво на регистрационния файл и връща bool. В AddDebug - премина най-ниското възможно ниво. В изхода на конзолата за отстраняване на грешки ще видим:

Конзолата показва:

Всичко е правилно, за конзолата пишем всичко, за отстраняване на грешки - само Debug и по-нови

AddConsole и AddDebug са просто обвивки над празен AddProvider (доставчик на ILoggerProvider), който добавя доставчик към тази фабрична регистрационна програма. Съответно можем да добавим конзолен регистратор, както следва:

И разбира се, можем да напишем собствения си доставчик, ако възникне необходимост.

Друго нещо, което си струва да се спомене, е Scopes. Те ви позволяват да свържете по-добре регистрирането с бизнес задачи. Като пример, нека напишем програма като тази:

Изходът на конзолата ще изглежда така:

Вижда се, че обхватът влияе на изхода и засяга всички регистратори.

Сега нека се опитаме да вградим NLog в приложение на ASP.NET Core. Първо, нека създадем проект, използвайки шаблона "ASP.NET Core Web Application", "Empty".

По време на това писане NLog за .NET Core е в бета версия, така че го инсталираме със следната команда:

След това ще инсталираме пакета NLog.Web.AspNetCore, който съдържа визуализатори за уеб приложения.

Създайте файл NLog.config в корена на проекта и задайте правилото за копиране в изходната директория - Винаги копирайте. Съдържание на файла:

В оформлението използвахме няколко рендери, специфични за ASP.NET - например,
$, за да се покаже URL адресът на заявката.

Сега нека променим нашия Startup.cs, за да добавим поддръжка за NLog там.

Добавете към метода ConfigureServices:

Това ще ни позволи да инжектираме IHttpContextAccessor в единични услуги и да имаме достъп до текущия HttpContext.

И добавете следното към метода за конфигуриране:

Метод
AddNLogWeb запазва DI контейнер (ServiceProvider) в статична променлива, от която NLog ще получи нещата, от които се нуждае (например същия IHttpContextAccessor).

loggerFactory.AddNlog - добавя доставчик на Nlog

След като стартираме приложението и изпълним всяка заявка, ще видим редове в нашия файл по следния начин:

Тук виждаме всичко, което се изисква, за да се разбере каква е била заявката.

Самите регистратори са органично вградени в инфраструктурата на ASP.NET Core - можете да инжектирате ILogger във всяка услуга и тя ще се раздели. Ако искате да работите като в класическите приложения и да създадете регистратор на ръка, просто запазете екземпляра ILoggerFactory в статично поле и издърпайте CreateLogger, когато пожелаете. Препоръчително е да не създавате статични регистратори, а да имате индивидуален екземпляр на регистратора за всеки екземпляр на клас.

По този начин инфраструктурата за регистриране е претърпяла някои промени и сега трябва да я използвате. Регистрацията е изведена на ново ниво на абстракция и можете да изберете кой метод на регистриране да използвате. Всички системни инструменти/рамки (като ASP.NET Core) използват този подход. Всичко това е органично вградено в цялостната екосистема и не изисква никакви специални знания от разработчика.