Web Dev - Где хранить состояние объекта, подобного магазинной корзине?

Вы создаете веб-приложение. Вам нужно сохранить состояние для корзины, например , во время сеанса пользователя.

Некоторые примечания:

  • Это не точно корзина для покупок, но больше похожа на маршрут, который пользователь создает ... но мы будем использовать слово cart, на которое теперь ссылается b/c ppl.
  • Вам не нужны «заброшенные» тележки.
  • Как только тележка будет завершена, мы сохраним ее в некоторых хранилищах на стороне сервера для последующего поиска.

Where do you store that stateful object? And how?

  • сервер (сеанс, db и т. д.?)
  • клиент (cookie key-vals, файл cookie JSON, скрытое поле формы и т. д.?)
  • другой ...

Update: It was suggested that I list the platform we're targeting - tho I'm not sure its totally necessary... but lets say the front-end is built w/ASP.NET MVC.

0
добавлено отредактировано
Просмотры: 27

11 ответы

Храните его в базе данных.

0
добавлено

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

http://www.scottcommonsense.com/toolbox.aspx

Нажмите «Контрольный список продуктов», чтобы открыть окно. Он использует ASPX, но только для управления ссылками JS, размещенными на странице. Остальное делается через AJAX, используя веб-службы.

Ранее я создал сайт ASP.NET 2.0 для сайта коммерции, который автоматически использовал cookie anon/auth. Каждый из них предоставляет вам значение GUID, которое вы можете использовать для идентификации пользователя, который затем связан с данными в вашей базе данных. Мне нужны файлы cookie, с которыми пользователь мог перейти на разные компьютеры; работа, дом и т. д. Я избегал использования полей «Профиль» для хранения сложного объекта ShoppingBasket, который был популярен за все время в книгах ASP.NET 2.0. Я не хотел заниматься «магическими» проблемами сериализации, поскольку структура данных менялась со временем. Я предпочитаю управлять изменениями схемы db с помощью скриптов update/alter, синхронизированных с изменениями программного обеспечения.

Если cookie anon/auth идентифицирует пользователя на клиенте, вы можете использовать клиентскую часть ASP.NET AJAX для вызова веб-служб проверки подлинности с использованием прокси-серверов JS, которые предоставляются вам как часть ASP.NET. Вам необходимо реализовать API-интерфейс членства, чтобы, по меньшей мере, аутентифицировать пользователя. Остальная реализация провайдера может безопасно сбрасывать NotImplementedException. Затем вы можете использовать свои собственные веб-службы ASMX через AJAX (см. Атрибут ScriptReference) и обновлять страницы с данными на стороне сервера. Вы можете полностью избавиться от ASPX-страниц и просто использовать статический HTML/CSS/JS, если хотите.

Одно большое предостережение - утечка памяти в JS. Пребывание на одной странице долгое время увеличивает вашу потенциальную проблему с утечками памяти. Это риск, который вы можете свести к минимуму путем тестирования длительных сеансов и использования таких инструментов, как Firebug и других, для поиска утечек памяти. Используйте инструмент JS Lint, а также помогите выявить основные проблемы во время вашей работы.

0
добавлено
Мне нравится этот подход, за исключением того, что я, скорее всего, буду использовать вызовы MVC и RESTful AJAX (возвращая JSON или разметку), поэтому мне не нужно будет беспокоиться о ASMX или ASPX cruft.
добавлено автор stevenharman, источник

Если вы не заботитесь о заброшенных тележках и имеете вещи для того, чтобы кто-то возился с данными на стороне клиента ... Я думаю, что cookie будет хорошим - особенно если это всего лишь куки данных JSON.

0
добавлено
Да, я согласен, что это действительно зависит от требований приложения относительно того, будет ли это лучший маршрут.
добавлено автор Ryan Lanciaux, источник
Файлы cookie ограничены 4K. Это может быть недостаточно данных, в зависимости от размера корзины покупок.
добавлено автор 64BitBob, источник

Я бы сказал, хранили состояние где-то на сервере и сопоставляя его с сеансом пользователя. Хотя файл cookie может быть равным местом для хранения вещей, если вы считаете безопасность и размер данных, сохранение как можно большего количества данных на сервере становится хорошей вещью.

Например, в настройках публичного терминала, было бы хорошо, если бы кто-то посмотрел содержимое файла cookie и посмотрел список? Если это так, cookie в порядке; если нет, вам просто нужен идентификатор, который связывает пользователя с данными. Это также позволит вам убедиться, что пользователь прошел аутентификацию на сайте, чтобы получить эти данные, а не хранить все на машине - им нужна определенная форма учетных данных , а также сеанс идентификатор.

С точки зрения размера, конечно, вы не будете слишком обеспокоены файлом cookie 4K или чем-то для пользователя браузера/широкополосного доступа, но если одна из ваших целей - разрешить подключение к мобильному телефону или BlackBerry (а не 3G) и иметь быстрый опыт (и не получать счета за данные), ключом будет минимизация объема данных, передаваемых клиенту.

Хранилище сервера также дает вам некоторую гибкость, упомянутую в некоторых других ответах: пользователь может сохранить свою тележку на одной машине и возобновить работу с ней на другом; вы можете привязать тележку к некоторым формам учетных данных (а не к переходной сессии) и сохраняться в тележке задолго до того, как пользователь очистит свои файлы cookie; вы получаете немного больше на пути отказоустойчивости - если браузер пользователя выходит из строя, на сайте все еще есть данные, безопасные и надежные.

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

Независимо от того, выбираете ли вы ключевой переходный сеанс или учетные данные, зависит от того, смогут ли пользователи сохранить свои данные и вернуться позже, чтобы получить его. Переходный сеанс в конечном итоге будет очищен как «заброшенный», и, возможно, все в порядке. Привязка к профилю пользователя позволит пользователю сохранять свои данные и явно отказываться от него. В любом случае, я бы использовал какой-то резервный магазин, такой как база данных для отказоустойчивости и центральной доступности. (Или, может быть, я переоцениваю решение?)

0
добавлено

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

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

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

0
добавлено
Я думаю, что это правильное предложение - за исключением того, что я, вероятно, использовал бы файлы cookie с JSON на стороне клиента, а не сеанс ...
добавлено автор stevenharman, источник
Как насчет ограничений размера файлов cookie? Как насчет печенья? Это может быть хорошо для списка, но для корзины это кажется действительно сырым? Что произойдет, если вы измените схему данных?
добавлено автор Andrew Rimmer, источник

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

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

0
добавлено

Without knowing the platform I can't give a direct answer. However, since you don't care about abandoned carts, then I would differ from my colleagues here and suggest storing it on the client. Why store it in the database if you don't care if it's abandoned?
Then again, it does depend on the size of the object you're storing -- cookies have their limits after all.

Edit: Ahh, asp.net MVC? Why not use the profile system? You can enable an anonymous profile if you don't want to bother making them log in

0
добавлено

В DB привязаны к тому, что вы используете для сеансов (сеансы db/memcache, подписанные файлы cookie) или к аутентифицированному пользователю.

0
добавлено
Там может быть даже не дБ (по крайней мере, не реляционный) ... :)
добавлено автор stevenharman, источник
Храните его в хранилище данных «на стороне сервера» :). Почему есть 2 разных хранилища данных? Хранение серверной части повышает гибкость и безопасность.
добавлено автор Andrew Rimmer, источник

Если вы заботитесь о поддержке пользователей без включенного Javascript, сеансы на стороне сервера позволят вам использовать переписывание URL.

0
добавлено

Представляете ли вы, что люди должны иметь возможность запускать на одной машине (например, их рабочий ПК), но продолжать/финишировать с другого компьютера (например, домашнего ПК)? Если да, то ответ очевиден.

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

Я использовал бы (зашифрованный) файл cookie на клиенте, который содержит идентификатор корзины пользователей. Если это действительно загруженный сайт, то заброшенные корзины не будут заполнять базу данных с помощью too , и вы можете запустить обычную задачу администрирования, чтобы очистить покинутые заказы, если вам это очень нужно. Также делая это таким образом, пользователь будет соблюдать свой порядок, если они закроют свой браузер и уйдут, корзина в сеансе будет очищена на этом этапе.

Наконец, это означает, что вам не нужно беспокоиться о написании кода для обработки/сериализации данных из клиентского файла cookie, а позже беспокоиться о том, чтобы действительно помещать эти данные в базу данных, когда она преобразуется в заказ (слишком много точки отказа по моему вкусу) ..

0
добавлено