Простая корзина с использованием переменных сеанса теперь с использованием AJAX

Question

Я знаю, что существует миллион вопросов о том, как внедрить корзину покупок на ваш сайт. Тем не менее, я думаю, что моя проблема может быть несколько иной. В настоящее время у меня есть рабочая корзина покупок, которую я написал за 1.1 дня, в которой используются переменные сеанса ASP.NET для отслеживания всего. Это существует уже около 6 лет и хорошо выполняет свою задачу. Тем не менее, пришло время обновить сайт, и часть того, что мне было поручено, - это создание более удобного для пользователя сайта. Частично это устранение updatepanel s и внедрение реальных решений AJAX.

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

Кроме того, способ обработки заказов был немного сложен. Все детали (выбранный цвет, выбранный тип и т. Д.) Передаются в PayPal через строку описания, которая по большей части в порядке, но если у продукта есть выборки, которые слишком длинны для строки (255 символов, я считаю), они отрезаны, и мы должны позвонить клиенту, чтобы подтвердить, что они купили. Если бы я внедрил более «солидную» корзину покупок, нам бы этого не пришлось делать, потому что все варианты клиента будут сохранены, в дополнение к тому, что заказ автоматически вводится в систему обработки заказов (они вводятся вручную таблица Excel. Я знаю, верно).

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

Спасибо!

Answer 1

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

Обработчик с IRequiresSessionState не продлевает время ожидания сеанса

другие ответы:

ASP.NET: как получить доступ к сеансу из обработчика?

Аутентификация в ASP.NET HttpHandler

Итак, что вы действительно хотите сделать, так этопросто посмотрите, чтобы реализовать PageMethods на ваших страницах, и тогда вы сможете сократить ОДНО накладные расходы на общение со страницами.Но если вы хотите перейти от того, что вы делаете сейчас, вы хотите начать реализовывать обработчики (и настроить их для использования JSON - для этого есть декоратор), и вы можете использовать это с jQuery.ajax() в качестве прямого URLи держите его в рамках вашего проекта.Обратите внимание, что по умолчанию он будет отправлять файлы cookie для вас, так что это не страшно.Причина, по которой я так говорю, заключается в том, что файл cookie содержит идентификатор из форм, позволяющий идентифицировать сеанс.

Поэтому, если вы используете IRequireSessionState, вы все равно можете использовать всю информацию о состоянии сеанса, которую вы используете.привык к использованию.Нет ничего плохого в использовании Session в сочетании с AJAX.Два действительно не имеют много общего друг с другом.Один используется для хранения на сервере, другой - для взаимодействия с сервером.

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

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

Что я мог бы уточнить здесь?

Answer 2

Есть несколько способов справиться с этим. Основной вопрос заключается в том, как долго вам нужно сохранять информацию о своей корзине (30 минут, 1 час, 1 день, 1 неделя и т. Д.).

Краткие требования к хранению Простое внедрение (30 минут - 1 час)

Вы можете использовать сеанс с методами страницы, используя HttpContext.Current.Session["key"], чтобы вы могли сохранить свое хранилище сеансов таким же, как оно в настоящее время работает для вас. Вы можете вызывать эти методы страницы с помощью jquery ajax довольно легко, и это устранит необходимость в панелях обновления, управлении сценариями и т. Д. Так что, на мой взгляд, это поможет вам на полпути. Ваши страницы будут загружаться быстрее и быстрее реагировать, и вам не придется выбрасывать код, связанный с кэшированием, во время сеанса. Основным недостатком этого является то, что вы все еще используете сеанс, поэтому вы действительно не хотите сохранять сеансы слишком долго, так как это приведет к зависанию сервера, на котором размещен сайт, если он достаточно активен.

Требования к длинному хранилищу Реализация на стороне сервера

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

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

Требования к длинному хранилищу Реализация на стороне клиента

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

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

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

Дайте мне знать, если что-либо из перечисленного неясно или у вас есть дополнительные вопросы.

РЕДАКТИРОВАТЬ: Не видел ответа выше, который по существу излагает требования к короткому хранилищу, которые у меня есть. Если это - принятое решение, поставьте ему галочку (он избил меня до этого (=). Оставив мой ответ, поскольку в нем изложены некоторые дополнительные опции.