Хранить объекты на сессии в направляющих
Я не уверен, сколько из примера "реального мира" это, но у меня в настоящее время есть приложение там, которое хранит детали для торговой карточной игры, включая изображения для карт. Предоставленный количество записей для базы данных только 2 851 запись до настоящего времени, но учитывая тот факт, что определенные карты имеют, выпущены многократно и имеют альтернативные иллюстрации, это был на самом деле более эффективный sizewise, чтобы просканировать "основной квадрат" иллюстраций и затем динамично генерировать границу и разные эффекты для карты, когда требуется.
исходный создатель этой библиотеки изображений создал класс доступа к данным, который представляет изображение на основе запроса, и это делает это довольно быстро для просмотра и отдельной карты.
Это также упрощает развертывание/обновления, когда новые карты выпущены, вместо того, чтобы архивировать всю папку изображений и отправить тем вниз канал и гарантировать, что надлежащая структура папок создается, я просто обновляю базу данных и сделал, чтобы пользователь загрузил ее снова. Это в настоящее время измеряет до 56 МБ, который не является большим, но я работаю над функцией инкрементного обновления будущих выпусков. Кроме того, нет "никакого изображений" версия приложения, которое позволяет тем по коммутируемому доступу получать приложение без задержки загрузки.
Это решение работало отлично до настоящего времени, так как само приложение предназначено как единственный экземпляр на рабочем столе. Существует веб-сайт, где все эти данные заархивированы для онлайн-доступа, но я никоим образом не использовал бы то же решение для этого. Я соглашаюсь, что доступ к файлу был бы предпочтителен, потому что он масштабируется лучше к частоте и объему запросов, сделанных для изображений.
, Надо надеяться, это не слишком много лепета, но я видел тему и хотел обеспечить некоторое свое понимание из относительно успешного маленького/среднего приложения масштаба.
4 ответа
Основная причина не сохранять объекты в сеансе заключается в том, что если структура объекта изменится, вы получите исключение. Примите во внимание следующее:
class Foo
attr_accessor :bar
end
class Bar
end
foo = Foo.new
foo.bar = Bar.new
put_in_session(foo)
Затем в следующем выпуске проекта вы измените имя Bar. Вы перезагружаете сервер и пытаетесь вывести foo из сеанса. Когда он пытается десериализоваться, он не может найти Bar и взрывается.
Может показаться, что избежать этой ловушки будет легко, но на практике я видел, как он укусил множество людей. Это просто потому, что сериализация объекта иногда может занимать больше, чем сразу видно (такого рода вещи должны быть прозрачными), и если у вас нет строгих правил по этому поводу, все будет иметь тенденцию запутаться.
Причина, по которой это обычно не одобряется, заключается в том, что это « Это очень распространено, чтобы укусить людей в ActiveRecord, поскольку довольно часто структура вашего приложения меняется со временем, а сеансы могут десериализоваться через неделю или дольше после их первоначального создания.
Если вы все это понимаете и готовы приложить усилия, чтобы убедиться, что ваша модель не изменится и не сериализует ничего лишнего, вы, вероятно, в порядке. Но будьте осторожны :)
Rails имеет тенденцию поощрять RESTful-дизайн, а использование сессий не очень похоже на RESTful. Я бы, наверное, сделал ресурс Quiz, в котором есть несколько слов, а также current_word. Таким образом, когда они вернутся, вы будете знать, где они были.
Итак, REST - это еще не все (в зависимости от того, с кем вы разговариваете), но есть довольно хороший аргумент против больших сессий. Помните, что сеансы записывают данные на диск и с диска, и чем больше данных вы записываете, тем больше времени требуется на обратное чтение ...
Поскольку ваше приложение является приложением Rails, я бы предложил:
- Использование способности ваших клиентов кэшировать путем кеширования карт в javascript. (вам понадобится приложение ajaxy, чтобы сделайте это, см. последний RailsCast для некоторых интересных моментов по кэшированию страниц javascript)
- Используйте один из многих других поддерживаемых rails серверных параметры кэширования (например, MemCached) в кэшировать эти данные.
A much more insidious issue you'll encounter storing objects directly in the session is when you're using CookieStore (the default in Rails 2+ I believe). It's very easy to get CookieOverflow errors which are very hard to recover from.