☕️ DotNetCurry — отличный источник знаний для .NET-разработчиков!

Он собрал в себе подробные статьи, пошаговые руководства и примеры кода по C#, ASP․NET, Blazor, Entity Framework и другим технологиям экосистемы Microsoft.

📌 Оставляю ссылочку: dotnetcurry.com

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

📂 Напоминалка по UML Class Diagrams!

Например, Association показывает связь между классами, Inheritance — наследование, а Composition — ситуацию, когда один объект является частью другого.

На картинке — основные элементы UML-диаграмм классов: классы, методы, атрибуты, интерфейсы и типы связей.

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

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

Создаём копию объекта с изменёнными данными!

Иногда нужно взять существующий объект и изменить в нём только одно-два значения.

Например, у нас есть record с данными пользователя:

record User(string Name, int Age);

Создадим пользователя:

User user = new User("Анна", 25);

Console.WriteLine(user);

Вот что получится:

User { Name = Анна, Age = 25 }

Теперь допустим, что возраст изменился.
Можно создать новый объект вручную:

User updatedUser = new User(user.Name, 26);

Console.WriteLine(updatedUser);

Но если свойств много, такой код становится неудобным.

В C# для record можно использовать выражение with:

User updatedUser = user with { Age = 26 };

Console.WriteLine(updatedUser);

with создаёт копию объекта и меняет только указанные свойства.
Исходный объект при этом остаётся прежним.

Вот что получится при запуске:

User { Name = Анна, Age = 26 }

🔥 with удобно использовать, когда нужно аккуратно обновлять immutable-объекты без ручного копирования всех данных

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

❤️ Free Programming Books — огромная коллекция бесплатных книг по программированию!

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

Оставляю ссылочку: GitHub 📱

➡️ C# Ready | #репозиторий

😎 Полезный разбор типичных ошибок в C#-проектах: перегруженные классы, смешение слоёв и слабая декомпозиция!

В этой статье:
• почему проект быстро становится неуправляемым
• как смешение логики, API и базы усложняет поддержку
• зачем разделять ответственность между слоями

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

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

Почему TryParse() лучше, чем Parse() внутри try/catch?

Когда мы работаем с пользовательским вводом, строкой из файла, query-параметром или данными из внешней системы, невалидное значение — это не что-то неожиданное. Это обычный сценарий, который нужно аккуратно обработать.

Если использовать Parse() и ловить ошибку через try/catch, код выглядит так, будто произошла настоящая авария:

try
{
    var age = int.Parse(input);
    SaveAge(age);
}
catch
{
    ShowError();
}

Формально это работает, но читается тяжелее.
Приходится воспринимать обычную проверку как исключительную ситуацию.

Гораздо понятнее выглядит такой вариант:

if (int.TryParse(input, out var age))
{
    SaveAge(age);
}
else
{
    ShowError();
}

TryParse() сразу показывает намерение:
мы пробуем преобразовать значение и заранее готовы к тому, что оно может быть невалидным.

Такой код: легче читать, проще контролировать, лучше подходит для обычной валидации и не превращает ожидаемую ошибку ввода в исключение.

Особенно полезно это при работе с формами, API-запросами, настройками, файлами и любыми данными, которые приходят извне.

🔥 Если ошибка ожидаема — лучше обработать её явно, а не прятать обычную проверку в try/catch.

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

🧐 Разбираем типичные варианты архитектурных ошибок!

Нашёл полезный разбор типичных ошибок в C#-проектах: перегруженные классы, смешение слоёв и слабая декомпозиция.

В статье:
• почему проект быстро становится неуправляемым
• как смешение логики, API и базы усложняет поддержку
• зачем разделять ответственность между слоями

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

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

Почему пустой массив лучше брать через Array.Empty<T>()?

Когда нужно вернуть пустой массив, можно написать так:

return new User[0];

На первый взгляд всё нормально. Мы действительно возвращаем массив без элементов.

Но проблема в том, что каждый раз создаётся новый пустой массив. Хотя смысла в этом нет: пустой массив можно переиспользовать.

Лучше использовать готовый вариант:

return Array.Empty<User>();

Такой код сразу показывает намерение: нам нужен именно пустой массив.

Он не создаёт лишний объект и читается как стандартный способ вернуть “ничего, но без null”.

Это особенно полезно в методах, которые часто вызываются.

🔥 Array.Empty<T>() - маленькая привычка, которая делает код чище и убирает лишние выделения памяти.

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

❤️ Awesome .NET Core — огромная база ресурсов по .NET и ASPNET Core!

Здесь собрано практически всё для .NET-разработчика: библиотеки, шаблоны, инструменты, ORM, статьи, архитектурные решения и полезные сервисы для backend-разработки на .NET Core. Особенно полезно тем, кто работает с ASPNET Core, микросервисами, Docker и современным backend-стеком. Можно быстро найти готовые решения, нужные инструменты и сильно ускорить разработку.

Оставляю ссылочку: GitHub 📱

➡️ C# Ready | #репозиторий

scoped в C#: как не дать ссылке “убежать” наружу!

Иногда при работе со Span<T>, ref и памятью важно не только избежать лишних аллокаций, но и не вернуть наружу ссылку на данные, которые скоро перестанут существовать.

Например, такой код может выглядеть безобидно:

static ReadOnlySpan<char> GetPrefix(ReadOnlySpan<char> text)
{
    return text.Slice(0, 3);
}

Метод принимает участок строки или буфера и возвращает первые 3 символа. Пока данные живут достаточно долго — всё нормально.

Но в более сложном коде можно случайно попытаться сохранить ссылку на временные данные там, где она жить уже не должна. Особенно это важно при работе с Span<T>, stackalloc и ref-параметрами.

В C# для таких случаев есть scoped:

static void PrintPrefix(scoped ReadOnlySpan<char> text)
{
    var prefix = text.Slice(0, 3);

    Console.WriteLine(prefix.ToString());
}

scoped говорит компилятору: этот параметр можно использовать внутри метода, но нельзя сохранить так, чтобы ссылка пережила текущий вызов.

То есть мы явно ограничиваем время жизни данных и помогаем компилятору поймать опасные сценарии ещё на этапе сборки.

Особенно полезно это выглядит вместе со stackalloc:

Span<int> numbers = stackalloc int[] { 1, 2, 3, 4, 5 };

Print(numbers);

static void Print(scoped Span<int> values)
{
    foreach (var value in values)
        Console.WriteLine(value);
}

Здесь данные лежат на стеке, и scoped помогает не дать ссылке на них случайно “утечь” наружу.

scoped не делает код быстрее сам по себе. Его задача другая — сделать работу с памятью безопаснее и понятнее для компилятора.

🔥 scoped — способ сказать C#: “эту ссылку можно использовать здесь, но нельзя уносить дальше”.

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

📂 Шпаргалка по безопасности API!

Безопасный API — это не только HTTPS. Нужны authentication, authorization, input validation, rate limiting, audit logs, защита от replay-атак, корректная работа с токенами и ограничение доступа к чувствительным данным.

На картинке — основные практики, которые помогают защитить API от типовых уязвимостей и злоупотреблений.

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

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