💻 Плавающие окна в Visual Studio

Если вы работаете с несколькими мониторами, вы наверняка отрывали Solution Explorer или окно отладчика на второй экран. Это удобно, но поведение плавающих окон по умолчанию бывает раздражающим: они не отображаются отдельными кнопками в панели задач Windows, сворачиваются вместе с основным окном IDE и всегда остаются поверх остальных окон.

В Visual Studio есть настройка, которая это меняет.

Где найти

Tools > Options > Environment > Windows > Floating Windows

Там есть выпадающий список «These floating windows are owned by the main window» с тремя вариантами:

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

• Tool Windows — значение по умолчанию. Документы плавают свободно, а панели инструментов привязаны к IDE.

• Documents and Tool Windows — классическое поведение Visual Studio: всё подчиняется главному окну.

Двойной клик с зажатым Ctrl по заголовку любой панели мгновенно переключает её между плавающим и закреплённым состоянием.

➡️ Блог разработчиков

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

🚀 .NET 11 Preview 3

Вышел третий превью-релиз .NET 11. Обновления затронули рантайм, SDK, библиотеки, ASP.NET Core, EF Core и .NET MAUI. Разберём главное.

• Библиотеки

System.Text.Json получил больше контроля над именованием полей и обработкой значений по умолчанию. Алгоритм сжатия Zstandard переехал в System.IO.Compression — теперь он часть стандартной библиотеки, а не отдельный пакет. ZIP-чтение добавило валидацию CRC32. Regex теперь корректно обрабатывает все Unicode-последовательности переноса строки.

• Рантайм

Runtime async больше не требует явного opt-in через атрибут — функция стала стабильнее и готовится к основному потоку. JIT-компилятор улучшил оптимизацию switch-выражений, проверок границ массивов и операций приведения типов. Для WebAssembly добавлена поддержка WebCIL и улучшена отладка в браузере.

• SDK

dotnet run теперь принимает переменные окружения прямо из командной строки:

dotnet run -e MY_VAR=value

Solution-фильтры можно редактировать через CLI без открытия IDE. Файловые приложения теперь можно разбивать на несколько файлов. dotnet watch получил поддержку Aspire, восстановление после краша и улучшения для Windows Desktop.

• C#

Добавлена начальная поддержка типа union это размеченные объединения в духе F# или Rust. Пока preview, но направление понятное.

• ASP.NET Core

Поддержка Zstandard для сжатия ответов и распаковки запросов. Компонент Virtualize в Blazor теперь адаптируется к элементам с переменной высотой в рантайме. HTTP/3 начинает обрабатывать запросы раньше — меньше задержек на старте соединения.

• Entity Framework Core

ChangeTracker.GetEntriesForState() позволяет получать записи по состоянию без лишнего обнаружения изменений. DbContext теперь умеет удалять провайдеры и добавлять пулы фабрик. SQL-генератор стал убирать лишние JOIN-ы, а для SQL Server добавлены JSON API.

• Контейнеры

Образы .NET на mcr.microsoft.com теперь подписываются. Можно верифицировать их подлинность перед запуском.

• .NET MAUI

Maps API получил кластеризацию маркеров, стилизацию и расширенное API взаимодействия. LongPressGestureRecognizer теперь встроен в платформу. Добавлена поддержка Android 17 / API 37 в режиме preview.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

🤖 Подборка вакансий для шарпистов

Team Lead C# — от 350 000 ₽ в офис или на удалёнку в Москве

Программист C#/С++/. NET (Middle) — до 400 000 ₽, офис в Москве

Backend .NET developer ( Middle/Middle+) — удалёнка

➡️ Еще больше топовых вакансий — в нашем канале C# Jobs

🐸 Библиотека шарписта

😊 Маппинг объектов без рефлексии и без оверхеда

Маппинг между моделями это одна из самых скучных вещей в C#-разработке. AutoMapper решает проблему, но тянет рефлексию в рантайме. FreakyKit.Forge генерирует весь маппинг-код на этапе компиляции через Roslyn source generators.

Вы объявляете partial-метод, библиотека генерирует его реализацию при сборке. Никакой рефлексии, никаких зависимостей в рантайме.

Установка:

<ItemGroup>
    <PackageReference Include="FreakyKit.Forge.Generator" Version="1.0.0" />
    <PackageReference Include="FreakyKit.Forge.Analyzers" Version="1.0.0" />
</ItemGroup>

Как это работает

Помечаем статический класс атрибутом [Forge] и объявляем метод без тела:

using FreakyKit.Forge;

public class Person    { public string Name { get; set; } public int Age { get; set; } }
public class PersonDto { public string Name { get; set; } public int Age { get; set; } }

[Forge]
public static partial class PersonForges
{
    public static partial PersonDto ToDto(Person source);
}

При компиляции Forge генерирует реализацию:

public static partial PersonDto ToDto(Person source)
{
    var __result = new PersonDto();
    __result.Name = source.Name;
    __result.Age = source.Age;
    return __result;
}

Вызов выглядит так:

var dto = PersonForges.ToDto(person);

Возможности

Базовый сценарий это маппинг по совпадению имён. Но библиотека умеет больше.

Переименование полей через [ForgeMap]:

public class Source { [ForgeMap("Name")] public string FirstName { get; set; } }
public class Dest   { public string Name { get; set; } }

Вложенные объекты с AllowNestedForging:

[Forge]
public static partial class PersonForges
{
    public static partial AddressDto ToAddressDto(Address source);

    [ForgeMethod(AllowNestedForging = true)]
    public static partial PersonDto ToDto(Person source);
}
// Генерирует: __result.Home = ToAddressDto(source.Home);

Коллекции обрабатываются автоматически — List<T>, T[], ImmutableArray<T> и другие. Если типы элементов отличаются, достаточно включить AllowNestedForging.

Обновление существующего объекта вместо создания нового — метод с двумя параметрами и void:

public static partial void Update(Person source, PersonDto existing);
// Генерирует: existing.Name = source.Name; existing.Age = source.Age;

Строгий режим для отлова расхождений при рефакторинге:

[ForgeMethod(StrictMapping = true)]
public static partial PersonDto ToDto(Person source);
// Если добавить поле в Source или Dest — компилятор выдаст ошибку, не предупреждение

Тип-конвертеры для несовместимых типов:

[ForgeConverter]
public static string ConvertDateTime(DateTime value) => value.ToString("yyyy-MM-dd");
// Forge сам найдёт подходящий конвертер и применит его при маппинге

Диагностика

Пакет FreakyKit.Forge.Analyzers добавляет 35 диагностических правил. Ошибки в объявлениях маппингов вы увидите прямо в редакторе при сборке, а не в рантайме.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

🔄 Апрельские обновления безопасности 2026 .NET

Microsoft выпустила плановые обновления для .NET 8, 9, 10 и .NET Framework. В этот раз пакет преимущественно про безопасность, ведь закрыто шесть CVE.

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

CVE-2026-23666 — отказ в обслуживании (DoS) в .NET Framework 3.0, 4.6.2–4.8.1

CVE-2026-26171 — обход защитного механизма. Затронуты .NET 8, 9, 10 и .NET Framework 2.0, 4.6.2–4.8.1

CVE-2026-32178 — удалённое выполнение кода (RCE). Затронуты .NET 8, 9, 10 и .NET Framework 2.0, 4.6.2–4.8.1

CVE-2026-32203 — DoS в .NET 8, 9, 10 и .NET Framework 2.0, 4.6.2–4.8.1

CVE-2026-32226 — DoS только в .NET Framework 2.0, 4.6.2–4.8.1

CVE-2026-33116 — RCE в .NET 8, 9, 10

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

🔒 Три строки, которые закрывают базовые уязвимости

Браузеры умеют защищать пользователей от ряда атак, но только если сервер явно это разрешает через HTTP-заголовки. Без них браузер не знает, как себя вести, и оставляет дыры открытыми.

Как добавить

Подключаем middleware в Program.cs:

app.Use(async (context, next) =>
{
    context.Response.Headers.Add("X-Content-Type-Options", "nosniff");
    context.Response.Headers.Add("X-Frame-Options", "DENY");
    context.Response.Headers.Add("X-XSS-Protection", "1; mode=block");
    await next();
});

Этот блок нужно поставить до app.UseRouting() и других middleware, иначе часть ответов уйдёт без заголовков.

Что делает каждый заголовок

X-Content-Type-Options: nosniff запрещает браузеру угадывать тип содержимого. Без него браузер может решить, что загруженный текстовый файл — это скрипт, и выполнить его. Атака называется MIME sniffing.

X-Frame-Options: DENY запрещает встраивать страницу в <iframe>. Защищает от clickjacking — когда злоумышленник накладывает прозрачный iframe поверх своего сайта и перехватывает клики пользователя:

// запрет для всех
context.Response.Headers.Add("X-Frame-Options", "DENY");

// или разрешить только своему домену
context.Response.Headers.Add("X-Frame-Options", "SAMEORIGIN");

X-XSS-Protection: 1; mode=block включает встроенный XSS-фильтр в старых браузерах. Если атака обнаружена — страница блокируется целиком, а не фильтруется частично. Современные браузеры опираются на Content-Security-Policy, а этот заголовок оставлен для совместимости со старыми версиями IE и Edge.

Что добавить ещё

Три заголовка выше это минимум. Для полноценной защиты стоит также настроить:

Content-Security-Policy — белый список источников скриптов, стилей и медиа. Самый мощный инструмент против XSS:

context.Response.Headers.Add(
    "Content-Security-Policy",
    "default-src 'self'; script-src 'self'; style-src 'self'"
);

Referrer-Policy — контролирует, какой URL браузер передаёт при переходе с вашей страницы:

context.Response.Headers.Add("Referrer-Policy", "strict-origin-when-cross-origin");

Permissions-Policy — ограничивает доступ к браузерным API: камера, микрофон, геолокация:

context.Response.Headers.Add(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
);

Проверка

После деплоя проверить заголовки можно на securityheaders.com — сервис покажет, что выставлено, что отсутствует и насколько это критично. Или через DevTools: вкладка Network, любой запрос, раздел Response Headers.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

👨‍💻 Singleton vs Service Locator в Unity

Когда проект перерастает пару сцен, рано или поздно встаёт вопрос: как организовать доступ к общим сервисам: звуку, аналитике, данным игрока?

Два самых распространённых ответа это Singleton и Service Locator. Разберём, чем они отличаются и когда какой уместен.

Singleton

Паттерн знаком почти каждому Unity-разработчику. Один экземпляр класса на всё приложение, доступный из любой точки кода:

public class AudioManager : MonoBehaviour
{
    public static AudioManager Instance { get; private set; }

    private void Awake()
    {
        if (Instance != null)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void PlaySound(AudioClip clip) { /* ... */ }
}

Плюсы:

+ Просто реализовать
+ Мгновенный доступ без регистрации
+ Подходит для небольших проектов

Минусы:

- Жёсткая связность: классы напрямую зависят от конкретной реализации
- Тестировать сложно — нельзя подменить AudioManager на заглушку
- При разрастании проекта Instance начинают тянуть отовсюду, и следить за зависимостями становится тяжело

Service Locator

Service Locator это реестр сервисов. Вместо того чтобы обращаться к конкретному классу, код запрашивает нужный интерфейс у локатора.

Сначала создаём интерфейс:

public interface IAudioService
{
    void PlaySound(AudioClip clip);
}

Реализация сервиса:

public class AudioManager : MonoBehaviour, IAudioService
{
    public void PlaySound(AudioClip clip) { /* ... */ }
}

Сам локатор:

public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> services = new();

    public static void Register<T>(T service)
    {
        services[typeof(T)] = service;
    }

    public static T Get<T>()
    {
        if (services.TryGetValue(typeof(T), out var service))
            return (T)service;

        throw new Exception($"Сервис {typeof(T)} не зарегистрирован");
    }
}

Плюсы:

+ Код зависит от интерфейса, а не от реализации
+ Легко подменить сервис на заглушку в тестах
+ Зависимости явно регистрируются в одном месте

Минусы:

- Если забыть зарегистрировать сервис, то получим исключение в рантайме, а не ошибку компиляции
- Чуть больше кода на старте
- Без дисциплины реестр может превратиться в свалку

Когда что выбирать

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

Service Locator стоит рассмотреть, когда проект планируется развивать: появляются юнит-тесты, несколько платформ, команда из нескольких человек. Возможность подменить реализацию без изменения потребителей сервиса окупается уже при первом рефакторинге.

Оба паттерна решают одну задачу — глобальный доступ к сервисам. Разница в том, насколько легко потом менять и тестировать код.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

❓ Что выведет код с картинки

💡 Подсказка: обратите внимание на конструкцию when. Это не просто синтаксический сахар.

➡️ А ответ тут

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#dotnet_challenge

👀 Смотрим внутрь любой .NET-сборки

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

ILSpy решает эту задачу это открытый декомпилятор .NET-сборок, который превращает IL-байткод обратно в читаемый C#.

ILSpy открывает любой .dll или .exe и показывает декомпилированный C#-код с навигацией по типам, методам и свойствам. Поддерживает поиск по всей сборке, переходы по гиперссылкам между типами и историю навигации.

Visual Studio 2022 и 2026 используют движок ILSpy внутри для F12-навигации по декомпилированным источникам, так что если вы нажимали «Go to Definition» на тип из NuGet-пакета, вы уже работали с ILSpy.

CLI-инструмент для Linux, Mac и Windows:

dotnet tool install -g ilspycmd

После установки можно декомпилировать прямо из терминала:

ilspycmd MyLibrary.dll

Использование как библиотеки

Движок декомпилятора доступен отдельным NuGet-пакетом ICSharpCode.Decompiler. Его можно встроить в собственные инструменты:

var decompiler = new CSharpDecompiler("MyLibrary.dll", new DecompilerSettings());
var code = decompiler.DecompileWholeModuleAsString();
Console.WriteLine(code);

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

👨‍💻 Не показывайте технические ошибки пользователям

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

Что происходит на практике

Допустим, в ASP.NET приложении возникает необработанное исключение. Без явной настройки middleware фреймворк вернёт подробный ExceptionDetails с именем метода, строкой кода и трассировкой стека. Атакующий получает информацию о структуре проекта, версиях библиотек и логике работы приложения без каких-либо усилий.

Как это закрыть

Правильный подход это перехват всех необработанныъ исключений. Нужно логировать их внутри системы и возвращать пользователю только нейтральное сообщение.

В ASP.NET это делается через UseExceptionHandler:

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionHandlerPathFeature =
            context.Features.Get<IExceptionHandlerPathFeature>();

        var logger = context.RequestServices
            .GetRequiredService<ILogger<Program>>();

        logger.LogError(exceptionHandlerPathFeature?.Error,
            "Unhandled exception");

        context.Response.StatusCode = 500;

        await context.Response.WriteAsJsonAsync(new
        {
            message = "Something went wrong. Please try again later."
        });
    });
});

Что здесь происходит: middleware перехватывает исключение, передаёт его в ILogger — туда, где его увидит только команда разработки — и возвращает клиенту простой JSON с универсальным сообщением об ошибке. Никаких деталей реализации наружу не уходит.

ILogger пишет в вашу систему мониторинга — будь то Application Insights, Seq, Serilog или любой другой инструмент. Вы по-прежнему видите полный стек вызовов и можете разобраться в причине ошибки. Пользователь при этом получает понятное сообщение, а не технический мусор.

Это базовая практика защиты приложений. Она не требует сложной архитектуры, достаточно одного middleware, настроенного в точке входа приложения.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector

🦾 Надоело чинить «упавших» ИИ-агентов после каждого микросбоя внешних сервисов?

Анонсируем старт продаж большого курса по AgentOps. Мы собрали опыт десятков разработчиков и сделали программу, которая учит выводить ИИ в стабильный прод.

🗓 Ждем вас 28 апреля в 19:00 МСК на эфире: «Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены».

👉 Кто вещает и в чем польза?

Спикер Кирилл Кухарев (Senior AI Engineer в Raft, спикер AI Conf и Highload++). Он реализовал более 50 коммерческих проектов в GenAI и на вебинаре покажет, как взять под контроль работу нескольких агентов, чтобы они не перекидывали друг другу лишний контекст и не сжигали ваши деньги.

В прямом эфире разберем:
• Как формируется контекст в LLM при маршрутизации между агентами;
• Куда утекают лишние токены и возникает перерасход;
• Практические методы: как сжимать историю, грамотно делить задачи, лимитировать передачу контекста и собирать промпты прямо в процессе запроса пользователя.

🔥 Два способа получить максимум:

1. Приходите на вебинар 28 апреля. Дарим участникам промокод на 5.000 ₽ (работает 3 дня после эфира - это шанс забрать курс по самому низу рынка).

2. Выбирайте Инженерный трек. В подарок к нему идет полный доступ к записям и автопроверкам завершенного курса «Разработка ИИ-агентов».

👉 Занять место на вебинаре и стать профи в AgentOps

🔍 ILSpy 10.0: поддержка C# 14, API diff и переход на .NET 10

Вышел крупный релиз ILSpy. Релиз собран на .NET 10, так что перед обновлением убедитесь, что он у вас установлен.

Новые языковые возможности

Декомпилятор теперь понимает конструкции C# 13 и C# 14. Добавлена поддержка ограничения allows ref struct из C# 13 и extension-членов из C# 14. Также подтянули поддержку InlineArray из C# 12 — на удивление поздно, но лучше поздно чем никогда. Детекция паттернов обновлена до Roslyn 5.0 RTM.

Новое в интерфейсе

Появился выделенный UI для работы с C# 14 extension-членами. Добавлена навигация по видимой истории — теперь можно перемещаться по посещённым узлам в дереве сборок. Из поставки убрали переводы интерфейса — проект сосредоточился на английском.

API diff

Одна из самых интересных новинок. ILSpy теперь умеет сравнивать публичное API двух сборок и показывать разницу. Полезно при анализе изменений между версиями библиотек, когда исходников нет.

Улучшения декомпилятора

Исправлена корректная декомпиляция pre-increment операторов, unmanaged function pointers и локальных функций с параметрами по умолчанию. Улучшено определение record-типов и primary constructors. CSharpConversions получил общие улучшения для правил C# вплоть до версии 9. Дизассемблер теперь поддерживает формат ildasm /caverbal.

Пакетная генерация PDB

Новый метод GeneratePdbForAssemblies заменил старый GeneratePdbForAssembly — теперь можно генерировать PDB для нескольких сборок за один вызов.

Чистка API

Удалены устаревшие типы: UnresolvedUsingScope, ToTypeReference, ITypeReference. ResolvedUsingScope переименован в UsingScope. Если вы используете ICSharpCode.Decompiler как NuGet-пакет в своих инструментах — стоит проверить совместимость.

Производительность

Убрана XML-сериализация из DecompilerSettings — настройки теперь сохраняются быстрее.

Важное предупреждение

Команда отдельно предупреждает: домен ilspy.org им не принадлежит. Скачивать ILSpy нужно только с GitHub Releases.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

📰 Новостной дайджест

Свежая газетка у вас на пороге

— Хирургия над контекстным меню Windows 11

— Фриланс для разработчиков

— Не фриланс для разработчиков

— .NET 11 Preview 3

— Обновления безопасности 2026 .NET

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

🤩 Фоновые задачи без лишних зависимостей

Если вы запускаете фоновые задачи через Task.Run или городите велосипед поверх IHostedService, знакомьтесь с BusyBee. Это небольшая библиотека для in-memory обработки фоновых задач в .NET, которая построена на нативных каналах (System.Threading.Channels).

Какую проблему решает

Хочется просто поставить задачу в очередь и не думать об управлении потоками, таймаутах и наблюдаемости. Стандартные средства .NET это умеют, но требуют немало бойлерплейта. Hangfire или Quartz — тяжеловато, если нужно только in-memory без персистентности.

Что умеет BusyBee

Ограниченные и неограниченные очереди с настройкой поведения при переполнении: можно выбросить исключение, подождать, отбросить самую старую или новую задачу. Параллельное выполнение задач с настраиваемым пулом слотов. Глобальные и per-job таймауты. Интеграция с OpenTelemetry для трассировки и метрик. Полная поддержка DI и CancellationToken.

Как подключить:

dotnet add package BusyBee

Регистрация в DI:

builder.Services
    .AddBusyBee()
    .WithUnboundedQueue()
    .WithGlobalJobTimeout(TimeSpan.FromSeconds(30))
    .WithLevelOfParallelism(10);

Поставить задачу в очередь:

await queue.Enqueue(async (services, context, cancellationToken) =>
{
    var logger = services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Обрабатываем задачу {JobId}", context.JobId);
    await Task.Delay(1000, cancellationToken);
}, cancellationToken);

Каждая задача получает контекст с JobId, временем постановки в очередь и временем старта. Через services доступны любые зарегистрированные сервисы.

Ограниченная очередь:

builder.Services
    .AddBusyBee()
    .WithBoundedQueue(capacity: 1000, OverflowStrategy.DropOldest);

Подключение OpenTelemetry:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource(BusyBee.Observability.TracingConstants.TraceSourceName)
        .AddConsoleExporter())
    .WithMetrics(metrics => metrics
        .AddMeter(BusyBee.Observability.MetricsConstants.MeterName)
        .AddPrometheusExporter());

Обработка ошибок

Можно подключить собственные обработчики для сбоев, таймаутов и ручной отмены задач через реализацию интерфейсов IJobFailureHandler, IJobTimeoutHandler и IManualCancellationHandler:

services.AddBusyBee()
    .WithJobFailureHandler<MyCustomJobFailureHandler>();

BusyBee подойдёт, когда нужен простой in-memory обработчик в фоне без внешних зависимостей и баз данных.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

✏️ Паттерн репозиторий: неочевидные моменты

Репозиторий скрывает логику работы с данными за интерфейсом. Контроллер или сервис не знает, откуда берётся объект: из базы, кеша или файла. Это удобно, но у паттерна есть нюансы, о которых редко говорят.

Зачем он вообще нужен

Без репозитория бизнес-логика тесно связана с DbContext. Тесты требуют реальной базы или громоздких моков. При смене ORM надо переписывать половину приложения.

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

Неочевидный момент 1: SaveChanges внутри репозитория

Если вызывать SaveChangesAsync() в каждом методе репозитория, теряется возможность атомарно сохранить несколько операций. Например, создать пользователя и сразу выдать ему роль в одной транзакции не получится.

Решение: убрать SaveChanges из репозитория и перенести его в Unit of Work или вызывать явно на уровне сервиса.

public interface IUnitOfWork : IDisposable
{
    IUserRepository Users { get; }
    IRoleRepository Roles { get; }
    Task<int> SaveChangesAsync();
}

public class UnitOfWork : IUnitOfWork
{
    private readonly AppDbContext _context;

    public IUserRepository Users { get; }
    public IRoleRepository Roles { get; }

    public UnitOfWork(AppDbContext context)
    {
        _context = context;
        Users = new UserRepository(context);
        Roles = new RoleRepository(context);
    }

    public async Task<int> SaveChangesAsync()
        => await _context.SaveChangesAsync();

    public void Dispose() => _context.Dispose();
}

Неочевидный момент 2: Generic-репозиторий не всегда помогает

Соблазн велик написать один GenericRepository<T> и использовать везде:

public class GenericRepository<T> : IRepository<T> where T : class
{
    protected readonly AppDbContext _context;
    protected readonly DbSet<T> _dbSet;

    public GenericRepository(AppDbContext context)
    {
        _context = context;
        _dbSet = context.Set<T>();
    }

    public async Task<T?> GetByIdAsync(int id) => await _dbSet.FindAsync(id);
    public async Task<IEnumerable<T>> GetAllAsync() => await _dbSet.ToListAsync();
    public async Task AddAsync(T entity) => await _dbSet.AddAsync(entity);
    public void Update(T entity) => _dbSet.Update(entity);
    public void Delete(T entity) => _dbSet.Remove(entity);
}

Проблема в том, что специфичные запросы всё равно придётся добавлять. Найти пользователя по почте через универсальный метод не выйдет без дополнительных расширений. В итоге generic-репозиторий обрастает методами и теряет смысл.

Лучше наследовать от него там, где действительно нет специфики, а сложные сущности описывать отдельными интерфейсами:

public interface IUserRepository : IRepository<User>
{
    Task<User?> GetByEmailAsync(string email);
    Task<IEnumerable<User>> GetActiveUsersAsync();
}

public class UserRepository : GenericRepository<User>, IUserRepository
{
    public UserRepository(AppDbContext context) : base(context) { }

    public async Task<User?> GetByEmailAsync(string email)
        => await _dbSet.FirstOrDefaultAsync(u => u.Email == email);

    public async Task<IEnumerable<User>> GetActiveUsersAsync()
        => await _dbSet.Where(u => u.IsActive).ToListAsync();
}

Неочевидный момент 3: EF Core уже репозиторий

DbContext и DbSet<T> это и есть реализация паттерна репозиторий. DbSet — коллекция объектов, DbContext — Unit of Work. Оборачивать EF Core в ещё один слой репозитория иногда только добавляет лишний код.

Это оправдано, когда нужно:
- тестировать бизнес-логику без базы (мок интерфейса проще, чем мок DbContext)
- поддерживать несколько источников данных
- изолировать слои приложения архитектурно

Если проект небольшой и планов менять ORM нет, прямое использование DbContext в сервисах может быть вполне нормальным решением.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

⚡️ Мы рады представить команду экспертов курса AgentOps!

— Дмитрий Антипов расскажет, как грамотно проверить работу AI-моделей
— Курилл Кухарев поделится, почему компаниям выгодно использовать локальные модели и как их развернуть
— Андрей Носов расскажет, как работать с данными и знаниями в AI-системах: построение RAG, выбор подходов к поиску и организация хранения данных
— Антон Будняк разберет, как обеспечить устойчивость сервиса, в котором используется ИИ
— Александр Ошурков расскажет, как оценивать качество работы LLM в backend-сервисах
— Екатерина Трофимов разберет, как проектировать инструменты для AI-агентов и выстраивать взаимодействие с внешними сервисами

Курс для backend-разработчиков, тимлидов и LLM инженеров о том, как внедрять AI-логику в бэкенд IT-продуктов и сохранять стабильность сервиса.

К концу обучения вы получите:

• Структурированный подход к архитектуре и деплою AI-агентов
• Навыки настройки мониторинга, тестирования и контроля расходов на токены
• Разбор сложных инженерных кейсов из реальной практики

🎁 Доступ к материалам курса «Разработка ИИ-агентов» в подарок при покупке Инженерного трека

👉 Все подробности и программа обучения.

🧑‍💻 Больше не нужно открывать терминал от администратора

На Linux и macOS всё просто: нужны права администратора, добавили sudo перед командой. На Windows для этого приходилось открывать новый терминал от имени администратора, делать правый клик, подтверждать UAC. Microsoft наконец добавила sudo в Windows 11 нативно, начиная со сборки 26045.

Что это такое

Sudo for Windows позволяет запускать команды с правами администратора прямо из обычного терминала, без переоткрытия сессии. Это не порт Unix-утилиты, а отдельная Windows-реализация той же идеи. Некоторые детали поведения отличаются от привычного sudo на Linux.

Как включить

Через настройки: Параметры → Система → Для разработчиков → Включить sudo.

Или через командную строку с правами администратора:

sudo config --enable normal

Три режима работы

forceNewWindow — режим по умолчанию. Команда запускается в новом окне с правами администратора. Похоже на runas, но удобнее.

disableInput — команда выполняется в текущем окне, но без возможности ввода. Подходит для автоматических задач, где интерактивный ввод не нужен.

normal — полный инлайн-режим, как на Linux. Команда запускается в текущем окне и может принимать ввод. Наиболее удобный вариант, но несёт больше рисков безопасности.

Переключение между режимами:

sudo config --enable forceNewWindow
sudo config --enable disableInput
sudo config --enable normal

Примеры использования

Редактирование системного файла:

sudo notepad C:\Windows\System32\drivers\etc\hosts

Установка глобального npm-пакета:

sudo npm install -g package-name

Проверка сетевых соединений:

sudo netstat -ab

Про безопасность

При запуске через sudo появляется UAC-запрос на подтверждение. Режимы disableInput и normal несут дополнительные риски: нежелательный процесс с низкими правами теоретически может взаимодействовать с повышенным процессом. Для большинства сценариев рекомендован forceNewWindow.

Что нужно учесть

Инструмент доступен только на Windows 11, начиная с версии 24H2. Управлять им можно через настройки, командную строку или реестр (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Sudo). Есть и GPO-политика для корпоративного управления.

➡️ Репозиторий

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view