Каково различие между Сессией. Отказ () и Сессия. Ясный ()
Для предложения немного отличающейся перспективы я думаю, что она зависит от контекста.
Прежде всего, за эти годы я переместился от того, чтобы быть 100%, убежденными в реализации ограничений в DBMS к тому, чтобы стараться избегать его в целом: Я хочу всю свою бизнес-логику на том же слое.
, Во-вторых, я работаю много с направляющими, и миграции ActiveRecord не допускают много резидентного дб ограничительного определения вне размера поля и NULL_ness.
, Если Вы создаете новое приложение, которое включает новую базу данных, которая полностью выделена Вашему приложению, тогда можно осуществить ограничения в коде приложения как часть бизнес-логики. Это - то, как направляющим нравится работать, и это, кажется, работает вполне прилично.
, Если Вы создаете новое приложение против дб прежней версии, который реализует бизнес-правила в ограничениях дб тогда, я предложил бы продолжить это и принять некоторое дублирование правил проверки в бизнес-слое. Лучше, чтобы проверить, что данные допустимы прежде, чем попытаться применить его к базе данных.
, Если Вы создаете новое приложение с ожиданием, что другие приложения получат доступ к данным, тогда подход собирается зависеть от того, как те другие приложения будут созданы. Снова, в направляющих, необходимо, вероятно, смотреть на способы совместно использовать модели, в этом случае тот слой должен быть достаточным. Если Вы не можете отклонить другие стили реализации от прямого доступа до Ваших данных, то Вы вернулись к дублированию. Мое предпочтение должно было бы попробовать - очень трудно - чтобы запретить прямого доступа дб к тем приложениям и стремиться обслужить их через (надо надеяться, УСПОКОИТЕЛЬНЫЙ) веб-сервис, так, чтобы можно было управлять целостностью данных на уровне бизнес-логики.
, Если третье лицо (внутренний или иначе) приложение имеет доступ DDL к Вашей схеме, то прекратите волноваться о проблеме - Вы уже потеряли контроль над своими данными, и Вы завинчены!
4 ответа
Очистить - удаляет все ключи и значения из коллекции состояний сеанса.
Abandon - удаляет все объекты, хранящиеся в сеансе. Если вы не вызываете метод Abandon явно, Он также вызывает такие события, как Session_End .
Session.Clear можно сравнить с удалением всех книг с полки , в то время как Session.Abandon больше похож на , когда выбрасывается вся полка .
Вы говорите:
] Когда я тестирую сеанс, он не вносит никаких изменений, когда я прекращаю сеанс.
Это правильно, пока вы делаете это только в рамках одного запроса .
При следующем запросе сеанс будет другим. Но идентификатор сеанса можно использовать повторно , так что идентификатор останется прежним.
Если вы будете использовать Session.Clear, у вас будет один и тот же сеанс во многих запросах.
Как правило, в большинстве случаев вам необходимо использовать Session.Clear.
Вы можете использовать Session.Abandon, если уверены, что пользователь собирается покинуть ваш сайт.
Итак, вернемся к различиям:
- Abandon вызывает запрос Session_End.
- Clear удаляет элементы сразу, Abandon - нет.
- ] Abandon освобождает объект SessionState и его элементы, чтобы он мог собрать мусор для освобождения ресурсов. Clear сохраняет состояние SessionState и связанные с ним ресурсы.
При очистке сеанса удаляются сохраненные в нем значения, но вы все равно можете добавлять туда новые. После разрушения сеанса вы не можете добавлять туда новые значения.
очистить - удалить ключ или значения из коллекции состояний сеанса ..
отказаться - удалить или удалить объекты сеанса из сеанса ..
Когда вы Abandon () сеанс, вы (или, скорее, пользователь) получите новый SessionId (при следующем запросе).
Когда вы Clear () сеанс, все сохраненные значения удаляются, но SessionId остается неизменным.