Насколько хороший и/или необходимый веб-сервисы С сохранением информации?
Я бы предпочел идентификатор пользователя для вашего DOM-элемента, а затем в модульном тесте angular2 вы можете вызвать что-то вроде ниже, чтобы получить ссылку на ваш желаемый DOM-элемент и протестировать то, что вам нравится.
//typscript syntax
fixture = TestBed.createComponent(<your component>);
let result = fixture.nativeElement.querySelector('<id attribute name of html element>');
expect(result.id).toEqual("id of your DOM element.").
Надеюсь, что это поможет.
5 ответов
В идеале веб-службы (и веб-сайты) не должны иметь состояния.
К сожалению, это требует очень хорошо продуманной проблемной области и четкого разделения проблем.
Я обнаружил, что на практике большинство реальных веб-сайтов зависят от состояния, даже если это ограничивает их масштабируемость.
Я также обнаружил, что многие реальные веб-сервисы также полагаются на состояние.
В конечном итоге «правильное» решение - это то, которое работает для конкретная проблема, поэтому, вероятно, можно написать веб-сервис, который полагается на состояние, и реорганизовать его позже, если масштабируемость станет проблемой.
Сильно зависит от того, ориентирована ли служба на одиночную транзакцию (например, получение котировок акций), или если вывод службы зависит от данных, предоставленных конкретным клиентом по нескольким транзакциям (в этом случае состояние должно поддерживаться.)
Что касается проблем с масштабируемостью, сохранение состояния в базе данных на самом деле неплохой способ (на самом деле, это, вероятно, единственный способ пойти, если вы балансируете нагрузку своей службы на сервере фарм.)
Похоже, вы приравниваете состояние и аутентификацию. Возможно, вы привыкли хранить имя пользователя и пароль в состоянии сеанса?
В этом нет необходимости даже для старых веб-служб ASMX. Просто передайте всю необходимую информацию операции «Вход». Эта операция будет определена для возврата заголовка «Authentication Ticket».
Для всех других операций, требующих аутентификации, потребуется этот заголовок «Authentication Ticket». Каждый из них будет проверять заголовок, чтобы увидеть, представляет ли он действительного аутентифицированного пользователя. Если так, то они выполнят свою задачу. Если нет, то они вернут ошибку SOAP, указывающую, что требуется аутентификация.
Состояние не требуется. Просто убедитесь, что билет проверки подлинности можно проверить на любом сервере, на котором работает ваша служба (например,
Я думаю, что с клиентами Flex состояние перемещается из службы на клиентский уровень. Держите службы без состояния и позвольте клиентам поддерживать необходимое состояние. Услуги остаются простыми, и клиенты могут смешивать их вместе, как они хотят.
Хотя это небольшая разница, но ее все же следует упомянуть:
Это не состояние в веб-сервисах , которое убивает масштабируемость, скорее это состояние на сервере приложений , на котором размещены веб-службы, которые убивают масштабируемость. В тот момент, когда вы говорите, что этому пользователю необходим доступ к этому серверу (как это делается в липких сеансах), вы фактически ограничиваете свои возможности масштабирования. Вы хотите понять, что «любой из ваших бесплатных серверов приложений с балансировкой нагрузки» может обрабатывать этот запрос веб-службы, и если я добавлю еще 1 сервер приложений, я смогу обрабатывать на% больше пользователей .
Совершенно нормально (и лично рекомендуется), если вы хотите сохранить состояние для передачи токена аутентификации и при каждом запросе получать службу для извлечения вашего «состояния» из хранилища данных (желательно избыточного и секционированного, например, распределенного + реплицированное хранилище данных типа ключ / значение). Вот как Amazon делает это с SimpleDb и Google с BigTable.
Ebay использует несколько иной подход и хранит большинство состояний клиентов в файлах cookie, чтобы они передавались с каждым запросом. Хотя он генерирует намного больше трафика, он по-прежнему масштабируется, поскольку любой из их серверов по-прежнему может обрабатывать запрос.
Если вам нужно масштабируемое хранилище данных, я бы порекомендовал взглянуть на redis , у него скорость и функции, которые невозможно превзойти в хранилище данных типа ключ / значение.
Вам также следует посетить highscalability.com , если вы хотите получить доступ к хорошим материалам о том, как создавать быстрые и масштабируемые услуги.