MVVM is a popular design pattern, but I think it is often misunderstood, and I frequently encounter people with strong opinions about how/when/where it should be used.
It's a powerful and useful pattern, but I meet people who use it that have never questioned if they should. It's just "what everyone does" and has become a default for many people.
It being a default isn't necessarily a bad thing, but never questioning decisions can be.
The MVVM pattern allows for separation between the UI/presentation layer and application or business logic.
It is commonly understood to provide 3 potential benefits:
- Increased testability (for business/application logic).
- Reuse of business/application logic in different projects/solutions/apps.
- More easily allow different people to work on the UI and other layers simultaneously.
And yet, I see people who are the sole developers on a project, don't write any tests, and don't need to (re)use any of the code elsewhere being dogmatic about using a pattern for which they get none of the intended benefits.
I admit that there can still be other benefits to using the pattern, but it's always worth questioning whether you should use something if you're not getting (or don't need) the benefits it was designed to provide.
Are you strictly sticking to "rules" of "how things are supposed to be done" when you're not getting or using any of the benefits the pattern was designed to enable and encourage?
The outcome you have mentioned is worth for relatively simple applications.
ReplyDeleteThe reason why I still tend to use MVVM being (sometimes) a sole developer - decreased complexity.
I need to mention that my regular tasks are far more complex than landing website or simple CRUD on server side.
I.e. when I need to get back to work done a month or more time ago I can easily understand my own code.
Of course, having extra bonus of MVVM (code duplication is close to zero) also helps.