I used to produce all the logic inside the service, but switching to MVVM I started doing this: I make events corresponding to the called functions of the contract and call them, and already somewhere outside the model I create an instance of the service, attach to these events and process them. Here I wonder how this approach is correct? It is in the context of MVVM how to do correctly?

  • one
    Tell us in more detail how your program works. Without this, no recommendations can be given. - VladD
  • @VladD I say there is a WCF service. In it, for example, the void Connect () method and the ClientConnected event. When the client calls this method, it does this: void Connect () => ClientConnected? .Invoke (). But in general, the question is not how I do, but how to do it correctly? - PECHAIRTER
  • Well, what's the point of the program? Clean service? What about UI? If there is no UI, then MVVM is not so necessary. - VladD
  • @VladD UI is. - PECHAPTER
  • one
    Okay, then describe what the program does. Your description ("there is a WCF service. In it, for example, the void Connect method () and the ClientConnected event") does not provide information to judge the correctness of the architecture. - VladD

1 answer 1

See it.

The MVVM ideology is that low-level things like WCF sit in a model and allow themselves to be controlled as they please . MVVM does not impose any restriction. For example, if this is a WCF service, you can have event ClientConnected and event ClientDisconnected , or there ObservableCollction<Model.Client> , or in another way - how you personally feel more comfortable.

The main thing is that the necessary data and change signals are at least somehow accessible. For example, so that they could use the console application.

But the task of the VM is to subscribe to the necessary events, and set the necessary data in such a way that View can use them. This means, for example, ObservableCollection<ClientVM> for a changing list of clients.

  • Those. You want to say that in principle I am doing the right thing? And in the ViewModel-and some kind of logic can be described or is it just a class for binding? Well, at least that I actually need to keep two lists of clients in parallel? One inside the service, and the other to form in the ViewModel-and by events? Those. inside the service in the list there will be models that include all Callbacks of clients there and other details related to logic. And inside the ViewModel-and the lists will be models that include only the properties that are bound to the client table for example. - PECHAPTER
  • @DarkByte: The idea is that there is nothing wrong with what you told. VM should have logic related to the program: start, start the service, show the UI, subscribe to service changes, accept commands from the user and transfer them to the service, etc. The logic of the service itself belongs to the service. - VladD
  • @DarkByte: Yes, quite often you need two client lists. The VM client does not need callbacks, but you need INotifyPropertyChanged . And WCF runs in some kind of its own flow, that is, the model client runs there, and ClientVM should run only in the main flow. - VladD
  • and here is a list of clients that is in the ViewModel. Will it consist of Model or ViewModel objects? - PECHAIRTER
  • @DarkByte: The one that is set for the Binding in the UI is a list of ViewModel objects. The UI should not see the model at all. - VladD