When NOT to use MVVM?

I have started using MVVM pattern recently. I have had several projects where I used it and with every new one, I start to see that it will fit great within that new project.

And now I start to 开发者_如何转开发ask myself are there situation when it's better NOT to use MVVM. Or is it such a nice pattern which you can use anywhere?

Could you please describe several scenarios where MVVM wouldn't be the best choice?

I can think of two circumstances under which I wouldn't use MVVM.

One is if the application's simple enough that I don't need a separation between the view model and the model. Does it muck up my class too much if I implement INotifyPropertyChanged and a RelayCommand or two? If not, I might skip the step of creating a separate class. Or I may just want a view model to mock up a functional UI, and worry about implementing actual back-end functionality if the client bites.

The other is when I need high enough performance, and there are enough objects in the view, that I need to write code that manipulates WPF objects directly. I haven't actually benchmarked it to be sure, but I'm be reasonably certain that drawing 1000 moving particles by iterating through an array containing them and modifying their TranslateTransform directly (if indeed that's the fastest way to position them) is going to be faster than modifying their base properties and having binding do it.

I only do not MVVM if its a tool that is not used more than at a specific moment and then never ever.

In many "small" projects, I have begun without, and later on, I have changed to MVVM. It makes the projects IMO much more clean and gives all my projects a similar structure. This helps me a lot to change quickly some things in some elder code if a client has a small request. I don't loose much time to me orientate.

Another advantage is that it's easier to hold my libraries clean, because I can focus on one technique and have therefore more time to maintain and extend.

It all depends on what you want to do.

Like the guys have said, if you are creating a small tool or project that will not need extensive testing etc then MVVM would be overkill.

Arguably MVVM's main advantage is that it makes the code unit testable as it abstracts away from Visual Layer. For large projects that need to be reliable and are to be used by customers etc (and not just yourself as the end user) then MVVM is a good design pattern to use.

I guess in a nutshell - if you are simply creating a small project to mess around with then MVVM would be like trying yo kill an ant with a bazooka :)

For me it's best to not use it when you want to do a small project or never plan to make it run under several ways (WPF/Silverlight/WEB/Dll), then MVC is enough.

Short Answer: Don't use MVVM if you are not using WPF/Silverlight/any technology I know with powerful automatic binding.

Long Answer: No other pattern facilitates unit testing better than MVVM in WPF/Silverlight. I would suggest you take a look at another of my answer : Why should I use MVVM in Silverlight app?

You may want to have a look at A vent about MVVM development at the Silverlight forum where some of the benefits and shortcomings of MVVM are discussed.