Hello, I will ask to help with understanding the use of MVVM pattern. How do I imagine it for myself:

  1. There is a separate self-sufficient project (or library) in which some ready-made functionality is written. The project user is provided with an interface in which properties are opened which determine the state of the service and events are opened for notification by the service (push / pull notification). For example, for notification, use ReactiveExt.

  2. The task is to use this service, write UI for it. We create a new WPF project, to facilitate MVVM support, we use some kind of framework (I use Caliburn.Micro).

  3. Create a View-ViewModel. We use Binding, we try not to use code behind (we use only for the functionality closed on View).

  4. We debug the UI project separately. We check the work of all notifications, binding, etc.

  5. We have 2 ready not connected projects. Service and UI.

  6. Further ... The simplest way is to get an instance of the service in the ViewModel (create directly, transfer to the constructor, get through DI). And sign event handlers for service events. In the body of the handlers, use the properties of the ViewModel that participate in the binding. Also, the ViewModel refers to the state of the service to the open properties of the service. Thus, the work of the service will be associated with the UI.

And where is the Model in this structure?

If you do a mapping service on the Model object. Those. A copy of the service has only the necessary properties for the UI. And already to receive a copy of model in ViewModel.

But then you have to duplicate and events (notification).

Here I am a little confused))) ... Tell me where is the Model ???

  • In this case, you don’t need a Model explicitly, you still have a “black box” interaction with which occurs through your Service. Service is the so-called. Façade , but for him, by and large, you should not care. - Bulson
  • Thank you, that's what I thought. And what if we get data from the database (through ORM for example) and if we directly use database entities for buying, then observable collections will appear in the entities of the Domen layer, that is. we UI climbed to another layer. Here I think I obviously need a mapping of the data obtained from the database. I'm right? and how best to do? - Aldmi

1 answer 1

You describe everything correctly. Service - this is your model.

If you think that the service has properties that are ready for display in the UI, this is most often not the case. For example, a model lives in an incomprehensible thread (and even in several, as it is convenient for it), and a VM should live in a UI thread. VM should set INotifyPropertyChanged , and your model should set Rx. Well, you probably do not need all the properties of your service, and some, perhaps, you want to combine or convert as best suited for the UI.

Yes, this may be some dubbing of the code. Here is a little more on the same topic.

  • Thanks VladD, now I’m more confident I will use MVVM) - Aldmi
  • @Aldmi: Please! I would be glad if it helped to understand. - VladD