Thinking out loud (or rather through typing) here.
The MVVM pattern has a problem: everyone has a different definition of what it is and how it should be implemented.
"Everyone" thinks their understanding is the correct one, and doing it a different way isn't the "proper" way of doing it.
It was always intended as a loose structural guideline and principles rather than as a highly prescriptive way of writing code.
Maybe it's just me, but I still hear more discussion and focus on the use of MVVM as a "framework" than on other aspects of making a great app and creating an easily understandable and maintainable codebase.
Two key benefits that MVVM was initially intended to provide don't seem all that relevant either.
Reuse - When a ViewModel was referenced in separate solutions that each targeted a different platform, abstracting logic away from the UI to easily be reused in multiple solutions/apps made a lot of sense. When using MAUI, Uno, or Avalonia--where a single solution can produce apps for multiple platforms--using an architecture that structures code for reuse when none is needed risks adding unnecessary complexity.
Testability - most ViewModel code (still--sadly) goes untested. If you're the exception, congratulations. So, doing something for the sake of testability but then not creating tests seems a bit unnecessary. (At best.)
So what to do instead?
I don't have a single answer.
I know there are things like MVU and MVUX, but I just wanted to write this to get my subconscious thinking about the idea...
I started using MVVM when I was programming Silverlight. The "you are doing it wrong" was the biggest problem in my opinion. Meaning it became a 'religion' rather than a design pattern. So I always did "MVVM Lite" meaning, just use the parts of the pattern that made sense. When I program MAUI apps (see: https://github.com/ADefWebserver/AIStoryBuilders) I just use Blazor. The end users don't know, nor (have they ever) cared.
ReplyDelete