Can the Architect be right "MVVM only splits the code behind to multiple (3) files "

Question

I am pretty new to WPF and I have an discussion this morning with my architect who is from C,C++ background.

We are trying to create a video calling application which depends on native dlls by making PInvoke. The WPF application is mainly the UI and in code behind we are making Pinvoke Calls for Video /Audio and listing the available drivers.

So If we are talking Data as from database then there is not much of the "Data" involved in our application.

The WPF application we are trying to modify is Boghe and surprisingly they too are not using MVVM.

While I am keen on implementing MVVM the architect points it as unnecessarily splitting the files in to 3 parts.

He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?

Though I have theoretical answers but can't help but agreeing to his point. Is he actually right?

Answer 1

I too agree with stakx and Mare Infinitus; MVVM provides a lot of benefits and is not just creation of multiple code behind files.

From my experience MVVM is the best way to learn and use the power of WPF, it kind of encourages and forces you to use WPF features like Binding, Commands, Styles, Converters etc. I have seen application's being developed without MVVM and they turned out to be WPF application in Winforms style having problems stakx mentioned (and more).

Apart from UnitTesting(which I think is very imp. in your application), re-usability etc. one very important benefit of using MVVM is that it can support multiple views, i.e. you can have multiple UI's for your application all of them can use same ViewModels; This may not be a requirement for you today but you may require to have a new interface few years down the line or support other platforms like Silverlight or Metro in future, MVVM will save you a lot of effort in that case.

I would suggest you to go through this post which explains real benefits of MVVM and explains other so called benefits (although I feel they are real benefits in practice) - MVVM Backlash

Answer 2

He says if we want to change any thing in the view like changing a button or any control then it can be directly done in code behind. Why then use MVVM?

Of course it can be done this way. The question is whether it should be done this way.

For a fairly small code base, you can probably get away with mixing up data access, core logic, and UI manipulation in code behind. In the long run however, that will not make for maintainable or testable code, and the mess is likely to get worse over time and turn into spaghetti code. Take my word for it, because a good portion of my time at work is put into reversing such old messes.

Some consequences of mixing everything up in code-behind are:

• Code that fundamentally violates the "Single Responsibility Principle" (SRP).
• Code that's hard to understand because it does very different things all in the same place.
• Code that breaks easily. I change something here and for some arcane reason, some feature breaks over there.
• Code duplication / violation of the "Don't Repeat Yourself" (DRY) principle. You often find the same logic in several places. Is this accidental, or on purpose? If I change logic here, must the same/similar logic over there be changed too?

Note that with the exception of the first point, these are not theoretical concerns, but very real, immediate problems of your typical "legacy" code base.

In my opinion, it's not entirely correct to say that MVVM introduces more code-behind classes. This is clearly a statement from someone who does not appreciate the fundamental separation of concerns that comes when you isolate the data, business logic, and UI logical layers from one another: Even with MVVM you have only one code-behind class for your views. The other two classes (yes, there will likely be two more) simply can't be considered "code-behind" because they aren't directly tied to the view / designer.

Answer 3

Short Answer: No! ViewModels are not the same as Codebehind in different files.

With a proper MVVM implementation, you do not have a codebehind, or at least a very small one.

But in the ViewModel you do not have direct access to the window, as in MVVM the communication between ViewModel and View is done over Binding, there is no direct reference to a View (normally).

MVVM brings in some enormous advantages over view centric approaches. It is testable, it is far easier changeable, it is an adapter, ...

edit And if he really is your software architect, he should know better... at least thats what I expected from a software architect

Answer 4

one purpose is that you can unittest your view logic(viewmodel) without the view.

here one nice comment from Rachel regarding viewmodel first approach:

Remember, with MVVM your ViewModels are your application. The View is just a pretty interface that allows users to interact with your ViewModels.

Answer 5

If you have only two people in the project, and everyone's all-in-one person, he's right.

But if you do not want designers messing up the controller (or ViewModel), or programmer that changes view to something, you know, as programmers do design.

In addition, You have the clue where to do changes immediately, without searching enormous text files.

Also, the separation by MVVM or MVC is one of basic principles of programming, it's Data-Logic-View separation, and if architect says you not to do it, may be it's time to ask another architect :)