Best architectural approach for a simple MVVM program

[reelthymeos]

Hi,

I am wondering if anyone can offer any tips or insights for a design approach for a program I am developing. I am developing a desktop application and using the MVVM approach. I worked on some of the Avalonia beginner MVVM samples to understand it better. Here is the background of my app:

This application is controlling a piece of test equipment. The equipment is a simple switch box for switching/selecting RF signals. I believe the app should be fairly simple. The main purpose is to allow the user to select the state/position of the various switches that are in the box. The app should also display information about the box, such as serial number, current firmware version, model number, etc...

I believe this is a simple app, so I am not sure if I need to have a model which is separate from the ViewModel? So far I have taken the following approach

• Developed views for various controls, for example a 'status' view which shows all the summary data of the overall box (serial number, model name etc..) and a 'switchControl' view for allowing the user to select states for each of the switches.

• Developed a ViewModel for each view. For example the SwitchControlViewModel has public properties for the states of each switch and it implements INotifyPropertyChanged so that if anything is updated in either the View or ViewModel, they are reflected in both.

QUESTIONS:

• How do all these views and viewModels come together in the end? I am planning on embedding each view into the MainWindow/MainView and the MainViewModel has instances of each ViewModel as public properties. Is this the correct way to link them all together when you have multiple separate Views and ViewModels?

• What about a model? Is a model that is separate from the viewModel(s) necessary here, or overkill? Since the model deals with the business logic, if I were to use one, I believe it would basically represent the state of the box. It is here that interactions with the actual box will take place (writing/reading to the device etc..). From there information can be propagated up to the various ViewModels. How is that relationship established? with the View and ViewModel relationship, we use Data Binding and INotifyPropertyChanged to establish that relationship. Should the same logic be used to connect the ViewModels to the Model?

Sorry if this is many questions wrapped into a single post, any suggestions or insights would be appreciated.

Thanks

[stevemonaco]

I typically only make Models when:

1. the data source is external and something I don't own (eg. web api)
2. I want a 1:1 mapping to a persistence schema (eg. JSON/XML)

Otherwise, I put the logic into a service class (eg. a service to query / control RF devices), call it directly from the ViewModel, and assign results directly to ViewModel state.

Having a real Model layer means more indirection and that adds more pain. Sometimes with little to no value, especially for small apps with a solo dev or very small team.

[reelthymeos]

Thanks @stevemonaco. Assuming I only use Views and ViewModels in this scenario (and the service class as suggested above), what about the question of how to structure the whole thing? i.e. Do I have a single MainViewModel that contains public properties which are instances of my individual ViewModels? And then the DataContext for my main view is that 'master' ViewModel?

[stevemonaco]

I use ViewModel-First MVVM, so I arrange my ViewModels in a tree-like hierarchy. So a MainViewModel would contain VMs and those VMs would contain other VMs.

The MainView has MainViewModel as its DataContext. Then ViewModels are presented with a combination of collection controls and ContentControl, so I never have to explicitly set a DataContext outside of the very root.

[reelthymeos]

@stevemonaco I have structured my solution so that the MainViewModel contains other VMs as you described. Also, my MainView has this MainViewModel as its data context. Regarding this part that you wrote

"Then ViewModels are presented with a combination of collection controls and ContentControl, so I never have to explicitly set a DataContext outside of the very root."

Could you expand on that a bit? All of my child View Models that are referenced in the MainViewModel have their own respective Views (and do data binding with them too), and since all of those views make up the MainView, I believe that everything should flow up to the main view. Each child View has its data context set to its respective viewModel, but since those viewModels are in turn instantiated inside of the MainViewModel, I believe that this should work?

We also talked earlier about having a serviceClass to handle the IO and control of the external device. How can I have access to that same serviceClass object across multiple viewModels? Each view model will have one or more functions that they will call in that class, but they all need to access the same instance.

[stevemonaco]

You can check out https://github.com/stevemonaco/AvaloniaNavigationDemo as an example of how to use ContentControl and collection controls to present VMs. It requires a ViewLocator (or a DataTemplate per-VM).

On service classes, it depends on what you need to share. There are several approaches via DI:

• Single global state, shared: register the service as singleton. Have the service own the data.
• Global state, shared: register the service as transient. Create separate state stores for the data and inject those. For multiple stores, you can derive new types or use keyed DI.
• Single global state, shared: create a VM without a View to store state. Register it as singleton and inject it everywhere necessary. Good for direct binding from many views so you don't need to synchronize data several places. See https://github.com/stevemonaco/ImageMagitek/blob/main/TileShop.UI/Features/Shell/EditorsViewModel.cs as an example. I inject into multiple components and they can all access the ActiveEditor or perform operations without much ceremony.

It gets trickier when the state is not global. Messaging can help communicate across decoupled components, especially when high level app events occur.

[reelthymeos]

Thanks @stevemonaco One final question. I understand the idea of creating a singleton. In my case the singleton is a service that deals with writing/reading to the external device. I don't really understand Dependency Injection yet and I'm trying to read up on it. I did install the nuget package of Microsoft.Extensions.Dependency injection. But in my case I am wondering if that is even required. Because each of my viewModels will be working with the same instance of the service class (singleton). Each of my viewModels is using that same service but data is not really shared between the view models. For example, one ViewModel deals with setting the RF switches on the device, so it will call that service to write to the device. Another view model deals with displaying system information of the device such as SerialNumber, FirmwareVersion etc.. To get that information this other ViewModel will call that same (singleton) service class, but it doesn't really need to share the data it gets from it with any other view model. It is simply for the purposes of displaying it in a view.

Since I am not really sharing data between these models (they are all instantiated inside MainViewModel however, so all there data flows up to the MainView) do I really need to care about dependency injection?

[stevemonaco]

DI is not required, but it is a best practice, especially for large components that deal with composing several functionalities. There are other DI libraries, but MEDI is a good starting point which you'll probably never need to ugprade from. That said, singleton lifetime may not be required either. You have to think about ownership, how many of each "data", you have, etc. The further you break things down into tiny components, the more indirection and wiring of instances you need to do to build a major component. There are always tradeoffs.