Чи веб-сесія "Поганий дизайн"? Чому?

днями я обговорював з колегою, і він вийшов, сказавши, що використовувати сеанс користувача у веб-додатку просто неправильно. Я відповів, що це може бути неправильним залежно від інформації, яку ви зберігаєте, інакше навіщо послуга веб-сеансу навіть надаватися Microsoft (ми говорили про ASP.NET).

Він знову мені відповів, що навіть у MS вони могли легко відповісти мені, що це поганий дизайн. І що він міг би показати мені деякі документи, що це демонструють.

На жаль, у мене більше немає контактів з цим хлопцем, але я дуже хотів би зрозуміти більше про його точку зору. Хтось має тут інформацію / точки зору?

Я не думаю, що він мав на увазі "поганий дизайн" настільки, як "погана практика". Взагалі кажучи, веб-додаток повинен бути максимально без громадянства. Незважаючи на те, що, наприклад, вам може знадобитися інформація про користувачів, щоб авторизувати перегляд сторінки, ця інформація може бути збережена на клієнтській машині у вигляді файлу cookie, а сервер просто перевіряє інформацію про користувачів кожного разу.

Це було б ідеально, але ви не завжди можете розраховувати, що клієнт зможе зберігати файли cookie. Крім того, це включає перевірку користувача в режимі без громадянства, що потенційно включає запит інформації з бази даних для простого запиту на сторінку. Часто буває просто простіше зберегти таку інформацію на сеансі.

Однак, перейшовши через Rubicon, багато програмістів спокушаються зберегти не тільки інформацію про аутентифікацію на сеансі, але й багато інших речей. Це анти-шаблон і, як правило, робить ваш веб-додаток сильно залежним від стану, саме цього слід було уникати в першу чергу.

Деякі програмісти будуть залежати від такої технології, як Spring (якщо ви використовуєте Java), щоб розплутати те, що інакше було б безладдям залежностей, але я заперечую, що це лише полегшує створення залежностей, а не усуває їх. Такі технології повинні сприяти вашому розвитку, а не робити вашу антидіапазон менш проблемою.

Тому хорошим правилом є те, що якщо ви можете написати це без громадянства, це, мабуть, краща ідея зробити це чи ви ризикуєте потрапити в цю пастку. Очевидно, що ви зіткнетеся з ситуаціями, в яких це потрібно, але, загалом кажучи, вам слід зберігати лише інформацію, яку в іншому випадку важко буде знову придбати.

Я думаю, що ви плутаєте дві різні теми: 1) сеанси та 2) модель сторінки веб-форм asp.net

Для аутентифікації користувача необхідний веб-сеанс . В ідеалі сеанс слід використовувати лише для цієї мети. Не слід зберігати дані користувачів під час сеансу (будь то на сервері, у файлі cookie або як це робиться asp.net/webforms: у самій сторінці). Ніхто не повинен говорити, що веб-сеанс - це погано, але, скоріше, зберігання даних користувачівна сесії - це погана практика. Причини не зберігання даних користувача на сервері включають ті самі причини, щоб уникнути глобальних змінних. Зберігання даних користувачів у файлах cookie або на сторінці може призвести до проблем безпеки. Використання моделі сторінки asp.net також не дотримується безмежжя в Інтернеті. Ви можете зробити пошук, щоб дізнатися більше про те, чому веб-форми є поганим дизайном. Сеанси з іншого боку - необхідна частина веб-додатків.

Керування та зберігання стану сеансу на сторінці - це, по суті, хак. Це справа MS - необхідна, оскільки вони хотіли мати можливість створити середовище розробки, де ви могли б розробляти сторінки, як можна, в умовах Winform.

MS самі просунулися до архітектури MVC (остання версія - MVC 4), що більше є поверненням до того, що протокол насправді повинен бути - без громадянства.

Є ситуації, коли зберігання стану все ще зручно, але слід розуміти, що це швидше виняток, ніж правило.