WPF / Silverlight programmers: MVVM Overkill?

Question

I just have mixed feelings about MVVM. It seems I need to code so much to get the most efficient things to work with. I miss events (commanding is such a pain), binding everything leads to a debugging nightmare, and I miss the link to the view!

I was just curious to know about your MVVM feelings against plain old code. What do you like more and / or what do you usually use or recommend to use?

thanks

Answer 1

I am definitely a minority on this, but I tend to agree with @Shnitzel. MVVMs and bindings that go hand in hand with it are great ideas, but they are poorly served by current MS tools. The syntax for all but the simplest bindings is very difficult to get right, and it is greatly complicated by the fact that WPF and Silverlight silently swallowed all the errors. (Yes, some errors appear in the debug window, but they are not enough, and without sufficient detail.) You can use hacks, such as writing a debug value converter, but the fact remains: the toolbox is still quite immature. (And here is my standard complaint that data binding is not strongly typed, which means that tools CANNOT catch errors for you.)

I hear everyone when they insist on testability, and I'm a big fan of automated testing. But, at least with the current state of our toolkit, improved MVVM testability comes at a pretty high price.

Consider this scenario: you have a large application with 50+ forms / pages, and you just got into a big refactoring of your model and ViewModel. In this process, you renamed a bunch of classes and properties, etc. Now find all the places in your XAML that you need to change to display the new class and property names. So much to test, huh? Not only will the IDE not catch your binding errors, the compiler will not catch them, and most importantly, the application will not even throw an error at runtime. You need to get a tester to run the entire application, and make sure all your bindings are still doing what you want them to do. Ugggh. Ugly and painful. At least when I did everything the old way, the compiler will tell me when I messed up something.

Returning to my cave, to avoid slings, arrows quickly headed towards my path ...

[Edit 12/10/2010 - MS recently announced that SL5 will be able to debug data bindings , including the ability to set breakpoints on them so you can see what is happening. This is a big step in the right direction. It still does not fix what I see as a fundamental problem, that data binding does not have compilation type validation, but it does slightly improve the usefulness of the toolbox.]

Answer 2

People mentioned testing, which is a good point. Another point, in my opinion, - reuse, binds the same model of representation to different representations. For example, perhaps you have a simplified view for some users and a more advanced one for others.

I see that people mention how event handling is pain and per se. There are MVVM mechanisms that handle this. In my opinion, this is also acceptable for intercepting event handlers for encoding and calling methods on the viewmodel from code. This is certainly better than not using MVVM due to difficult times when people can connect to events.

Another HUGE advantage lies in the nature of MVVM, the separation of GUI and business logic. If you work with designers, they are all in the XAML world, talking about gradients, borders, shading, and what not. While you, the programmer happily encodes your ViewModel with unit tests. Therefore, when a designer has a prototype ready, it’s just a matter of connecting commands and bindings. Easy piecy GUI ready =)

Answer 3

The thing is that IMHO, a bunch of super-technological marketing hype, will serve NO purpose in the long run, except to stimulate development, where development costs can bear the burden of productivity loss ... i.e., offshore. Extremely SLOW creates a functional user interface that does NOTHING. It’s as if all applications are simple content pages, shopping carts or data grids. Very sorry. So, if an application in which there are several errors that smooth out over several release cycles is so bad, we will simply exchange it for a system that no one can understand in a general way ... for what? Testability? What a bunch of shit. As if the days of errors and corrections have gone? I, right ... my test says 2 + 2 = 4, so my application is error-free. Correctly.

Iterative development will return, mark my words. Once the true costs of TDD become more apparent than producing SOME functionality, you need it as soon as possible.

Answer 4

The truth is that many people do not use unit testing. And yet, there is still a good reason to use MVVM. I would like to point out that this excludes business logic from the user interface. In addition, if you have similar views, you can use the same presentation model for both of them.

I also like that I can make huge changes to the interface without touching my logic. Or I can easily add to the logic without touching my user interface. For example, I moved from a list to a combo box and should not have touched the code.

As for the command, this was a difficult moment for me for a long time. Then I discovered RelayCommand in MVVM Light. In this case, it is quite simple to configure the method to run using the command. Personally, I almost never use a parameter in my commands. I prefer to use only state inside the viewmodel.

Answer 5

Now some use MVVM and do a great job of this. Some of them are not since they raise the majority of dev tasks and do not participate in any large projects with such designers, testers, etc. However, I was in both and saw both ways. There are people who jump on any pattern and must implement it, no matter what. Even small small data management applications are developed in MVVM and more. They will be planned and planned for weeks, although some of these programs can be hacked in a few days, but templates and testing and much more must be completed. And honestly: many developers are learning, and some of these patterns are extremely overwhelming because they combine so many patterns and abstract programming techniques.

Answer 6

The usefulness of an approach like MVVM depends on the scale and complexity of the application. At one end, it’s not very difficult, not very useful, and the opposite end is “many man-years to build, impossible without something like MVVM”.

Testability goes hand in hand with this - applications are small enough and simple enough for MVVM to feel that the top is also so small and simple that the actual unit test coverage is farcical. However, the real world is usually very complex, which means that real-world applications need unit tests to maintain quality, and they need MVVM to be tested and manageable. Anyone who thinks they are without them burns a huge amount of energy, where very little is required; or, even worse, allow serious quality problems to mask something else.

Answer 7

From Josh Smith's article on MVVM :

In addition to WPF (and Silverlight 2), which make MVVM a natural way to structure your application, the template is also popular because ViewModel classes are easy to unit test. When the life of application interaction logic in a set of ViewModel classes you can easily write code that tests it. In a sense, views and unit tests are just two different types of ViewModel consumers. With a suite of tests for the application, ViewModels provides free and fast regression testing, which helps reduce the cost of maintaining the application over time.

For me, this is the most important reason for using MVVM.

Previously, I would have had controls that washed the view and viewmodel together. But the view, in fact, has mice and keyboard events as input, and drawn pixels as output. How do you unit test or integration test something like this? MVVM fixes this problem because it separates the untested view from the view model being tested and keeps the view layer as thin as possible.

Answer 8

MVVM has its own pain points - like all the template code needed for commanding, messing with the binding syntax, and incredibly stupid hacks should close the form.

- but -

This is all due to the lack of a good structure - this video was a big open for me for the eyes, if you choose the right structure it can automatically take care of all the unpleasant parts (and if you cannot find a good structure writing your own mini-frame, which solves your pain points are easier than dealing with bare MVVMs).

Take a look at this video and see how with a nice little structure you can write MVVM applications with less code than the alternative.