Ась? А по русски? :D Вот что по этому поводу пишет мелкософт: "Контекст синхронизации, заданный для UI-потока большинства сред с пользовательским интерфейсом, часто для полученных заданий будет назначать приоритет более высокий, чем для заданий по обработке ввода и прорисовке. По этой причине не следует полагаться на await Task.Yield(); для сохранения отклика пользовательского интерфейса." Взято отсюда: https://msdn.microsoft.com/ru-ru/library/system.th...
Во первых калбэк даже не сам слушает сервер. Есть же еще всякие побочные классы вроде ClientBase, это они уже вызывают функции калбэка. Во вторых да, если в нем самом не реализована никакая другая бизнес-логика то он может выступать в роли VM. Под бизнес-логикой я понимаю такие вещи как например: вот на сервере мой сервис принимает например запрос на регистрацию и сам обращается к БД, сам регистрирует. Он не извещает об этом ViewModel. Это и есть BL. А то что делает калбэк это VM в чистом виде имхо.
Я понимаю, но все равно задача то будет выполняться в другом потоке, что создает определенные неудобства. (особенно в плане UI) У меня таких методов несколько, это своего рода обработчики событий, которые я просто хотел сделать асинхронными. Да, по поводу Task.Join это опечатка была, поправил. Я имел ввиду Task.Delay.
Если я правильно понял вы дословно перефразировали то что я уже и так описал. BL - калбэк, в нем функции которые вызываются с сервера, каждая функция вызывает соответствующее ей событие, на которое подписывается ViewModel. Отвечаю который раз: функций таких вагон. Нафига же я буду на каждую функцию делать по событию, потом цепляться к ней во ViewModel-и если я могу просто этот калбэка использовать как ViewModel, а функции его использовать как обработчики? Вам не кажется что так в разы проще? Я считаю что в этом случае даже (!!!) не нарушаются никакие принципы MVVM, т.к. калбэк в данном случае не является частью бизнес-логики ни в каком виде. Он просто слушает сервер и обновляет данные.
А нельзя объявить в интерфейсе калбэка на сервере прямо событие, вызвать его там и чтобы оно передалось клиенту? Таким образом ничего лишнего не пришлось бы править... Только я не знаю возможно ли это и как...
Все как раз наоборот. При моем подходе править надо будет интерфейс калбэка на сервере и класс калбэка на клиенте. А при вашем помимо этого еще придется править тип эвента в классе калбэка и обработчик его.
Я уже сказал почему я не хочу делать калбэк моделью. Таких функций слишком много. Это просто двойная работа будет. Ладно бы если бы этот калбэк еще реально что то делал сам. Реализовывал какую то бизнес-логику. Но он же просто получается как передаточное звено.
Да я обычно так и делал. Но таких функций очень много (не меньше 10 штук, а может и больше будет). Неужели теперь надо делать под каждую функцию по событию? Чего ради? Просто у меня в этом callback-е ну вообще никаких действий не производится. Он тупо принимает эти функции, а они тупо изменяют интерфейс и все. Мне кажется какой смысл делать двойную работу - передавать это все в события и в другом месте делать такие же обработчики...
Уже абсолютно точно решено что с этим абсолютно нереально сделать то что мне нужно. Решение найдено: FlowDocument. Только с биндингом там придется повозиться, но вроде бы это тоже реализуемо...
Вячеслав Золотов: Ну в таком случае вы просто сказали то что я сказал уже выше. Только у меня разумеется не список, а ObservableCollection. И да, мне кажется что раз свойства используются для биндинга значит это ViewModel. А может и нет хз. :D В общем если конкретизировать я имею ввиду WCF приложение. У меня там клиента представляет отдельный класс, в котором есть как свойства которые биндятся, так и прочие свойства такие как калбэк и т.п. которые просто используются в коде.
