Лучшая практика для расположения стилей в Silverlight

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

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

Типичная иерархия стилей в обратном порядке

Первые несколько элементов - это ваши «самые запеченные» и наиболее часто используемые стили, обычно вам нужно начинать снизу и постепенно продвигаться вверх. Приятно также не работать с несколькими файлами XAML и сохранять их в отдельности.

На уровне приложения (App.xaml)

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

Если вы используете Silverlight 2, это лучший способ сделать ваши стили доступными для всего приложения без взлома.

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

Объединенный словарь

Объединенные словари ресурсов позволяют разделить стили на дополнительные файлы XAML, что упрощает их разбиение по функциональной области, функции, типу элемента управления, названию группы и т. Д. Подробнее об этой функции.

Рассмотрите возможность использования этого для стилей уровня приложения в ситуациях, когда это имеет смысл, поскольку затем вы можете использовать их в отдельных проектах и ​​решениях.

Недоступно для Silverlight 2, эта функция была добавлена ​​в Silverlight 3.

На уровне страницы

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

Не стесняйтесь начинать дальше вниз по визуальному дереву (например, на уровне управления) и перемещать эти стили вверх, если это имеет смысл.

На панели

Хорошо содержать кучу похожих частей, например, при форматировании формы.

На контроле

Начало здесь. Когда вы стилизуете элемент управления в Blend, он обычно начинается здесь, если вы не выберете опцию ресурса для всего приложения.

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

Неявные стили и темы

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

Я нашел в Интернете хороший учебник с быстрым поиском для вас узнать больше об ISM.

Когда использовать свойства вместо общих стилей

W.R.T. на ваш вопрос, если у вас есть набор текстовых полей, в которых различаются MaxLength, Width и т. д., вам, вероятно, следует явно указать их как свойства для каждого экземпляра элемента управления - если они разные.

Если у вас есть несколько (скажем, 3 элемента) с одинаковыми значениями, имеет смысл вытащить его, а затем начать использовать атрибут Style = "{StaticResource keyName}". Однако, если вы набираете XAML вручную, это намного раздражает больше, чем вводить Width = "20".

Извините за подключение моего собственного материала (или, если это не разрешено / не одобряется в SO), но я быстро написал в блоге о моем опыте реорганизации ресурсов в крупном проекте Silverlight 2 (т.е. без MergedDictionaries) некоторое время назад . Сообщение находится здесь.

В проекте Silverlight, над которым я работаю, используется шаблон бизнес-приложения RIA от MS. Все стили были в папке «assets», а файл назывался Styles.xaml. Я придерживался их организации, и мне она нравилась, хотя я также добавил отдельные папки для «диалогов» и «настраиваемых элементов управления».

Вы можете скачать их образец здесь, который может ответить на ваши вопросы: http://blogs.msdn.com/brada/archive/2009/07/10/amazing-business-apps-example-updated-for-silverlight-3-rtm-and-net-ria-services-july-update.aspx

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

Я лично собираю все «общие» стили (для текстового поля, поля со списком и т. Д.) В одном файле resource.xaml. Я разделяю стили в дополнительных словарях xaml-resource-dictionaries только в том случае, если я могу по какой-то причине исключить их. Например, я помещаю стили для компонентов от сторонних поставщиков в отдельные файлы ресурсов s.th. Я могу загрузить свой общий файл ресурсов «автономно» в приложения, которые не ссылаются на эту стороннюю библиотеку. Точно так же я отделяю стили, специфичные для проекта (цвета, соответствующие фирменному стилю клиентов) от глобальных стилей (стили продукта, не зависящие от клиента), что очень похоже на руководящие принципы, которые должны соблюдаться для наследования классов. Затем мое приложение загружает все ресурсы, s.t. пользовательские элементы управления не должны знать о них.