Can the Architect be right "MVVM only breaks the code into several (3) files"

Question

I am new to WPF and this morning I have a discussion with my architect who is in the background of C, C ++.

We are trying to create a video calling application that depends on its own DLLs by creating PInvoke . The WPF application is basically the user interface and the code behind which we make PInvoke Calls for video / audio and listing the available drivers.

So, if we say “Data as from a database”, then in our application there is not much “ Data ”.

The WPF application we are trying to change is Boghe , and, surprisingly, they do not use MVVM either.

While I'm interested in implementing MVVM, the architect points out that he unnecessarily splits files into 3 parts.

He says that if we want to change any thing in the view, for example, change a button or any control, then this can be done directly in the code. Why use MVVM?

Although I have theoretical answers, I cannot but agree with his point of view. Is he really right?

Answer 1

He says that if we want to change any thing in the view, for example, change a button or any control, then this can be done directly in the code. Why use MVVM?

Of course, this can be done like this. The question is whether this should be done in this way.

For a fairly small code base, you can probably avoid mixing data access, core logic, and user interface manipulation in the code. In the long run, however, this will not do for supported or verifiable code, and the mess will probably get worse over time and turn into spaghetti code. Take my word for it, because most of my time at work is put in the opposite direction of such old riots.

Some consequences of mixing all the code in the code:

• Code that fundamentally violates the “Single Responsibility Principle” (SRP).
• Code that is hard to understand because it does different things in the same place.
• Code that breaks easily. I'm changing something here and for some secret reason, there are some functions.
• Code duplication / Do Not Repeat Yourself (DRY) violation. You often find the same logic in several places. Is it random or intended? If I change the logic here, should the same / similar logic be changed too?

Please note that with the exception of the first point, these are not theoretical problems, but very real, immediate problems of your typical "old" code base.

In my opinion, it is not entirely correct to say that MVVM introduces more code classes. This is clearly an expression from someone who does not understand the fundamental separation of the problems that arise when you isolate the data, business logic and logical levels of the UI from each other: even with MVVM you only have one code class for your views. The other two classes (yes, most likely, two more) simply cannot be considered "code", because they are not directly tied to the presentation / design.

Answer 2

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

With proper MVVM implementation, you don't have code, or at least very small.

But in ViewModel you don’t have direct access to the window, as in MVVM the connection between ViewModel and View is done on Binding, there is no direct link to the view (usually).

MVVM brings some enormous advantages over oriented approaches. It can be easily replaced, it is adaptive, ...

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

Answer 3

I also agree with stakx and Mare Infinitus; MVVM provides many advantages and does not just create multiple files containing code.

From my experience, MVVM is the best way to learn and use the power of WPF, it kind of encourages and makes you use WPF features like Binding , Commands , Styles , Converters , etc. I saw an application developed without MVVM, and they turned out to be a Winforms-style WPF application with the problems mentioned by stakx (and more).

Besides UnitTesting (which I think is very impressive for your application), reuse, etc., a very important advantage of using MVVM is that it can support multiple views , that is, you can have multiple user interfaces for your application can use the same ViewModels; This may not be for you today, but in the future you may need a new interface in a few years or support for other platforms such as Silverlight or Metro, MVVM in this case will save you a lot of effort.

I suggest you go through this post that explains the real benefits of MVVM and explains the other so-called benefits (although I think they are real benefits in practice) - MVVM Backlash

Answer 4

one goal is that you can turn off your view logic (viewmodel) without a view.

here is one good comment from Rachel regarding the first approach to the viewmodel:

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

Answer 5

If you have only two people in the project, and each person is "all in one", he is right.

But if you do not want designers to ruin the controller (or ViewModel) or the programmer who changes the view to something, you know how programmers do design.

In addition, you have a key where you need to make changes immediately, without searching for huge text files.

In addition, the separation of MVVM or MVC is one of the basic principles of programming, this is the separation of Data-Logic-View, and if the architect says that you are not doing this, maybe it's time to ask another architect :)