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.