Clean code and SOLID principles in WPF/MVVM view models?

Question

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?

Answer 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.