Что лучше в WPF для макета пользовательского интерфейса, используя одну сетку или вложенные сетки

Question

Я делаю пользовательский интерфейс в WPF, у меня есть несколько функциональных областей, и я использую Grid для его организации.

Теперь сетка, которую я хочу, не является однородной, так как некоторые функциональные области будут занимать несколько ячеек в сетке. Мне было интересно, как лучше всего решить эту проблему. Должен ли я создать одну сетку, а затем для каждой функциональной области установить ее на несколько ячеек или разделить ее на несколько вложенных сеток.

На этом изображении мне нужна самая левая панель (панели, разделенные серой полосой). Средняя панель показывает одну сетку, где синие линии перекрываются функциональной областью. Крайняя правая панель показывает, как я могу сделать это с помощью вложенных сеток. Вы можете видеть, что зеленая сетка имеет одно горизонтальное разделение. В нижней ячейке находится желтая сетка с вертикальным разделением. В левой части находится красная сетка с горизонтальным разделением. Сетки http://www.freeimagehosting.net/uploads/08f2711bae.jpg

Мне просто было интересно, что лучше всего делать, средняя или правая панель.

ОБНОВЛЕНИЕ: просто для пояснения, более «ориентированный на код» пример:

Средняя панель

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="25" />
        <RowDefinition Height="*" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions> 

    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="200" />
        <ColumnDefinition Width="*" />
    </Grid.ColumnDefinitions>

    <Menu          Grid.Row="0" Grid.Column="0" Grid.ColumnSpan="2" />
    <uc:Info       Grid.Row="1" Grid.Column="0" />
    <uc:Control    Grid.Row="2" Grid.Column="0" />
    <uc:Simulation Grid.Row="1" Grid.Column="1" Grid.RowSpan="2" />
</Grid>

Правая панель:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="25" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>

    <Menu Grid.Row="0"/>

    <Grid Grid.Row="1">
        <Grid.ColumnDefinitions>
            <ColumnDefinition Width="200" />
            <ColumnDefinition Width="*" />
        </Grid.ColumnDefinitions>

        <Grid Grid.Column="0">
            <Grid.RowDefinitions>
                <RowDefinition Height="*" />
                <RowDefinition Height="*" />
            </Grid.RowDefinitions>

            <uc:Info    Grid.Row="0" />
            <uc:Control Grid.Row="1" />
        </Grid>

        <uc:Simulation Grid.Column="1" />
    </Grid>
</Grid>

Обновление: я должен признать, что теперь, когда я написал код для обоих подходов, решение "span" выглядит намного лучше.

Answer 1

Я бы лично использовал вашу среднюю компоновку, используя единую сетку с интервалами столбцов и строк, чтобы структурировать общую компоновку пользовательского интерфейса, а затем поместил бы панель в каждом из этих разделов, чтобы содержать фактические элементы управления (и, возможно, дальнейшую подробную компоновку) .

Answer 2

Я бы рекомендовал создать одну мастер-сетку, разделенную на функциональные области, а затем создать отдельные сетки / стековые панели / и т. Д. В этих областях. Возможно, вы не знаете требований для каждой функциональной области, поэтому вы можете свободно размещать их элементы и переключаться между макетами. Когда вы помещаете все в одну сетку со столбцами и / или строками диапазона, вы получите «сложный в управлении» макет.

Answer 3

Честно говоря, я бы выбрал док-панель или что-то подобное для композиции верхнего уровня и сетки для низкого уровня

Answer 4

Боюсь, я не смогу отличить ваши решения по цвету в разных сетках и вложенных сетках.

Что я могу посоветовать, так это создать UserControl для каждой функциональной области, а затем создать сетку для размещения этих областей.

Каждый UserControl может свободно создавать свой собственный макет (с другой сеткой, или с более простой StackPanel, или с чем угодно) и отвечает за отображение подмножества данных / обработку пользовательских событий в своей собственной области.

Тогда внешняя сетка является арбитром для вещей, которые включают более одной области (например, переадресация событий между областями).