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

Ответ 1

Это был мой опыт работы с Commerce Starter Kit и MVC Storefront (и другими сайтами, которые я построил), что независимо от того, что вы думаете сейчас, информация об пользовательских взаимодействиях с вашими "продуктами" имеет первостепенное значение для деловых людей. Там так много показателей для захвата - это орехи.

Я сохраню вам все, с чем я прошел, - что на сегодняшний день является самым успешным для меня - это просто создать объект Order с статусом "NotCheckedOut", а затем добавить к нему элементы, а пользователь добавит элементы. Это позволяет пользователям иметь больше одной тележки и позволяет вывести tar из таблицы Orders. Также довольно легко выполнить транзакцию - просто измените статус.

Сохранение "по мере того, как они идут" также позволяет пользователю вернуться и закончить корзину, если они не могут по какой-то причине. Прощение огромно с электронной торговлей.

Cookies suck, session sucks, Profile привязан к понятию пользователя, и он попадает в БД, поэтому вы можете также использовать БД.

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

Ответ 2

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

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, а также помогите определить основные проблемы, когда вы идете.

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

Изменить: Ahh, asp.net MVC? Почему бы не использовать систему профилей? Вы можете включить анонимный профиль, если вы не хотите беспокоиться о том, чтобы сделать их вход в систему

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

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

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

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

Ответ 11

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

Ответ 12

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

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