.NET Разработчик

Public

Не можете присоединиться? @NetDeveloperDiary

6.7k Участники

Обновлено: May 16, 2026 at 2:37 PM

.NET Разработчик

Дневник сертифицированного .NET разработчика. Заметки, советы, новости из мира .NET и C#. Для связи: @SBenzenko Поддержать канал: - https://boosty.to/netdeveloperdiary - https://patreon.com/user?u=52551826 - https://pay.cloudtips.ru/p/70df3b3b

@NetDeveloperDiary offers specialized information about httpsboostytonetdeveloperdiary and sbenzenko for subscribers interested in Техноновости

Рейтинг

Глобальный рейтинг

#456

Рейтинг по языку

#45

Рейтинг по категории

#23

-1

Рост участников (Последние 6 дней)

Всего: 6.7K

Рост за 24ч: +0 0%

Последние посты

.NET Разработчик

21 мая 2026 г., 07:07

День 2658. #Карьера
Дорожная Карта . NET Разработчика в 2026. Начало
Чтобы стать успешным . NET разработчиком, не нужно запоминать фреймворки или гнаться за каждым новым релизом. Необходимо сформировать прочные базовые знания, выбрать правильную специализацию и постепенно развиваться до уровня, позволяющего проектировать, создавать и поддерживать готовые к производству системы. Эта дорожная карта призвана помочь вам уверенно продвигаться вперёд, независимо от того, начинаете ли вы свой путь или уже работаете в экосистеме . NET.

I. Основы (обязательно)
Перед специализацией каждый . NET-разработчик должен освоить общий набор фундаментальных принципов. Их пропуск приводит к хрупкости знаний и медленному карьерному росту.

1. Основы разработки
- Как работает веб (запросы, ответы, методы HTTP);
- Базовые концепции работы с сетью;
- Принципы чистого кода и ООП;
- Системы контроля версий Git (ветвления, коммиты, пул-реквесты).
Эти навыки применимы везде, а не только в . NET.

2. Основы . NET и C#
- Современный синтаксис и особенности языка C#;
- Концепции среды выполнения . NET;
- Использование CLI для сборки и запуска проектов;
- Уверенная работа в IDE (Visual Studio, VS Code, Rider).
Не спешите с этим шагом. Прочные основы здесь окупятся на долгие годы.

3. Создание первого бэкенда
- Создание простого веб-API;
- Понимание маршрутизации, контроллеров и внедрения зависимостей;
- Подключение к реляционной БД;
- Выполнение базовых CRUD-операций;
- Использование ORM и понимание, что происходит «под капотом».
Цель — не совершенство, а уверенность.

4. ИИ как помощник в программировании
Инструменты ИИ могут ускорить повторяющиеся задачи, предложить решения и помочь быстро исследовать новые паттерны. Разбирайте генерируемый код, проверяйте его и интегрируйте продуманно. Думайте об ИИ как о помощнике, который повышает производительность, а не о чём-то, что пишет код за вас. Чем прочнее ваши базовые знания, тем эффективнее вы сможете использовать ИИ, не теряя контроля. Используйте ИИ для:
- Изучения идей;
- Повышения продуктивности;
- Быстрого выявления закономерностей.

II. Выбор направления
Настало время специализации. Не нужно изучать всё, нужно изучать то, что соответствует вашим целям.

1. Путь бэкенд-разработчика
Работа с API, данными, производительностью и масштабируемостью.
Ключевые навыки:
- Проектирование API и лучшие практики;
- Аутентификация и авторизация;
- Обработка ошибок и логирование;
- Валидация и чистая архитектура;
- Кэширование и оптимизация производительности;
- Фоновая обработка;
- Модульное и интеграционное тестирование.
Бэкенд-разработчики отвечают за надёжность и корректность — здесь глубина знаний важнее широты.

2. Путь Blazor-разработчика
Создание интерактивных веб-приложений на C#.
Ключевые навыки:
- Разработка компонентного UI;
- Маршрутизация и проектирование компоновки;
- Обработка и валидация форм;
- Стратегии управления состоянием;
- Фреймворки и стилизация UI;
- Основы JavaScript-интеропа;
- Тестирование компонентов UI.
Этот путь хорошо подходит для корпоративных приложений, панелей мониторинга и внутренних инструментов.

3. Путь фулстек-разработчика
Объединение бэкенд API с фронтенд-приложениями.
Ключевые навыки:
- Проектирование API;
- Создание UI, использующего API;
- Обработка сквозной аутентификации;
- Управление общими моделями и контрактами;
- Понимание как производительности, так и пользовательского опыта.
Этот путь требует баланса — не поверхностных знаний, а универсальности.

Окончание следует…

Источник: https://www.c-sharpcorner.com/article/a-practical-net-developer-roadmap-for-2026/

1,370

.NET Разработчик

21 мая 2026 г., 07:07

День 2657. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

33. Разработка веб-API
«Расскажите, как бы вы спроектировали и реализовали веб-API, используя возможности минимальных API? Опишите шаги, необходимые для создания минимального API, и как это упрощает разработку API по сравнению с более ранними версиями Web API».

Хороший ответ
Минимальные API обеспечивают упрощённый подход к созданию высокопроизводительных, легковесных HTTP API. Вот как я бы спроектировал и реализовал минимальный API.

1. Создать новый проект Web API можно с помощью команды: dotnet new webapi

2. В Program.cs создадим нужные конечные точки. Минимальные API используют лямбда-выражения для обработки запросов непосредственно в коде, что упрощает маршрутизацию и настройку контроллера:
var builder = WebApplication. CreateBuilder(args);
var app = builder. Build();

app. MapGet("/products", async (AppDbContext db) =>
await db. Products. ToListAsync());

app. MapGet("/products/{id}",
async (int id, AppDbContext db) =>
await db. Products. FindAsync(id) is Product product ?
Results. Ok(product) : Results. NotFound());

app. MapPost("/products",
async (Product product, AppDbContext db) =>
{
db. Products. Add(product);
await db. SaveChangesAsync();
return Results. Created($"/products/{product. Id}", product);
});

//…

app. MapDelete("/products/{id}",
async (int id, AppDbContext db) =>
{
if (await db. Products. FindAsync(id) is Product product)
{
db. Products. Remove(product);
await db. SaveChangesAsync();
return Results. Ok(product);
}
return Results. NotFound();
});

app. Run();

3. Настроим необходимые сервисы, такие как контекст БД, в настройках конструктора:
builder. Services. AddDbContext(opts =>
opts. UseSqlServer(builder. Configuration
. GetConnectionString("DefaultConnection")));

4. Тестировать API можно с помощью Postman или Swagger. . NET поддерживает Swagger по умолчанию:
builder. Services. AddEndpointsApiExplorer();
builder. Services. AddSwaggerGen();

Преимущества минимальных API
- Уменьшение шаблонного кода: устраняет необходимость в отдельных контроллерах, делая кодовую базу проще и меньше.
- Простота использования: упрощает настройку маршрутизации, облегчая создание и управление API.
- Производительность: предлагает легковесную альтернативу традиционным MVC-архитектурам, потенциально повышая производительность. Проекты минимальных API могут быть скомпилированы с использованием нативного AOT для ещё большей производительности.
Этот подход использует новейшие возможности . NET для эффективного создания API, фокусируясь на простоте и производительности.

Часто встречающийся плохой ответ
«Минимальные API подходят только для тестов и самых простых проектов и не предлагают ничего такого, чего не могли бы сделать контроллеры. Лучше придерживаться стандартного шаблона MVC».

Почему это неверно
- Сопротивление новым функциям: этот ответ демонстрирует сопротивление внедрению новых фреймворков и улучшений в технологиях. Минимальные API были введены для упрощения и ускорения разработки простых API, и они специально разработаны для улучшения опыта разработчиков и производительности в подходящих сценариях.

- Непонимание сценария использования: в ответе не учитывается, что минимальные API идеально подходят для приложений, которые не требуют полной структуры MVC, особенно для микросервисов или простых CRUD-операций.

- Отсутствие гибкости: ответ указывает на отсутствие гибкости в применении новых методов, которые могут обеспечить повышение эффективности в конкретных сценариях использования.

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

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

.NET Разработчик

21 мая 2026 г., 07:07

День 2655. #ЧтоНовенького
Атрибут ConfigurationIgnore в . NET 11
В Microsoft. Extensions. Configuration атрибут ConfigurationKeyNameAttribute существует с . NET 6 и позволяет переименовывать ключ, к которому привязано свойство. Но официального способа указать «не привязывать это свойство вообще» никогда не было. Этот пробел наконец-то устранён в . NET 11 с помощью ConfigurationIgnoreAttribute.

Проблема
Допустим, у вас есть класс параметров, который выглядит примерно так:
public class CsvIngestionOptions
{
// Вычисляется после загрузки – НЕ должен идти из конфигурации
public CsvFormatOptions DefaultFormat { get; set; }

// Раздел конфигурации, который мы привязываем и обрабатываем
public IConfigurationSection? DefaultFormatSection { get; set; }

// Вызывается после загрузки конфигурации, чтобы применить постобработку и значения по умолчанию
internal void OnConfigurationLoaded()
{
DefaultFormat = new CsvFormatOptions();
DefaultFormatSection?. Bind(DefaultFormat);
DefaultFormat. EnsureEncodingDefined();
}
}
DefaultFormat извлекается из DefaultFormatSection после некоторой постобработки. Его никогда не следует заполнять напрямую связывателем. Но поскольку у него есть публичные геттер и сеттер, система конфигурации пытается его связать.

Единственным обходным путём до . NET 11 было злоупотребление ConfigurationKeyNameAttribute с намеренно некорректным ключом:
// Костыль
[ConfigurationKeyName("__ignored_" + nameof(DefaultFormat))]
public CsvFormatOptions DefaultFormat { get; set; }
Это ненадёжно, вводит в заблуждение и создаёт странный код в вашей схеме конфигурации.

Решение
. NET 11 добавляет специальный атрибут ConfigurationIgnoreAttribute в Microsoft. Extensions. Configuration. Просто добавляем атрибут к тому свойству, которое не должно быть привязано:
public class CsvIngestionOptions
{
[ConfigurationIgnore]
public CsvFormatOptions DefaultFormat { get; set; }

[ConfigurationKeyName(nameof(DefaultFormat))]
public IConfigurationSection? DefaultFormatSection { get; set; }
// …
}

Ещё один распространённый сценарий
Постобработка — наиболее очевидный, но не единственный вариант использования. Ещё один классический пример — парсинг исходного значения:
public class FeatureFlags
{
public string RawFlags { get; set; } = string. Empty;

[ConfigurationIgnore]
public IReadOnlyDictionary
ParsedFlags { get; set; }
= new Dictionary();
}

Можно ли просто использовать [JsonIgnore]?
Нет, в этом и проблема. System. Text. Json. Serialization. JsonIgnoreAttribute не влияет на связыватель конфигурации.

Замечание: начиная с . NET 9, связыватель уже пропускает свойства только для чтения (только-get/только-init при отсутствии соответствующего раздела). Предлагаемый здесь атрибут предназначен для свойств, доступных для записи, которые могут быть связаны, но не должны быть связаны.

См. также https://github.com/dotnet/runtime/issues/125111.

Источник: https://steven-giesel.com/blogPost/18a61100-6074-43ac-86ae-573ad66a2c8a/configurationignoreattribute-in-net-11

.NET Разработчик

21 мая 2026 г., 07:07

📷 Photo

День 2656. #SystemDesign101
Data Warehouse, Data Lake или Data Mesh
Хранение данных — это просто. Настоящая проблема — решить, где и как их организовать.

Хранилище данных (Data Warehouse) — это традиционный подход. Очищает и структурирует данные перед их сохранением. Запросы выполняются быстро, а отчёты остаются согласованными. Но добавление нового источника данных требует усилий, поскольку всё должно сначала соответствовать схеме.

Озеро данных (Data Lake) использует противоположный подход. Хранит все данные в необработанном виде, например, базы данных, журналы, изображения и видео. Обрабатывает их по мере необходимости. Гибкость — это здорово, но, если правила именования, форматирования и владения данными не установлены должным образом, вы получите дублирующиеся, устаревшие и недокументированные данные, которыми трудно управлять.

Сетка данных (Data Mesh) переносит владение данными от центральной команды к отдельным подразделениям. Например, отдел продаж публикует данные о продажах, а финансовый отдел — финансовые данные. Общие стандарты обеспечивают совместимость между командами.
Это хорошо работает в крупных организациях. Но для этого каждой команде необходимы подходящие люди и процессы для управления качеством данных, документацией и доступом к ним, что является непростой задачей.

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

Источник: https://bytebytego.com/

.NET Разработчик

21 мая 2026 г., 07:07

День 2654. #Оффтоп
История Архитектур Приложений в . NET. Окончание


Современные архитектурные стили
Чистая/Луковая/Гексагональная архитектура. Это вариации одной идеи: инвертирование направления зависимостей, чтобы доменная/бизнес-логика находилась в центре, без зависимостей от инфраструктуры. Инфраструктура (БД, файловая система, внешние API) зависит от домена через абстракции (интерфейсы), а не наоборот. Это вытеснило наивный многоуровневый подход, поскольку делает бизнес-логику действительно тестируемой и заменяемой. Чистая архитектура (популяризированная Робертом Мартином и в . NET шаблоном Джейсона Тейлора) — вероятно, самая распространённая «серьёзная» архитектура для приложений . NET сегодня.

. Разделяет операции чтения (запросы) и записи (команды). Часто используется в сочетании с MediatR в . NET. Добавляет сложности, поэтому лучше всего подходит для областей, где шаблоны чтения и записи значительно различаются.

. Вместо хранения текущего состояния вы храните последовательность событий, которые привели к текущему состоянию. Часто используется в сочетании с CQRS. Мощный инструмент для журналов аудита и сложных доменов, но значительно усложняет систему. Это нишевый шаблон — ценный, когда он необходим, избыточный, когда нет.

Микросервисы. Разделение приложения на независимо развёртываемые сервисы, каждый из которых владеет собственными данными. В . NET имеет сильную поддержку благодаря http://ASP.NET/ Core, Docker, Kubernetes и . NET Aspire. Микросервисы вытеснили монолиты для больших команд и сложных областей, но наблюдается заметное движение против них, признающее, что микросервисы вносят сложность распределённых систем (сбои сети, конечная согласованность, операционные накладные расходы), с которой многие команды не готовы справиться.

. Это набирающая популярность «разумная золотая середина» — единая развёртываемая система, внутренне организованная в чётко ограниченные модули с ясными интерфейсами между ними. Вы получаете большинство организационных преимуществ микросервисов без проблем распределённых систем. Если позже потребуется выделить модуль в отдельный сервис, границы уже будут четко определены.

Шаблоны для настольных/клиентских приложений
Windows Forms (WinForms) — всё ещё поддерживается, все ещё используется, но в значительной степени считается устаревшим фреймворком для новой разработки. Имеет событийно-ориентированный, тесно связанный код пользовательского интерфейса.

WPF. Более современный фреймворк для настольных приложений с MVVM, привязкой данных и XAML. Всё ещё активно поддерживается и используется для сложных настольных приложений.

Xamarin → . NET MAUI — кроссплатформенное мобильное/настольное приложение. Xamarin снят с поддержки; MAUI — его преемник, использующий шаблон MVVM.

. Новейший фреймворк, позволяющий писать интерактивный веб-интерфейс на C# вместо JavaScript. Доступен в серверной (на основе SignalR) и WebAssembly версиях. Не заменяет все фронтенд-фреймворки, но привлекателен для команд, которые хотят оставаться в C#.

Итого: что на что заменено
Веб-интерфейс: Веб-формы → MVC → Razor Pages/минимальные API.
Сервисы: WCF → Web API → gRPC.
Структура проекта: Многоуровневая архитектура → Чистая архитектура.
Топология развёртывания: Монолит → Микросервисы → Модульный монолит.

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

Источник: https://todayamerican.medium.com/net-c-application-architecture-over-time-7218f0470a02

.NET Разработчик

21 мая 2026 г., 07:07

День 2652. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 8

8. https://www.querypie.com/ (совместная работа с SQL + оптимизация)
Что даёт: Совместная работа команды над оптимизацией запросов со встроенным анализом производительности.
Тип: Коммерческий (доступен бесплатный уровень)
Базы данных: Postgres, MySQL, Redshift, BigQuery, Snowflake

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

Как работает
Пишете запрос в IDE QueryPie -> Автоматически запускается EXPLAIN ANALYZE -> Отображаются показатели производительности -> Делитесь запросом с командой по ссылке -> Члены команды предлагают варианты оптимизации -> A/B-сравнение версий запроса -> Лучшая версия продвигается в прод.

Пример рабочего процесса
1. Аналитик данных пишет запрос (QueryPie IDE)
SELECT
c.customer_name,
SUM(o.total) as revenue
FROM customers c
LEFT JOIN orders o ON c.id = o.customer_id
WHERE c.country = 'US'
GROUP BY c.customer_name
ORDER BY revenue DESC
LIMIT 100;
2. Вывод QueryPie:
Execution time: 23.4s
Rows scanned: 5.2M
Cost: $0.45 (Вымышленная валюта)
Warning: LEFT JOIN inefficient (NULL handling overhead)
3. Разработчик нажимает "Предложить оптимизацию". ИИ QueryPie предлагает:
SELECT
c.customer_name,
SUM(o.total) as revenue
FROM customers c
INNER JOIN orders o ON c.id = o.customer_id -- Добавить INNER
WHERE c.country = 'US'
AND o.total IS NOT NULL -- Добавить фильтр
GROUP BY c.customer_name
ORDER BY revenue DESC
LIMIT 100;
4. Новые метрики:
Execution time: 1.2s (19x faster)
Rows scanned: 234K (22x less)
Cost: $0.02 (22x cheaper)
5. Показывается сравнение результатов.
6. При нажатии кнопки «Принять оптимизацию» исходный запрос помечается как устаревший, команда уведомляется об улучшении.

Когда использовать
- Несколько человек пишут SQL-запросы;
- Требуется совместная оптимизация;
- Необходимо версионирование запросов;
- Предпочитаете веб-IDE локальным инструментам.

Когда отказаться
- Разработчик-одиночка (функции совместной работы не используются);
- Довольны текущей IDE (pgAdmin, DBeaver и т. д.);
- Очень ограниченный бюджет ($15-50 на пользователя в месяц).

Скрытая функция
Автоматическое обнаружение регрессии производительности запросов. QueryPie отслеживает каждое выполнение запроса и может предоставлять динамику производительности запроса во времени и рекомендации по улучшению.

С осторожностью
QueryPie хранит результаты запросов. Соображения конфиденциальности:
- Запросы выполняются через прокси QueryPie;
- Результаты кэшируются для обмена;
- Может содержать конфиденциальные данные.

Конфигурация:
- Установить политику хранения данных (по умолчанию 7 дней);
- Исключить столбцы с персональными данными из кэширования;
- Использовать локальное развёртывание для конфиденциальных данных;
- Перед развёртыванием командой проверить политики безопасности.

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

.NET Разработчик

21 мая 2026 г., 07:07

День 2653. #Оффтоп
История Архитектур Приложений в . NET. Начало

Ранние годы
Классический ASP / «Спагетти-код» (конец 1990-х). До появления . NET веб-приложения Microsoft создавались с помощью классического ASP — скриптового языка VBScript, смешанного с HTML. Реальной архитектуры не было; бизнес-логика, доступ к данным и представления были переплетены между собой. От этого отказались, потому что это было неподдерживаемо, нетестируемо и немасштабируемо.

Web Forms (2002–~2012). http://ASP.NET/ Web Forms был первым крупным веб-фреймворком . NET от Microsoft. Он пытался сделать веб-разработку похожей на разработку настольных приложений, абстрагируя HTTP с помощью модели, основанной на состоянии и событиях (ViewState, postbacks, серверные элементы управления). Его заменили, потому что абстракция сильно «протекала». Она создавала раздутый HTML, делала модульное тестирование практически невозможным, противоречила тому, как на самом деле работает веб, и давала разработчикам очень мало контроля над отображаемым результатом. К тому времени, когда появились jQuery, а затем и фронтенд-фреймворки, Web Forms казался архаичным.

Основополагающие шаблоны (по-прежнему актуальны, но эволюционировали)
Многоуровневая/трёхуровневая архитектура. Классический многоуровневый подход: представление → бизнес-логика → доступ к данным. Это был основной принцип работы корпоративного . NET на протяжении многих лет. Теоретически каждый уровень мог быть развёрнут независимо. Он не устарел сам по себе, но был усовершенствован. Проблема заключалась в том, что на практике команды часто получали «анемичный» бизнес-слой, который просто передавал данные, и тесную связь между слоями через общие DTO или модели Entity Framework, просачивающиеся вверх.

. http://ASP.NET/ MVC был запущен примерно в 2009 году как «противоядие» от Web Forms. Он использовал HTTP, предоставлял разработчикам контроль над HTML, позволял проводить модульное тестирование и правильно соблюдал принцип разделения ответственности. MVC по-прежнему широко используется в http://ASP.NET/ Core, хотя Razor Pages и Minimal API стали использоваться в более простых сценариях. MVC остается предпочтительным вариантом для сложных веб-приложений с множеством контроллеров и представлений.

MVVM (Модель-Представление-Модель Представления). Этот шаблон стал доминирующим в настольных приложениях WPF и Silverlight, а позже и в Xamarin. Модель Представления (ViewModel) предоставляет данные и команды, к которым представление привязывается декларативно. MVVM по-прежнему является основным шаблоном для . NET MAUI (преемника Xamarin. Forms) и WPF. Silverlight мёртв, но концепция MVVM процветает.

Сервисно-ориентированные шаблоны
WCF (Windows Communication Foundation). Представлял собой унифицированную платформу Microsoft для создания сервисно-ориентированных приложений — SOAP, REST, именованные каналы, TCP, очереди сообщений — всё в рамках одной модели программирования. Был невероятно мощным и таким же сложным. Конфигурация была печально известна своей сложностью (бесконечные XML-файлы). WCF был вытеснен, потому что отрасль перешла к легковесным REST/HTTP API, и сложность WCF не была оправдана для большинства вариантов использования. http://ASP.NET/ Web API, а позже и http://ASP.NET/ Core, заняли его место. Существует поддерживаемый сообществом проект CoreWCF для сценариев миграции, но новые проекты почти никогда не выбирают WCF.

Web API / REST http://ASP.NET/ Web API (2012), а затем и http://ASP.NET/ Core сделали создание HTTP API простым. Теперь это стандарт для взаимодействия сервисов в . NET. Минимальные API в . NET 6+ ещё больше упростили его для небольших сервисов.

. Для взаимодействия между сервисами, где важна производительность, gRPC (поддерживается нативно в http://ASP.NET/ Core) предлагает бинарную сериализацию через Protocol Buffers, потоковую передачу HTTP/2 и строгие контракты. Это современная замена WCF в сценариях взаимодействия между сервисами, где не требуется совместимость с браузерами.

Окончание следует…

Источник: https://todayamerican.medium.com/net-c-application-architecture-over-time-7218f0470a02

.NET Разработчик

21 мая 2026 г., 07:07

День 2651. #ЧтоНовенького
VSTest удаляет зависимость от Newtonsoft. Json
Начиная с . NET 11 Preview 4 и Visual Studio 18.8, VSTest, платформа, на которой работают dotnet test и Test Explorer, больше не будет зависеть от Newtonsoft. Json. Теперь будет использоваться System. Text. Json в . NET и JSONite в . NET Framework. Большинству проектов никаких действий не требуется. Небольшое количество проектов может столкнуться с ошибкой сборки или тестирования и решить её добавлением одной строки PackageReference.

Зачем?
VSTest годами поставлялся с Newtonsoft. Json в составе . NET SDK и Visual Studio. Все версии Newtonsoft. Json ниже 13.0.0 теперь помечены как уязвимые на http://NuGet.org/, и наличие этой зависимости делает тестовую платформу уязвимой в компоненте, который ей больше не нужен. Удаление является частью более масштабной работы по удалению Newtonsoft. Json из . NET SDK.

Что не меняется?
- Формат передачи VSTest. Сообщения сериализуются одинаково независимо от того, используется ли Newtonsoft. Json, System. Text. Json или JSONite.
- Старые тестовые хосты остаются совместимыми с обновлённой платформой, и наоборот.
- Производительность сериализации остается прежней или улучшается.

Кого это НЕ затронет?
Большинство тестовых проектов:
- Проекты, которые не используют Newtonsoft. Json.
- Проекты, которые ссылаются на Newtonsoft. Json в виде обычной ссылки PackageReference.
- Проекты xUnit и NUnit, работающие на . NET или использующие AppDomains. Для них уже требовалась явная ссылка.

Кого это затронет и как это исправить
Каждая из перечисленных ниже ошибок не является скрытой, сообщается в ходе выполнения теста и передаётся в TRX и представления тестов Azure DevOps / GitHub.

1. Ошибка сборки: отсутствует ссылка на Newtonsoft. Json
Если тестовый проект использует типы Newtonsoft. Json (например, JObject, JsonConvert) без ссылки на этот пакет, ранее он компилировался только потому, что Newtonsoft. Json просачивался через VSTest. После обновления это будет не так.
Исправление: добавьте пакет.


2. Ошибка выполнения: FileNotFoundException для Newtonsoft. Json
Проекты, которые ссылаются на Newtonsoft. Json, но не содержат ресурс времени выполнения — например:

runtime

Предполагалось, что копия библиотеки из VSTest будет присутствовать во время тестирования. После этого обновления запуск теста завершится с ошибкой:
System. IO. FileNotFoundException: Could not load file or assembly 'Newtonsoft. Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.
Исправление: уберите runtime, либо установите Newtonsoft. Json без исключения ресурсов времени выполнения.

3. Ошибка загрузки расширения в тестовом адаптере или сборщике данных
Адаптеры и сборщики данных, которые использовали Newtonsoft. Json, не указав его в качестве зависимости, завершатся с ошибкой во время загрузки с сообщением, подобным следующему:
Data collector 'SampleDataCollector' threw an exception during type loading, construction, or initialization: System. IO. FileNotFoundException: Could not load file or assembly 'Newtonsoft. Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'.
В сообщении будет указано имя расширения, которое необходимо обновить, однако на данный момент о таких проблемах не сообщалось. Авторам расширений следует добавить Newtonsoft. Json в свой пакет (или отказаться от него); пользователи могут добавить Newtonsoft. Json в тестовый проект или отключить затронутое расширение до его обновления.

Изменение публичного API
VSTest предоставлял доступ к Newtonsoft. Json. Linq. JToken в одном месте своего API связи. Этот тип удаляется из публичного доступа. Он имел смысл только для кода, участвующего в протоколе VSTest, и вряд ли будет использоваться реальными пользователями, но авторам расширений следует об этом знать.

Источник: https://devblogs.microsoft.com/dotnet/vs-test-is-removing-its-newtonsoft-json-dependency/

.NET Разработчик

21 мая 2026 г., 07:07

День 2650. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

32. Синтаксис Razor
«Расскажите, что такое Razor и как он используется в приложениях http://ASP.NET/ Core? Приведите пример».

Хороший ответ
Razor — это синтаксис разметки, который позволяет встраивать код C# в HTML-документы для динамической генерации HTML-контента на сервере перед его отправкой клиенту. Он используется в основном в представлениях http://ASP.NET/ Core MVC, Razor Pages и веб-приложениях Blazor для создания динамических веб-страниц.

Блоки кода в Razor начинаются с символа @, который помогает компилятору отличать код C# от HTML. Это позволяет беспрепятственно интегрировать серверную логику в структурированный HTML-файл, расширяя возможности рендеринга веб-страниц на основе динамических данных.

В качестве примера синтаксиса Razor в представлении http://ASP.NET/ Core MVC рассмотрим простую модель, представляющую продукт:
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}
В следующем представлении показано, как отобразить список продуктов:
@model IEnumerable
Список Продуктов

@foreach (var p in Model)
{

@* Денежный формат *@

}


Название
Цена


@p. Name@p. Price. ToString("C")



В этом примере синтаксис Razor используется для итерации по коллекции объектов Product, переданных в представление из контроллера. Он динамически генерирует строки таблицы () для каждого продукта с его названием и ценой. Символ @ используется для вставки кода C# в HTML для итерации по списку и отображения данных.

Преимущества использования Razor включают:
- Повышение производительности: Razor снижает сложность написания и поддержки динамических веб-страниц, позволяя разработчикам писать код C# непосредственно в представлении.
- Строгая типизация: Используя C# в представлении, Razor поддерживает IntelliSense и проверку кода во время компиляции, уменьшая количество ошибок во время выполнения.
- Чёткое разделение: Razor помогает поддерживать чёткое разделение задач между логикой пользовательского интерфейса и логикой бэкэнда, придерживаясь паттерна MVC.

Часто встречающийся неверный ответ
«Синтаксис Razor — это просто использование символа @ для написания любого кода C# непосредственно в HTML. Можно выполнять любую бизнес-логику в представлении, чтобы манипулировать данными так, как вам нужно».

Почему это неправильно
- Неправильное использование Razor для бизнес-логики: Этот ответ предполагает ненадлежащее использование представлений Razor для выполнения бизнес-логики, что нарушает принцип разделения ответственности в MVC. Представления Razor предназначены для обработки логики представления, а не бизнес-логики.

- Потенциальные проблемы с избыточностью и поддержкой: Встраивание сложной логики C# в представления Razor может привести к избыточному, трудно поддерживаемому коду. Это затрудняет чтение и управление представлением, особенно для других разработчиков или при возвращении к коду через некоторое время.

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

Эта ошибка обычно возникает из-за непонимания ролей в паттерне MVC или из-за опыта работы с фреймворками веб-разработки, которые нечетко разделяют бизнес-логику и логику представления.

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

Название	Цена
@p. Name	@p. Price. ToString("C")

.NET Разработчик

21 мая 2026 г., 07:07

День 2649. #ProjectManagement
Как Проваливаются Разработчики ПО. Окончание

Эффект накопления
Стоимость создания неправильного продукта людьми ограничена скоростью человека. Команда за спринт может создать 10-15 функций. С ИИ-агентами та же команда теперь может создавать 10-15 функций в день. Если эти функции неверны, потери — и количество необходимых исправлений — кратно увеличиваются. Хуже того, большая кодовая база, полная неправильных функций, создает накопительную сложность: будущим агентам (и людям) придётся обходить все ошибки, которые были допущены. Агенты отлично следуют существующим шаблонам: большая кодовая база, полная неправильных функций, будет использована в качестве модели для следующей функции. Преимущество мощности ИИ-агентов делает их опасными, когда они делают не то.

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

1. Вкладывайте значительные усилия в требования и спецификации. Чем яснее и точнее входные данные для ИИ-агентов, тем лучше результаты. Расплывчатые требования, которые разработчик-человек мог бы разумно интерпретировать, будут реализованы агентом буквально — или, что ещё хуже, изобретательно.

2. Автоматизируйте контрольные точки качества. Код, сгенерированный ИИ, нуждается в автоматизированных тестах, проверке синтаксиса, сканировании безопасности и других проверках качества. Эти контрольные точки становятся основной защитой от ошибок при масштабировании. Их также гораздо проще создать с помощью ИИ-агентов, поэтому важно настроить их с самого начала.

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

4. Часто проводите проверки и валидацию. Короткие циклы обратной связи особенно важны при работе с агентами. Настройте процесс таким образом, чтобы он развивался небольшими итерациями с частыми этапами проверки человеком, чтобы гарантировать, что разработка идёт по плану.

5. Измеряйте результаты, а не только объём. В случае с ИИ-агентами возникает соблазн измерить объём выпущенного кода. Но важно то, получают ли пользователи выгоду. Отслеживайте использование, удовлетворённость пользователей и бизнес-результаты наряду с показателями скорости.

6. Оптимизируйте последующие процессы. Сегодня ИИ-агенты могут создавать код в десять раз быстрее людей. Но создание кода не было узким местом раньше, и уж точно не является им сейчас. Ускорение не являющихся узкими местами процессов в системе приводит лишь к увеличению потерь и замедлению общей доставки. Прежде чем натравить ИИ-агентов на весь ваш бэклог, убедитесь, что вы создали контрольные точки качества, автоматические проверки развёртывания, тестовые среды, где новые функции могут быть оценены и утверждены людьми, и т.д.

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

Быстрое движение имеет значение только в том случае, если вы движетесь в правильном направлении. Как гласит классическая цитата: «Мы заблудились, зато мы всех опережаем!»

Источник: https://ardalis.com/how-software-developers-fail/

.NET Разработчик

6 мая 2026 г., 20:11

День 2643. #ВопросыНаСобеседовании
Марк Прайс предложил свой набор из 60 вопросов (как технических, так и на софт-скилы), которые могут задать на собеседовании.

31. Паттерн MVC
«Расскажите, что такое паттерн MVC и как вы его реализовали в своих проектах? Приведите пример того, как вы использовали MVC.»

Хороший ответ
Паттерн MVC (Model-View-Controller) — это принцип проектирования, который разделяет приложение на три взаимосвязанных компонента. Такое разделение помогает управлять сложностью, способствует организации кода и поддерживает масштабируемость:
1. Модель - слой данных и бизнес-логики приложения. Она отвечает за хранение данных, их обработку и определение бизнес-правил.
2. Представление - обрабатывает отображение данных, получая модель от контроллера. Оно только отображает информацию пользователю и отправляет команды пользователя контроллеру.
3. Контроллер - выступает в качестве посредника между моделью и представлением, получая данные из модели и решая, какое представление отображать.

В своих проектах я использовал паттерн MVC, чтобы обеспечить надлежащее разделение задач, что упрощает поддержку и расширение приложения. Например:
// Модель
public class Product
{
public int Id { get; set; }
public string Name { get; set; }
public decimal Price { get; set; }
}

// Контроллер
public class ProductsController : Controller
{
private readonly IProductRepo _repo;

public ProductsController(IProductRepo repo)
{
_repo = repo;
}

public async Task Index()
{
var products = await _repo. GetAllAsync();
// Передаём модель в представление
return View(products);
}
}

// Представление (Index.cshtml)
@model IEnumerable
Продукты

@foreach(var product in Model)
{
@product. Name - $@product. Price

}

В этом примере ProductsController получает данные о продуктах, используя репозиторий IProductRepo, который абстрагирует логику доступа к данным. Полученные данные затем передаются в представление Index, которое отвечает за отображение информации о продуктах. Такое разделение позволяет вносить изменения в модель БД или бизнес-логику, не затрагивая логику представления, и наоборот, тем самым соблюдая принцип единственной ответственности.

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

Часто встречающийся плохой ответ
«MVC — это просто обеспечение наличия моделей, представлений и контроллеров в проекте. Нужно поместить HTML-код в представления, код получения из БД в модели и использовать контроллеры для связи всего этого».

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

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

- Непонимание лучших практик в архитектуре MVC, таких как размещение бизнес-логики вне контроллеров и представлений.

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

Источник: https://github.com/markjprice/tools-skills-net8/blob/main/docs/interview-qa/readme.md

.NET Разработчик

6 мая 2026 г., 20:11

День 2642. #ЗаметкиНаПолях
Паттерн «Интерпретатор» в . NET. Расширенное использование


1. Создание правил из конфигурации
Парсим правила из JSON или БД:
public class RuleEngine
{
public IExpression BuildFromConfig(
RuleDefinition def) => def. Type switch
{
"OrderTotalGreaterThan" =>
new OrderTotalGreaterThan(
def. GetParam("threshold")),
"CustomerIsVip" =>
new CustomerIsVip(),
"OrderContainsCategory" =>
new OrderContainsCategory(
def. GetParam("category")),
"AND" =>
new AndExpression(
BuildFromConfig(def. Left!),
BuildFromConfig(def. Right!)),
"OR" =>
new OrExpression(
BuildFromConfig(def. Left!),
BuildFromConfig(def. Right!)),
"NOT" =>
new NotExpression(BuildFromConfig(def. Left!)),
_ => throw new InvalidOperationException(
$"Неизвестный тип: {def. Type}")
};
}

Определение правила в JSON:
{
"type": "AND",
"left": { "type": "CustomerIsVip" },
"right": { "type": "OrderTotalGreaterThan", "params": { "threshold": 200 } }
}
Теперь отдел маркетинга может определять правила в UI панели управления. RuleEngine анализирует и оценивает их без изменения кода.

2. Парсинг выражений для вычисляемых полей
Аналогично можно создавать математические выражения:
public interface IMathExpression
{
decimal Evaluate(Dictionary variables);
}

public class NumberLiteral(decimal value)
: IMathExpression
{
public decimal Evaluate(Dictionary variables)
=> value;
}

public class Variable(string name)
: IMathExpression
{
public decimal Evaluate(Dictionary variables)
=> variables[name];
}

public class Multiply(IMathExpression left, IMathExpression right)
: IMathExpression
{
public decimal Evaluate(Dictionary variables)
=> left. Evaluate(variables) * right. Evaluate(variables);
}

// Выражение: price * quantity * (1 - discount)
var totalExpr = new Multiply(
new Multiply(new Variable("price"), new Variable("quantity")),
new Subtract(new NumberLiteral(1), new Variable("discountRate")));

var vars = new Dictionary
{
["price"] = 29.99m, ["quantity"] = 3, ["discount"] = 0.10m
};

var total = totalExpr. Evaluate(vars); // 80.973

Когда не использовать
1. Для сложных правил. Если нужны циклы, функции или сложный синтаксис, используйте подходящий генератор парсеров (ANTLR) или существующий скриптовый движок (Roslyn, Lua). Паттерн «Интерпретатор» плохо масштабируется для сложных языков.

2. Важна производительность. Каждый вызов Interpret() проходит по дереву выражений. Для часто используемых путей с миллионами вычислений скомпилированные выражения (Expression. Compile()) на порядки быстрее.

3. Правила редко меняются. Если правила стабильны и меняются раз в год, затраты на создание интерпретатора не оправданы. Просто пишите условия напрямую.

«Интерпретатор» избыточен?
Для 3-4 фиксированных условий — да. Просто используйте if-else. Паттерн особенно эффективен, когда у вас более 20 правил, которые регулярно меняются и позволяют создавать комбинации без перекомпиляции кода.

Альтернативы
Для оценки во время выполнения деревья выражений C# Expression компилируются в IL. Для простой оценки правил может подойти словарь делегатов или .

Источник: https://thecodeman.net/posts/interpreter-pattern-in-dotnet

.NET Разработчик

6 мая 2026 г., 20:11

День 2641. #ЗаметкиНаПолях
Паттерн «Интерпретатор» в . NET. Начало
Когда бизнес-правила похоронены в цепочках if-else.

Система скидок начиналась с простого: 10% на заказы свыше $100. Одно условие, одно правило. Затем отдел маркетинга захотел: "20% для VIP-клиентов И заказом свыше $200." Затем: "Бесплатную доставку товаров категории "Электроника" ИЛИ за заказ свыше $500." И т.д., и т.п.

Теперь метод предоставления скидок — это 150 строк вложенных условных операторов, к которым никто не хочет прикасаться:
public decimal CalculateDiscount(
Order order, Customer customer)
{
if (customer. IsVip && order. Total > 200)
return order. Total * 0.20m;
else if (order. Total > 100)
return order. Total * 0.10m;
else if (order. Items. Any(i => i. Category == "Electronics") || order. Total > 500)
order. Shipping = 0;

// … ещё 20 условий

return order. Total;
}

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

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

Паттерн «Интерпретатор»
Паттерн «Интерпретатор» определяет грамматику для языка и предоставляет интерпретатор, который оценивает выражения на этом языке. Каждое правило в грамматике - класс. Сложные правила компонуются из простых.

Определим интерфейс выражений и атомарные выражения:
// Контекст - данные, которые будут оцениваться в выражениях
public class RuleContext(Order order, Customer customer)
{
public Order Order { get; } = order;
public Customer Customer { get; } = customer;
}

// Абстрактное выражение
public interface IExpression
{
bool Interpret(RuleContext ctx);
}

// Окончательные выражения: атомарные условия
public class OrderTotalGreaterThan(decimal threshold)
: IExpression
{
public bool Interpret(RuleContext ctx)
=> context. Order. Total > threshold;
}

public class CustomerIsVip : IExpression
{
public bool Interpret(RuleContext ctx)
=> context. Customer. IsVip;
}

public class OrderContainsCategory(string category)
: IExpression
{
public bool Interpret(RuleContext ctx)
=> ctx. Order. Items. Any(i =>
i. Category. Equals(category,
StringComparison. OrdinalIgnoreCase));
}

// …
Теперь нетерминальные выражения – логические действия:
// И
public class AndExpression(IExpression left, IExpression right)
: IExpression
{
public bool Interpret(RuleContext ctx)
=> left. Interpret(ctx) && right. Interpret(ctx);
}

// ИЛИ
public class OrExpression(IExpression left, IExpression right)
: IExpression
{
public bool Interpret(RuleContext ctx)
=> left. Interpret(ctx) || right. Interpret(ctx);
}

// НЕ
public class NotExpression(IExpression expression)
: IExpression
{
public bool Interpret(RuleContext ctx)
=> !expression. Interpret(ctx);
}

Составляем правила из выражений:
// VIP-клиент и заказ > $200
var vipHighValueRule = new AndExpression(
new CustomerIsVip(),
new OrderTotalGreaterThan(200));

var ctx = new RuleContext(order, customer);

if (vipHighValueRule. Interpret(ctx))
discount = 0.20m;
Правила — это компонуемые структуры данных. Вы можете хранить их, сериализовать и создавать из конфигурации.

Почему это лучше
1. Правила — это данные, а не код. Вы можете хранить определения правил в БД и создавать деревья выражений во время выполнения. Для новых правил не требуется повторное развёртывание.
2. Компонуемость. Операторы И, ИЛИ и НЕ объединяют любые выражения. Сложные правила строятся из простых, протестированных компонентов.
3. Тестируемость. Каждое выражение представляет собой отдельный класс с одним методом. Тестируйте OrderTotalGreaterThan независимо от всего остального.

Окончание следует…

Источник: https://thecodeman.net/posts/interpreter-pattern-in-dotnet

.NET Разработчик

6 мая 2026 г., 20:11

День 2640. #ЗаметкиНаПолях
Первичные Конструкторы для Внедрения Зависимостей. Окончание


Ловушка, которая отталкивает многих
Параметры первичного конструктора не являются полями только для чтения. Когда вы используете параметр первичного конструктора непосредственно в теле класса (), компилятор захватывает его как изменяемую переменную. За кулисами не генерируется поля только для чтения.

Т.е. вы можете изменить значение параметра:
public class OrderService(
IOrderRepository repo,
ILogger logger)
{
// …

public void SomeOtherMethod()
{
repo = null!;
logger = null!;
}
}
Этот код компилируется без ошибок и предупреждений. Если вам необходимы гарантии неизменяемости, явно присвойте параметр полю только для чтения:
public class OrderService(
IOrderRepository repo,
ILogger logger)
{
private readonly IOrderRepository _repo = repo;
private readonly ILogger _logger = logger;

// …
}
Но теперь мы потеряли большую часть преимуществ первичных конструкторов. Мы вернулись к объявлениям полей и присваиваниям, только с другим синтаксисом.

На практике вряд ли вы столкнётесь с этой проблемой в классе сервиса, получаемого из DI. Маловероятно, что вы случайно измените значение logger посреди метода. Но это может создать проблемы в классах сущностей или объектов-значений, где неизменяемость действительно важна. Это единственное место, где по-прежнему стоит проявлять осторожность.

Где использовать традиционные конструкторы
Вот случаи, когда стоит придерживаться традиционного подхода:

1. Сложная логика валидации
Если нужно проверять параметры перед их присваиванием, понадобится тело конструктора:
public class EmailAddress
{
private readonly string _value;

public EmailAddress(string value)
{
if (string. IsNullOrWhiteSpace(value)
|| !value. Contains('@'))
throw new ArgumentException(
"Неверный email.", nameof(value));

_value = value;
}
}
Первичные конструкторы не позволяют разместить логику валидации до выполнения тела класса.

2. Множественные перегрузки конструкторов
Первичные конструкторы поддерживают одну сигнатуру конструктора. Если вам нужны перегрузки, придётся связывать обычные конструкторы с помощью this(…), что быстро приводит к беспорядку.

3. Слишком много параметров
Как только вы достигнете 5 и более зависимостей, строка первичного конструктора станет трудночитаемой. Хотя, тогда класс, вероятно, будет иметь слишком много обязанностей, и рефакторинг будет лучшим решением, чем ухищрения с форматированием.

Итого
- Можно использовать первичные конструкторы для всех классов сервисов в DI. Экономия на шаблонном коде того стоит.
- Они полезны для создания сущностей, когда вы хотите обеспечить обязательность параметров на уровне типа.
- Параметры основного конструктора сохраняются как изменяемые переменные, а не поля только для чтения. Это единственное, о чём нужно помнить. Эта изменяемость не страшна в классах сервисов, потому что в этом контексте это вряд ли вызовет реальные ошибки.
- Стоит придерживаться традиционных конструкторов для типов с валидацией, множественными перегрузками или со слишком большим количеством зависимостей.

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

Источник: https://www.milanjovanovic.tech/blog/why-i-switched-to-primary-constructors-for-di-in-csharp

.NET Разработчик

6 мая 2026 г., 20:11

День 2639. #ЗаметкиНаПолях
Первичные Конструкторы для Внедрения Зависимостей. Начало
Когда в C# 12 внедрили первичные конструкторы в классах, это было встречено скептически. Неявное изменяемое поле вместо явного поля только для чтения? Это казалось обменом безопасности на удобство. Но практика показала, что они значительно сокращают количество шаблонного кода в сервисных классах, а ловушка, которой все опасались, становится управляемой, если вы о ней знаете.

Классы сервисов
Вот как раньше выглядели классы сервисов:
public class OrderService
{
private readonly IOrderRepository _repo;
private readonly ILogger _logger;

public OrderService(
IOrderRepository repo,
ILogger logger)
{
_repo = repo;
_logger = logger;
}

public async Task GetAsync(Guid id)
{
_logger. LogInformation("Получаем заказ {OrderId}", id);
return await _repo. GetByIdAsync(id);
}
}
И как теперь:
public class OrderService(
IOrderRepository repo,
ILogger logger)
{
public async Task GetAsync(Guid id)
{
logger. LogInformation("Получаем заказ {OrderId}", id);
return await repo. GetByIdAsync(id);
}
}
Объявления полей, тело конструктора, присваивания — всё исчезло. Параметры перехватываются и становятся доступны во всём теле класса.

Это наиболее распространённый вариант использования первичных конструкторов: внедрение зависимостей в классы сервисов. Вы объявляете то, что вам нужно, и используете это напрямую. Экономия на шаблонном коде быстро накапливается. Классам сервисов обычно не нужно проверять или преобразовывать свои зависимости. DI-контейнер предоставляет их, а вы их используете. Первичные конструкторы идеально подходят для этого.

Создание сущностей (с оговоркой)
Можно использовать первичные конструкторы для сущностей предметной области и объектов-значений, где необходимо обеспечить обязательность параметров во время создания:
public class Order(Guid customerId, Money total)
{
public Guid Id { get; } = Guid. NewGuid();
public Guid CustomerId { get; } = customerId;
public Money Total { get; } = total;
public OrderStatus Status { get; private set; }
= OrderStatus. Pending;
public DateTime CreatedAt { get; }
= DateTime. UtcNow;

public void Confirm()
{
if (Status != OrderStatus. Pending)
{
throw new InvalidOperationException(
$"Нельзя подтвердить заказ в статусе {Status}.");
}

Status = OrderStatus. Confirmed;
}
}
Создать заказ без customerId и total невозможно. Первичный конструктор делает это ограничение видимым на уровне объявления типа.

Обратите внимание на ключевое отличие от шаблона класса сервиса: параметры первичного конструктора присваиваются свойствам с инициализаторами (= customerId). Это важно, и это приводит к самой большой проблеме первичных конструкторов.

Окончание следует…

Источник: https://www.milanjovanovic.tech/blog/why-i-switched-to-primary-constructors-for-di-in-csharp

.NET Разработчик

6 мая 2026 г., 20:11

День 2638. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 7

7. https://github.com/ankane/pghero (Панель Управления Производительностью Postgres)
Что даёт: простой мониторинг производительности PostgreSQL для команд без выделенных администраторов баз данных.
Язык: Ruby.
Поддержка: очень активная.

Зачем нужен
Большинство инструментов мониторинга сложны и дороги. pghero предоставляет 80% функциональности в простом веб-интерфейсе: медленные запросы, отсутствующие индексы, раздувание таблиц, проблемы с подключением — всё на одной панели мониторинга.

Установка
1. Docker (самая простая)
docker run -ti -e DATABASE_URL=postgres://user:pass@host:5432/dbname \
-p 8080:8080 ankane/pghero
2. Для Rails
gem install pghero
pghero config:set DATABASE_URL=postgres://…
pghero server

За чем можно наблюдать
1. Медленные запросы (последние 24 часа):
SELECT … FROM orders JOIN … (avg: 45s, 234 calls)
→ Missing index on orders(customer_id, order_date)

UPDATE inventory … (avg: 12s, 5,432 calls)
→ Long-running, blocking other queries

2. Отсутствующие индексы:
- orders.customer_id (queries: 1,234/day, est. speedup: 100x)
- http://customers.email/ (queries: 456/day, est. speedup: 50x)

3. Раздувание таблиц:
- orders: 35% bloat (recommend VACUUM)
- customer_events: 62% bloat (recommend VACUUM FULL)

4. Проблемы с соединением:
- Max connections: 100
- Current: 87 (87% utilization) ⚠️
- Idle in transaction: 12 (potential locks)

5. Использование индексов:
- idx_orders_date: 2.3M scans/day ✅
- idx_orders_legacy: 0 scans/day (unused, consider dropping)

Когда использовать
- PostgreSQL в продакшене;
- нет выделенного администратора баз данных;
- нужен простой мониторинг;
- нужны действенные рекомендации (а не просто метрики).

Когда отказаться
- необходим мониторинг разных БД (pghero работает только с PostgreSQL);
- необходим подробный исторический анализ (pghero отображает текущее состояние + 24 часа);
- уже есть комплексный мониторинг (Datadog и т. д.).

Скрытая функция
Визуализация плана запроса. В pghero щёлкните на любой медленный запрос. Отобразится:
1. Текст запроса;
2. План выполнения (визуальный);
3. Рекомендуемые индексы;
4. Предложение по изменению запроса;
5. Создание индекса одним щелчком (генерирует DDL).

С осторожностью
Запросы pghero могут быть дорогими на больших базах данных. Настройка, чтобы снизить нагрузку:
# config/pghero.yml
databases:
primary:
url: <%= ENV["DATABASE_URL"] %>
# Снижение частоты запросов
slow_query_ms: 1000 # Только запросы длиннее 1с
slow_query_calls: 10 # Только 10+ вызовов
# Выключение дорогих проверок
index_bloat: false # Медленно на БД в 1TB+

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

.NET Разработчик

6 мая 2026 г., 20:11

День 2637. #TipsAndTricks
Программно Подавляем Предупреждения Анализатора Roslyn
Анализаторы Roslyn отлично подходят для обеспечения соблюдения стандартов кодирования и поиска ошибок. Однако иногда они могут ложно срабатывать или выдавать предупреждения, которые вы хотите игнорировать в определённых контекстах. Вы можете подавить эти предупреждения с помощью директив #pragma или атрибутов [SuppressMessage], но оба подхода требуют изменения исходного кода.

DiagnosticSuppressor — компонент Roslyn, который подавляет диагностические сообщения, сообщаемые другими анализаторами или компилятором. В отличие от обычного анализатора, он выдаёт новых диагностических сообщений, а проверяет существующие и решает, следует ли их подавить. Это особенно полезно, когда вам нужно контекстно-зависимое подавление без загромождения кода.

Для реализации DiagnosticSuppressor необходимо:
1. Создать класс, наследующий от DiagnosticSuppressor;
2. Декорировать класс с помощью [DiagnosticAnalyzer(LanguageNames. CSharp)];
3. Определить SuppressionDescriptor для каждого правила, которое вы хотите подавить;
4. Переопределить SupportedSuppressions, чтобы возвращать поддерживаемые дескрипторы;
5. Переопределить ReportSuppressions, чтобы реализовать логику подавления.

Пример
Допустим, вы используете Newtonsoft. Json для сериализации классов. Правило анализатора CA1507 предлагает заменить строковые литералы выражениями nameof. Однако, когда вы используете атрибут [JsonProperty("propertyName")], анализатор помечает строковый литерал как нарушение CA1507. Но в этом сценарии вам может быть удобнее использовать строку, т.к. это имя свойства JSON является частью контракта API и должно оставаться неизменным, даже если вы переименуете свойство C#.

Вот как можно реализовать подавитель для этого сценария:
using Microsoft. CodeAnalysis;
using Microsoft. CodeAnalysis. CSharp. Syntax;
using Microsoft. CodeAnalysis. Diagnostics;
using System. Collections. Immutable;

namespace Analyzer. Suppressors;

[DiagnosticAnalyzer(LanguageNames. CSharp)]
public sealed class CA1507Suppressor : DiagnosticSuppressor
{
// Определяем правило подавления
private static readonly
SuppressionDescriptor RuleJsonProperty = new(
id: "EXAMPLE0001", // ID «подавителя»
suppressedDiagnosticId: "CA1507", // ID правила
justification: "Suppress CA1507 on methods decorated with a [Newtonsoft. Json. JsonPropertyAttribute]."
);

// Регистрируем подавление
public override ImmutableArray
SupportedSuppressions => [RuleJsonProperty];

public override void ReportSuppressions(
SuppressionAnalysisContext ctx)
{
// Проверяем правила диагностики
foreach (var diag in ctx. ReportedDiagnostics)
{
// Получаем локацию диагностики и синтаксическое дерево
var location = diag. Location;
var tree = location?. SourceTree;
if (tree is null)
continue;

// Находим ноду в дереве
var root = tree. GetRoot(ctx. CancellationToken);
var node = root. FindNode(location!. SourceSpan);
if (node is null)
continue;

var parent = node. FirstAncestorOrSelf();
if (parent is null)
continue;

var semanticModel = ctx. GetSemanticModel(tree);
var info = semanticModel. GetSymbolInfo(parent, ctx. CancellationToken);

if (info. Symbol is not IMethodSymbol mtdSymb)
continue;

// Проверяем, что тип атрибута Newtonsoft. Json. JsonPropertyAttribute
var attrType = ctx. Compilation. GetTypeByMetadataName(
"Newtonsoft. Json. JsonPropertyAttribute");

if (attrType is null)
continue;

if (mtdSymb. ContainingType. Equals(attrType, SymbolEqualityComparer. Default))
{
// Подавляем
var suppr = Suppression. Create(RuleJsonProperty, diag);
ctx. ReportSuppression(suppr);
}
}
}
}

Источник: https://www.meziantou.net/suppressing-roslyn-analyzer-warnings-programmatically-using-diagnosticsuppressor.htm

.NET Разработчик

6 мая 2026 г., 20:11

День 2636. #Карьера
Приём Повышения Продуктивности, Который Используют Сеньоры. Окончание


Глубокая работа важнее постоянной активности
Ещё одна привычка, повышающая продуктивность — глубокая работа. Сеньоры избегают постоянных отвлечений. Они выделяют время для непрерывного обдумывания. Они знают, что сложные проблемы требуют длительных периодов сосредоточенности. Во многих командах продуктивность разрушается из-за:
- бесконечных сообщений в Slack,
- плотного графика совещаний,
- постоянного переключения контекста.
Старшие инженеры учатся защищать своё внимание. Не потому, что им не нравится сотрудничество. Потому что сложные инженерные проблемы требуют непрерывного обдумывания.

Совещания - тихий убийца продуктивности
Если вы внимательно посмотрите, как опытные инженеры управляют своим расписанием, вы заметите, что они крайне избирательны в отношении совещаний. Они посещают те, которые важны, и пропускают менее важные. Каждый час, проведённый на совещании, — это час, не потраченный на:
- проектирование систем,
- отладку проблем в проде,
- улучшение архитектуры,
- обдумывание компромиссов.
Джуны часто чувствуют давление, заставляющее их посещать все совещания. Сеньоры знают, что защита своего времени защищает качество их работы.

Реальный показатель производительности
Большинство команд измеряют производительность, используя такие показатели, как:
- выполненные задачи,
- ,
- смерженные пул-реквесты,
- коммиты в неделю.

Но эти показатели редко отражают реальное влияние. Старшие инженеры фокусируются на других результатах. Они задают такие вопросы, как:
- Сделало ли это изменение систему проще?
- Устранили ли мы технический долг?
- Предотвратили ли мы будущие инциденты?
- Улучшили ли мы надёжность?
Они измеряют производительность по долгосрочному состоянию системы, а не по краткосрочным результатам.

Почему об этом приёме редко говорят
Этот приём повышения продуктивности незаметен. Размышления не отражаются в метриках. Упрощение системы не выглядит впечатляюще на панели мониторинга. Удаление кода редко приветствуется. Но за месяцы и годы такой образ мышления создаёт огромные различия между инженерами. Самые продуктивные разработчики — это не те, кто печатает быстрее всех. Это те, кто принимает лучшие решения ещё до того, как что-либо напечатает.

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

1. Делайте паузу перед написанием кода
Потратьте время на глубокое понимание проблемы. Часто первое решение не является лучшим.

2. Сократите ненужную работу
Ищите возможности для упрощения, а не для добавления новых функций.

3. Защищайте свою концентрацию
Выделите время для глубокого размышления. Сложные инженерные задачи редко решаются за 5 минут.

Итого
Продуктивность в разработке ПО заключается не в том, чтобы работать усерднее. Она заключается в качестве работы. Лучшие инженеры не пишут больше кода. Они ясно мыслят, упрощая системы и решая правильные проблемы. И как только вы начнёте работать таким образом, вы сможете писать меньше кода, чем раньше. Но этот код будет иметь гораздо большее значение.

Источник: https://medium.com/@optimzationking2/the-productivity-trick-that-senior-engineers-use-but-never-talk-about-5549af0078f9

.NET Разработчик

6 мая 2026 г., 20:11

[poll]

2,030

.NET Разработчик

6 мая 2026 г., 20:11

День 2635. #Карьера
Приём Повышения Продуктивности, Который Используют Сеньоры. Начало
В начале своей карьеры я думал, что продуктивность означает работать усерднее всех остальных. Больше часов. Больше кода. Больше закрытых задач. Если я выпускал пять новых функций за неделю, я чувствовал себя продуктивным. Но происходило что-то странное. Самые уважаемые инженеры в моей команде — те, к кому все обращались при инцидентах — казались совсем не занятыми. Они не писали код постоянно. Они не спешили закрывать задачи. Иногда они даже уходили раньше остальных. И всё же каким-то образом они всегда были самыми эффективными. Мне потребовались годы, чтобы понять, какой приём они используют.

Иллюзия продуктивности
Разработка ПО создаёт опасную иллюзию: активность выглядит как прогресс. Вы пишете код часами, проводите рефакторинг модулей, проверяете пул-реквесты, посещаете ежедневные совещания, планирования спринтов, ретроспективы, архитектурные совещания. В конце дня вы чувствуете себя измотанным. Но измотанность — это не продуктивность.

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

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

Не потому, что они ленивы. Потому что они знают, что один час размышлений может сэкономить недели работы. Когда возникает новая проблема, джуны часто сразу переходят к реализации. Сеньоры делают паузу. Они задают вопросы:
- Действительно ли это проблема?
- Есть ли более простое решение?
- Можем ли мы устранить проблему, вместо того чтобы её решать?
Именно в этой паузе кроется настоящая продуктивность.

Почему слишком быстрое написание кода опасно
Многие руководства по повышению продуктивности призывают разработчиков работать быстро. Но опытные инженеры знают, что скорость может нанести долгосрочный ущерб. Каждая строка кода вносит:
- поддержку в будущем,
- потенциальные ошибки,
- увеличение сложности,
- увеличение времени на отладку.
Опытные инженеры относятся к коду как к обузе, а не как к достижению.

Прежде чем что-либо писать, они задают себе простой вопрос: «Действительно ли нам нужен этот код?» Иногда ответ отрицательный. И когда ответ отрицательный, прирост продуктивности огромен.

Сила делать меньше
Одна из самых удивительных особенностей опытных инженеров — это то, как часто они удаляют код вместо того, чтобы писать его. Они упрощают системы, удаляют ненужные абстракции. Они устраняют сложность до того, как она распространится. Джун может реализовать остроумное решение. Опытный инженер может перепроектировать систему так, чтобы проблема полностью исчезла. Именно поэтому их работа на первый взгляд кажется медленнее, но со временем даёт гораздо лучшие результаты.

Окончание следует…

Источник: https://medium.com/@optimzationking2/the-productivity-trick-that-senior-engineers-use-but-never-talk-about-5549af0078f9

.NET Разработчик

1 мая 2026 г., 07:41

1,800

.NET Разработчик

1 мая 2026 г., 07:41

День 2633. #TipsAndTricks
Вызываем Файлы из Репозитория Действий в GitHub Actions
GitHub Actions позволяет создавать многократно используемые действия. Один из самых простых способов сделать это — использовать составные действия (Composite Actions), которые позволяют объединять несколько шагов в одно действие. Это уменьшает дублирование кода в ваших рабочих процессах.

При создании составного действия вам может потребоваться сослаться на файлы, хранящиеся в репозитории действий, например, на скрипт PowerShell или Bash.

По умолчанию, когда выполняется действие, рабочий каталог — это корень репозитория, использующего действие. Это означает, что относительные пути разрешаются в репозиторий вызывающего объекта, а не в репозиторий действия.

Для доступа к файлам из репозитория действий используйте контекстную переменную github.action_path, которая содержит путь к каталогу, где находится ваше действие.

Вот пример того, как использовать её в файле action.yml:
name: 'My Composite Action'
description: 'An example'
runs:
using: "composite"
steps:
- name: Run script
run: ${{ github.action_path }}/script.sh
shell: bash
В этом примере файл script.sh находится в корневом каталоге репозитория действий. Использование ${{ github.action_path }}/script.sh гарантирует, что исполнитель выполнит скрипт из правильного места.

Дополнительные ресурсы:
- https://docs.github.com/ru/actions/reference/workflows-and-actions/contexts#github-context
- https://docs.github.com/ru/actions/tutorials/create-actions/create-a-composite-action

Источник: https://www.meziantou.net/accessing-files-from-the-action-repository-in-a-github-composite-action.htm

1,740

.NET Разработчик

1 мая 2026 г., 07:41

День 2634. #TipsAndTricks #Git
Команды Git, Которые Я Запускаю Перед Чтением Кода
Автор оригинала: Ally Piechowski

Я занимаюсь аудитом кодовых баз моих клиентов. Первое, что я обычно делаю, когда берусь за новую кодовую базу, открываю терминал и запускаю несколько команд Git. Я хочу понять, кто основные авторы, где сосредоточены проблемы, уверенно ли команда выпускает продукт или ходит по минному полю.

1. Что меняется чаще всего
git log --format=format: --name-only --since="1 year ago" | sort | uniq -c | sort -nr | head -20
20 самых часто изменяемых файлов за последний год. Файл, находящийся вверху списка, почти всегда тот, о котором говорят: «К нему все боятся прикасаться».

Высокая активность в файле - иногда это просто активная разработка. Но если авторов много — это явный признак проблемы. Это файл, где каждое изменение — это исправление исправления. Я беру 5 файлов из этого списка и сопоставляю их с командой поиска ошибок (см. п. 3). Файл с высокой активностью и большим количеством ошибок — это основной источник риска.

2. Кто авторы
git shortlog -sn --no-merges
Авторы по количеству коммитов. Если на одного человека приходится 60%+, это ваш «автобусный фактор». Если он ушёл полгода назад, это кризис. Если ведущий автор из списка не появляется в течение 6 месяцев (git shortlog -sn --no-merges --since="6 months ago"), я немедленно сообщаю об этом клиенту.

Я также смотрю на хвост. 30 авторов, но только 3 были активны в течение последнего года. Т.е. люди, которые создали эту систему, не те, кто её поддерживает.

Замечание: рабочие процессы объединения коммитов сжимают информацию об авторстве. Если команда объединяет каждый пул-реквест в один коммит, этот результат отражает, кто объединил, а не кто написал. Стоит уточнить стратегию объединения, прежде чем делать выводы.

3. Места ошибок
git log -i -E --grep="fix|bug|broken" --name-only --format='' | sort | uniq -c | sort -nr | head -20
Та же структура, что и у 1й команды, но отфильтрована по коммитам с ключевыми словами, связанными с ошибками. Файлы, которые появляются в обоих списках, — это код с самым высоким риском: они постоянно ломаются и постоянно исправляются, но никогда не исправляются должным образом.

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

4. Проект ускоряется или умирает?
git log --format='%ad' --date=format:'%Y-%m' | sort | uniq -c
Количество коммитов по месяцам. Стабильный ритм — это хорошо. Но что, если количество коммитов падает в 2 раза за месяц? Обычно - кто-то ушёл. Снижение в течение 6-12 месяцев говорит о том, что команда теряет темп. Периодические всплески, за которыми следуют спокойные месяцы, означают, что команда работает над релизами партиями, а не выпускает их непрерывно.

5. Как часто «тушат пожары»?
git log --oneline --since="1 year ago" | grep -iE 'revert|hotfix|emergency|rollback'
Частота откатов и хотфиксов. Несколько откатов за год нормально. Каждые пару недель - команда не доверяет своему процессу развёртывания. Это свидетельство более глубокой проблемы: ненадёжные тесты, отсутствие приёмочных тестов или конвейер развертывания, который усложняет откаты. Отсутствие результатов – сигнал, что либо команда стабильна, либо никто не пишет подробные сообщения о коммитах.

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

Источник: https://piechowski.io/post/git-commands-before-reading-code/

.NET Разработчик

1 мая 2026 г., 07:41

День 2632. #МоиИнструменты #PG
Инструменты Оптимизации Запросов в PostgreSQL. Часть 6

6. https://github.com/sqlfluff/sqlfluff (SQL-линтер для производительности)
Что даёт: выявляет антипаттерны производительности до того, как запросы попадут в прод.
Зачем нужен: Большинство проблем с производительностью SQL возникают из-за распространённых ошибок: SELECT *, ненужные DISTINCT, отсутствие WHERE, неэффективные соединения. SQLFluff выявляет их на этапе разработки, до того, как они вызовут проблемы в продакшене.
Установка:
pip install sqlfluff

# Создаём конфиг
cat > .sqlfluff < '2024-01-01';
Проблемы:
1. SELECT * (возвращает ненужные поля);
2. Неявное объединение (неясное намерение);
3. Сравнение даты без явного приведения типа.

После SQLFluff:
SELECT
o.order_id,
o.order_date,
o.total,
c.customer_name
FROM orders AS o
INNER JOIN customers AS c
ON o.customer_id = c.id
WHERE o.order_date > CAST('2024-01-01' AS DATE);

Когда использовать
- dbt-проекты (отлично интегрируется);
- Несколько инженеров, пишущих SQL-запросы (обеспечение согласованности);
- Предотвращение распространённых ошибок;
- Конвейер CI/CD для SQL.

Когда отказаться
- Разработчик-одиночка (меньшая ценность);
- ad-hoc запросы (избыточно);
- Нестандартный диалект SQL (ограниченная поддержка).

Скрытая функция
Пользовательские правила для антипаттернов в вашей команде:
# custom_rules/no_cross_joins.py
from sqlfluff.core.rules import BaseRule, LintResult
class Rule_Custom_NoCrossJoin(BaseRule):
"""Запрет CROSS JOIN (почти всегда необязательны)."""

def _eval(self, segment, **kwargs):
if segment.is_type("join_clause"):
if "CROSS" in segment.raw_upper:
return LintResult(
anchor=segment,
description="Найден CROSS JOIN. Почти всегда необязателен.",
fixes=[...] # Опционально: предложение исправления
)
Добавить в .sqlfluff.

С осторожностью
Слишком агрессивный линтинг убивает продуктивность:
# Слишком строго (инженеры возненавидят)
sqlfluff lint --rules all
# Лучше начать с критических правил
sqlfluff lint --rules L042,L044,L052
Постепенно добавляйте правила со временем. Соблюдайте баланс между отловом проблем и сопротивлением разработчиков.

Источник: https://medium.com/@reliabledataengineering/15-sql-optimization-tools-that-make-queries-10x-faster-8629ac451d97

.NET Разработчик

1 мая 2026 г., 07:41

День 2631. #ЗаметкиНаПолях
Проверяем Конфигурацию при Запуске. Окончание


Доступ к другим сервисам внутри валидатора
Поскольку валидатор является обычным классом, зарегистрированным в DI, вы можете внедрять зависимости. Это одно из ключевых преимуществ по сравнению с аннотациями данных. Кроме того, аннотации данных не могут выражать зависимости между свойствами. В валидаторе вы можете добавить любую логику.
public class DatabaseOptionsValidator
: IValidateOptions
{
private readonly IHostEnvironment _env;

public DatabaseOptionsValidator(IHostEnvironment env)
=> _env = env;

public ValidateOptionsResult Validate(
string? name, DatabaseOptions opts)
{
var errors = new List();

// Более строгие правила вне среды разработки
if (!_env. IsDevelopment())
{
…
}
…
}
}

Именованные конфигурации
IValidateOptions поддерживает именованные конфигурации через параметр name. Это важно при регистрации нескольких экземпляров одного типа конфигурации — например, двух разных клиентов API:
public class ApiClientOptionsValidator
: IValidateOptions
{
public ValidateOptionsResult Validate(
string? name, ApiClientOptions opts)
{
…

// … Валидация общих свойств …

// Более строгие правила для API Payments
if (name == "Payments"
&& opts. Timeout > 30)
errors. Add($"Таймаут клиента [{name}] не должен превышать 30 сек.");

…
}
}
Регистрация именованных настроек:
builder. Services
. AddSingleton, ApiClientOptionsValidator>();

builder. Services
. AddOptions("Payments")
. BindConfiguration("ApiClients:Payments")
. ValidateOnStart();

builder. Services
. AddOptions("Shipping")
. BindConfiguration("ApiClients:Shipping")
. ValidateOnStart();

Использование в сочетании с OptionsBuilder
API OptionsBuilder (возвращаемый функцией AddOptions()) имеет перегрузку метода . Validate(), которая принимает делегат. Это подходит для простых случаев. Для чего-либо более сложного предпочтительнее использовать реализацию IValidateOptions — она позволяет тестировать логику проверки и не размещать её в Program.cs:
// Делегат — для простых проверок
builder. Services
. AddOptions()
. BindConfiguration("FeatureFlags")
. Validate(opts => opts. Percentage is >= 0 and <= 100,
"Percentage должен быть от 0 до 100")
. ValidateOnStart();

// Класс – для сложных проверок
builder. Services
. AddSingleton, SmtpOptionsValidator>()
. AddOptions()
. BindConfiguration("Smtp")
. ValidateOnStart();
Вы можете объединить оба варианта в одном типе параметров — фреймворк запускает все зарегистрированные валидаторы и агрегирует ошибки.

Источник: https://bartwullems.blogspot.com/2026/03/validating-configuration-at-startup.html

.NET Разработчик

1 мая 2026 г., 07:41

День 2630. #ЗаметкиНаПолях
Проверяем Конфигурацию при Запуске. Начало
. NET-приложения со строго типизированной конфигурацией предоставляют удобный способ привязки разделов appsettings.json к классам C#. Но привязка — это не то же самое, что проверка: отсутствие обязательного значения или число, выходящее за пределы допустимого диапазона, без проблем привяжутся и незаметно сломают приложение во время выполнения. IValidateOptions — механизм, предоставляемый . NET для решения этой проблемы.

Рассмотрим типичный класс параметров:
public class SmtpOptions
{
public string Host { get; set; } = "";
public int Port { get; set; }
public string FromAddress { get; set; } = "";
}
Если в файле appsettings.json отсутствует Host, приложение запустится нормально. Ошибка проявится только при отправке email. Аннотации данных ([Required], [Range] и т.п.) в сочетании с вызовом ValidateDataAnnotations() помогают, но с ними есть 2 проблемы.

1. Они используют рефлексию, что приводит к:
- Затратам на производительность, что важно в сценариях с высокой нагрузкой и требованиям к быстрому запуску.
- Несовместимости с AOT и агрессивным триммингом (true). Могут быть исключены метаданные, от которых зависит рефлексия, что приводит к предупреждениям IL2026/IL3050 или к сбоям во время выполнения.

Это можно исправить, используя генератор кода в . NET8+. Для активации генератора для конкретного класса валидатора параметров потребуется:
- Класс параметров, помеченный атрибутами Data Annotation.
- Частичный класс, реализующий IValidateOptions и помеченный [OptionsValidator], с пустым телом:
using Microsoft. Extensions. Options;

[OptionsValidator]
public partial class ValidateSmtpOptions
: IValidateOptions
{
}
Генератор заполнит тело класса при сборке.

2. Но иногда аннотация данных вовсе недостаточно, когда необходимы:
- Проверка нескольких свойств объекта конфигурации;
- Асинхронные или основанные на данных из БД проверки;
- Условная логика в зависимости от среды;
- Многократно используемые валидаторы, общие для нескольких типов конфигурации.

Здесь пригодится реализовать IValidateOptions. Это интерфейс в Microsoft. Extensions. Options с единственным методом:
public interface IValidateOptions
where TOptions : class
{
ValidateOptionsResult Validate(
string? name, TOptions options);
}

Вы реализуете этот интерфейс, регистрируете его в DI-контейнере, и инфраструктура Options вызывает его автоматически:
- лениво (при первом обращении),
- немедленно при запуске, если используется ValidateOnStart().

Вот простой валидатор для класса, описанного выше:
public class SmtpOptionsValidator
: IValidateOptions
{
public ValidateOptionsResult Validate(
string? name, SmtpOptions opts)
{
var errors = new List();

if (string. IsNullOrWhiteSpace(opts. Host))
errors. Add("Требуется Host");

if (opts. Port is < 1 or > 65535)
errors. Add($"Port должен быть от 1 до 65535");

if (string. IsNullOrWhiteSpace(opts. FromAddress))
errors. Add("Требуется FromAddress");

return errors. Count > 0
? ValidateOptionsResult. Fail(errors)
: ValidateOptionsResult. Success;
}
}
Регистрируем в Program.cs:
builder. Services
. Configure(
builder. Configuration. GetSection("Smtp"))
. AddSingleton, SmtpOptionsValidator>()
. AddOptions()
. ValidateOnStart();

Если проверка не проходит, во время выполнения app. Run() генерируется исключение OptionsValidationException, поэтому сервис никогда не запустится с некорректной конфигурацией. Этот вариант «быстрого сбоя» обычно предпочтительнее, чем исключение NullReferenceException во время выполнения, возникающее где-то в глубинах бизнес-логики.

Окончание следует…

Источник: https://bartwullems.blogspot.com/2026/03/validating-configuration-at-startup.html

.NET Разработчик

19 апр. 2026 г., 20:37

📷 Photo

День 2628. #SystemDesign101
Что Происходит, Когда вы Вводите http://google.com/ в Браузере?

Вы вводите адрес веб-сайта в адресную строку браузера.

Браузер сначала проверяет свой кэш. Если адрес не найден в кэше, он должен найти IP-адрес.

Начинается поиск DNS (представьте, что вы ищете номер телефона). Запрос проходит через различные DNS-серверы (корневой, TLD - сервер имен доменов верхнего уровня - и авторитативный). Наконец, извлекается IP-адрес.

Браузер инициирует TCP-соединение, начиная с рукопожатия. Например, в случае HTTP 1.1 клиент и сервер выполняют трёхстороннее TCP-рукопожатие с сообщениями SYN, SYN-ACK и ACK.

Браузер отправляет HTTP-запрос на сервер, и сервер отвечает файлами HTML, CSS и JS.

Браузер обрабатывает ответ. Он анализирует HTML-документ и создаёт деревья DOM и CSSOM.

Браузер выполняет код JavaScript и отображает страницу, проходя через различные этапы (токенизатор, парсер, дерево рендеринга, компоновка и отрисовка).

Веб-страница появляется на экране.

Источник: https://bytebytego.com/guides/what-happens-when-you-type-google/

.NET Разработчик

19 апр. 2026 г., 20:37

День 2627. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Окончание





Ресурсы
Существует множество видео, курсов и книг по теме. Платные курсы рекламировать не буду, решайте сами, стоят ли они того.

Книги:
1)
- Красивые диаграммы;
- Более 15 вариантов системного проектирования.

2)
- Глубокий технический анализ;
- Читать после изучения основ;
- Отличный справочник.

Сдвиг мышления, который изменил всё
Перед изучением системного проектирования.
Синдром самозванца:
- «Я недостаточно опытен»
- «Это слишком сложно»
- «Я никогда не пойму распределённые системы»

Тревога перед собеседованием:
- Надеюсь, я сталкивался с этой проблемой;
- Паника, когда застреваю;
- Заучивание решений.

Карьерный застой:
- Ограничен задачами по программированию;
- Неучастие в принятии архитектурных решений;
- Мимо руководящих должностей.

После освоения системного проектирования
Уверенность:
- Возможность обсуждать архитектуру с кем угодно;
- Понимание компромиссов;
- Мышление в масштабе.

Успех на собеседованиях:
- Возможность ответить на любой вопрос по проектированию;
- Сосредоточенность на размышлении, а не на запоминании.

На собеседованиях по системному проектированию (и в реальной работе):
Плохой ответ: «Мы будем использовать микросервисы и Kafka».
Хороший ответ: «Мы могли бы использовать микросервисы для независимого масштабирования, но, учитывая размер нашей команды (5 инженеров) и текущий масштаб (10 000 пользователей), хорошо структурированный монолит с чёткими границами модулей будет проще в обслуживании. Мы можем выделить сервисы позже, когда достигнем 100 тыс пользователей или нам потребуется независимое развёртывание».

Что изменилось:
- Продемонстрировал понимание компромиссов;
- Учел команду и масштаб;
- Предоставил обоснование;
- Обсудил эволюцию.

Интервьюерам не нужны идеальные проекты. Им нужно увидеть, как вы мыслите.

Итого
Проектирование систем — это навык, а не талант.
Вам не нужны:
- 10 лет опыта;
- Степень в области компьютерных наук;
- Фотографическая память;
- Природный талант.

Нужно только:
- Любопытство изучать, как всё работает;
- Готовность к систематическому обучению;
- Практика проектирования реальных систем;
- Терпение.

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

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

.NET Разработчик

19 апр. 2026 г., 20:37

День 2626. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Продолжение




6. Применение в работе (реальные системы и ограничения)
Теория бесполезна, пока вы не создадите что-то реальное. На работе я был в команде, разрабатывавшей систему обработки платежей:
- Большой объём транзакций;
- Требуется строгая согласованность данных;
- Нулевая терпимость к потере данных;
- Сложная бизнес-логика.

Что я применил
1) Архитектурное решение - разделить монолит на сервисы:
- платежи;
- уведомления;
- бухгалтерия;
- обнаружение мошенничества.
Почему: Каждый сервис имеет разные потребности в масштабировании.

2) Стратегия коммуникаций:
- Синхронная: REST API для операций, ориентированных на пользователя.
- Асинхронная: Kafka для внутренних событий:
Платеж обработан
→ Уведомить пользователя;
→ Обновить учётную запись;
→ Провести проверку на мошенничество.

3) Согласованность данных:
Проблема: деньги не могут быть дублированы или потеряны.
Решение:
- Ключи идемпотентности (предотвращение дублирования транзакций);
- Паттерн для распределённых транзакций;
- Паттерн для аудита.

4) Надёжность:
- (предотвращение каскадных сбоев)
- Повторные попытки с экспоненциальной задержкой;
- Очереди недоставленных сообщений.

5) Мониторинг:
- Отслеживание задержек (P50, P95, P99);
- Оповещения об уровне ошибок;
- Уровень успешности транзакций;
- Панель мониторинга в реальном времени.

Создание реальных систем научило меня:
1) Идеальных проектов не существует
- Каждый выбор — это компромисс;
- Бизнес-ограничения имеют значение;
- Технический долг неизбежен.

2) Эксплуатация важнее проектирования
- Мониторинг и оповещения критически важны;
- Отладка распределённых систем сложна;
- Необходимо планирование отката.

3) Важна команда
- Самый лучший проект ничего не значит, если команда не может его поддерживать;
- Документация имеет решающее значение;
- Привлечение новых инженеров занимает время.

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

7. Я обучал других (лучший способ учиться)
Обучение выявляет пробелы в понимании.

Что я начал делать
1) Наставлял младших инженеров:
- Объяснял кэширование, базы данных, масштабирование;
- Разбирал реальные системные проекты;
- Отвечал на их вопросы «почему».

2) Проводил внутренние технические презентации:
- «Как работает наша платежная система»;
- «Введение в очереди сообщений»;
- «Базы данных: когда что использовать».

3) Писал посты в блоге с диаграммами:
- Помогает систематизировать мысли;
- Приходится ясно объяснять;
- Появляется обратная связь от читателей.

4) Проводил пробные собеседования с коллегами:
- Практика в формулировании мыслей;
- Умение справляться с трудностями;
- Разные подходы к решению.

Почему обучение сработало?
Если вы не можете объяснить что-то просто, значит, вы недостаточно хорошо это понимаете.

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

Преподавание превращает понимание в мастерство.

Окончание следует…

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

.NET Разработчик

19 апр. 2026 г., 20:37

День 2625. #Карьера #SystemDesign
Как я Освоил Системное Проектирование. Продолжение



5. Я проектировал реальные системы (на бумаге, а затем в коде)
Теория без практики бесполезна. Освоив основы, я перестал просто наблюдать. Я начал проектировать системы. Каждое воскресенье я выбирал реальную систему: WhatsApp, YouTube, Uber, Instagram, TinyURL, Netflix, Twitter, Dropbox.

Шаблон разработки системы
1) Функциональные требования (Что нужно делать?)
Пример (Twitter):
- Публиковать твиты (280 символов);
- Подписываться на пользователей;
- Просматривать ленту (твиты от людей, на которых вы подписаны);
- Лайки/ретвиты.

2) Нефункциональные требования (Масштабируемость, производительность, доступность)
- 300 млн активных пользователей;
- 500 млн твитов в день;
- Загрузка ленты <300 мс;
- 99,95% времени безотказной работы.

3) Оценка (приблизительные расчёты)
Хранилище:
- 500 млн твитов в день × 280 символов × 365 дней = 51 ТБ/год (только текст);
- Фотографии: 200 млн/день × 200 КБ = 40 ТБ/день;
- Видео: отдельный расчёт.

Трафик:
500 млн твитов/день ÷ 86400 секунд = ~5800 твитов/секунду.
Пик: 5x среднее значение = 29000 твитов/секунду

4) Высокоуровневый дизайн (нарисуйте архитектуру)
Клиент (веб/мобильное приложение) -> Балансировщик нагрузки -> API-серверы (сервис твитов, сервис ленты, сервис пользователей) -> Кэш (Redis) + БД (PostgreSQL, Cassandra) -> Объектное хранилище (S3 для медиафайлов).

5) Детальный дизайн (подробный анализ компонентов)
Как сгенерировать ленту?
- Подход 1: Пул-модель (интенсивное чтение)
Когда пользователь открывает приложение, запросить все подписки, получить последние твиты, объединить и отсортировать по времени.
Проблема: медленно для пользователей, подписанных на тысячи человек.

- Подход 2: Пуш-модель (интенсивная запись)
Когда кто-то публикует твит, отправить его во все ленты подписчиков. Быстрое чтение (предварительно вычислено).
Проблема: дорого для знаменитостей (миллионы подписчиков).

- Подход 3: Гибридный
Пул для твитов знаменитостей. Пуш для обычных пользователей.

6) Масштабирование и оптимизация
- Добавить кэширование (Redis);
- базы данных (по user_id);
- Асинхронная обработка (очереди сообщений);
- CDN для медиафайлов.

7) Обработка сбоев
- Что если БД выйдет из строя? (Репликация)
- Что если сервер приложения выйдет из строя? (Проверки работоспособности балансировщика нагрузки)
- Что если кэш выйдет из строя? (стратегия ).

Я проектировал по одной системе в неделю в течение 12 недель. К 5й системе я перестал гуглить решения, а стал мыслить самостоятельно. К 10й я смог сравнивать различные подходы и обосновывать свой выбор. В этом разница между запоминанием и пониманием. Я также читал решения распространённых задач проектирования систем, чтобы выявить недостатки своего решения и улучшить его.

Продолжение следует…

Источник: https://medium.com/javarevisited/how-i-learned-system-design-861efe86f173

Showing 30 of 46 posts

Рейтинг

Требуется вход

Отзывы пользователей (0)

Пока нет отзывов. Будьте первым, кто поделится своим опытом!

.NET Разработчик

.NET Разработчик

Рейтинг

Рост участников (Последние 6 дней)

Последние посты

Список Продуктов

Продукты

Рейтинг

Отзывы пользователей (0)

Похожие каналы Telegram

Магазин цифровых товаров YanGoShop(@yangosart)

Финтехстан

Горизонт событий | Event horizon

Новости в 3д сфере. Stl news 3d models. Видео по 3D

Электрион Клуб

TMT Channel

ИнфоТЭК

Афонтово

Похожие каналы Telegram

Магазин цифровых товаров YanGoShop(@yangosart)

Финтехстан

Горизонт событий | Event horizon

Новости в 3д сфере. Stl news 3d models. Видео по 3D

Электрион Клуб

TMT Channel

ИнфоТЭК

Афонтово

Отзывы пользователей (0)

Последние посты

Список Продуктов

Продукты