Good day.

As in many cases, when using the MVVM pattern, the VM part simply duplicates the Model. Duplication occurs at 90 percent. I would like to temporarily get rid of full duplication, but also so that the connection between VM and M remains as separate. enter image description here

Above is how it is now. When updating the Model (not from the VM side), an update event of the model is triggered, according to which the VM reports what is worth updating in the View (it seems called DomainEvent)

But there is a lot of duplication of properties (and the Model logic, which is more important and more problematic).

Decision:

Inherit the Model and override the updated properties.

As a result, all Model logic will be written to the base. I just need to call OnModelCreated ();

To override the properties, I can set the name of the attributes in the View (for communication) or in the transfer method OnModelCreated ();

Question: What is the reason for this logic for an application that can grow greatly? So everything is cool: View knows nothing about M, VM knows everything about M, M knows nothing about VM.

Question 2: how much does this match the pattern? (All the conventions that the pattern is not a dogma, I understand)

UPD 2:

Approximate description of the program in Update 2 questions: Synchronization Model and ViewModel, when the application - Client

  • 2
    If you have M duplicates VM, do you even need M? ru.stackoverflow.com/a/379331/10105 The existence of M is not a dogma. - VladD
  • @VladD yes, I read this answer and often I turn to it. The fact is that truth is needed. As I wrote, VM partially duplicates M, but I am sure that in the near future there will only be duplication of these entities (and this will be 50% of VM). The program will definitely become big and knowing that you don’t want to rewrite. What I described in the question (an example of a solution) is an example of life hacking - "How to simplify your life for yourself now, but not to complicate it much in the future." If the VM entity is very different, then I just need to remove the inheritance. - Arantler
  • Usually they do not inherit, but implement Façade. - Bulson
  • one
    You correctly noted VladD that you can get away entirely from the layer M. I just want to add on my part that, in my opinion, the M layer is needed in principle when the model is written, tested separately from the application with the UI. Those. Initially it is assumed that a different type and UI functional will be implemented for one written model, say, a WPF website and client applications, for mobile phones, etc. - Bulson
  • one
    @Arantler: Here is an example of code generation: ru.stackoverflow.com/a/739879/10105 - VladD

0