Лучшая практика для размещения стилей в Silverlight

Ответ 1

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

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

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

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

Уровень приложения (App.xaml)

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

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

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

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

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

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

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

Страница уровня

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

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

На панели

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

При управлении

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

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

Проект Silverlight, над которым я работаю, использовал шаблон бизнес-приложения RIA от MS. Он имел все свои стили в папке "активы", и файл назывался 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

Ответ 4

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

Я лично собираю все "общие" стили (для текстового поля, combobox и т.д.) в одном ресурсе .xaml. Я разделяю стили в дополнительных словарях xaml-ресурса, только если я могу исключить их для какой-либо цели. Например, я поместил стили для компонентов сторонних поставщиков в отдельные файлы ресурсов, с. Я могу загрузить свой общий ресурс файл "standalone" в приложениях, которые не ссылаются на эту стороннюю-lib. Аналогичным образом, я разделяю стили конкретных проектов (цвета, подходящие для корпоративной идентичности клиентов) из глобальных стилей (не зависящие от клиента стили продуктов), что очень похоже на рекомендации, которые должны выполняться для наследования классов. Затем мое приложение загружает все ресурсы, s.t. пользовательские элементы управления не должны знать о них.