Может ли Callback выступать в роли ViewModel-и?

Question

[DarkByte2015]

Скажите пожалуйста Callback на клиенте может выступать в роли ViewModel-и с точки зрения MVVM? Просто все его методы они получаются как бы события которые вызываются с сервера. В то же время никакую особую логику свойственную только сервису в него не впихнешь. (во всяком случае в моей задаче) Так почему бы и нет? Что толку что я в нем насоздаю событий на каждую функцию и буду ловить их во ViewModel-и? Может проще просто использовать сразу его как ViewModel? Ну если (как обычно) кому то что-то не понятно будет (я уже предчувствую) то вот вам пример. Обычный чат. На калбэке вызываются функции вроде: клиент подсоединился / клиент отсоединился, получено приватное / публичное сообщение и т.п. Они тупо как события. Никаких особых действий тут в калбэке не происходит. Просто добавляются сообщения в отображаемый список или добавляет / убирается пользователь из списка подключенных.

Answer 1

[Станислав Силин]

VM это сущность которая предназначена для передачи/отображения информации. Она может содержать логику которая поможет это сделать. Судя по описанию вы хотите добавить некий кусок логики ответсвеный за нотификацию в VM, на мой взгляд это плохая идея. Думаю все это должно быть в бизнесе, а там уже можно и колбеки и события.

Comments

[DarkByte2015]

Да я обычно так и делал. Но таких функций очень много (не меньше 10 штук, а может и больше будет). Неужели теперь надо делать под каждую функцию по событию? Чего ради? Просто у меня в этом callback-е ну вообще никаких действий не производится. Он тупо принимает эти функции, а они тупо изменяют интерфейс и все. Мне кажется какой смысл делать двойную работу - передавать это все в события и в другом месте делать такие же обработчики...

[DarkByte2015]

Куда подробнее? Все описано стартовом посте.

[Станислав Силин]

DarkByte2015: Я переформулировал ответ))

[DarkByte2015]

Я уже сказал почему я не хочу делать калбэк моделью. Таких функций слишком много. Это просто двойная работа будет. Ладно бы если бы этот калбэк еще реально что то делал сам. Реализовывал какую то бизнес-логику. Но он же просто получается как передаточное звено.

[Станислав Силин]

DarkByte2015:
Мне кажется какой смысл делать двойную работу - передавать это все в события и в другом месте делать такие же обработчики...

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

[DarkByte2015]

Все как раз наоборот. При моем подходе править надо будет интерфейс калбэка на сервере и класс калбэка на клиенте. А при вашем помимо этого еще придется править тип эвента в классе калбэка и обработчик его.

[DarkByte2015]

А нельзя объявить в интерфейсе калбэка на сервере прямо событие, вызвать его там и чтобы оно передалось клиенту? Таким образом ничего лишнего не пришлось бы править... Только я не знаю возможно ли это и как...

[Станислав Силин]

По поводу вашего примера с чатом. Не вижу причины в использовать событий и ивентов.

Смоделируем ситуацию.
Эсть некий UI, уровень view model(VM) и бизнес логика(BL) чата. BL слушает сеть и сообщает о изменениях. В данном случаии BL не нужен UI чтобы понять, что что-то произошло. Она сама все знате и когда нужно может вызывать событие на которое VM как-то отреагирует и что-то отобразит на UI.

[DarkByte2015]

Если я правильно понял вы дословно перефразировали то что я уже и так описал. BL - калбэк, в нем функции которые вызываются с сервера, каждая функция вызывает соответствующее ей событие, на которое подписывается ViewModel. Отвечаю который раз: функций таких вагон. Нафига же я буду на каждую функцию делать по событию, потом цепляться к ней во ViewModel-и если я могу просто этот калбэка использовать как ViewModel, а функции его использовать как обработчики? Вам не кажется что так в разы проще? Я считаю что в этом случае даже (!!!) не нарушаются никакие принципы MVVM, т.к. калбэк в данном случае не является частью бизнес-логики ни в каком виде. Он просто слушает сервер и обновляет данные.

[Станислав Силин]

т.е. по вашему слушание сервера бизнес логикой не является, это должна делать VM?

[DarkByte2015]

Во первых калбэк даже не сам слушает сервер. Есть же еще всякие побочные классы вроде ClientBase, это они уже вызывают функции калбэка. Во вторых да, если в нем самом не реализована никакая другая бизнес-логика то он может выступать в роли VM. Под бизнес-логикой я понимаю такие вещи как например: вот на сервере мой сервис принимает например запрос на регистрацию и сам обращается к БД, сам регистрирует. Он не извещает об этом ViewModel. Это и есть BL. А то что делает калбэк это VM в чистом виде имхо.

Answer 2

[Larry Underwood]

В данном случае не согласен с пользователем Станислав Силин .
Если всё так примитивно, как Вы описываете, то вполне возможно биндиться сразу на объект коллбека и не парить себе мозг.
Слоеность по бизнесу и DAL делается для того, чтобы упростить разработку, поддержку и отладку. Если нечего упрощять, поддерживать и отлаживать, то смысла дублировать логику коллбек объекта в другом классе с названием BlablablaViewModel - нет.

To Станислав Силин: Сущность для отображения - это View, ViewModel - это сущность, которая открывает данные модели для View и позволяет выполнять над этими данными действия (ICommand).

Comments

[Станислав Силин]

Так все говорят... а потом через N-ое время начинается рефакторинг, где клянут того кто это написал...