Alexey2112АлексейК, ты же, вроде, за "понерфить MVVM".Я за то, что каждый подход имеет свои преимущества и недостатки. Одна из главных задач при разработке архитектуры - выбрать наиболее подходящий подход в данном конкретном случае.
Alexey2112Как относишься к предложенному подходу?Ну я активно использую code-behind + DependencyProperty + Binding, проблем за несколько лет не замечено. Я только не понял, зачем назначать Binding через Style+Setter.
Alexey2112Или тоже за сервисы?Я за выделение классов по необходимости. Например, для повторного использования кода в разных контролах. Появилась необходимость - выносим часть кода в отдельный класс, даём новому классу гордое имя "сервис". :-)

Alexey2112Алексей Кпропущено...
Ну я активно использую code-behind + DependencyProperty + Binding, проблем за несколько лет не замечено. Я только не понял, зачем назначать Binding через Style+Setter.
Идея такая, что надо пробросить путь к выбранному файлу во вью модель. Выбор файла - через стандартный FileOpenDialog. Если этот диалог открывать во вью - то только в коде бихайнд (ну не в замле же?).code-behind имеет свойства скорее ViewModel, чем View. При таком отношении к code-behind всё встаёт на свои места. Считаю это ключевым моментом, на который стоит обратить особое внимание.
Alexey2112 Т. е. в коде бихайнд надо завести свойство, которое будет хранить выбранный путь к файлу. А теперь как связать это свойство со вью моделью? Если через замл, то свойство должно быть свойством зависимости. А как установить свойство зависимости в замле? - Ну, через стиль, например? У тебя есть вариант лучше?Для биндинга на code-behind мы применяем такое расширение разметки. Тут писал об этом: "Особенности применения UserControl" .
Alexey2112Хотя, можно и во вью модели сделать вызов OpenFileDialog - тогда не надо никакого гемора с байндингами и свойствами зависимостей - просто во вьюхе вяжешь команду из вью модели к кнопке и всё, ну а в команде открываешь диалог.Нет никакого гемора, если дополнить WPF своим расширением разметки, как показано выше.
Alexey2112Ведь, по идее, у нас вью зависит от фреймворка GUI, а вью модель должна "подстраивать" модель под это вью. Т. е. вью модель тоже каждый раз разная - в зависимости от платформы. Ну и диалог открытия файла - тоже разный в зависимости от платформы. Поэтому выбирать файл можно и в коде бихайнд вью, и в коде вью модели - они же всё равно оба зависят от фреймворка GUI. Вот моя логика.Я не ставлю задачу переносимости ViewModel между разными UI-Фреймворками. Считаю это глупой затеей.
Alexey2112Наверное, перенесу открытие файла во вью модель, чтобы не гемориться с депенденси пропертями и байндингами.Если ставится задача переносимости, то да, работу с FileDialog нужно выносить в UI-зависимый отдельный сервис.
Alexey2112Вообще, я вижу это так по MVVM.

Разделение модели и вью модели - чтобы писать логику предметной области на выбранном языке, не зависимом от языка приложения, которое будет показывать UI пользователю. Т. е. это как бы заточка и на то, чтобы вывести модель на сервер, и, если надо, разместить её в самом пользовательском приложении - да вообще, где угодно. Т. е. более кроссплатформенно сделать, когда UI уже не зависит от того, на чём написана модель.

Разделение вью модели и вью - для стилизации. Т. е. и вью модель, и вью должны быть связаны каким-то общим фреймворком (для модели и вью модели это не обязательно). Т. е. имея одну вью модель, можем сделать много разных вью для неё - для разных устройв (типа, под мобильный тач, под десктоп и прочее), но всё - на одном GUI-фреймворке. Т. е. разделение вью и вью модели "менее сильное", чем модели и вью модели. Т. е. в некоторых случаях их можно довольно сильно связать - чтобы избавиться от привнесённых "правил" (искусственно созданных трудностей), когда многостилевость для UI не требуется.Скорее так: Model содержит прикладную логику, ViewModel содержит логику представления.
Alexey2112Алексей КЯ за выделение классов по необходимости. Например, для повторного использования кода в разных контролах. Появилась необходимость - выносим часть кода в отдельный класс, даём новому классу гордое имя "сервис". :-)
Т. е., по идее, если надо не в одном месте подобный выбор файлов и байндинг на вью модель применять, то тогда лучше сервис?


vs

Alexey2112Алексей КЯ только не понял, зачем назначать Binding через Style+Setter.
А в чём, собственно, проблема? Просто непривычно для тебя, или какой-то плохой эффект от такого назначения ты усматриваешь?Ну мне показалось, что это не самый простой способ. Или я не понял, зачем так сделано.
skyANAАлексей КЯ за выделение классов по необходимости.У тебя это прям идея фикс какая-то :)Есть такое. :-)