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 показывает, как там дела, затем снова можно выбирать.
задача очень просто решается, как вы сказали, "в лоб". а если захотите мввм - подбирайте себе бубен и разминайтесь : )
если вы еще не работали с wpf, но хотите въехать, я бы порекомендовал прочитать/проработать эту книгу:
https://mehmetakifsonmez.files.wordpress.com/2013/12/wpf-4...
я эту редакцию еще не видел, сам учился по первому изданию, эту просто нагуглил специально для вас : )
да, про мввм там ничего нет, но это уж вы сами поищите, если есть интерес. а о binding'ах здесь очень хорошо изложено. потом, после этой книги (или одновременно) - вот очень толковое и подробное чтиво:
https://www.codeproject.com/Articles/23772/WPF-A-Beginner-...
а пример я просто так привел, чтобы проиллюстрировать, что мввм не всегда удобный. его идея
- мы не пытаемся менять/опрашивать наши данные из когда диалога
- мы не организовываем наши данные в угоду удобства их визуализации и вообще об их визуализации здесь ничего не знаем.
- для этого мы создаем нечто между гуи и данными, что знает обе стороны: с одной стороны это (в мввм это называется вью-модель) знает как огранизованы данные, с другой стороны содержит объекты, к которым вью может прицепиться binding.
идея правильная, но ее не обязательно нужно реализовывать, жестко разделяя все приложение на вью, вьюмодель и модель. реальные задачи богаче и разнообразнее, чем те, которые удобно реализовывать по этой схеме. чаще нужно просто эти принципы (известные задолго до впф и мввм) не забывать и руководствоваться здравым смыслом, а не пытаться непременно запихнуть все в прокрустово ложе какого-нибудь пэттерна.
приведенный мной пример также можно реализовать как мввм, но прийдется нагородить сущностей, которые будут служить только для того, чтобы эту логику, которую можно отнести и к
"бизнес-", и к гуи, поместить "как положено" во вьюмодель, и все нас похвалили за "правильность". но это будет менее удобно, чем делать все, не вспоминая о мввм.
Прикреплённые файлы
https://www.visualstudio.com/vs/community/
2010 у меня уже давно нет. Ладно тогда ехешник закину. А код можно и так глянуть.
если вы еще не работали с wpf, но хотите въехать
Спасибо за заботу, гляну.
У меня стадия немного другая - я не знаю многих ньюансов и не делаю многое на "автомате".
Имелось в виду, что сделанный мной пример можно в WPF реализовать "правильнее" чем это сделал я.
я бы для эксперимента попроще держался. давайте заменим содержимое вашего grid на это:
(вставлю файл)
(вставлю файл)
вот кнопочки уже и перекрашиваются. примитивным образом. для "одноразовых" задач - сойдет, но я бы не непосредственно цвет менял, а сделал бы производную кнопку, добавил ей dependency property "isSelected", и в стиль вставил триггер, который бы выбирал цвет в зависимости от значения.
но это - не то, чем мы сейчас увлечены. нам вроде как интересно подумать, куда же воткнуть "правила" выбора кнопок. самое простое - поямо в код окна. это - быстро и просто, но это - только если если делаем "одноразовку". а чтобы было хорошо, такой подход не годится, нужно вынести это куда-нибудь. вариантов - много. ждем предложений.
кстати, если сразу настроиться, что "мввм для впф - эакон", то нужно начинать углубляться, строить модель, куда помещать данные (видимо, некий набор выбранных значений), создавать вьюмодель, где имплементировать некие объекты, к которым можно было бы прицепить состояние кнопок, и команды, к которым прицепить свойство Command от кнопок, и убрать нафиг button_click и прочее из кода окна. все переедет во вьюмодель, будем в Execute() ловить, которая кнопка нажата и проставлять по правилам свойства у объектов, к которым привязаны свойства isSel & IsEnabled всех кнопок.
до сих пор все не так уж сложно (хотя "в лоб" - значительно проще). гдавное начнется, когда мы захотим нажать на "дуит", и захотим видеть прогресс.
шайсе! не знал, что квота все выравнивает влево :
( сейчас, если разбурусь, как аттачить файлы, прицеплю...
А нельзя ли выложить полный 2010 проект?
Потому как после простой замены cs файла и части хамл (что кстати совсем не ожидал, всегда ожидаю "целый" файл) ничего вообще не компилируется.
Но вообще то, как и ожидал, все закинулось в одну кучу. Естественно, что в этом случае никакие "нормальные" паттерны не помогут. Дело в том что я/мы так не делаем никогда.
Ну и нагружать вьюв "хамловской логикой" я лично просто ненавижу, возможно сказывается дурное воспитание винформс.
Весь смысл attached property в том, чтобы добавлять свойства классам без создания их наследников. Если вдруг понадобится свойство IsSelected присобачить другим элементам, то в случае с attached property ничего делать больше не надо - класс-то готов уже. А по вашему варианту придётся создавать наследников для всех этих элементов.
я так сделал, чтобы показать, что такое "в лоб".
Спасибо что пояснили, потому как у меня совершенно другое представление как это делать в "лоб". В любом случае, старт был такой же как я выложил раньше.
Потому как подобный "бардак" не признается ни как каком уровне. Разве что тест для изучения чего либо.
Давайте тогда свой "старт", будет интересно глянуть.
причина где-то в хамл-коде.
не думаю, хамл то без проблем открывается в дизайнере студии. Единственный способ, который нашел раньше. Переименовать старый файл, создать новый с требуемым именем и все туда перенести со старых.
Я вот так и не понял, как бороться с подобной ситуацией, делаешь, что то то делаешь, а после хамл не грузится - кричит давай проект перекомпилируй. Приходится пол хамла комментировать (иногда копировать куда то), компилировать, а после восстанавливать.
Что то явно со студией. Сегодня десяток раз вылетала на открытии "попорченного" проект, а теперь и вовсе не хочет грузится. Счас пробую переинталлировать.
Кстати, пока не смог решить проблему с изменением цвета кнопки после нажатия. То бишь цвет кнопки то меняется, НО только после того как мышка уйдёт с данной кнопки. Хотелось бы чтобы цвет изменился сразу после нажатия кнопки мышки (уже и с триггером пробовал, всё равно не получается). Где нахомутал пока не понял.
Кстати, пока не смог решить проблему с изменением цвета кнопки после нажатия. То бишь цвет кнопки то меняется, НО только после того как мышка уйдёт с данной кнопки.
для этого я вам кусок кзэмыла прицепил, где поменял стиль этих кнопок. верните назад, и кнопка перестанет реагировать на наведение мышью.
Нее проблема не в Вашем коде а в моем.
У меня цвет кнопки меняется, однако не тогда когда хочется.
Хочется чтобы менялся сразу после нажатия, а он меняется только после того как мышка "уйдет" с кнопки.
Попробовать правда пока ничего нельзя. Студия "сломалась". Хотя сейчас уже второй раз "ремонтировал" студию, но похоже проблема в каком то плагине.
послушайтесь меня на этот раз. верните style на место, и все будет как вы хотите. у кнопки есть стандартный стайл, и там предусмотрен ее вид, если мышь наведена на нее. другого способа это отключить, кроме как переписать стайл, я не знаю. кнопка ваша меняет цвет сразу, только вы это замечаете только после того, как курсор сползен с кнопки. попробуйте навести мышку на кнопку снова, и убедитесь.
visual studio не может грохнуться от того, что вы в коде ошибку допустили. если бы так, с ней бы никто не смог работать : )
послушайтесь меня на этот раз. верните style на место, и все будет как вы хотите.
С удовольствием послушаюсь, но никак не возьму в толк. Сделать новый стиль - какой? Я ведь не убирал ничего.
Есть пустая форма, на нее кидаю кнопку. Запускаю - по OnHover меняется цвет. Меня это не интересует, по нажатию на кнопку ничего не происходит.
Затем добавляю код в c# для изменения background по нажатию на кнопку, кидаю другую кисточку, пробовал и черз XAML Запускаю, нажимаю на кнопку - ничего не происходит. Убираю мышку цвет меняется.
Было предположение что обновление не приходит вовремя, но похоже дело не в этом.
visual studio не может грохнуться от того, что вы в коде ошибку допустили
Согласен, просто интересное совпадение. Какой то плагин грохнулся. В /SafeMode работает, в /RootSuffix Exp работает
А как отключить плагин не зная его "ид" не нашел пока. Пробую по одному удалять.
Сделать новый стиль - какой? Я ведь не убирал ничего.
поведение кнопки если курсор на нее наводят описано в ее стандартном стиле. а когда вы клацаете на кнопку, курсор находится на ней, поэтому вы и не видите, что там что-то меняется, пока курсор с нее не съедет.
чтобы этого не происходило, следует переопределить стиль для кнопки. в кзэмл файле сразу после (угольные скобки я заменил везде на круглые, иначе не покажет как надо)
(Grid)
допишите следующее:
(Grid.Resources)
(Style x:Key="btnstle" TargetType="Button")
(Setter Property="Template")
(Setter.Value)
(ControlTemplate TargetType="Button")
(Grid Background="{TemplateBinding Background}")
(ContentPresenter HorizontalAlignment="Center" VerticalAlignment="Center"/)
(/Grid)
(/ControlTemplate)
(/Setter.Value)
(/Setter)
(/Style)
(/Grid.Resources)
, и кнопке определите этот стиль:
(Button Content="A" Style="{StaticResource btnstle}"... HorisontalAlignment="..... .../)
и ваша кнопка перестанет
замечить, что на ней находится курсор.
если название стиля btnstle вам не нравится, назовите по своему. остальное все - ключевые слова.
и ваша кнопка перестанет замечить, что на ней находится курсор.
Угу так и есть, получилось. 
Теперь следующий этап - зафигачить кнопы в группу. Хочется чтобы состояние кнопок выдавало интегер как набор битов, тогда правила будет проще записать.
Но я еще даже не думал об этом. Со студией возился, там теперь новый инсталлер и нужно обязательно выбрать .NET desctop development
ну вот, такое получилось. еще бы что-нибудь "вьюмодель" обозвать, да какую-нибудь "модель", где "правила зажигания кнопок" разместить, и полный вам мввм.
попробуйте сказать, что это "неудобно" : )
код бихайнд остался вообще нетронутым, как его студия содзала.
докрутил только три первые кнопки, для остальных нужно пропертиз прописать и к ним прибайндиться, и тоже будут "преключаться".
я, наверное, дальше продолжать тему не буду, реальная тема ждет. всем спасибо за участие ...
Как говориться, спасибо и за это. Жалко конечно, но мне пока интересно енто делать, буду продолжать.
Я пока смотреть проект не буду, пока свое не сделаю. Только вот интересно, гляньте кто нибудь - организация GUI такая же как и была раньше, все на одну форму накидано?
Тогда вообще нечего обсуждать, по теме. Для меня подобные проекты - прямо в мусор и конечно, еще какие то паттерны городить там совершенно бессмысленно.
...организация GUI такая же как и была раньше, все на одну форму накидано?Тогда вообще нечего обсуждать, по теме. Для меня подобные проекты - прямо в мусор...
жаль, что мне не удалось донести до вас, о чем собственно тема. теперь вижу, что для вас она определенно - в мусор.
если я правильно понял, "все на одну форму накидано" - это о кнопках? тема была вовсе не о том, что за кнопки, можно было взять просто прямоугольники или любые другие элементы, и "накидать" их все равно куда. тема была о том, как построить дизайн так, чтобы было удобно: с мввм или как-то иначе. а вы - "организация хуи"... я в вас разочарован. не люблю, когда люди говорят (особенно резко) о том, в чем ничего
не понимают.
тема была о том, как построить дизайн так, чтобы было удобно
можно было взять просто прямоугольники или любые другие элементы, и "накидать" их все равно куда
Вы хотите связать несвязываемые вещи. К "бардаку" нельзя построить "удобный" дизайн.
я в вас разочарован
Вы можете быть разочарованы только в том что у нас различные точки зрения к построению проектов.
И то что они различные - это совершенно ни о чём не говорит.
люди говорят (особенно резко) о том, в чем ничего не понимают
Я вроде и не скрывал, что в WPF не работаю постоянно и что сейчас он меня побеждает, а не я его. Вы вроде и сами писали что в рабочих проектах так не делаете. Конечно было бы интересно узнать как делается в "рабочих проектах".
А организация посторения GUI от языка вообще мало зависит. Данную форму можно было реализовать и на Яве и в ASP.NET и в Winforms.
Для любого языка просто так накиданные элементы на форме для меня "бардак", с которым низзя работать.
Сделал вот первый вариант, не все так как хотелось и не все "правильно", но вроде все главные условия выполнены.
Ехешник не удалял, так что можно сразу запустить.
Документация получилась размеров в мегабайт, так что выложу просто картинки.
