Использование команд (ICommand) вне View

Тема возникла в результате обсуждения с novikov.ea о применении команд (ICommand) в теме Можно ли биндить на команды находящиеся в модели в MVVM?
Посты относящиеся к этому обсуждению перенёс сюда.

По прошествии нескольких дней, начал реализовывать одну задачу и опять встала дилемма использовать ICommand в Модели или создать свой аналогичный интерфейс.
И сам никак не могу определиться как верно КОНЦЕПТУАЛЬНО будет реализовать.

Прошу всех "шарящих" высказаться по этому вопросу.
Любое мнение будет ценно.

Особо приглашаю к дискуссии: kolorotur, Рядовой, proa33, Rius, Someone007, sttrox.
Если кого забыл упомянуть - мои извинения.

1

Если под командой понимать только реализацию ICommand, то не должно быть (использование ICommand в Модели).
ICommand находится в пространстве System.Windows.Input.
Это пространство специфично только для WPF.
А Модель, в принципе не знает, с какого типа View будет её использовать.
Может Формы или Консоль? А у них нет пространства System.Windows.Input.

Тоже самое относится и к ViewModel.
Хотя паттерн MVVM появился как способ реализации инструментов предоставленных WPF, это не означает, что его можно использовать только в WPF. И у VM (в идеале) не должно быть информации о View, даже о её типе.
Используя же ICommand мы даём такую информацию VM и тем самым жёстко её завязываем на WPF View.

Но в реале, делая MVVM приложение мы всегда подразумеваем, что в нём будет WPF View. Исключения, возможно есть, но мне они ни когда не встречались.
И если Модель ещё как-то потенциально делается унифицировано, без жёсткой завязки на WPF (допустим для многоплатформенного приложения, или разные View на одну Модель для более широкого охвата аудитории), то VM всегда делается жёстко под WPF.
По этой причине проникновение ICommand в VM проблем не создаёт.
Но в ИДЕАЛЕ такого быть в MVVM не должно.


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

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

То есть идея ICommand сама по себе имеет довольно широкое применение.
Проблема этого интерфейса его размещение в пространстве для WPF.
Размести MS его в пространстве System.ComponentModel, там же где находится INotifyPropertyChanged, то никаких ограничений на использовании ICommand в Модели не было бы.
INPC же можно использовать где угодно (без фанатизма, конечно).
Так же было бы и с ICommand.

1

Сообщение от Элд Хасп ICommand находится в пространстве System.Windows.Input. Это пространство специфично только для WPF

Это совершенно неправда. Пространство имён не является ограничением ни на что. Это всего лишь контейнер для типов, также являющийся частью полного имени класса. ICommand абсолютно легально используется в слое ViewModel.
Для работы WPF приложения необходимы библиотеки WindowsBase.dll, PresentationCore.dll, PresentationFramework.dll, System.Xaml.dll. Большинство объектов из пространства имён System.Windows.Input находятся в сборке PresentationCore.dll. Но интерфейс ICommand находится в сборке System.ObjectModel.dll. ViewModel использует типы из System.ObjectModel.dll, но не из PresentationCore.dll, поэтому уровни абстракции успешно соблюдаются.

Добавлено через 4 минуты

Сообщение от Элд Хасп Проблема этого интерфейса его размещение в пространстве для WPF. Размести MS его в пространстве System.ComponentModel, там же где находится INotifyPropertyChanged, то никаких ограничений на использовании ICommand в Модели не было бы.

Вообще именно так и сделано
В .NET Framework оба типа находятся в сборке System.dll, а в .NET Core - В System.ObjectModel.dll

0

Сообщение от novikov.ea Это совершенно неправда.

Я отталкиваюсь от этого: https://docs.microsoft.com/ru-... mework-4.8

System.Windows.Input Namespace Предоставляет типы для поддержки системы ввода Windows Presentation Foundation (WPF). Сюда входят классы абстрагирования устройств для устройств мыши, клавиатуры и пера, часто используемые классы диспетчера ввода, поддержка для команд и пользовательских команд, а также различные служебные классы.

0

Тема создана переносом постов.
Всем кому есть что сказать - прошу ответить.

0

Использование ICommand в модели не запрещено. Так же, как и использование INotifyPropertyChanged. Нужно исходить из задачи. В случае команды: нужны ли все члены её интерфеса? Нужны ли и метод Execute, и метод CanExecute, и событие CanExecuteChanged. Будет ли использоваться параметр у Execute? Если ответ на все эти вопросы - да. То можно использовать ICommand. Если ответ хотя бы на один из этой вопросов - нет, то не следует использовать ICommand, необходимо написать свои типы, отвечающие условиям задачи.
Также и с INotifyPropertyChanged. Если кому-то требуется знать об изменениях всех свойств объекта, то INotifyPropertyChanged - идеальный вариант. Иначе этот интерфейс не следует использовать.

2

Сообщение от novikov.ea В случае команды: нужны ли все члены её интерфейса?...

Это понятно.
Кроме этого, на уровне Model нужна иная реализация ICommad - на у этом уровне не нужна автоподписка команды на CommandManager.RequerySuggested.В MvvmLight для этого есть две различные реализации RelayCommand в пространствах GalaSoft.MvvmLight.Command и GalaSoft.MvvmLight.CommandWpf.

Как я уже и писал выше в ICommand меня больше всего смущает его расположение в System.Windows.Input о котором в документации сказано Предоставляет типы для поддержки системы ввода Windows Presentation Foundation (WPF).

1