Лучшие практики для сохранения сохраненных в базе данных поисковых данных на уровне приложения в MVC

Question

Пробираясь через MVC + EF и пытаясь сосредоточиться на правильных действиях. Сейчас я хочу добавить в форму раскрывающийся список, но я бы хотел избегать попадания в базу данных при каждой загрузке страницы, поэтому я хотел бы сохранить данные на уровне приложения. Я считаю, что создание переменной уровня приложения - не лучший подход. Я читал об использовании кеша и статических утилит, но, что удивительно, ничто не звучало так уж определенно. (Статические классы плохо подходят для модульного тестирования, плохо кэшируются

Итак, у меня есть два сценария, которые мне интересны, я не уверен, будет ли подход отличаться между ними.

1) Базовый поиск, скажем, пятьдесят состояний. Маленький, определенный, никогда не изменится. Загрузка при запуске приложения. (Не ищет жестко закодированное решение, но поиск из базы данных.)

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

Похоже на базовые вещи, но в основном это то же самое, что и эта тема, на которую никогда не отвечали:

Хорошо ли использовать статический контекст объекта EF в приложении MVC для лучшей производительности?

Любая помощь приветствуется.

Answer 1

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

Вторая часть - это «правильный» способ сохранить этот тип постоянных данных, чтобы вам не приходилось совершать поездки в БД для заполнения общих элементов пользовательского интерфейса. Для этого я не рекомендую хранить объекты EF. Я хотел бы создать объекты POCO (View модели или аналогичные), которые вы кэшируете. Так что в примере с вашими 50 штатами у вас может быть что-то вроде этого:

public class State
{
    public string Abbreviation { get; set; }

    public string Name { get; set; }
}

Тогда вы бы сделали что-то подобное для создания своего кэшированного списка:

List<State> states = Context.StateData.Select(s => new State { Abbreviation = s.Abbreviation, Name = s.Name}).ToList();

Наконец, каким бы ни было ваше решение для кэширования, в нем должен быть реализован интерфейс, позволяющий смоделировать этот метод кэширования для тестирования.

Чтобы сделать это без использования циклических ссылок или использования отражения, вам потребуется как минимум 3 сборки:

Ваше приложение MVC Библиотека классов для определения ваших объектов и интерфейсов POCO Библиотека классов выполняет доступ к данным и кеширование (очевидно, что это можно разделить на 2 библиотеки, если это облегчает поддержку и / или тестирование)

Таким образом, вы можете иметь что-то подобное в своем коде MVC:

ICache myCache = CacheFactory.CreateCache();
List<State> states = myCache.ListStates();
// populate your view model with states

Где ICache и State находятся в одной библиотеке, а ваша фактическая реализация ICache - в другой.

Это то, что я делаю для своей стандартной архитектуры: разделение объектов POCO и интерфейсов, которые не зависят от доступа к данным, в отдельную библиотеку от доступа к данным, который отделен от моего приложения MVC.

Answer 2

Изучите использование инструмента внедрения зависимостей, такого как Unity, Nineject, Structuremap и т. Д. Они позволят получить требуемый контроль уровня приложения, реализовав ядро, которое удерживает объекты очень похоже на то, что вам кажетсябыть описывающим.