Approach for Constructing View Models in Complex MVVM Application

Question

I'm struggling with the design in a WPF MVVM application. In a few courses I've taken, they say that having a lot of parameters in a constructor is a code smell, but they never address how to deal with it.

In a recent project of mine we used dependency injection to provide services that follow a data adapter pattern. Each of these classes are focused on a type, such as vendor, employee, detail, quote, request for quote, etc.

In this application the high level view models don't do much, but they host several view models, such as: details, file attachments, notes, vendor selection, and vendor requirements. The constructor for the unprocessed details view model takes almost every service in its constructor, but only uses those parameters to construct its child view models.

It doesn't make sense that the main view model would know about a detail view model, because the main view model is only responsible for top level navigation. So what approach can be used to compose the high level view models without a lot of constructor parameters, or is it not a bad practice in this case because the high level view models are responsible for composing the low level view models?

Answer 1

Our team had the same problem with view models in the ASP.NET MVC framework. Composing the view hierarchy started becoming complex, and as the user interface evolved we had to make changes higher and higher up in the view model structure, and then propagate those changes further and further down by passing constructor arguments.

We came to realize that a view model representing an entire web page really needed a lot of information from multiple sources. Even then we were able to reuse view models in multiple contexts, but configured just a little differently.

I came to the realization that these "top level" view models really represented a use case in the application, and had different initialization needs than view models that represented parts of a web page — individual components.

We introduced view model factory objects that specialized in initializing the complex view models. View models that represented a single component on screen had fewer dependencies, and we were able to continue initializing them through constructor parameters.

There was no clear line that got crossed where we said "we need a view model factory!" It became a gut feeling. When initializing a view model becomes complex, we moved the initialization logic into a factory method, but initializing view models remains the responsibility of each view model's constructors until we reach that point.