Каковы преимущества и недостатки ресурсных словарей по сравнению с пользовательскими элементами управления для организации больших файлов xaml?

Question

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

Мой вопрос: в чем плюсы и минусы использования ресурсных словарей по сравнению с пользовательскими элементами управления для организации больших файлов xaml?

Answer 1

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

Используйте ResourceDictionary, где вы хотите поделиться ресурсами . Например, если у вас есть набор кистей, которые вы хотите использовать в нескольких местах (и хотите иметь центральное место для их обновления), это будет кандидатом в ResourceDictionary.

Существуют случаи, которые могут быть реализованы исключительно с помощью ресурсов, но в любом случае вы можете захотеть упаковать их как элемент управления, чтобы их было легче понять в момент использования. Например, если у вас есть кнопка, предназначенная для мигания, когда мышь над ней, вы можете почувствовать, что пользователям легче писать (и читать) <local:AnnoyingButton />, чем <Button Style="{StaticResource AnnoyingButton}" /> (где стиль находится в AnnoyingButton.xaml словарь ресурсов), хотя на самом деле все это можно сделать с помощью шаблонов и триггеров, а не с помощью реального кода. Здесь я склонен ошибаться при создании элемента управления, потому что (а) он более устойчив, если я обнаружу, что мне нужно добавить код позже, и (б) это избавит меня от необходимости писать ResourceDictionary.MergedDictionaries элементов. Это суд призыва.

Answer 2

Мое эмпирическое правило: используйте ResourceDictionaries для DataTemplates, ControlTemplates, Style и ValueConverters, TemplateSelectors и т. Д., А также UserControls для «разрезания» вашего большого представления (визуальных элементов) на части, причем все они используют ваши ResourceDictionaries для стилей.

Проблема с ResourceDictionaries заключается в том, что если вы поместите туда визуальный элемент, вы можете использовать его только один раз, так как он создается в ресурсах, так что вы получите «Визуальные элементы могут иметь только одного родительского» - типы исключений если вы используете его дважды в разных визуальных элементах управления. С другой стороны, DataTemplates, Styles и ControlTemplates работают как фабрики, так как многие элементы управления могут использовать их одновременно - каждый получает свою собственную реализацию. ValueConverters и TemplateSelectors (просто опасайтесь изменения состояния внутри них) могут использоваться несколькими визуальными элементами управления, поскольку сами они не являются визуальными, что делает их идеальным кандидатом для статического подхода ResourceDictionary.

Надеюсь, это немного прояснит ситуацию.