.NET нечувствительность к регистру HttpSessionState
Я полагаю, что WCF действительно совершенствует реализацию веб-сервисов ASMX во многих отношениях. В первую очередь, это обеспечивает очень хорошую многоуровневую объектную модель, которая помогает скрыть внутреннюю сложность распределенных приложений. Во-вторых, у Вас могут быть больше, чем шаблоны обмена сообщениями воспроизведения запроса, включая асинхронные уведомления от сервера до клиента (невозможный с чистым HTTP), и в-третьих абстракция далеко протокол базовой передачи от обмена сообщениями XML и таким образом изящно поддержки HTTP, HTTPS, TCP и другого. Обратная совместимость с "1-м поколением" веб-сервисы также плюс. WCF использует стандарт XML в качестве внутреннего формата представления. Это могло быть воспринято как преимущество или недостаток, особенно с растущей популярностью "обезжиренные альтернативы XML" как JSON.
2 ответа
Ключи HttpSessionState были сделаны без учета регистра, чтобы соответствовать поведению классического объекта сеанса ASP. Это упростило разработчикам перенос своих приложений ASP на ASP.NET, не создавая тонких проблем с чувствительностью к регистру.
Такое же поведение ключа без учета регистра верно для объектов QueryString, Cookies и т. Д., А также других встроенных объектов, аналогичных классическому ASP.
Я был в команде IIS в Microsoft, когда ASP.NET проектировался и ASP.NET работал трудно держать код ASP.NET обратно совместим с ASP, где это возможно. Это не означает, что у ASP.NET была идеальная обратная совместимость, но всякий раз, когда возникало решение (например, с учетом регистра), ответом по умолчанию было соответствие классическому поведению ASP, если только не было веской причины не делать этого.
Тем не менее, я согласен, что Сессия ' s нечувствительность к регистру может быть лучше задокументирована.
Кстати, коллекция сеансов ASP.NET получает свое поведение случая из NameObjectCollectionBase , который является базовым классом для всех встроенных объектов ASP.NET для файлов cookie, состояния сеанса, состояния приложения, заголовков и т. Д. . Из документов:
Базовая структура для этого class - хеш-таблица.
Каждый элемент представляет собой пару ключ / значение.
Емкость NameObjectCollectionBase - это число элементов NameObjectCollectionBase может содержать. Как элементы добавляются в NameObjectCollectionBase, емкость автоматически увеличивается по мере необходимости посредством перераспределения.
Поставщик хеш-кода выдает хеш коды для ключей в NameObjectCollectionBase экземпляр. В поставщик хэш-кода по умолчанию - это CaseInsensitiveHashCodeProvider.
Компаратор определяет, ключи равны. Компаратор по умолчанию является CaseInsensitiveComparer.
В .NET Framework версии 1.0 это класс использует строку с учетом языка и региональных параметров сравнения. Однако в .NET Framework версии 1.1 и более поздних, это класс использует CultureInfo .. ::. InvariantCulture когда сравнение строк. Для большего информация о том, как культура влияет сравнения и сортировка, см. Сравнение и сортировка данных по конкретному Сравнение культур и сортировка данных для Конкретная культура и исполнение Строковые операции, нечувствительные к культуре.
Разумным последующим вопросом может быть следующий: почему классический ASP был разработан с ключами без учета регистра? Причина этого заключается в том, что еще в 1996 году (или около того) основным языком, используемым с ASP, был VBScript, поэтому имело смысл удовлетворить ожидания разработчиков VB без учета регистра.
While C# is case sensitive, these constructs in ASP.NET are case-insensitive because much in HTML is case insensitive (at least in HTML4 -- XHTML is case-sensitive, or course). I believe this is implemented in the class itself. It's independent of whether the state is in-proc or elsewhere.