View Models and dependency injection

by

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.

More Related Contents:

  1. Singleton by Jon Skeet clarification
  2. MVVM: Tutorial from start to finish?
  3. Good or bad practice for Dialogs in wpf with MVVM?
  4. ICommand MVVM implementation
  5. Managing multiple selections with MVVM
  6. How to implement Generic Repository Design Pattern with Dapper?
  7. Instantiate an object with a runtime-determined type
  8. Model-View-Presenter in WinForms
  9. MVVM in WPF – How to alert ViewModel of changes in Model… or should I?
  10. WPF MVVM Why use ContentControl + DataTemplate Views rather than straight XAML Window Views?
  11. Refactoring code to avoid anti-pattern
  12. Implementing the Producer/Consumer Pattern in C#
  13. What is difference between MVC, MVP & MVVM design pattern in terms of coding c#
  14. Give some command to View in MVVM
  15. MVVM show new window from VM when seperated projects
  16. Disallow/Block selection of disabled combobox item in wpf
  17. DDD Approach to Access External Information
  18. Should I bind to ICollectionView or ObservableCollection
  19. Proper way to use CollectionViewSource in ViewModel
  20. Entities VS Domain Models VS View Models
  21. Entity Framework Multiple Object Contexts
  22. One ViewModel for UserControl and Window or separate ViewModels
  23. The component does not have a resource identified by the uri
  24. How to expose a collection property? [closed]
  25. Best practices for multi-form applications to show and hide forms? [closed]
  26. Timeout pattern on task-based asynchronous method in C#
  27. What exactly is “interface based programming”?
  28. Generic Type in constructor
  29. How to prevent an exception in a background thread from terminating an application?
  30. Is Using .NET 4.0 Tuples in my C# Code a Poor Design Decision?

Leave a Comment