Which could be the best approach to break a large xaml?

I'm working on a desktop project using WPF, framework 3.5.

This application has lots of screens, but all of them are presented using a s开发者_C百科ingle user control (basically a stack panel wrapped in a class with some extra logic), what I do is like push and pop screens depending on the user choices.

Now, all the screens (which are basically stack panels) remain in a single xaml file, and this file is becoming incredibly large and it's becoming really difficult to maintain and update.

So I was thinking that maybe I can create user controls for each screen on the application and that would break the xaml file, making it easier to work with, but I'm not sure if this is the best approach or the recommended approach, that's why I'll like to know what do other people do to handle this issue.

Thanks!

why not use resource dictionaries to break up the Xaml

<Window.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <ResourceDictionary Source="Dictionary1.xaml" />
            <ResourceDictionary Source="Dictionary2.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Window.Resources>
<Grid>
    <StackPanel>
        <ContentControl Content="{StaticResource StackPanel1}" />
        <ContentControl Content="{StaticResource StackPanel2}" />
    </StackPanel>
</Grid>

and the dictionaries would have content similar to this

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <StackPanel x:Key="StackPanel1">
        <Button />
        <Button />
    </StackPanel>
</ResourceDictionary>

It makes a lot of sense to modularize your XAML into smaller files. User controls are a very good way to do this - it's the first think I try when I need to do this, and I haven't needed to find a second.

The only real problem you'll run into is if the pieces of XAML you're trying to modularize are involved with each others' implementation details - like if you're binding controls in one to elements in another. That raises the difficulty a bit, but only a bit.