Могу ли я использовать вспомогательный метод статического кэша в контроллере NET MVC?

Question

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

Есть два замечательных примера, с которыми я пытался работать, но будучи новичком в MVC, мне интересно, какой из них самый чистый и лучше всего подходит методологии MVC? Я знаю, что вам нужно учитывать DI и юнит-тестирование.

Пример 1 (вспомогательный метод с делегатом)

... в контроллере

var myObject = CacheDataHelper.Get(thisID, () =>
WebServiceServiceWrapper.GetMyObjectBythisID(thisID));

Пример 2 (проверка наличия кэша в классе модели) в контроллере

var myObject =   WebServiceServiceWrapper.GetMyObjectBythisID(thisID));

затем в классе модели ..............

if (!CacheDataHelper.Get(cachekey, out myObject)) {

//do some repository processing

// Add obect to cache CacheDataHelper.Add(myObject, cachekey);

}

Оба используют класс вспомогательного статического кэша, но в первом примере используется сигнатура метода с переданным методом делегата, который имеет имя вызываемого метода репозитория. Если данные не находятся в кэше, вызывается метод, и класс помощника кэша обрабатывает добавление или обновление текущего кэша.

Во втором примере проверка кэша является частью метода репозитория с дополнительной строкой для вызова метода добавления вспомогательного кэша для обновления текущего кэша.

Из-за недостатка опыта и знаний я не уверен, какой из них лучше всего подходит для MVC. Мне нравится идея вызова помощника кеша с именем метода делегата, чтобы удалить любой код кеша в хранилище, но я не уверен, идеально ли использовать статический метод в контроллере?

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

Answer 1

У меня довольно большой проект, в котором мы выполняем Пример 1 - Статический класс Cache с делегатом поиска, используемым из контроллеров.На самом деле, в нашем случае у нас есть уровень класса обслуживания, который обрабатывает кэширование, а контроллеры ссылаются на уровень обслуживания.Сервисный уровень имеет дело с извлечением данных, кэшированием, проверкой разрешений и т. Д., В то время как контроллеры в основном занимаются сборкой данных из сервисов в модели.

По вашему вопросу вам не обязательно нужен статический помощник кеша.Вы можете использовать DI, чтобы внедрить экземпляр вашего помощника кеша, чтобы потом смоделировать его для тестирования и т. Д.

Answer 2

Я бы, конечно, не поместил кеширующий код в модель. Он не занимается бизнесом, зная о характеристиках кэширования веб-приложения. Вам также не нужно использовать статический экземпляр в ваших контроллерах. Вы можете достичь того же эффекта и сохранить тестируемость, сделав свой CacheHelper обычным классом (по всей видимости, обернутым вокруг веб-кэша) или одиночным. В любом случае вы использовали бы инъекцию для предоставления экземпляра вашему контроллеру.

Простой способ сделать это без DI-фреймворка состоит в том, чтобы конструктор, который принимает экземпляр помощника, создал подходящее значение по умолчанию, если предоставленный параметр равен нулю. Ваш конструктор по умолчанию, который использует фабрика контроллеров, вызывает этот конструктор с нулевым экземпляром, и поэтому вы получаете значение по умолчанию. Ваши тесты вызывают его с фиктивным экземпляром, и поэтому вы поддерживаете тестируемость.

Если вы используете обычный класс для своего помощника - я настоятельно рекомендую вам попробовать сделать эту работу - вы можете использовать ту же технику для внедрения объекта Cache. К этому так, чтобы это могло быть проверено также.