Переопределение алгоритма сохранения / восстановления состояния продолжения? - PullRequest
2 голосов
/ 30 сентября 2011

Когда я увидел первые новости об ожидании, я был очень взволнован, и я подумал о многих способах его использования. Одним из них является использование его в моей веб-среде, чтобы скрыть асинхронный аспект обмена клиент-сервер, как это делается в нескольких средах. Итак, вот сделка:

Я хотел бы написать такие вещи:

{   
    Page p = new Page();
    FormResponse response = await p.Show();
    var field1 = reponse.inputField["input1"];
    ...
}

Я бы хотел, чтобы разработчик мог написать этот код на сервере. Как вы догадались, p.Show() напишите в HttpResponse html-код, отображающий страницу с формой, и отправьте ответ клиенту, поэтому поток убит, и я никогда не достигну следующей инструкции (FormResponse response =).

Итак, вот мой вопрос: Есть ли способ сделать такую ​​вещь? Я знаю, жду, когда вы урежете код, упакуете его в продолжение, сделайте закрытие для нас и сохраните где-нибудь, чтобы перезвонить, когда p.Show () будет завершен. Но здесь поток будет уничтожен, и это мой код, который получает ответ на отправку от страницы, которая имеет дело с ним. Поэтому я должен восстановить продолжение, которое «ожидал» создал, и выполнить его самостоятельно.

Я поднимаюсь высоко или это возможно?

Редактировать: дополнительная информация

Я могу объяснить немного больше, но нам нужен пример. Представьте, что вы хотите сделать асинхронный вызов веб-службы, вы просто используете await, а затем вызываете веб-сайты. Веб-страница не отображает какую-либо страницу, она возвращает фрагменты информации, и вы можете продолжить следующие инструкции, поэтому с веб-сайтами у нас есть: Клиент -> Сервер A [-callwebs-> Сервер B ->] Сервер A -> Клиент.

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

Итак, с помощью веб-интерфейса пользовательского интерфейса мы имеем: Клиент -> Сервер A [-response_redirect-> Клиент -get-> Сервер B (здесь UIwebs, клиент вводит все что угодно) -response_redirect-> Клиент -get->] Сервер A -> Клиент

То, что я положил в скобки, должно быть обращено на пути разработчика:

так что для классических веб-сайтов я могу представить, что асинхронная страница «спит», ожидая ответа веб-сайтов, но с веб-интерфейсом пользовательского интерфейса мы должны ответить à перенаправить клиенту, поэтому страница создана для asp.net, и SynchronizationContext говорит, что больше не нужно ждать асинхронной инструкции.

На самом деле, мне нужно то же самое, что включить веб-сервер и отправить ему запрос, который восстановит все необходимое для выполнения кода сразу после ожидания.

С уважением, Julien

1 Ответ

0 голосов
/ 30 сентября 2011

Я не уверен, в чем проблема.

Если у вас есть, например, асинхронные страницы ASP.NET, то любая функция верхнего уровня (async void) должным образом уведомит ASP.NET, чтостраница не завершена и освободить поток.Позднее продолжение будет выполняться в (возможно, другом) потоке, восстановит контекст запроса и завершит запрос.

Дизайн async был тщательно выполнен, чтобы включить это точное поведение.В частности, async void увеличивает количество незавершенных асинхронных операций в SynchronizationContext, как я описал в недавней статье MSDN .

Если вы используете свой собственный хост (т. Е. Нес использованием ASP.NET), вам придется реализовать SynchronizationContext.Это нетривиально, но и не очень сложно.Как только это будет сделано, async и await будут "просто работать".:)

Обновленный ответ в ответ на редактирование:

Имейте в виду, что await / async являются просто синтаксическим сахаром;они не включают ничего, что раньше было невозможно - они просто делают это проще.

Если я правильно понимаю вашу ситуацию, вы хотите, чтобы веб-сервис возвращал пользовательский интерфейс, а затем отвечал на него.Это инверсия того, как работает HTTP, так что вам придется сделать что-то интересное с viewstate.Я подумаю об этом ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...