MVVM. Так где таки разместим business logic?
здесь, например, утверждается:
ViewModel: ViewModel is the middle layer between the view and model. ViewModel contains the business logic, which manipulates the row data to show in the view. Any kind of function and methods should be in the view model.
а здесь - совсем другое:
the view model, which encapsulates presentation logic and state; and the model, which encapsulates the app's business logic and data.
кто какое утверждение находит правильным (я - второе, если интересно), и почему?
Каждый по-своему понимает. И где должна быть бизнес логика, и что такое бизнес логика.
Обработка данных при передаче из модели во вью - тоже логика. А модель с конкретным вью и даже приложением тесно не связана - её можно к другому вью или приложению подключить. Можно назвать логику модели доменной, а логику приложения - бизнес. А можно не придумывать дублирующих названий, а называть логику по тому, в каком месте она находится - логика модели, логика вью модели и т.д.
Айти страдает от засилья теоретизирующих чудаков, множащих сущности без причины. Домен, модель, бизнес - всё суть одно и тоже.
Каждый выбирает свою позицию и будет считать ее единственно правильной. 
Но в принципе у нас есть:
- Model в которой "располагаются" данные и которыми мы можем обмениваться и сохранять. Значит там нем места для чего-то другого.
- View, который должен отображать данные или забирать их от пользователя. Ничего другого от него не требуется.
- ViewModel, связка между данными и отображением, как в одну сторону, так и в другую. Здесь тоже нет места для чего-то другого.
Приходим к тому, что для логики нужны свои собственные объекты, которые могут взаимодействовать и с Model и с ViewModel
А если бы ты был в состоянии читать английский текст, то ты бы выделил правильные куски и понял бы, что одно утверждение ни разу не противоречит другому.
ViewModel: ViewModel is the middle layer between the view and model. ViewModel contains the business logic, which manipulates the row data to show in the view. Any kind of function and methods should be in the view model.
the view model, which encapsulates presentation logic and state; and the model, which encapsulates the app's business logic and data.
Вывод: кури учебник английского.
мое понимание следующее:
Логика поведения во фронте должна быть в VM
Но там не может быть логики самого приложения.
мы не говорим о фронте/бэке. у нас имеется просто ПРИЛОЖЕНИЕ, задизайненное под mvvm pattern. т.е. наше приложение условно разделено на view, viewmodel и model.
под бизнес логикой будем понимать ... эээ... бизнес логику. хотел отослать к википедии, но мне их описание не нравится. там речь идет о real world и т.д. я бы определил бизнес логику как совокупность объектов, задействовованных в выполнении собственно задач приложения. неказисто получилось, можно еще подумать-подкрасить, но не сейчас. в общем, если мы программируем игру "полет на альфа центавра" в компании, похожей на ту, что у капитана кирка (или как его), то для меня это - не real world. но части приложения, которые будут решать, что делать, если в GUI клацнули мышкой на какую-то стрелячку, и попадет ли снаряд в приближающийся метеорит - это и есть для меня бизнес логика.
и я стараюсь выделить ее в "отдельный кусок", со своим интерфейсом, который может работать вообще без GUI (а с каким-нибудь тестером, его симулирующим. или как когда-то "вы можете пойти в калах". там же и в капитана кирка играли. лучи смерти и пр.). и бизнес логика в идеале вообще не должна знать, существует ли какое-то GUI.
и тут читаешь утверждение, что все это нужно поместить во viewmodel! в принципе, можно выполнение этой задачи вообще так размазать по приложению, что части бизнес логики можно будет обнаружить везде. и даже допускаю, что местами так будет казаться удобным: клацнули мышкой - и тут же из code behind запустили ракету. никаких тебе сообщений, вызовов, команд и прочей дребедени, вовлекающей в такое простое действие "лишних" участников.
Айти страдает от засилья теоретизирующих чудаков, множащих сущности без причины. Домен, модель, бизнес - всё суть одно и тоже.
почему именно айти? этим вся наша жизнь обременена. посмотрите, как много выражений (не айти, хотя...) для того же самого: какая ерунда, какая чепуха, какая мелочь, какая х-ня, ... нет чтобы оставить, к примеру, только последнее, и все бы понимали и не путались.
Приходим к тому, что для логики нужны свои собственные объекты, которые могут взаимодействовать и с Model и с ViewModel
пока я был поглощен работой над длинной простыней, вы очень сжато выразили то, на что у меня ушло полстраницы. я ставлю мою подпись!
мы не говорим о фронте/бэке. у нас имеется просто ПРИЛОЖЕНИЕ, задизайненное под mvvm pattern. т.е. наше приложение условно разделено на view, viewmodel и model.
Классическое описание MVVM есть букварь для новичков, мало или вообще не знакомых с многослойными, распределёнными приложениями. С одной стороны, этого достаточно, чтобы сосредоточиться на описании именно этого паттерна проектирования. С другой, многим это сужает кругозор. Лучше думать об архитектуре приложения как о совокупности разных слоёв или систем (распределённое приложение), при этом не обязательно строго иерархически связанных и не обязательно с одними, жёстко заданными направлениями потоков данных. И всякие паттерны проектирования лишь частные случаи конфигураций этих слоёв. В сложном приложении нельзя точно сказать, какой паттерн в нём применён - всего понемногу и не обязательно в целом виде. Когда разрабатываешь сложное приложение, лучше не думать навязанными понятиями, типа "модель", "вью модель", а думать более универсальными, типа "обработка данных домена", "конвертация данных". Как это назвать конкретно - модель или вью модель - дело десятое.
Вот цитата от автора букваря
"The viewmodel of MVVM is a value converter"
Согласен. Некоторые пытаются в том же WPF во вьюшные Value Converters поместить много логики, тогда как вся конвертация должна быть на самом деле во VM.
Я только ещё могу добавить, что в этом MVVM, который МС изобрела для WPF, есть особенность - тесная связь вью модели и вью. Связь в смысле особенностей проектирования вью модели - там классы вью специально заточены, чтобы во вью модели были реализации определённых интерфейсов. Такой связи и требований между моделью и вью моделью нет.
я придерживаюсь таких правил:
- View это сам XAML (в нём только Binding c ViewModel)
- ViewModel желательно ничего не знает о View (или знает как можно меньше)
- Model категорически ничего не знает ни о View, ни о ViewModel (только подозревает о них, потому предоставляет события)
Тогда View всё что делает в своих событиях (обычно мыши) - только вызывает одноименные функции Контроллера.
А вот конкретный Контроллер (не абстрактный) создаётся для каждой операции отдельно и удаляется по ее завершении.
Смысл имеет делать Контроллер только для тех операций которые связаны с более чем одним событием от View.
- ViewModel желательно ничего не знает о View (или знает как можно меньше)
ВМ и В в WPF связаны довольно тесно. Гораздо теснее, чем ВМ и М. Теоретически, одну ВМ можно привязать к разным В, но на практике обычно для каждой В своя ВМ. Одновременно, для одной М на практике обычно несколько ВМ испольуется и соответствующих им В.
Ещё В каким-то образом сама лезет во ВМ обновлять её свойства, даже если не использовать привязки - ты указываешь лишь контекста данных для В в виде ВМ в целом. ВМ же обновляет М только если ты явно это пропишешь.
Потому что, как написано в другой теме, ВМ для В в WPF является просто большим конвертером данных из и в М.