How best to split responsibility into multiple ViewModels/Views? Should I?
Posted: 03 Oct 2023, 16:40
Hi,
I have a GameViewModel, which serves as the "main" view model for the game. It has a number of ViewModels on it, and is represented in the UI with a GameView.xaml UserControl, which has some direct UI elements it creates, but also binds properties of GameViewModel to e.g. ItemsControl widgets and so on.
I'm trying to figure out how "best" to split some data out of it. For example, I have a bunch of interaction with units in a game (or at least am planning to), for example hovering over points of interest leading to specific pop-ups, as well as various controls for making and modifying orders. I didn't want to put everything right onto GameView and in the GameView,xaml as that will get crazy. How does one split things out into more focused-responsibility view models?
First I was thinking of some over-arching view model like ClientOrderInteractionViewModel, and then somehow getting a xaml spawned to represent that, which can create and bind different views to the various view model properties that live on ClientOrderInteractionViewModel, e.g. properties like that can be bound as data context to other xaml files.
I guess I'm just misunderstanding the glue here:
* How does GameView.xaml "spawn" these other views?
* Does it make sense to split into single-responsibility ViewModels like this for sanity? In a non-UI world I would definitely wouldn't put every single bit of data in one class
* In this example, ClientOrderInteractionView would itself do nothing but create and hold other views and bind their DataContexts; is this a normal use-case for a view? I feel like I'm going to have multiple full-sized views covering the entire application window that create different parts of the main UI kind of like layers, rather than it being in one integrated file. That wraps back around to feeling bad again, like the split isn't helpful.
* But is this missing the purpose of a view? I'm looking for some xaml to hold some of these bindings/widgets so I guess so? But a 'view' feels more like, I dunno, a button or a widget or something, not this vague container of other controls?
Any help would be appreciated understanding the approach/model here when getting into the weeds. I can handle basic game-level data like the name of the current world or whatever - that's pretty obvious for GameViewModel and is bound by some TextBlock widget, easy. But then getting more complicated and needing to split out and have all of the above, potentially... that's confusing as hell still.
Thanks!
EDIT: It had been a while and I was confused. I have remembered that I can set up a DataTemplate to "load" the correct view and display it, like so (in this case PredictionViewModel might be the thing that has orders as mentioned above, or another intermediary ViewModel between them)
In GameView.xaml (my main game View)
I could see in this case, ClientPredictionView.xaml could itself have a bunch of DataTemplates like this, and serve to display and position sub-views that bind to ViewModels that exist on the ClientPredictionViewModel.
While that mechanism makes more sense to me now, the questions around what might be "best" or "standard" remain. Intermediary views xamls and ViewModels?
I have a GameViewModel, which serves as the "main" view model for the game. It has a number of ViewModels on it, and is represented in the UI with a GameView.xaml UserControl, which has some direct UI elements it creates, but also binds properties of GameViewModel to e.g. ItemsControl widgets and so on.
I'm trying to figure out how "best" to split some data out of it. For example, I have a bunch of interaction with units in a game (or at least am planning to), for example hovering over points of interest leading to specific pop-ups, as well as various controls for making and modifying orders. I didn't want to put everything right onto GameView and in the GameView,xaml as that will get crazy. How does one split things out into more focused-responsibility view models?
First I was thinking of some over-arching view model like ClientOrderInteractionViewModel, and then somehow getting a xaml spawned to represent that, which can create and bind different views to the various view model properties that live on ClientOrderInteractionViewModel, e.g. properties like
Code: Select all
List<ClientOrderViewModel> activeOrders;
I guess I'm just misunderstanding the glue here:
* How does GameView.xaml "spawn" these other views?
* Does it make sense to split into single-responsibility ViewModels like this for sanity? In a non-UI world I would definitely wouldn't put every single bit of data in one class
* In this example, ClientOrderInteractionView would itself do nothing but create and hold other views and bind their DataContexts; is this a normal use-case for a view? I feel like I'm going to have multiple full-sized views covering the entire application window that create different parts of the main UI kind of like layers, rather than it being in one integrated file. That wraps back around to feeling bad again, like the split isn't helpful.
* But is this missing the purpose of a view? I'm looking for some xaml to hold some of these bindings/widgets so I guess so? But a 'view' feels more like, I dunno, a button or a widget or something, not this vague container of other controls?
Any help would be appreciated understanding the approach/model here when getting into the weeds. I can handle basic game-level data like the name of the current world or whatever - that's pretty obvious for GameViewModel and is bound by some TextBlock widget, easy. But then getting more complicated and needing to split out and have all of the above, potentially... that's confusing as hell still.
Thanks!
EDIT: It had been a while and I was confused. I have remembered that I can set up a DataTemplate to "load" the correct view and display it, like so (in this case PredictionViewModel might be the thing that has orders as mentioned above, or another intermediary ViewModel between them)
In GameView.xaml (my main game View)
Code: Select all
<UserControl.Resources>
<DataTemplate DataType="{x:Type viewModels:ClientPredictionViewModel}">
<views:ClientPredictionView/>
</DataTemplate>
</UserControl.Resources>
<Grid>
<ContentControl Content="{Binding PredictionViewModel}"></ContentControl>
While that mechanism makes more sense to me now, the questions around what might be "best" or "standard" remain. Intermediary views xamls and ViewModels?