Поиск лучшего способа написания сложных пользовательских интерфейсов WPF

Question

Приложение WPF, которое я унаследовал, содержит значительное количество XAML, которое следует такой схеме:

<Window ...>
    <Grid>
        <z:SomeUserControl>
            <z:AnotherUc>
                <Label /> <Button /> <ComboBox />
            </z:AnotherUc>
            <z:AnotherUc>
                <Label /> <Button /> <ComboBox />
            </z:AnotherUc>
        </z:SomeUserControl>
    </Grid>
</Window>

Другими словами, у нас есть разделы пользовательского интерфейса, сгруппированные по UserControl, часто вложенные в другие UserControls. В какой-то момент контент определяется с помощью основных элементов управления контентом WPF.

Проблема, с которой мы пытаемся справиться, заключается в том, что атрибут x: Name нельзя применить ни к одному из самых внутренних элементов управления из-за печально известного ограничения WPF:

Невозможно установить значение атрибута имени {0} для элемента {1}. {1} входит в область действия элемента {2}, имя которого уже зарегистрировано, когда оно было определено в другой области действия

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

Однако, если Microsoft не намерена разрешать это так называемое «ограничение», необходимо найти лучший способ. Учитывая, что использование CS + внешнего файла шаблона XAML было размещено, как показано в работе GaryGJohnson на сайте подключения. Однако это вызывает чувство сфагетти, и все, что нарушает связывание, не допускается.

Answer 1

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

Answer 2

Лучшим вариантом здесь, как правило, является избегание использования кода позади этих «внутренних» элементов. Вы все еще можете использовать привязку данных, поэтому привязка их к свойствам в вашем DataContext будет работать правильно.

Другой альтернативой, конечно, является предоставление метки / кнопки / комбинированного списка непосредственно как свойства зависимости класса AnotherUc. Это позволит вам использовать их непосредственно в качестве членов UserControl, что позволяет избежать проблемы с областями видимости.

Недостатком этого является, конечно, то, что вы должны настроить пользовательский элемент управления для определенной комбинации элементов, вместо того, чтобы размещать какие-либо элементы управления внутри него.