I'm about to create WPF application. So far at uni the only way we have ever done GUIs is to have one main window with one code-behind file for handling its button clicks etc..
My issue is that as the application grows, the GUI grows, and the size of the code behind file can get really out of hand!
I have identified about 15 main use cases for my system (example: enter details, view details, etc…). I am creating a main window (size: 480×320) that consists of 15 seperate screens (one for each use case). This could be achieved with a centered and stretched TabControl, with 15 TabItem's. Or more likely it could just be a bunch of layered containers, one on top of the other (only one visible at a time).
The point is, with 15 seperate screens, my code-behind file will become enormous (not to mention the xaml file!): Juggling between states – making 14 collapsed/hidden and making one visible, Handling the controls for 15 different screens.
Is there a way to having 15 seperate forms, each with its own code-behind file, instead of 15 TabItems on the one form, and then having one main engine creating and scrapping them as needed? Ofcourse, it should appear as though it is one form, not 15 pop ups.
How do i deal with this? How would you deal with the issue of xaml and code-behind files that are thousands of lines long?
Best Answer
Your instincts are good: you don't want to put everything in one Window. You would be far better off putting each of the 15 "screens" in its own XAML file, as either user controls, or pages.
If Web-browser-style navigation would make sense for your application, then look at the Page class. If you set your Application's StartupUri to point to a Page (instead of a Window), then you'll automatically get a window with Back and Forward buttons, and you can use Hyperlinks (set the NavigateUri property to point to another Page) or the methods of NavigationService to navigate to new pages.
If you don't want the Back and Forward buttons, then put each "screen" in its own UserControl, and add some minimal logic to the main Window to show and hide them. Or if you're using MVVM, you could set up some magic where you just change your Window's DataContext (or better yet, a property on your application-level ViewModel) and it automatically loads and shows the correct UserControl (look into DataTemplates, or watch the video below).
I would also strongly recommend that you use MVVM to try to write as little codebehind as possible (ideally none at all -- not always achievable, but you'll learn a lot by trying). That makes your XAML tons easier to refactor. If you later decide that one of your Grids has way too much stuff on it, you can just cut and paste it into a new UserControl, without needing to spend tons of time disentangling all the codebehind.
Since it sounds like you're not familiar with the MVVM pattern, this video might go over your head, but I can't help recommending the MIX2010 talk "Build Your Own MVVM Framework". It's an eye-opener on what MVVM can do, and has some solid ideas on how to manage navigation between different UserControls. (It also has a link to an intro-to-MVVM talk.)