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


I am very new to WPF and this morning with my architect, I have a discussion with C, C ++ background, I have a discussion.

We are trying to create a video calling application that relies on native code PInvoke WPF application is primarily a UI, and in the code we create a list of calls and available drivers for pinwoke video / audio.

So if we are talking about data from the database, there is not much of the " data " included in our application.

We are trying to amend and surprisingly they are not even using MVVM.

While I'm eager to implement MVVM, the architect states that unnecessarily dividing the files into 3 parts is.

He says that if we want to change anything like changing a button or any control, then it can be done directly behind the code, why use MVVM?

Although I have theoretical answers but can not help, but agree on its point. Is that really true?

He says that we want a button or any control Change anything in the scene like changing, it can be done directly behind the code, why use MVVM?

Of course this can be done in such a way that the question is whether should be done in such a way.

For a small code base, you can probably get it with data access, core logic and UI manipulation behind the code. Although in the long run, it will not be for a static or testable code, and the disturbance may get worse over time and can change into spaghetti code. Take your word for it, because a good part of my time in the work is put in the back of such old mistakes.

Code - There are some results of mixing everything in the rear:

  • A code that originally violates "Single Liability Principle" (SRP).
  • This code is difficult to understand because it does very different things in one place.
  • The code that breaks easily. I am changing something here and for some mysterious reasons, some facilities break on it.
  • Repetition / violation of code repeat / "do not repeat itself" (DRY) principle You often find the same argument in many places. Is this accidental, or on purpose? If I change the argument here, then should the same logic be changed?

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

    In my opinion, it is not entirely true that MVVM presents more code-behind classes, it is clearly a statement from someone who gives you a The other does not appreciate the fundamental separation of the concerns coming on the data, business logic, and UI separation of the logical layers : Even with MVVM you have only one code For the rear squared, the other two squares (h , There are two more likely to be there) can not be considered as "code-behind" because they are not directly connected to the visual / designer.

Comments

Popular posts from this blog

Python SQLAlchemy:AttributeError: Neither 'Column' object nor 'Comparator' object has an attribute 'schema' -

java - How not to audit a join table and related entities using Hibernate Envers? -

mongodb - CakePHP paginator ignoring order, but only for certain values -