Долгосрочное состояние на многих веб-сессиях MVC

Question

Мне нужно создать сайт MVC, где модель данных, по-видимому, не подходит для базы данных и, конечно же, не может быть перестроена каждый сеанс. Есть ли способ эффективно создать статический класс на сайте MVC, который используется всеми пользователями/сеансами веб-сайта ... в течение нескольких недель за раз?

Деталь: У меня есть класс C#, который извлекает состояние из контроллера, предлагающего сырую фишку сокета (думаю, RS232). Скорость передачи данных этого контроллера медленная, и для создания правильных классов требуется требуемое состояние извлечения, имена строк для каждого элемента и т. Д. Это занимает 30 секунд. В классе устройств есть 2 дюжины или около того, поэтому это не тривиально. Вот почему я предложил сериализацию для SQL, было бы неплохо.

Использование терминов для настольных приложений ... При загрузке приложения инициализируются его статические классы. Конструктор статического класса будет запускаться один раз и получать текущее состояние. Он также зарегистрировал обработчик сокета aw, чтобы постоянно поддерживать активное состояние модели класса. Затем, когда пользователи запрашивают веб-страницы, сайт может использовать эту общую модель данных.

Упрощение здесь лучше, так как я не разработчик полного времени. Например: я бы предпочел не создавать полный веб-сервис, а затем должен сортировать все данные через JSON для 2 дюжины или около того объектов в классах устройств.

Answer 1

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

Кроме того, вы ничего не можете сделать, чтобы сохранить его дольше, чем приложение. Когда приложение умирает (например, 20 минут бездействия, или сайт перезапускается, ...) вся память освобождается, поэтому нет места, где вы можете сохранить ее, а не постоянный механизм (например, БД).

Если вы обнаружите, что сопоставление этой модели с реляционной БД - это слишком много усилий, вы можете захотеть взглянуть на решение NoSQL, такое как MongoDB, Riak ... Что вы делаете, это в основном сериализовать его в JSON и сохранить все граф. Затем вы можете получить его, просто десериализируя его.