After 2 years, I'm still struggling with MVVM as a practical method of producing working software. In some cases it's great. I did a multithreaded application that controlled a small assembly line that would have been a nightmere without MVVM concepts. An abstraction from the physical assembly line was almost a no brainer.
However, my career mostly revolves around internal line of business applications - formalizing and optimizing the operations of a business. In such apps, there is generally a business teir revolving around CRUD and compound operations. In LOBs, my view models end up being a very simple collections of one line wrapper functions of the business class methods and in the end only end up complicating the simplest of tasks like showing a message box or opening a window. Doesn't anybody else find it odd when people go into long discriptions of "dependency injection" and "messaging providers" for a Window.ShowDialog call that has been around for decades? How many other questions are there on stack overflow asking for advice for tasks that were extremely simple in winforms?
Don't get me wrong - I get MVVM and how it could be invaluable to large teams doing horizontal development of a shrink-wrapped and marketed software package. Unit testing the view models could save millions by avoiding a bad RTM bug and dedicated UI developers could give a rich experience. But when the cost of redeployment is minimal and all the business cares to pay for is simple working software, why should i spend time unit testing a simple "wrapper" vm when my business logic is already unit tested? How much time is the business really going to allow me to spend on cute animations and color schemes? Is there anything left for a junior developer to do (tracking down a bug in a save functionality used to be looking at "Save_Click", but now you have to understand the patterns and the project as a whole especially if you're relying on templating to marry up the VM with the view).
Admittedly, I really like the databinding of WPF. To take advantage of it, I set the data context to the window itself, where it has access to the business class as well as any other observable properties. Yes I break nearly every MVVM "rule" by doing so. But at least I have simple event driven code that's easy to read AND I get to take advantage of the new databinding and validation. The problem is in the designers - which I don't use all that much but hope to now that it's better integrated in 2012 - the designer shows the hundreds of properties that a window and its base classes have.
For those that can relate can you point me to resources, books, or even just changes in perspective that made this easier to swallow. I'll give MVVM another shot, but the last time I felt pretty stupid for worrying about dependency injection just to show a message box from a VM I had no intention of unit testing. Even if I did unit test are we really getting more quality by trading run time testing for compile time errors of those dreaded "tightly-coupled" applications?
I realize one answer is to just stay in winforms. But as one of the last supporters of WebForms (I have much of the same critique of the trend of web developement), i felt a little like a dinosaur as it is when I descovered there's no more WebForms left in the Microsoft certification tracks. Moving forward is the only option, even if I don't like it.