C# C# · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Внедрение зависимостей

Проверяет встроенный контейнер зависимостей, времена жизни, области, фабрики и composition root. В сценариях нужно распознать захваченную scoped-зависимость, скрытый service locator, неверное владение IDisposable и архитектурную цену удобного разрешения сервисов.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. На 30 вопросов отведено 85 минут. В заданиях с кодом учитывайте указанную конструкцию и не додумывайте отсутствующие условия. После завершения откроются общий результат, тематические шкалы и разбор каждого ответа.

Вопрос 1 из 30

Что показывает constructor injection?

public sealed class InvoiceService(
    IInvoiceRepository repository,
    IClock clock)
{
}

Сигнатура перечисляет все закрытые поля класса, включая вычисляемые Конструктор предназначен только для необязательных настроек Контейнер определяет порядок сборок мусора для переданных объектов Параметры конструктора автоматически становятся HTTP-маршрутами Обязательные зависимости объекта видны в момент его создания

Вопрос 2 из 30

Что произойдёт при запросе незарегистрированного конкретного класса, даже если все параметры его открытого конструктора можно разрешить?

var services = new ServiceCollection();
using var provider = services.BuildServiceProvider();
var concrete = provider.GetRequiredService<ConcreteService>();

GetRequiredService выбросит InvalidOperationException: сервис не зарегистрирован Метод вернёт null, несмотря на слово Required Контейнер сам зарегистрирует ConcreteService по его собственному типу Программа не скомпилируется из-за отсутствующей регистрации Контейнер создаст объект и сохранит его как singleton

Вопрос 3 из 30

Как получить все зарегистрированные IHandler?

services.AddTransient<IHandler, EmailHandler>();
services.AddTransient<IHandler, SmsHandler>();

public Dispatcher(IEnumerable<IHandler> handlers) { }

Использовать dynamic Внедрить IEnumerable<IHandler> Вызвать GetService<IHandler> пять раз Добавить static list вручную IHandler[] только через reflection

Вопрос 4 из 30

Что даёт open generic registration?

services.AddScoped(typeof(IRepository<>), typeof(EfRepository<>));

Разрешение любого interface без implementation Запрет constraints Генерация кода во время выполнения обязательна Правило построения закрытых вариантов, например IRepository<Order> Open generic создаёт один singleton для всех закрытых типов

Вопрос 5 из 30

Как раньше обнаружить неразрешимый граф?

Отключить предупреждения контейнера, чтобы построение provider завершилось успешно Включить ValidateOnBuild/ValidateScopes и добавить smoke-тест построения provider Проверять граф только первым production-запросом, когда будут известны реальные параметры Использовать GetService вместо GetRequiredService Ждать NullReferenceException при первом использовании отсутствующей зависимости

Вопрос 6 из 30

Что означает Scoped в ASP.NET Core?

services.AddScoped<RequestState>();
using var scope = provider.CreateScope();
var first = scope.ServiceProvider.GetRequiredService<RequestState>();
var second = scope.ServiceProvider.GetRequiredService<RequestState>();

Один на controller type Новый объект на каждое обращение к полю Один на поток Один объект на процесс Один экземпляр на scope, обычно на HTTP-запрос

Вопрос 7 из 30

Почему singleton не должен напрямую зависеть от scoped DbContext?

services.AddSingleton<ReportCache>();
services.AddScoped<AppDbContext>();

public sealed class ReportCache(AppDbContext db)
{
}

Scoped-контекст окажется захвачен долгоживущим singleton-объектом Scoped-зависимость автоматически становится потокобезопасной внутри singleton Проблема возникает только из-за наличия метода Dispose у DbContext Singleton-сервисам запрещено иметь конструкторы с параметрами Контекст будет создаваться заново при каждом обращении к полю singleton

Вопрос 8 из 30

Как BackgroundService получить scoped-сервис на одну итерацию?

using var scope = scopeFactory.CreateScope();
var worker = scope.ServiceProvider.GetRequiredService<ScopedWorker>();
await worker.RunAsync(stoppingToken);

Создать ServiceProvider заново Использовать ThreadLocal Создавать scope через IServiceScopeFactory на итерацию Сделать сервис static Внедрить scoped-сервис в constructor singleton

Вопрос 9 из 30

Кто Dispose-ит сервис, созданный контейнером?

Сборщик мусора до конца scope, если на сервис больше нет локальных ссылок Первый consumer после завершения собственного метода использования сервиса Контейнер при завершении соответствующего scope/provider Вызывающий метод считается владельцем любого полученного сервиса Никто: освобождением созданных сервисов занимается только сборщик мусора

Вопрос 10 из 30

Когда Transient IDisposable может быть проблемой?

var item = root.GetRequiredService<DisposableTransient>();
item.Use();

Корневой provider может удерживать созданные IDisposable до остановки приложения Когда объект создаётся вне контейнера, но его Dispose ошибочно ожидают от provider Контейнер освобождает transient сразу после возвращения из Resolve Только если Transient зарегистрирован вместе со Scoped-сервисом Transient IDisposable всегда освобождается в конце текущего метода

Вопрос 11 из 30

Где обычно находится composition root?

В миграции базы данных вместе с изменением схемы Только в тестовом проекте, но не в рабочем приложении В каждой доменной сущности рядом с её бизнес-методами В Program и модулях регистрации на внешней границе приложения В DTO, который пересекает границу HTTP-запроса

Вопрос 12 из 30

Зачем extension-метод AddBillingModule?

public static IServiceCollection AddBillingModule(
    this IServiceCollection services, IConfiguration config)
{
    services.AddOptions<BillingOptions>()
        .Bind(config.GetSection("Billing"))
        .ValidateDataAnnotations()
        .ValidateOnStart();
    return services.AddScoped<IBillingService, BillingService>();
}

Скрыть регистрации так, чтобы composition root не видел зависимостей модуля Чтобы все сервисы стали singleton Сгруппировать регистрации одного модуля Чтобы отключить validation Чтобы создать service locator

Вопрос 13 из 30

Что решает decorator?

public sealed class LoggingSender(IMessageSender inner, ILogger<LoggingSender> log)
    : IMessageSender
{
    public async Task SendAsync(Message message, CancellationToken token)
    {
        log.LogInformation("Sending {Id}", message.Id);
        await inner.SendAsync(message, token);
    }
}

Создаёт новый scope Удаляет исключения Добавить поведение вокруг сервиса без смены контракта Decorator подменяет интерфейс конкретным классом и скрывает исходный сервис Decorator преобразует синхронный контракт в async без изменения интерфейса

Вопрос 14 из 30

Когда factory лучше прямой зависимости?

public interface IExporterFactory
{
    IExporter Create(ExportFormat format);
}

Когда конструктор пуст Когда создание зависит от данных времени выполнения Чтобы использовать static state Чтобы скрыть цикл Для каждой singleton-зависимости

Вопрос 15 из 30

Как выбирать реализацию по фиксированному ключу в современном встроенном DI?

Использовать keyed services или собственную явную factory/strategy map Вызывать BuildServiceProvider внутри регистрации Сравнивать GetType().Name Менять registrations после старта Использовать reflection по namespace

Вопрос 16 из 30

Почему IServiceProvider в доменном сервисе — запах?

public sealed class CheckoutService(IServiceProvider services)
{
    public Task RunAsync() =>
        services.GetRequiredService<IPaymentGateway>().ChargeAsync();
}

IServiceProvider — лишь медленный lookup без архитектурных последствий Он создаёт только singleton Зависимости скрыты и обнаруживаются при выполнении Это запрещено компилятором Он не generic

Вопрос 17 из 30

Что не так с GetService<T>() для обязательной зависимости?

var sender = provider.GetService<IEmailSender>();
sender!.Send(message);

GetService работает только внутри тестовых проектов GetService сразу выбрасывает исключение при отсутствии регистрации Ошибка регистрации превращается в поздний null и менее ясный сбой Каждый вызов GetService всегда создаёт два экземпляра сервиса Проблема ограничивается предупреждением nullable и не влияет на выполнение

Вопрос 18 из 30

Почему BuildServiceProvider внутри ConfigureServices опасен?

Вызов удаляет уже добавленные регистрации из исходной коллекции Опасность только в кратковременном увеличении памяти при запуске Создаётся второй контейнер, из-за чего дублируются singleton и нарушается владение объектами Второй контейнер не умеет читать Options и конфигурацию Второй контейнер автоматически разделит singleton с основным

Вопрос 19 из 30

Когда IServiceProvider допустим?

В сущности, чтобы загружать репозитории по мере необходимости На инфраструктурной границе, где динамический выбор реализации — часть обязанности В value object, чтобы получать форматирование из контейнера В сервисе, чтобы скрыть циклическую зависимость от валидатора В каждом действии контроллера вместо явных параметров конструктора

Вопрос 20 из 30

Как заменить locator, выбирающий formatter по enum?

public sealed class FormatterFactory(
    IReadOnlyDictionary<Format, IFormatter> formatters)
{
    public IFormatter Get(Format format) => formatters[format];
}

Сериализовать enum Вызывать new для всех внутри метода Внедрить IFormatterFactory/словарь стратегий с явным контрактом Использовать static ServiceProvider Передать глобальный provider

Вопрос 21 из 30

Какой smoke-тест полезен для DI?

var services = new ServiceCollection();
services.AddApplication(configuration);
using var provider = services.BuildServiceProvider(new ServiceProviderOptions
{
    ValidateOnBuild = true,
    ValidateScopes = true
});
provider.GetRequiredService<OrderEndpoint>();

Запустить GC Сравнить service names Проверить число строк Program.cs Собрать provider и разрешить ключевые точки входа Mock-нуть IServiceCollection

Вопрос 22 из 30

Как проверить Scoped lifetime?

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

Вопрос 23 из 30

Что журналировать при resolution failure?

Все значения Options вместе с секретными параметрами Тип сервиса, цепочку ошибок и версию среды без секретов Все options с секретами Полный provider dump Только текст верхнего исключения без типа запрошенного сервиса

Вопрос 24 из 30

Нужен ли health check, который создаёт весь граф на каждый запрос?

Обычно нет: граф проверяют при запуске, а текущую проверку направляют на критичные зависимости Нет: проверка работоспособности не должна касаться зависимостей вообще Да: проверка должна разрешать каждый singleton перед каждым ответом Нужно создавать только scoped-сервисы и не проверять внешние системы Да: редкий запуск делает полное создание графа безопасным

Вопрос 25 из 30

Как увидеть слишком частое создание transient-сервиса?

metrics.ServiceCreated.Add(1, new("service", "PdfRenderer"));

Удалить Dispose Сделать сервис static Метрика созданий или профиль аллокаций по типу Проверить только logs startup Считать constructors вручную в production

Вопрос 26 из 30

Что должно происходить в constructor сервиса?

Синхронный HTTP-запрос для загрузки начального состояния Запуск долгоживущей фоновой задачи без возможности отмены Присваивание зависимостей и проверка дешёвых инвариантов без ввода-вывода Применение миграций и открытие соединения с базой Полное чтение файлов конфигурации и прогрев внешнего API

Вопрос 27 из 30

Почему слишком широкий constructor — архитектурный сигнал?

public MegaService(A a, B b, C c, D d, E e, F f, G g, H h) { }

Класс, вероятно, смешал слишком много обязанностей DI поддерживает максимум 4 параметра Число параметров конструктора важно только из-за аллокаций Нужно заменить всё provider Он не компилируется

Вопрос 28 из 30

Когда внедрение зависимостей, сгенерированное во время компиляции, особенно полезно?

Когда AOT не используется, а время запуска уже не является проблемой Когда бизнес-код должен получать сервисы через глобальный provider Когда нужно исправить циклическую зависимость без изменения графа Когда важны запуск или AOT, а динамическое разрешение реально ограничивает публикацию Для любого небольшого приложения независимо от измерений

Вопрос 29 из 30

Почему singleton-кэш не всегда ускоряет систему?

Singleton-кэш очищается сборщиком мусора после каждого запроса Кэш не может загружать данные асинхронно Без лимита и потокобезопасности он удерживает память, создаёт конкуренцию и отдаёт устаревшие данные Dictionary внутри singleton нельзя синхронизировать Он создаётся заново в каждой области и поэтому не сохраняет данные

Вопрос 30 из 30

Как DI помогает модульной архитектуре?

services.AddOrdersModule();
services.AddPaymentsModule();

Контейнер сам запрещает все связи, не описанные в архитектурной схеме После регистрации все внутренние классы модулей становятся публичными Модульная регистрация устраняет необходимость в архитектурных тестах Регистрация сервисов полностью заменяет правила зависимостей между проектами Модули связываются через опубликованные интерфейсы и явную композицию

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу