Мини-кеш в памяти через MemoryCache — меньше лишних запросов к БД!

Когда данные меняются редко, но читаются постоянно (настройки, справочники, профили), тянуть их каждый раз из БД или файла — расточительно. Проще один раз загрузить и держать в памяти пару минут, используя MemoryCache.

Сначала подключим нужные пространства имён и создадим кеш:

using System;
using Microsoft.Extensions.Caching.Memory;

var cache = new MemoryCache(new MemoryCacheOptions());

Теперь сделаем метод, который сначала пытается взять данные из кеша, а если их там нет — читает из «БД» и кладёт в кеш на 5 минут:

string GetUserName(int userId)
{
string cacheKey = $"user:{userId}";

if (!cache.TryGetValue(cacheKey, out string name))
{
    Console.WriteLine("Читаем из БД...");
    name = LoadUserNameFromDatabase(userId);

    // кэшируем на 5 минут
    cache.Set(cacheKey, name, TimeSpan.FromMinutes(5));
}

return name;
}

Для примера сделаем простую «заглушку» под запрос к БД:

string LoadUserNameFromDatabase(int userId)
{
// здесь могла бы быть реальная работа serId}";
}

Теперь посмотрим, как это работает при двух подряд вызовах с одним и тем же userId:

Console.WriteLine(GetUserName(42)); // первый вызов — попадём в "БД"
Console.WriteLine(GetUserName(42)); // второй вызов — уже из кеша

Возможный вывод в консоли:

Читаем из БД...
User #42
User #42

🔥 Обрати внимание: сообщение «Читаем из БД…» появилось только один раз — дальше значение берётся из памяти, пока не истечёт время жизни записи (в нашем примере 5 минут).

➡️ C# Ready | #практика

Как избавиться от конкатенации строк в логах?

В старом коде логи часто собирают через +: дописываем кусочки текста, ID пользователя, источник, детали ошибки — и в итоге получаем длинную, плохо читаемую строку.

_logger.LogWarning(
    "User " + userId + " not found in " + source);

Такой код шумный, легко промахнуться с пробелами/запятыми, а параметры потом сложнее вытаскивать из логов.

С интерполяцией и шаблонами сообщения становятся короче и понятнее:

_logger.LogWarning("User {UserId} not found in {Source}", userId, source);

Текст читается как обычное предложение, а значения подставляются отдельными аргументами. Логгер может сохранить их структурированно — по полям UserId, Source, что упрощает фильтрацию и поиск.

🔥 В итоге логи меньше засоряют код, сообщения читаются с первого взгляда, а параметры удобно анализировать в системе логирования.

➡️ C# Ready | #совет

📂 Напоминалка по созданию грамотных RESTful API!

Например, корректное использование HTTP-методов и чёткая структура эндпоинтов делают API предсказуемым и удобным для интеграции.

На картинке — 8 ключевых принципов, которые стоит учитывать при проектировании API: от версионирования и семантических путей до batch-операций и продуманного query-языка.

Сохрани, чтобы не забыть!

➡️ C# Ready | #ресурс

Цветной лог в консоли через Console.ForegroundColor — ошибки сразу в глаза!

Обычный консольный лог — это сплошная серая простыня текста. Гораздо приятнее, когда ошибки красные, предупреждения жёлтые, а успешные операции зелёные.

В .NET это делается в пару строк через Console.ForegroundColor.

Подключать ничего дополнительно не нужно, достаточно стандартного System:

using System;

Сделаем маленький «логгер» с тремя уровнями: Info, Warn и Error — каждый со своим цветом:

static class Logger
{
    public static void Info(string message) =>
        Write("INFO", message, ConsoleColor.Green);

    public static void Warn(string message) =>
        Write("WARN", message, ConsoleColor.Yellow);

    public static void Error(string message) =>
        Write("ERROR", message, ConsoleColor.Red);

    private static void Write(string prefix, string message, ConsoleColor color)
    {
        var prev = Console.ForegroundColor;

        Console.ForegroundColor = color;
        Console.WriteLine($"{prefix}: {message}");
        Console.ForegroundColor = prev; // возвращаем старый цвет
    }
}

Теперь пользоваться таким логгером очень просто:

Logger.Info("Сервис успешно запущен");
Logger.Warn("Конфиг не найден, используем значения по умолчанию");
Logger.Error("Не удалось подключиться к базе данных");

В консоли сразу видно, где успех, где потенциальная проблема, а где уже всё плохо — цветом подсвечено без всякой сложности в коде.

🔥 Главное — всегда возвращать предыдущий цвет (prev), чтобы не поломать остальной вывод консоли.

➡️ C# Ready | #практика

Передаём переменные по ссылке с помощью ref!

Сейчас научимся передавать переменные в методы по ссылке, а не по значению. Это особенно полезно, когда нужно изменить переменную внутри метода и сохранить изменения снаружи.

Подключим нужные библиотеки — всё уже есть в стандартной библиотеке:

using System;

Допустим, у нас есть метод, который увеличивает значение числа:

void Increment(ref int number)
{
    number++;
}

Создадим переменную и передадим её в метод по ссылке:

int value = 5;
Increment(ref value);
Console.WriteLine(value);

🔥 Без ref переменная осталась бы равной 5 — метод работал бы с копией. А с ним мы передаём реальную переменную, и её значение меняется внутри метода.

➡️ C# Ready | #практика

🐱 Обзор нововведений в C# 12 — компактный разбор ключевых фич свежей версии языка!

В этой статье:
• Разбираются первичные конструкторы и влияние на архитектуру классов
• Показываются выражения коллекций и упрощение работы со списками
• Объясняются новые возможности алиасов типов и параметры по умолчанию

🔊 Продолжай читать на Habr!

➡️ C# Ready | #статья

Как перестать писать if (str != null && str.Trim() != "") ??

Во вводе пользователя и данных из внешних систем мы постоянно боимся null и пустых строк — в итоге условия разрастаются:

string name;
if (user.InputName != null && user.InputName.Trim() != "")
{
    name = user.InputName.Trim();
}
else
{
    name = "Гость";
}

С string.IsNullOrWhiteSpace то же самое записывается гораздо короче и понятнее:

var name = string.IsNullOrWhiteSpace(user.InputName)
    ? "Гость"
    : user.InputName.Trim();

string.IsNullOrWhiteSpace сразу проверяет три вещи: строка не null, не пустая и не состоит из одних пробелов.

🔥 Вместо громоздких ручных проверок используем один метод — меньше шума в условиях, меньше шансов забыть про крайний случай, а код читается как простое правило: «если имя не задано — подставь "Гость"».

➡️ C# Ready | #совет

Перестаём плодить new HttpClient() с IHttpClientFactory!

Частая ошибка: в каждом методе делать new HttpClient(). В итоге — утечки сокетов, странные таймауты и боль в проде. В .NET есть нормальный способ — IHttpClientFactory.

Сначала регистрируем фабрику и настраиваем клиент в DI:

using System;
using System.Net.Http;
using Microsoft.Extensions.DependencyInjection;

var services = new ServiceCollection();

services.AddHttpClient("github", client =>
{
    client.BaseAddress = new Uri("https://api.github.com/");
    client.DefaultRequestHeaders.UserAgent.ParseAdd("CSharpReadySample");
});

var provider = services.BuildServiceProvider();

Достаём IHttpClientFactory и берём настроенный клиент по имени:

var factory = provider.GetRequiredService<IHttpClientFactory>();

using var client = factory.CreateClient("github");

var response = await client.GetAsync("repos/dotnet/runtime");
var content  = await response.Content.ReadAsStringAsync();

Console.WriteLine(content[..200] + "...");

🔥 Главное — вместо десятков new HttpClient() используйте один IHttpClientFactory: настроили клиент в одном месте, берёте его из DI где нужно — без утечек и с предсказуемым поведением в проде.

➡️ C# Ready | #практика