ViewModel code file too big. How can I put related code together?

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?
deleydSoftware EngineerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

David Johnson, CD, MVPOwnerCommented:
I'd go with using nested classes myself as this works on the OOD principles.  It also makes testing and QA a lot easier
0
Dirk StraussSenior Full Stack DeveloperCommented:
I'm wondering if there's a better way to consolidate this, perhaps different parts could be split into different files.
What you are describing here are partial classes. Have a look at Partial Classes and Methods (C# Programming Guide).
If nested classes suit you better, have a look at the following links:
Why Would I Ever Need to Use C# Nested Classes
Why/when should you use nested classes in .net? Or shouldn't you?
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
deleydSoftware EngineerAuthor Commented:
Thank you everyone for the help! The partial class idea worked out great! It's so nice to have code which logically goes together actually near each other. It made such a difference!
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
WPF

From novice to tech pro — start learning today.