So many methodologies on how to program. Things were so simple 20-30 years ago. Single file programs. Then turning into multiple files, procedural. Then OOP. Then Winforms. Then MFC. Then .NET and all the C# goodness. Then WPF. And now MVVM.
There’s pluses and minuses to advancement in technology. On some occasions, I feel that things are a bit over-engineered or are lacking. MFC lacked. MVVM is a bit over-engineered for most cases. MFC is no longer relevant, but MVVM certainly appears to have a place in Windows technology right now.
I’ve developed a number of applications both applying and not applying MVVM verbatim. Here are my thoughts:
- MVVM has benefit for when you have a team of people where Engineer and UX Designer are two different people.
- Separation of concerns is generally a good thing. It can make things easier when creating a test plan.
- Communicating between ViewModel and Model can really become a pain.
- Projects can take me 3x longer to complete by following true MVVM.
- Large hurdles to overcome, like adding a crazy EventAggregator so that two ViewModels can communicate. Yes, it’s crazy because it becomes so heavy on events.
- The “Binding/x:Bind” concept is cool, but debugging is a nightmare, if not impossible.
- Although there are cool concepts like ICommand, not every View control supports it.
- Many of the features in WPF have gone away in UWP. Even the IWeakEventListener referenced in Josh Smith’s PropertyObserver is not longer available.
Clearly, I’m not completely sold on the C# implementation of MVVM from Microsoft. It’s good to see advancement, but it’s now getting to a point where a single Engineer must spend 2-3 weeks building a Framework for a simple program. IMO, Microsoft should take something like MVVMLight or Prism and build it directly into their API. Downloading through NuGet is not an answer – especially since some packages advertised with the NuGet Package Manager do not work with UWP.
For reference, here’s Microsoft’s take on MVVM.