Шаблон стратегии с ASP.Net Core DI
Создавая свой Rest API, я наткнулся на создание кэшированного репозитория на основе эта статья.
Создание кэшированного репозитория с помощью шаблона стратегии
Идея понравилась, потому что код казался красивым и сухим. Поэтому я пошел и попробовал, и реализация была довольно хорошей.
Однако теперь я хочу подключить свой DI (стандартный Microsoft DI, поставляемый с ASP.Net Core и ничего особенного), и я столкнулся с некоторыми проблемами.
В основном проблема в том, что у меня есть несколько реализаций одного и того же интерфейса, а кешированная реализация берет ссылку на прямую реализацию следующим образом:
public class CachedArticleRepository : IArticleRepository
{
public CachedArticleRepository(IArticleRepository article, IMemoryCache cache)
{
_article = article;
_cache = cache;
}
}
public class ArticleRepository : IArticleRepository
{
public ArticleRepository(IAmbientContextLocator locator)
{
_locator = locator;
}
}
Я использую его в своем сервисе (как объясняется в статье) следующим образом:
public class DivisionService : IDivisionService
{
public DivisionService(IArticleRepository article)
{
_article = article;
}
}
Мой вопрос теперь в том, как я могу настроить DI так, чтобы вариант без кеширования использовался для создания кэшированного репозитория, а кэшированный репозиторий использовался для всего остального?
Класс CachedArticleRepository является реализацией Шаблон проектирования декоратора.
Ответы 1
Используйте перегрузку фабричного делегата при регистрации службы
//...
services.AddScoped<ArticleRepository>();
services.AddScoped<IArticleRepository, CachedArticleRepository>(serviceProvider => {
IArticleRepository nonCachedVarient = serviceProvider.GetService<ArticleRepository>();
IMemoryCache cache = serviceProvider.GetService<IMemoryCache>();
return new CachedArticleRepository (nonCachedVarient, cache);
});
//...
Таким образом, вариант без кеширования используется для создания кэшированного репозитория, а кэшированный репозиторий - для всего остального.
В приведенном выше коде предполагается, что в коллекцию служб добавлены все остальные зависимости.
CachedArticleRepository зарегистрирован как IArticleRepository, поэтому он будет разрешен всякий раз, когда потребуется эта зависимость.
Вы можете изменить срок службы по своему усмотрению. AddScoped использовался только для демонстрации процесса регистрации.
Сработало как Очарование, спасибо за то, что сделали и спасли мне день (снова) @Nkosi: D
использовать фабричный делегат при регистрации службы