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

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.