Я считаю ViewModel должна только вызывать логику классов модели, логику вспомогательных классов и сервисом.
По сути ViewModel это код связывающий View и Model и никакой дополнительной логики во ViewModel быть не должно.

Здравствуйте, igor-booch, Вы писали:

IB>Я считаю ViewModel должна только вызывать логику классов модели, логику вспомогательных классов и сервисом.
IB>По сути ViewModel это код связывающий View и Model и никакой дополнительной логики во ViewModel быть не должно.

Мне кажется, что ваши посты — тончайший троллинг.

По теме: логика презентационного слоя во ViewModel уместна, хотя это и не единственный вариант её размещения. Бизнес-логика — нет.

Здравствуйте, igor-booch, Вы писали:
IB>Я считаю ViewModel должна только вызывать логику классов модели, логику вспомогательных классов и сервисом.
IB>По сути ViewModel это код связывающий View и Model и никакой дополнительной логики во ViewModel быть не должно.

В общем-то ViewModel по-моему — это не медиатор, а инкапсулятор логики представления.
Не надо забывать также, что одно из важных предназначений ViewModel (и младших братьев контроллеров/презентеров в MVC/MVP)
— возможность покрытия этой логики тестами. С этой точки зрения presentation logic для конкретного View как раз должна размещаться во ViewModel, а не быть размазанной по сервисам.
Модель на мой взгляд лучше вообще сделать максимально свободной от логики. Хотя в MVC и практикуется подход, когда presentation logic сосредоточена в модели, а контроллер — чистый посредник.

Обычно я стараюсь придерживаться следующей архитектуры — во ViewModel помещается логика представления,
на отдельном BL-слое размещается бизнес-логика (как правило описывается интерфейсными контрактами, которые легко подменять mockup-объектами для целей тестирования). Какая-то специфическая логика доступа к данным
может быть в модели, но от ViewModel эта логика опять же скрывается для уменьшения связности, т.е. ViewModel работает с моделью как с черным ящиком.

E>Обычно я стараюсь придерживаться следующей архитектуры — во ViewModel помещается логика представления,
E>на отдельном BL-слое размещается бизнес-логика

По каким критериям логику можно отнести к логике представления?
По каким критериям логику можно отнести к бизнес логике?

Здравствуйте, igor-booch, Вы писали:

E>>Обычно я стараюсь придерживаться следующей архитектуры — во ViewModel помещается логика представления,
E>>на отдельном BL-слое размещается бизнес-логика

IB>По каким критериям логику можно отнести к логике представления?
IB>По каким критериям логику можно отнести к бизнес логике?

Тут тонкие моменты могут быть. В принципе есть такой подход: что не измениться если существующий интерфейс заменить на интерфейс командной стоки-то есть бизнес логика.

А>В принципе есть такой подход: что не измениться если существующий интерфейс заменить на интерфейс командной стоки-то есть бизнес логика.

То есть получается что логика представления это логика для визуализации в формах, то есть UI логика. Например, селектор стиля или раскраска строчек грида или сложная анимация, которую через xaml не описать. Но я думаю, что такой логике место в код бихайнде xaml. Иначе получается, что, вообще ничего в код бихайнд писать нельзя?
Еще: ценность MVVM (и вообще семейства паттернов Model View) состоит в том, мы одну логику можем по разному визуализировать, то есть для одной ViewModel можно подставлять разные View (возможно даже во время выполнения). Но если во ViewModel будет логика UI, это усложнится.

E>Не надо забывать также, что одно из важных предназначений ViewModel (и младших братьев контроллеров/презентеров в MVC/MVP)
E>- возможность покрытия этой логики тестами. С этой точки зрения presentation logic для конкретного View как раз должна размещаться во ViewModel, а не быть размазанной по сервисам.

Не понял, пишите тесты на сервисы и вспомогательные классы, которые вызываются из ViewModel.
IB>Я считаю ViewModel должна только вызывать логику классов модели, логику вспомогательных классов и сервисом.

Предположим у Вас во View пользователь может искать и удалять что-либо. Будет два класса Searcher и Deleter. По отдельность их протестировать проще, чем тестировать ViewModel, в которой вся логика этих классов (Searcher и Deleter) была смешана.
Если вынести логику удаления и поиска в отдельные классы её можно повторно использовать, даже на сервере. А ViewModel повторно использовать труднее.

Здравствуйте, igor-booch, Вы писали:

IB>Я считаю ViewModel должна только вызывать логику классов модели, логику вспомогательных классов и сервисом.
IB>По сути ViewModel это код связывающий View и Model и никакой дополнительной логики во ViewModel быть не должно.

У меня вью-модели содержат логику представления. Вот пример: у нас есть модель, класс Person (Id, Name), инвариантом этого класса является не пустота его имени. И есть класс вью-модели: PersonViewModel (Id, Name), который может использоваться как при создании новой карточки "человека", так и для редактирования. Вью-моделька может содержать логику валидации входных данных, поскольку она не обязана налагать те же ограниченя (читай, инварианты), что и класс модели, поскольку при создании новой карточки человека мы можем допускать пустое значение в свойстве Name вью-модели. Она же (вью-моделька), теоретически, может использовать сервисы для дополнительной проверки введенных данных (например, для проверки уникальности имени).

Иногда в виде модели могут выступать дата-объекты, над которыми могут накручиваться разные слои: в сервисах — это будет свои враперы (дополнительная сервисная логика), а в UI-е — свои (дополнительная UI-йная логика, представленная вью-моделями без дополнительных выделенных классов моделей). Вью-модели в этом случае могут содержать, например, следующую логику: доступность редактирования некоторых свойств модели в тех или иных случаях (если юзер выбрал в комбобоксе определенный тип, то задизейблить ввод некоторых данных); они могут объединять несколько дата объектов под одной вью-моделью, чтобы проще было байндить эту вью-модель к представлению.

В общем, все очень сильно зависит от задачи, от текущего представления о том, что такое "модель", о том, насколько классы "модели" находят соответствие к тем представлениям, на которых они будут отображаться или редактироваться. И самое главное, нужно четко понимать, что подразумевается под понятием "логики": вью-модели не должны содержать бизнес-логики модели, но должны содержать логику представления.

ST>У меня вью-модели содержат логику представления. Вот пример: у нас есть модель, класс Person (Id, Name), инвариантом этого класса является не пустота его имени.
Всегда хотел разобраться в понятии инварианта, объясните, пожалуйста, здесь поподробнее.

ST>И есть класс вью-модели: PersonViewModel (Id, Name), который может использоваться как при создании новой карточки "человека", так и для редактирования. Вью-моделька может содержать логику валидации входных данных, поскольку она не обязана налагать те же ограниченя (читай, инварианты), что и класс модели, поскольку при создании новой карточки человека мы можем допускать пустое значение в свойстве Name вью-модели. Она же (вью-моделька), теоретически, может использовать сервисы для дополнительной проверки введенных данных (например, для проверки уникальности имени).
Я всегда стелюсь к следующему, начну издалека:
Валидация состоит из двух частей:
1) бизнес правила
2) вызов проверки бизнес правил и показ пользователю результатов проверки

Я стараюсь размещать бизнес правила в модели, по максимуму используя атрибуты. Что касается второй части, то я поступаю следующим образом (упрощенно). Для всех UI контролов я делаю наследники и использую их. Для кнопки добавлю свойство bool RequireValidationOnClick. У TextBox добавляю метод Validate, при его вызове TextBox проверяет бизнес правило для свойства класса модели к которому привязан. Если бизнес правило нарушено TextBox обводит себя красную рамку. Данное решение позволяет повторно использовать бизнес правила в различных View и уменьшает объем кода. Не знаю, может я плохо знаю MVVM, но если размещать бизнес правила во ViewModel, то добиться повторной используемости бизнес правил сложнее (если, например, несколько ViewModel'ей связаны с одним классом модели).


ST>Иногда в виде модели могут выступать дата-объекты, над которыми могут накручиваться разные слои: в сервисах — это будет свои враперы (дополнительная сервисная логика),
Под дата-объектами, Вы подразумеваете DTO? Я специализируюсь на толстых клиентах и люблю использовать ORM. Может поэтому я нас несколько разные взгляды?


ST>а в UI-е — свои (дополнительная UI-йная логика, представленная вью-моделями без дополнительных выделенных классов моделей). Вью-модели в этом случае могут содержать, например, следующую логику: доступность редактирования некоторых свойств модели в тех или иных случаях (если юзер выбрал в комбобоксе определенный тип, то задизейблить ввод некоторых данных); они могут объединять несколько дата объектов под одной вью-моделью, чтобы проще было байндить эту вью-модель к представлению.

А бы сделал в классе модели свойство bool TypeAbcIsSelected и сделал binding свойства ReadOnly на это свойство, для тех контролов, ввод в которые нужно заблакировать. Опять же, а если
1) в TypeAbcIsSelected будет какой нибудь нетривиальный код (гипотетически)
2) Вы этот код разместили во ViewModel,
3) Вам понадобиться реагировать на значение этого свойства в нескольких View (причем по-разному),

то по-моим представлениям придется
либо дублировать код в нескольких ViewModel для нескольких View,
либо создавать одну кашеобразную универсальную ViewModel на эти несколько View.
либо создавать создавать сложные иерархии наследования ViewModel (которые как я чувствую будут тяготеть к множественному наследованию)

Не знаю может есть метод в MVVM, который позволяет этого избежать, который позволяет этого избежать???


ST>В общем, все очень сильно зависит от задачи, от текущего представления о том, что такое "модель", о том, насколько классы "модели" находят соответствие к тем представлениям, на которых они будут отображаться или редактироваться.
Пожалуйста, расскажите поподробней.



ST>И самое главное, нужно четко понимать, что подразумевается под понятием "логики": вью-модели не должны содержать бизнес-логики модели, но должны содержать логику представления.
Вот-вот, бизнес правила и всякие предикаты это все бизнес логика по моему мнению.