Как реализовать трехуровневую архитектуру в Windows Phone при вызове веб-сервисов - PullRequest
0 голосов
/ 17 августа 2011

Недавно я работал над интеграцией Windows Phone для sharepoint. Я использовал для связи веб-сервисы, предоставляемые sharepoint.

Форма там я узнал, что Windows Phone поддерживает только асинхронные звонки на веб-сервисы, который начинает выполнять оставшуюся строку кода, и как только я получу ответ, он начнет выполнять его. Но в этом случае предположим, что моя логика зависит от ответа веб-службы, тогда для меня бесполезно вызывать асинхронный вызов веб-службы. Мне нужно написать всю логику в openreadcompleted или такого рода событиях и т. Д.

Это работает не во всех сценариях, поэтому я создал имя класса CustomTask для связи, и код приведен ниже:

MainClass
{
        foreach (Task t in tasks)
        {

                CustomTask objCustomTask = new CustomTask();
                objCustomTask.IsTaskCompleted += new EventHandler<CustomEventArgs>(objCustomTask_IsTaskCompleted);
                objCustomTask.sortTasks(t.ID, t);

        }
}

public class CustomTask
{
    public event System.EventHandler<CustomEventArgs> IsTaskCompleted;
    CustomEventArgs objCustomEventArgs = new CustomEventArgs();
    WorkflowService.WorkflowSoapClient ws = new WorkflowService.WorkflowSoapClient();

    public void sortTasks(String id, Task t)
    {
        objCustomEventArgs.objTask = t;
        ws.CookieContainer = Login.cookieJar;
        ws.GetWorkflowDataForItemAsync("TaskName");
        ws.GetWorkflowDataForItemCompleted += new EventHandler<WorkflowService.GetWorkflowDataForItemCompletedEventArgs>(ws_GetWorkflowDataForItemCompleted);
    }

    void ws_GetWorkflowDataForItemCompleted(object sender, WorkflowService.GetWorkflowDataForItemCompletedEventArgs e)
    {


        objCustomEventArgs.IsPendingTask = false;
        XElement objxelement = e.Result;
        IEnumerable<XElement> objXElementColl = objxelement.Descendants(XName.Get("ActiveWorkflowsData", Constant.strWorkflowList));
        foreach (XElement objXElementWorkflowTemplate in objXElementColl)
        {
            XElement objXElementWorkflows = objXElementWorkflowTemplate.Element(XName.Get("Workflows", Constant.strWorkflowList));
            if (objXElementWorkflows != null && objXElementWorkflows.HasElements == false)
            {
                objCustomEventArgs.IsPendingTask = true;
            }
        }
        IsTaskCompleted(sender, objCustomEventArgs);

    }

    public List<Task> GetPendingTask()
    {
        return null;
    }

}

Моя работа выполнена, но у меня есть несколько вопросов:

  1. Метод, который я использовал, повлияет на производительность приложения?

  2. означает ли асинхронный вызов, что мы не можем реализовать трехуровневую архитектуру?

  3. Почему синхронные вызовы не поддерживаются.

1 Ответ

2 голосов
/ 17 августа 2011
  1. Нет ничего очевидного, что выпрыгивает из вашего кода как вероятная проблема с производительностью. Единственный способ узнать наверняка - это запустить его и при необходимости измерить.

  2. Использование асинхронных вызовов никак не связано с количеством используемых архитектурных уровней. Это относится к тому, как приложение ожидает ответа.
    Ваше утверждение «что Windows Phone поддерживает только вызовы ASync для веб-сервисов, что заставляет поток ждать ответа» неверно. Выполнение асинхронных вызовов означает, что поток не ожидает ответа. Используя ключевые слова Asyncawait) (если вы используете Async CTP), код по-прежнему выполняется асинхронно, но выполняется (насколько вам известно) способом, сравнимым с тем, как если бы он был синхронный.

  3. Синхронные методы не были доступны, поскольку они не имеют смысла в мобильном контексте по двум важным причинам:

Воспринимаемая производительность:
Невозможность использования приложения (из-за блокирующего потока) во время ожидания ответа на запрос может создать ужасные возможности для пользователя на мобильном устройстве, так как пользователь обычно взаимодействует с приложением, работающим на устройстве в его руке (по сравнению с ПК) означает, что любая пауза длится сравнительно дольше. Поскольку приложение не ожидает ответа, оно может отображать индикатор ожидания, позволяя пользователю делать что-то еще (с тем, что может быть очень ограниченным числом процессов) или позволяет пользователю намного проще отменить запрос.

Иногда (и часто низкого качества) подключение:
Возможность подключения мобильного устройства по своей природе отличается от подключения к ПК. В мобильном устройстве вы должны предположить, что какое-либо соединение может быть не установлено или, в зависимости от используемого метода соединения, для возврата может потребоваться много времени. Если пользователь подключен к сетевому соединению 2G и запрос на получение большого объема данных может занять много времени. Вы не хотите заставлять пользователя ждать все это время. Если приложение написано для работы с асинхронными запросами, то также легче справиться с этим кодом, не получая ответа.

Чтобы избежать вышеуказанных проблем с синхронным кодом, необходимо написать его так, как если бы он был асинхронным. Лучше просто вырезать среднего человека.

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

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