!NOTE Цей план містить перелік «мастхев» бібліотек для сучасної ASP.NET розробки. Кожна тема — це окрема стаття, що пояснює проблему, рішення та практичне впровадження.
Проблема: DataAnnotations розкидані по полях, складно тестувати, неможливо додати складну логіку (наприклад, перевірку унікальності в БД). Зміст:
AbstractValidator<T>.NotEmpty().EmailAddress().Must()Проблема: Ручний маппінг (переписування полів з DTO в Entity) займає багато часу та призводить до помилок. AutoMapper занадто складний та повільний. Зміст:
.Adapt<T>()Проблема: Використання Exceptions для бізнес-помилок — це дорого і робить код важким для читання. Зміст:
ErrorOr: типи успіху та помилокПроблема: Стандартне логування — це просто текст. Складно фільтрувати по ID користувача або Transaction ID. Зміст:
appsettings.jsonПроблема: Величезні контролери/сервіси з десятками залежностей. Зміст:
Проблема: Зовнішні API падають. Потрібно вміти «перечекати» або «спробувати ще раз». Зміст:
HttpClientПроблема: Як дізнатися, що база даних впала або Redis недоступний без перевірки логів? Зміст:
/health ендпоінтаПроблема: Як вимкнути функцію в продакшені без редиплою? Зміст:
Проблема: SmtpClient застарів, а API сервісів (SendGrid, Mailgun) різні.
Зміст:
Проблема: Створення PDF через HTML-to-PDF — це боляче, повільно і нестабільно. Зміст:
Проблема: Складно створювати реалістичні дані для тестів вручну. Зміст:
Проблема: Код завалений перевірками if (obj == null) throw... та некрасивим відображенням дат/чисел.
Зміст:
Guard.Against.Null(obj)Окремий великий модуль (Планується):
Humanizer та Guard Clauses в ASP.NET Core
Humanizer: перетворення даних у людиночитабельний текст (дати, числа, рядки, переліки). Guard Clauses: захисні перевірки для чистого коду без вкладених if-else.
Від Minimal API до Razor Pages: концептуальний перехід
Плавний перехід від Minimal API до Razor Pages: навіщо потрібен server-side rendering, коли обирати API vs SSR, порівняльна таблиця концепцій, Convention-based routing через файлову структуру Pages/, перші кроки у Program.cs.