Питання на співбесіді .NET-розробника

Типи-значення (int, struct, DateTime) зберігають дані безпосередньо і копіюються при присвоєнні. Типи-посилання (class, string, масиви) зберігають посилання на об'єкт у керованій купі — кілька змінних можуть вказувати на один об'єкт.

Через це зміна поля структури в копії не впливає на оригінал, а зміна поля класу — впливає. string хоч і тип-посилання, але незмінний.

record — тип для незмінних даних із порівнянням за значенням: два записи з однаковими полями рівні. Компілятор генерує Equals, GetHashCode, ToString і підтримку with для створення зміненої копії.

Звичайний клас порівнюється за посиланням. Записи зручні для DTO, повідомлень і value objects.

Режим <Nullable>enable</Nullable> змушує явно позначати, чи може посилання бути null (string?), а компілятор попереджає про можливий NullReferenceException.

Це ловить велику частину помилок ще до запуску. У нових проєктах режим увімкнено за замовчуванням, і попередження варто сприймати серйозно, а не глушити оператором !.

Залежності реєструють у контейнері, а фреймворк сам передає їх у конструктори контролерів і сервісів. Є три тривалості життя:

• Transient — новий екземпляр щоразу;
• Scoped — один на HTTP-запит (наприклад, DbContext);
• Singleton — один на весь застосунок.

Типова помилка — впровадити scoped-сервіс у singleton: він житиме вічно і може тримати застарілі дані.

Блокуюче очікування займає потік, поки задача виконується, а в деяких контекстах (старий ASP.NET, WinForms, WPF) призводить до дедлоку: задача чекає повернення в зайнятий потік.

В ASP.NET Core дедлоку немає, але блокування вичерпує пул потоків під навантаженням. Правило — async до кінця ланцюжка, плюс передача CancellationToken, щоб скасовувати роботу при закритті запиту.

Основні прийоми:

• AsNoTracking() для запитів лише на читання;
• проєкції через Select у DTO замість завантаження цілих сутностей;
• Include для потрібних зв'язків, щоб уникнути N+1, і AsSplitQuery() для великих колекцій;
• індекси на полях фільтрації;
• ExecuteUpdate / ExecuteDelete для масових змін без завантаження в пам'ять.

Дивитися згенерований SQL через логування або ToQueryString().

IEnumerable виконує LINQ-операції в пам'яті застосунку. IQueryable будує дерево виразів, яке провайдер (EF Core) перетворює на SQL і виконує в базі.

Якщо передчасно перетворити запит на IEnumerable або викликати ToList(), фільтрація відбудеться в пам'яті після завантаження всієї таблиці. Тому фільтри й пагінацію додають до виконання запиту.

Кожен middleware обробляє запит і вирішує, передати його далі через next() чи завершити. Порядок реєстрації в Program.cs визначає порядок виконання: обробка винятків, HTTPS, статика, маршрутизація, автентифікація, авторизація, ендпоінти.

Неправильний порядок — часта помилка: наприклад, UseAuthorization до UseAuthentication не бачитиме користувача.

Ідея — домен у центрі без залежностей від інфраструктури, а EF Core, зовнішні API й UI — на краях. Це спрощує тестування й заміну інфраструктури.

Але для невеликих сервісів повна структура з десятком проєктів, репозиторіями поверх EF Core і MediatR на кожну дію — надмірна. Альтернатива — vertical slice architecture: код організовано за функціями. Добра відповідь показує, що ви обираєте структуру під розмір і складність домену.

Три складники: структуровані логи (Serilog або вбудований ILogger з JSON), метрики й трасування. У сучасному .NET усе це стандартизовано через OpenTelemetry, а .NET Aspire спрощує локальну розробку з дашбордом телеметрії.

Важливо корелювати логи з трасуванням за trace ID, мати health checks для оркестратора й алерти на p95/p99 затримки та частку помилок, а не лише на падіння сервісу.

ValueTask — структура, яка дозволяє уникнути алокації Task, коли результат часто доступний синхронно (наприклад, із кешу). Це важливо в гарячих шляхах із мільйонами викликів.

Обмеження: ValueTask не можна чекати двічі чи кешувати. Для звичайного бізнес-коду Task простіший і безпечніший — ValueTask варто обирати після вимірювань.

Оптимістична конкурентність: токен конкурентності (rowversion у SQL Server або xmin у PostgreSQL). Якщо запис змінився після читання, EF Core кине DbUpdateConcurrencyException, і можна повторити операцію або показати конфлікт користувачу.

Песимістичне блокування (SELECT ... FOR UPDATE) використовують, коли конфлікти часті й дорогі, наприклад при резервуванні обмежених ресурсів.