.NET MVC3 Service Locator / Resoldency Resolver Вопрос с Ninject

Question

У меня есть то, что я считаю стандартным шаблоном репозитория .NET MVC3, с которым я играю / учусь.Это довольно стандартная структура.

• Проект репозитория (с упомянутой ниже инфраструктурой кэширования)
• Проект доменной модели
• Проект сервисного уровня
• Презентация MVCproject

Я столкнулся со сценарием, в котором мне нужно внедрить закрытый член класса, в котором есть только статический конструктор, из-за чего мне не везет в конструктор.

Рассматриваемый класс является оболочкой для использования реализации кэширования AppFabric, которую я только что завершил.(Для тех, кто так склонен, моя реализация основана на http://cgeers.wordpress.com/2010/07/04/windows-server-appfabric-caching/)

По существу у меня есть:

• интерфейс ICacheProvider
• класс DefaultCacheProvider: ICacheProvider
• Кэш статического класса (используя любую внедренную мной реализацию)

Кэш статического класса - это то место, где я хотел бы внедрить ICacheProvider, который разрешается в DefaultCacheProvider.

    private static readonly ICacheProvider CacheProvider;

    static Cache()
    {
        //DependencyResolver.Current.GetService<ICacheProvider>();

        //CacheProvider =
        //    (ICacheProvider)ServiceLocator.Current
        //                            .GetInstance(typeof(ICacheProvider));
    }

    public static void Add(string key, object value)
    {
        CacheProvider.Add(key, value);
    }

    public static void Add(string key, object value, TimeSpan timeout)
    {
        CacheProvider.Add(key, value, timeout);
    }

    public static object Get(string key)
    {
        return CacheProvider[key];
    }

    public static bool Remove(string key)
    {
        return CacheProvider.Remove(key);
    }

Исходя из того, что я прочитал, это похоже на сценарий для ServiceLocator, но я видел несколько очень сильных мнений по этому поводу (анти-паттерн и т. Д.), Что и мое знакомство с ним низкое, поэтому яЯ не уверен в реализации, которая бы работала.

Я видел рекомендацию по StackOverflow проектировать класс Cache как стандартный класс и внедрять ICacheProvider в SingletonScope

kernel.Bind<ICacheProvider>().To<DefaultCacheProvider>().InSingletonScope();

, но ялично я предпочел бы статическую оболочку для простоты использования.

Является ли установка ServiceLocator подходом или есть что-то еще очевидное, чтоЯ не в курсе?Если ServiceLocator - это путь, есть ли связь с Ninject для использования?Я знаю, что Ninject теперь имеет возможности поиска сервисов, но не знал, как это реализовать.

Спасибо за любую информацию.

Answer 1

Я думаю, что в вашем подходе отсутствует сущность контейнера Inversion of Control для обеспечения внедрения зависимостей.

Исходя из того, что я прочитал, это похоже на сценарий для ServiceLocator, но я видел несколько очень сильных мнений по этому поводу (анти-паттерн и т. Д.)

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

Как выглядит код, который потребляет синглтон Cache? Позвольте мне предложить гипотетическое.

public class SomeClass
{
    public string GetSomeMetaData()
    {
        return Cache.Get("magicKey");
    }
}

В этом случае вы абстрагируете IoC и избегаете DI, используя Singleton. Я бы предложил

public class SomeClass
{
    private readonly ICacheProvider _cacheProvider;

    public SomeClass(ICacheProvider cacheProvider)
    {
        _cacheProvider = cacheProvider;
    }

    public string GetSomeMetaData()
    {
        return _cacheProvider.Get("magicKey");
    }
}

Теперь потребление ICacheProvider происходит непосредственно в классе, который нуждается в нем, и может легче приспособиться к изменению ICacheProvider реализаций. У этого было дополнительное преимущество упрощения тестирования. Синглтон-паттерн практически невозможно проверить.