MVVM - pro & contra
хотелось бы услышать мнение тех, кто в теме.
понимаю, что без вступительного слова с личным мнение открывать тему неприлично, посему скажу, что не являюсь почитателем этого пэттерна. считаю, что его применение оправдано в очень ограниченном кругу приложений, в большинстве же случаев его применение не привносит ничего кроме усложнения дизайна.
о чем говорит ваш опыт?
вы создавали приложения с MVVM from scratch? или это проделал кто-то другой, а вас подключили позже, показали где что происходит и куда лазить в случае чего? это важно.
С WPF почти не работал, но MVP под винформс использую с удовольствием - очень приятная штука.
Если привыкли работать по "старинке", то сразу и не вкуришь нафига енто надо.
Но зато когда логика отделена от отображения, получается весьма неплохо. К одному контроллеру можно цеплять различные въювы. Модель удобно сериализировать.
Хотя вообще меняется сам подход к разработке проги, да и тесты проще писать.
Я бы сказал, что применение оправдано почти везде, где чуть сложно.
Для WPF MVVM - это как бы "закон".
о чем говорит ваш опыт?
Пока вклинешся, то мозг дымит 
Но если врубился всистему, то очень даже удобная штуковина.
Даже в небольших проектах можно использовать уже готовые блоки без их особой переделки под определённый проект.
Можно разрабатывать саму программу и дизайн отдельно, не мешая одно другому.
Я делал и сам кое что по мелочам, и в группе работал.
Лучше конечно если с самого начала в проекте учавствовать.
Ну или если не с самого начала, то нужно что бы или доки хорошие были,
или чтобы кто-то объяснил куда нужно или можно лазить 
MVVM
И ему подобные используются сейчас всё чаще, хоть в нормальном программировании, хоть в веб.
Называется по другому, а принцип очень схожий или даже полностью
такой.
Для WPF MVVM - это как бы "закон".
это - не закон, а мода.
что смешивать гуи с бизнес логикой в кучу не есть хорошо - прописная истина, отарытая задолго до появления xaml, wpf и mvvm. и способов это сделать - множество. это можно чудесно реализовать без mvvm. не спорю: для определенного круга задач это должно хорошо подойти.
что такое mvvm я уже не первый год знаю, сделал одно приложение даже с опорой на него, и оно мне не нравится, собираюсь переделать. понимаю, сейчас народ начнет высказываться, что "руки кривые", я не собираюсь возражать, я знаю, что в данном случае виноваты не мои руки, а то, что я решил следовать моде и использовать этот пэттерн, где он не подходит. почему-то мне нравится, когда пэттерны упрощают задачу, а не усложняют.
особенно неудобно получается с этим mvvm, когда бизнес-логику нельзя отработать в главно трэйде (как это происходит во всех практически примерах по теме), а нужно создавать один (по крайней мере) working thread, как-то синхронизировать всю эту кухню, в общем, я разочаровываюсь все больше и больше. с mvvm это выглядит слишком навороченным. да, приятно, когда можно в хамл прописать один байндинг, и "все срабатывает автоматически". дело в том, что эта "автоматика" слишком навороченной получается, если следовать этому пэттерну. в общем, примерно так...
это - не закон, а мода.
не думаю что это мода, тем более на сезон. WPF вроде как бы базируется на этом принципе.
Но вообще начинать с поиска паттернов - это не очень удобно. Знавал одного, как что в СТ вычитает, сразу хочет применить.
Я обычно начинаю с другого, что мне не нравится в проекте и как это можно улучшить. Если есть похожий паттерн хорошо, определим, что из него взять лучшее.
Вот в последнее время перешел мне проект в "наследство" WPF c MVVM. Сервер, роботы и два устройства - все нужно связать в одно целое.
Если бы данный патерн не применялся, то фиг бы я во всей этой каше разобрался, а так получилось очень даже удобно.
Может тогда лучше начать с определения Ваших задач (не для вас конечно)?
что-то, конечно, знаю, но многое лучше знают другие, отсюда и вопрос.
касаемо "исторического развития", на моей жизни прошли восторги от
структурного программирования
языков высокого уровня
модульного программирования
объектно-ориентированного программирования
компонентов
распределенных приложений
...
по части HW ситуация похожая: мэйнфрэймы, мини-эвм с терминалами, затем - персоналки с ресурсами сравнимыми (и превосходящими) вчерашние мэйнфрэймы, и параллельно - виртуальные машины на мэйнфрэймах, сегодня - снова возврат к виртуальным "персоналкам" на мэйнфрэймах, и так д.
, и каждое из них было "шагом вперед" (хотя термин появлялся намного позднее, как правило, чем использование концепции), позволяло решать определенный круг проблем (большинство было просто маркетинговым трюком), но в то же время становился модной фишкой, без которой вы не могли сказать, что работаете "на уровне". из сегодняшних модных фишек наряду с упомянутым в теме могу назвать test driven development, "rapid" development (хорошее маркетинговое слово: кто посмеет утверждать, что "быстрая разработка" - это плохо?), и масса всякого, известного любому. большинство из них подходят под общий термин: silver bullet.
вспомните corba, например. помню время, где все искали разработчиков, имеющих опыт с этой технологией. сегодня не всякий знает, что это было такое.
а если уже говорить о "стандартах" wpf, то еще круче, чем mvvm будет prism. слыхали уже? я нечто подобное применил впервые лет пять назад (ну да, я - крутой : ), конечно, не в таком масштабе, как эта команда (ресурсы у меня по сравнению с ихними - ничто), но не назвал это "технологией", просто решил вот так построить приложение. до словарей и манагеров, правда, дело не дошло.
делаю вывод: первоначально wpf был задуман очень хорошо. не зря возникли проекты mono, xamarin и пр. но вот эти prism&mvvm - это то, где наступает перебор. где вложение усилий в их освоение и применение уже начинает давать отрицательный эффект, и поэтому требует вынесения технологий на новый уровень. наверняка уже появились новые технологии, созданные с учетом полученного опыта, где приложение вроде сегдоняшних "призм" создаются за пару маускликов, но сегодня мы (я : ) не знаем, которая "правильная". просто времени нет (пока).
не думаю что это мода, тем более на сезон. WPF вроде как бы базируется на этом принципе.
если бы это было так, принцип возник бы раньше, чем wpf. а оно наоборот. причем сильно наоборот.
mvvm это принцип, который какой-то студент не поленился довести до уровня "пэттэрн". уверен, многие строили на базе wpf приложения подобным образом (я в том числе), но никто не пытался это как-то обозвать и заявить, что теперь все должны делать только так.
Если бы данный патерн не применялся, то фиг бы я во всей этой каше разобрался, а так получилось очень даже удобно.
у меня это было еще удобнее: когда понадобилось подключить других разработчиков, они ко мне даже с вопросами не подоходили, они просто забрали код, попялились в него пару часов и поехали делать свое дело, держа перед гдазами спецификацию. я, правда, не употреблял нигде слов model и viewmodel, но каши нигде не было, и все (двое, правда, всего) сразу поняли, где происходит бизнес-логика, где происходит гуи и пр. да, там не все было красиво, и я до сих пор жалею, что не было времени на "последний штрих" (а его нет никогда), но, работая с мввм, всегда сравниваю. и уверен, построй я тогда
то же самое на этом мввм, мне долго пришлось бы помогать коллегам въехать в тему.
Но вообще начинать с поиска паттернов - это не очень удобно.
я с этого и не начинал. просто не могу оценить технологию, пока руками не попробую. а тут - как раз подвернулась возможность опробовать. так сказать "пойти в ногу со временемъ" : )
короче. сегодня каждый имеет машину и умеет ей управлять. в машинах есть по-прежнему газ, руль, тормоз, сцепление, указатели поворотов, включатель дворников (не путать с указателем поворотов!), свет туда-сюда, ремни безопасности и вроде все, этим можно обойтись (летом еще кондишн). и вот появляется гений, который добавляет кнопки "повернуть направо", "повернуть налево", "остановиться на светофоре", ... все очень круто, только уже так много кнопок, что не всегда найдешь нужную. так вот для меня этот "стандарт" мввм - "кнопка ехать в супермаркет".
сегодня, кстати, тратится куча бабла на разработку "безпилотной" машины. странно только, что до сих пор нет ни беспилотных локомотивов, ни беспилотных транспортных судов. а ведь там все на порядки проще, чем с автотранспортом. это и есть - мввм : )
вот, набрел на статью
https://msdn.microsoft.com/en-us/magazine/dn630646.aspx
, которая (если прочитать) со 100% точностью показывает, что wpf создавался без никакой mvvm в голове, и последний появился уже как "наворот", который, предполагалось, что-то "облегчит", "ускорит" и "автоматизирует", помимо родных изначально wpf'овских bindings.
меня удивляет, что до сих пор никто не создал сегодня никакой достойной альтернативы, все строят "навороты" на уже имеющиеся технологии. единственно кто развивается (кажется), это сегодня qt. но у них - своя ниша, мало пересекающаяся с wpf.
Что то вопрос не понял.
Мне просто интересно было в чем лично для вас главное отличие.
Лично для меня разница исключительно в Data Binding (а я его в принципе не люблю, потому и MVVM отношение соответствующее). Типа View будет знать к чему ему из VM привязываться (ха-ха три раза). А уж мыслЯ про многократное использование VM и невозможность презентер использовать многократно... даже комментировать не хочется.
Общее отношение к MVVM... как к типичному микроштофовскому "выкидышу" - мы сделаем как у всех, но поменяем пару слов местами, сделаем несовместимым и назовем по-своему!
со 100% точностью показывает, что wpf создавался без никакой mvvm в голове
Там вроде немного о другом. У меня несколько иная информация.
https://msdn.microsoft.com/en-us/magazine/dd419663.aspx
2004 - Martin Fowler публикует статью о паттерне Presentation Model (PM)
2005 - John Gossman, из команды архитекторов WPF и Silverlight в Microsoft, представляет Model-View-ViewModel (MVVM) в своём блоге. View странным образом понимает и INotifyPropertyChange, и Observable и пр.
2006 - WPF 3.0
Никакой MVVM в голове ну уж точно не было
Мне просто интересно было в чем лично для вас главное отличие.
Давайте для начала еще раз уточним, подавляющее время я работал с WinForms, ASP.NET и WPF встречаются время от времени.
Поэтому чувства "совместной" жизни с WPF пока нет. Всё что говорил относилось к "моей" реализации паттерна MVP для WinForms. И судя по тому с чем я до сих пор сталкивался, отличия от MVVM для WPF не очень значительные.
Презентер заменяется Въюв-моделью и для въюва не нужно определять интерфейс. Об OnPropertyChange не нужно забывать.
невозможность презентер использовать многократно... даже комментировать не хочется
тут совсем наоборот, пользовал я презентер с различными въювами - очень удобно получается. Хотя насколько моя реализаци отличается от классического определения - исследования не проводил. Как то было совсем неинтересно - главное что бы было удобно пользоваться.
просто не могу оценить технологию, пока руками не попробую
Ну вроде у всех так.
У меня таке предложение. Давайте возъмем какое-то приложение сделанное с MVVM и сделаем из него "решение в лоб" и "ваше" решение.
А после уже будем анализировать.
Мне вот попалось следующее приложение
https://yadi.sk/d/F8XfnjR03NXuus
из статьи на хабре
не надо ничего искать. я вам просто такую простую задачу нарисую.
гуи - единственный диалог, где дюжина-две кнопок, при нажатии кнопка окрашивается как "выбранная", при повторном нажании - "невыбранная". мы должны наклацать из них некую "допустимую" комбинацию. существуют некие "правила": например, нельзя одновременно выбрать А и (Б или В), если выбрана Б, то Г,Д и Е должны быть деактивированы и прочее. когда комбинация оказывается "допустимой", кнопка Ъ становится активной, если ее нажать, на заднем плане начнет выполняться нечто в течение 10-15 секунд, в течение которых некий progressbar показывает, как там дела, затем снова можно выбирать.
задача очень просто решается, как вы сказали, "в лоб". а если захотите мввм - подбирайте себе бубен и разминайтесь : )