0

I'm currently reading "Clean Code" by Robert Martin (which I should have read years ago), and it's given me a bit of a wakeup call, especially regarding keeping methods and classes small, which I do try to follow, but we all know that bad habits can creep in.

It got me wondering about how much of his advice (and other principles such as SOLID) applies to view models in a WPF/MVVM application. Although obviously still a class, it feels like view models are fulfilling a "special" need and their complexity ultimately depends on the UI/view - the more complex the UI, the more complex the view model.

There are some approaches that can be taken of course, e.g. if the UI is "hierarchical" in nature, or consists of different "sections", then I'll create separate VMs for each section or level in the hierarchy, but beyond this I struggle to find ways to reduce the size of complex VMs, as all that functionality shares something in common (i.e. the view).

There will always be methods in a VM that are "related" in some way (e.g. methods that manipulate rows in a list-based UI: move, cut, paste, add, remove, etc), and I sometimes wonder if I Should move these into their own class, but doing so brings issues of its own, such as introducing dependencies between that and its "parent" VM. It ends up getting too messy, especially when the only benefit is to reduce the VM by a couple of hundred lines.

Am I worrying unnecessarily about trying to reduce the size of view model classes? Are many of the SOLID and clean code principles really intended for "business logic" classes?

2
  • not really an answer but I was wondering the same thing. Also if you look at WPF classes for UI elements etc, they are much bigger than any classes I have developed so far. I also wonder where would you place all you main application code if not in view model? At some point there should be some final class where everything is called from isn't it? May 11 at 9:24
  • 1
    The ViewModels (a.k.a. presentation models) in MVVM are entirely within the presentation layer. They are meant to be models (representations) of some view (which itself may be a subview). You can in principle apply the same general design guidelines to them, but it will look a little different because ViewModels are usually meant to be used with some kind of a data-binding mechanism between them and the view. However, you might be constrained in some ways design-wise by the MVVM library/framework you're using, so practice might differ from theory. May 11 at 18:06

1 Answer 1

1

I spent three years developing a WPF application for flight test management. Here are some of the principles that I followed:

  1. Use a foundational infrastructure, such as Prism, that enables modular development and provides navigation capabilities. Prism uses an IoC container to implement these features.

  2. Whenever possible, implement UI logic in the View Model using Data Binding to the View instead of events and Code Behind.

  3. If UI logic must be implemented directly in the View, favor writing additional XAML over Code Behind and Event Handling.

  4. The View Model should be confined to UI logic. Anything not related to UI goes into the Model. Large View Models with program logic in them can be refactored into individual Model classes, the usual way you would refactor any other class that violates SRP.

Were these principles followed precisely? Of course not. Getting better at MVVM applications and writing better MVVM applications is always a work in progress, and "best practices" are generally flexible, based on meeting your specific needs.

All of the SOLID principles are at work here. Once the foundational MVVM principles are in place, you use SOLID to craft your classes the same way you would use it to improve any other collection of classes, especially in the Model.

While I do view Code Behind as a "last resort," the custom calendaring system I wrote for this application was 100% code behind, because none of the existing WPF paradigms was suitable. Code Behind can be very powerful, if you are careful with it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.