предварительно заполнить модели MVC с помощью IOC - альтернатива кешированию?

Question

Я рассматриваю стратегии простой реализации CMS для сайта ASP.NET MVC. Простая часть состоит в том, что я абстрагировал значения, используемые в различных частичных представлениях, каждый из которых является пользовательским элементом управления, который использует идентичные макеты CSS. Поэтому я заполняю пользовательские значения в идентичных частичных представлениях из базы данных, где я могу время от времени изменять их, используя CRUD.

Не очень простая часть - это достаточно эффективная и логичная абстракция стандартного элемента пользовательского интерфейса в виде строки таблицы SQL. Но, отложив это в сторону ...

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

То, что заставляет меня думать, что я немного схожу с ума, - это время загрузки статических данных. Но опять же, SharePoint!

Так (я думаю), почему бы не загрузить все это в application_start? Почему бы и нет? Я отвечаю! Затем я использую IoC для чего-то, что Google не возвращает ни одной ссылки на полезную информацию даже от одного умного человека, который когда-либо считал, что это может быть разумной идеей.

Так есть ли у кого-нибудь лучшая идея для заполнения Model из базы данных с использованием контейнера IoC, кроме помещения вызова репозитория в конструктор?

И потом, кто-нибудь думает, что помещать эти модели статических данных в контейнер IoC, доступный для контроллеров, - глупая идея?

Спасибо,

S. Machino

Answer 1

Следуя нескольким принципам SOLID, держите ваши вещи как можно более целеустремленными. Для полустатических данных сначала создайте репозиторий, который загружает эти данные. Это загрузит данные для каждого запроса. Он работает, но, вероятно, не так хорошо работает, но теперь у вас есть нужная реализация.

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

Таким образом, вы уважаете Разделение забот.

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

Answer 2

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

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