We have a program that was originally a WinForms program. We converted it to WPF and MVVM. Problem is the VIewModel for the window is still 3000 lines. It's difficult to maintain because I'm always jumping around the file trying to find related parts.
I'm wondering if there's a better way to consolidate this, perhaps different parts could be split into different files.
The window has a toolbar, with several buttons on it, and a couple TextBoxes. There's buttons like Play, Pause, Stop, Open File, Save File, typical stuff. A couple textboxes users can enter times in.
The ViewModel has a Play command, a Pause command, a Stop command, an Open File command, a Save File command. There's a property for TextBox1, and a property for TextBox2. The properties send notifications when they are changed. Standard stuff.
It all just becomes a lot when it's all placed together in the same ViewModel file. Even worse, our coding standard dictates that all fields should go in one place, while all Properties go in another place, so whenever I look at a property, the corresponding field is somewhere else if I want to look at it.
If I'm trying to trace the Play button, for example, the ViewModel constructor sets up the PlayCommand. The PlayCommand variable however is defined elsewhere. The constructor just sets it. Then the Play() method it calls is elsewhere in the file, and the CanPlay method is elsewhere. And mixed in with this all is the code for all the other buttons and TextBoxes I'm not interested in.
Is there a way to consolidate this, so code which logically goes together is actually together? Can I create a "Play" class, which contains all the Play stuff? And another class for Pause? And another class for Stop? And another class... I start having an explosion of classes and files. But perhaps that's inevitable. Maybe I can make them nested classes? Any ideas?