Сегрегация интерфейса зависимостей в основной области AspNet - PullRequest
0 голосов
/ 11 сентября 2018

Итак,

// this doesn't work or make sense
services.AddScoped<IReadSomething>(sp => new Something());
services.AddScoped<IWriteSomething>(sp => new Something());

Итак, у меня есть два интерфейса для одного и того же класса, IReadSomething и IWriteSomething, класс просто Something.

Они должны быть ограничены областью, потому что они переносят подмножество данных из HttpContext в произвольную независимую от фреймворка 'DTO'.

Они оба должны ссылаться на один и тот же экземпляр Something, очевидно, один из них просто представляет некоторые операции чтения, а другой - некоторые операции записи. Таким образом, он записывается где-то в конвейере Middleware - и остальная часть приложения может просто использовать IReadSomething и читать данные, чтобы мы могли уменьшить случайное перезапись данных.

Ведение

services.AddScoped<IReadSomething, Something>();
services.AddScoped<IWriteSomething, Something>();

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

Чего мне не хватает, чтобы заставить сегрегацию интерфейса и разрешение зависимостей по объему работать вместе - я чувствую, что мне нужно беспокоиться о ASP.NET Core Scoped Service Factory или чем-то подобном?

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

1 Ответ

0 голосов
/ 11 сентября 2018

Сделайте область видимости целевого класса и затем свяжите его с желаемыми интерфейсами

services.AddScoped<Something>();
services.AddScoped<IReadSomething>(sp => sp.GetService<Something>());
services.AddScoped<IWriteSomething>(sp => sp.GetService<Something>());

Таким образом, вызов для любого интерфейса вернет один и тот же экземпляр в области действия

...