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?