When is it ok to combine 2 viewmodels into 1 instead of using some form of viewmodel-viewmodel communication?

Question

I have 2 viewmodels that each have their own view.

the first view model has 3 properties being displayed by the view:

PolicyProvider

PolicyType

PolicyNumber

the second view model has only 1 property being displayed by its view:

TypeOfInvestmentFund

There is a 1 to many relationship between the PolicyType and the TypeOfInvestmentFund.

Both of these view models and their views are being displayed as user controls inside a parent form.

The available choices for the TypeOfInvestmentFund is dependent on which PolicyType is selected in the other view.

---

To me this feels like these 2 view models could be combined, because

a) they are clearly somewhat coupled

b) the controls are both so small and simple that joining them will not create a complex and unmanageable object.

However this data is fairly unrelated; unrelated enough that the user would still want the data visible in seperate parts of the form (and therefore be placed on seperate views).

I personally feel that combining these 2 view models and having 2 seperate views connect to it to display different parts of it is a lot less overhead then managing the communication between the 2 objects.

I could however create loosely coupled events with the Prism Event Aggregator, and although I have never done this it is probably not much to manage, and keeping these 2 view models seperate would preserve seperation of concerns. Furthermore if other controls were to appear later on in development that also need this information, I cant keep absorbing them, so starting an event aggregator at this stage would prevent rework as the events would be available already to subscribe to. It is still more work then just combining the view models.

Which one of these 2 is 'more correct'? I understand its a judgement call, but I can't decide so I'm looking for opinions to help me make up my mind.

Answer 1

Ok thank you for the replies. Got a bunch of ideas from Rachels suggestion (upvote for you ma'am) but none of them paned out. In the end the project manager didn't like the idea and wants me to implement a more standard approach for readability and to prevent rework, so I'm going to go the message root.

Instead of eventaggregator I'm just going to make the parent subscribe to the PropertyChanged event of the Policy child and then change a property of the TypeOfInvestment child.

I'm kinda bummed I didnt get to implement the viewmodel merge as it really made more sense to me.

Answer 2

A ViewModel reflects the View, not the Data

If your View shows a Policy and a dynamic TypeOfInvestmentFund, then by all means your ViewModel should have both those objects.

Personally I would have my ViewModel expose a Policy model to the View, and have the PolicyModel contain properties for Provider, Type, Number, and InvestmentFund

I could then use DataTemplates to tell WPF how to draw each object. Here's a rough example outlining how you would do that:

<DataTemplate DataType="{x:Type local:PolicyModel}">
    <StackPanel>
        <local:PolicyView />
        <ContentControl Content="{Binding InvestmentFund}" />
    </StackPanel>
</DataTemplate>

<DataTemplate DataType="{x:Type local:InvestmentFundA}">
    <local:InvestmentFundA />
</DataTemplate>

<DataTemplate DataType="{x:Type local:InvestmentFundB}">
    <local:InvestmentFundB />
</DataTemplate>

Edit

If Policy and TypeOfInvestment are two separate objects, I'd keep their Models separate, and put them both in the same ViewModel. Models are for modeling your data, while ViewModels are for modeling your View

Answer 3

I look at problems like this as being very similar to database normalization. On the one hand, normalization is good practice, as is creating two separate view models. But at the same time a certain amount of denormalization has been known to help performance as well.

I personally feel that combining these 2 view models and having 2 seperate views connect to it to display different parts of it is a lot less overhead then managing the communication between the 2 objects.

And that statement says it all. While combining the two view models might not be considered "best practice", the feeling I'm getting from you is that it makes sense for your application (based-on the levels of coupling and complexity that you mentioned). I would say go ahead and combine them and keep an eye on how it performs.