Най-добра практика за местоположение на стилове в Silverlight

Йерархията съществува с причина, вероятно е добра идея да започнете просто и локално за елемент, с който работите, след което да го преместите, когато стане необходимо.

Вашите дизайнери също може да имат специални изисквания, които могат да надхвърлят това. Например, екип, който изпраща много ревизии на някои стилове, може да иска да съдържа цялата работа по стила в един XAML файл, докато не стане готов за още.

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

Първите няколко елемента са вашите „най-изпечени“ и най-често използвани стилове, обикновено ще искате да започнете от дъното и да продължите нагоре. Хубаво е също така да не се налага да работите с множество XAML файлове и да го запазите.

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

Стиловете на ниво приложение ще бъдат полезни навсякъде, където интерфейсът на приложението ви е изложен, за общи елементи.

Ако използвате Silverlight 2, това е най-добрият ви метод без хакване, за да направите вашите стилове достъпни във вашето приложение.

Бъдете внимателни, ако редовно използвате ресурси на App.xaml, тъй като библиотека за модулни тестове, която съществува извън вашето приложение, ще бъде много по-трудна за тестване, тъй като в някои ситуации няма да вземе стиловете на ниво приложение на вашето приложение.

Обединен речник

Обединените речници на ресурсите ви позволяват да разделяте вашите стилове на допълнителни XAML файлове, което улеснява разпределянето им по функционална област, функция, тип контрол, име на екип и т.н. Научете за тази функция.

Обмислете използването на това за стилове на ниво приложение в ситуации, в които има смисъл, тъй като след това можете да ги използвате в отделни проекти и решения.

Не се предлага за Silverlight 2, тази функция е добавена в Silverlight 3.

На ниво страница

Всичко, което е специфично за отделна страница (може да е цялостно приложение, визуална страница или част от приложение), което не излиза извън краищата, е добър кандидат за това.

Чувствайте се свободни да започнете по-надолу във визуалното дърво (като контролното ниво) и преместете тези стилове нагоре, когато има смисъл.

На панела

Добре е да съдържа куп подобни части, както при форматиране на формуляр.

Контрола

Започни тук. Когато стилизирате контрола в Blend, тя обикновено започва тук, освен ако не изберете опцията за ресурс за цялото приложение.

Това е междинната стъпка между настройката на свойството и действителното създаване на истински ресурс за стил, тъй като ще бъде само настройка за свойството Style на контролата - но можете лесно да добавите x:Key и да го преместите нагоре във визуалното дърво, когато ти си готов.

Имплицитни стилове и теми

Ако вашият екип или компания използва редовен набор от стилове за всички контроли от определен тип (бутони, квадратчета за отметка, каквото и да е име), обмислете използването на функционалността Implicit Style Manager (добавена стойност за Silverlight), за да правите имплицитни стилове. Това е подобно на историята за стилизиране на WPF, където не е необходимо да задавате стила на всички места, където го използвате.

Намерих добър урок онлайн с бързо търсене за вас, за да научете повече за ISM.

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

W.R.T. вашият въпрос, ако имате набор от текстови полета, където разликите са MaxLength, Width и т.н., вероятно трябва да ги зададете изрично като свойства на всеки контролен екземпляр - ако са различни.

След като имате няколко (да кажем 3 елемента), използващи едни и същи стойности, може да има смисъл да го извадите и след това да започнете да използвате атрибут Style="{StaticResource keyName}". Ако обаче въвеждате XAML на ръка, това е много по-досадно от въвеждането на Width="20".

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

Проектът Silverlight, върху който работя, използва шаблона RIA Business Application от 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

Бих се съгласил с последното ви предложение: Поставете общата част на всички текстови полета в стилов речник, който след това може да бъде зареден от приложението/страницата/контролата, в зависимост от това кое ниво споделя тази обща част. IMHO необичайната част трябва да бъде зададена директно в екземплярите на текстовото поле, няма смисъл от друг стил, освен ако не използвате повторно тази специална настройка в няколко текстови полета.

Аз лично събирам всички "често срещани" стилове (за текстово поле, комбинирано поле и т.н.) в един resource.xaml. Разделям стилове в допълнителни xaml-resource-dictionaries само ако искам да ги изключа за някаква цел. Например, поставям стиловете за компоненти от доставчици на трети страни в отделни файлове с ресурси, s.th. Мога да зареждам общия си файл с ресурси „самостоятелно“ в приложения, които не препращат към тази библиотека на трета страна. По същия начин отделям специфичните за проекта стилове (цветове, подходящи за корпоративната идентичност на клиентите) от глобалните стилове (независими от клиента стилове на продукта), доста подобни на насоките, които трябва да се спазват за наследяване на класове. След това приложението ми зарежда всички ресурси, s.t. потребителските контроли не трябва да знаят за тях.