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

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

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

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

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

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

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

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

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

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

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

Есть несколько способов справиться с этим. Главный вопрос заключается в том, как долго вам нужно сохранять информацию о корзине покупок (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 на домен. С хорошей стратегией (т.е. хранением идентификатора продукта, а не описания продукта) у вас, вероятно, все будет хорошо.

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

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