View Models and dependency injection

The following is one of many different ways to approach the problem.

I prefer view models which are much more lightweight. I then add a class whose responsibility is to compose the view model from one or more sources (e.g. a repository). This doesn't eliminate the problem of cascading dependencies, but it does free up your view model constructors.

It also keeps logic out of the controllers, and allows view models to be reused (when appropriate, of course).

• Lightweight view models

• Lightweight controller knows how to locate a composer which assembles the view model (you could use a DI framework to setup the composer with all of its dependencies). The controller may play a minor role in the setup process, but it should be kept simple.

• Controller knows how the view model should be assembled, and shares that with the composer class. For example, the action might request a summary view which can still leverage the same view model with no children populated.

• Composer assembles the necessary information to complete the view model. Composer may use other composers to gather information for which it is not directly responsible. Again, a DI framework can be used here so that these composers are also given the dependencies that they need.

• Controller renders the view as usual with the completed view model.

In my opinion, this also provides a better level of abstraction. Just because a view model often looks like a particular domain model, that doesn't mean it will always be the case.

The end result:

• Lots of classes (a downside, granted), but minimal repetition of code (i.e. DRY)

• Thin view models which are testable (if needed...they may contain nothing to test)

• Thin, testable controllers.

• Testable composer objects which can be reused for different scenarios because they (presumably) know how to assemble view model(s) for various purposes.

• Flexibility to mix and match view models, controllers, and composers to support different scenarios.