Блог

Я уже знаю, что вызовы служб WCF через Silverlight являются асинхронными. Я также знаю, что многие люди пытаются найти способы заставить их синхронизировать вызовы по разным глупым причинам (например, блокирование потока пользовательского интерфейса), и что такого следует избегать, как чумы, в целом.

Я просто хочу иметь возможность самостоятельно обрабатывать все потоки, поскольку обнаружил, что необходимость подключать / отсоединять все события ‘ * Completed’ — это большая дополнительная работа и огромная боль, особенно когда вы не знаете порядок вызовов и т.д. Кто-нибудь знает умный способ выполнять вызовы синхронизации и выполнять потоки самостоятельно?

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

Все, что вам нужно сделать, это использовать [ServiceContract] интерфейс (вместо клиентского класса) — тот, который предоставляет операции Begin / End — и вызвать EndXXX(BeginXXX(parameters, null, null)) , как показано в примере ниже (это страница с двумя элементами управления, Button Click событие которого привязано к Button_Click обработчику, и TextBox именем «txtDebug»куда код записывает результаты.

 public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();
    }

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        this.AddToDebug("In Button_Click");
        ThreadPool.QueueUserWorkItem(delegate
        {
            ServiceReference1.Service1Client client = new ServiceReference1.Service1Client();
            ServiceReference1.Service1 asInterface = client;
            this.AddToDebug("Calling server "synchronously"...");
            int result = asInterface.EndAdd(asInterface.BeginAdd(45, 67, null, null));
            this.AddToDebug("Result: {0}", result);
            client.CloseAsync();
        });
    }

    private void AddToDebug(string text, params object[] args)
    {
        if (args != null amp;amp; args.Length > 0)
        {
            text = string.Format(text, args);
        }

        text = string.Format("[{0} - {1}] {2}", Thread.CurrentThread.ManagedThreadId, DateTime.Now.ToString("HH:mm:ss.fff"), text);

        this.Dispatcher.BeginInvoke(() => this.txtDebug.Text = this.txtDebug.Text   text   Environment.NewLine);
    }
}
  

Теперь, если вы хотите сделать это из потока пользовательского интерфейса, тогда действительно нет способа заблокировать и дождаться ответа (поскольку ответ должен быть возвращен и в потоке пользовательского интерфейса). И если вас устраивает шаблон Begin / End, вы все равно можете выполнять асинхронные вызовы, но не беспокоясь о утечке обработчиков событий.

Решений, которые полагаются на блокировку потока (любого потока, а не только потока пользовательского интерфейса), лучше избегать. Потоки — это дорогостоящие ресурсы, а потоки пула потоков — ограниченный ресурс. Вот почему сетевые API имеют семантику обратного вызова на первом месте.

Я согласен с Карлосом , что первое , что нужно сделать , это переключиться на .Интерфейс СЕТЕВОГО асинхронного шаблона, предоставляемый службой вместо ужасного, основанного на событиях. (Подход, основанный на событиях, предназначен для упрощения работы разработчиков пользовательского интерфейса, которые «мыслят событиями»). Если ваша служба называется «Service1», ваш клиентский класс будет называться «Service1Client». Однако этот класс также будет поддерживать интерфейс с именем «Service1», который будет иметь начальную / конечную версии OperationContracts.

«умный способ выполнения вызовов синхронизации»

Без блокировки потока это невозможно. Однако синхронность выполнения ряда задач на самом деле не является обязательным требованием. Мы просто хотим убедиться, что ряд задач выполняется последовательно. Вы можете сделать это, просто вызвав следующую задачу из метода обратного вызова предыдущей задачи, но вложение становится небольшой проблемой.

Взгляните на эту серию статей, возможно, начиная с той, что на .ЧИСТЫЙ асинхронный шаблон. К сожалению, статья WCF все еще находится в стадии разработки, но я действительно должен опубликовать ее в ближайшее время, этот материал часто появляется здесь.

Что, если вы перенесете вызов в другую функцию, и эта функция будет находиться в спящем режиме, пока не вернется асинхронный вызов?