Для WPF MVVM - это как бы "закон".

это - не закон, а мода.

что смешивать гуи с бизнес логикой в кучу не есть хорошо - прописная истина, отарытая задолго до появления xaml, wpf и mvvm. и способов это сделать - множество. это можно чудесно реализовать без mvvm. не спорю: для определенного круга задач это должно хорошо подойти.

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

особенно неудобно получается с этим mvvm, когда бизнес-логику нельзя отработать в главно трэйде (как это происходит во всех практически примерах по теме), а нужно создавать один (по крайней мере) working thread, как-то синхронизировать всю эту кухню, в общем, я разочаровываюсь все больше и больше. с mvvm это выглядит слишком навороченным. да, приятно, когда можно в хамл прописать один байндинг, и "все срабатывает автоматически". дело в том, что эта "автоматика" слишком навороченной получается, если следовать этому пэттерну. в общем, примерно так...