Проектирование приложения с учетом использования единого опыта разработки для настольных и Web-проектов
Решение проблем недостающего функционала
Отсутствие FrameworkPropertyMetadata
Как известно, в Silverlight отсутствует класс FrameworkPropertyMetadata. Одна из наиболее часто используемых возможностей этого FrameworkPropertyMetadata по сравнению с имеющемся в Silverlight PropertyMetadata – это логические переключатели, которые управляют влиянием свойства на различные аспекты прорисовки объекта, такие как AffectsMeasure, AffectsArrange, и другие. Если один из флагов установлен в истинное значение, соответствующий аспект объявляется недействительным.
К счастью, данное поведение достаточно легко эмулировать при помощи PropertyMetadata и PropertyChangedCallback. Так, если в случае разработки только для WPF можно написать:
1: public static readonly DependencyProperty SomethingProperty 2: = DependencyProperty.Register( 3: "Something", typeof(string), typeof(Window1), 4: new FrameworkPropertyMetadata(string.Empty, 5: FrameworkPropertyMetadataOptions.AffectsMeasure) 6: );
То универсальный WPF/Silverlight код, достигающий такого же эффекта, будет выглядеть следующим образом:
1: public static readonly DependencyProperty SomethingProperty
2: = DependencyProperty.Register(
3: "Something", typeof(string), typeof(Window1),
4: new PropertyMetadata(string.Empty,
5: new PropertyChangedCallback(
6: Window1.SomethingProperty_Changed)));
7:
8: private static void SomethingProperty_Changed(
9: DependencyObject d, DependencyPropertyChangedEventArgs e)
10: {
11: ((FrameworkElement)d).InvalidateMeasure();
12: }Чтобы не допустить копирования кода, имеет смысл создать вспомогательный класс, методы которого устанавливают недействительными различные аспекты и их комбинации, и использовать эти методы в обработчиках изменений зависимых свойств, если нет необходимости добавлять в них дополнительную логику.
Отсутствие приведения значения
WPF имеет достаточно мощный механизм приведения значений зависимых свойств. К сожалению, такого функционала в Silverlight нет. Приведение значений возможно производить при помощи сочетания PropertyChangedCallback и обычных методов класса. В некоторых сложных, но не слишком критичных сценариях, возможно, имеет смысл использовать приведение значения в WPF версии и не проверять его совсем в Silverlight версии.
Отсутствие метода OverrideMetadata()
WPF позволяет переопределять метаданные зависимых свойств при помощи метода OverrideMetadata объекта DependencyProperty. В следующем коде переопределяется ширина по умолчанию у элемента управления, наследованного от класса Control:
1: static MyControl()
2: {
3: FrameworkPropertyMetadata newMetadata
4: = new FrameworkPropertyMetadata();
5: newMetadata.DefaultValue = 180.0;
6: Control.WidthProperty.OverrideMetadata(typeof(MyControl),
7: newMetadata);
8: }Так как в Silverlight такой метод отсутствует, при необходимости изменить значение по умолчанию какого-либо свойства необходимо просто установить это значение в конструкторе:
1: public MyControl()
2: {
3: this.Width = 180;
4: }Другая возможность метода OverrideMetadata() – это задание обработчика изменения зависимого свойства базового класса:
1: static MyControl()
2: {
3: #if !SILVERLIGHT
4: FrameworkPropertyMetadata newMetadata
5: = new FrameworkPropertyMetadata();
6: newMetadata.PropertyChangedCallback
7: += MyControl.VisibilityProperty_Changed;
8: Control.VisibilityProperty.OverrideMetadata(
9: typeof(MyControl), newMetadata);
10: #endif
11: }После этого в методе VisibilityProperty_Changed можно обрабатывать все изменения зависимого свойства Visibility.
1: private static void VisibilityProperty_Changed(
2: DependencyObject d, DependencyPropertyChangedEventArgs e)
3: {
4: // do something here
5: }К сожалению, т.к. данного метода в Silverlight нет совсем, изящного решения данной проблемы не существует. Однако можно воспользоваться не очень чистым приемом, включающим определение дополнительного зависимого свойства и привязку исходного свойства к нему. Аналог приведенного выше примера для Silverlight приложения в таком случае будет выглядеть следующим образом:
1: #if SILVERLIGHT
2: // объявление дополнительного зависимого свойства, которое
3: // использует такой же PropertyChangedCallback, что и WPF код
4: private static readonly DependencyProperty
5: VisibilityChangedWorkaroundProperty
6: = DependencyProperty.Register(
7: "VisibilityChangedWorkaround", typeof(Visibility),
8: typeof(MyControl),
9: new PropertyMetadata(MyControl.VisibilityProperty_Changed));
10: #endif
11:
12: public MyControl()
13: {
14: #if SILVERLIGHT
15: // привязка дополнительного зависимого свойства
16: Binding visibilityBnd = new Binding("Visibility");
17: visibilityBnd.Source = this;
18: visibilityBnd.Mode = BindingMode.TwoWay;
19: this.SetBinding(
20: MyControl.VisibilityChangedWorkaroundProperty,
21: visibilityBnd);
22: #endif
23: }Как видно из примера, определено дополнительное зависимое свойство VisibilityChangedWorkaroundProperty, и в качестве его обработчика изменения указан тот же метод, что и в WPF коде, приведенном выше. Нет необходимости создавать CLR свойство-обертку для дополнительного свойства, и само дополнительное зависимое свойство определено как приватное, так что оно доступно только внутри класса и невидимо для внешних компонент.
Затем в конструкторе дополнительное свойство привязывается к свойству Visibility базового класса. Таким образом, когда свойство базового класса изменится, дополнительное свойство также будет изменено в результате срабатывания привязки, после чего будет вызван обработчик VisibilityProperty_Changed.
Отсутствие зависимых свойств только для чтения
Одна из действительно удобных возможностей WPF – определение зависимых свойств только для чтения. Такое свойство полезно, если необходимо отобразить какой-либо статус объекта, определяемый его внутренним состоянием (как, например, свойство IsMouseOver), и разработчик не хочет позволять внешним компонентам изменять данное значение извне. Такого эффекта можно с легкостью достичь при использовании обычных .NET свойств, но что если необходимо создать свойство только для чтения, которое будет обладать всеми возможностями зависимого свойства?
К сожалению, не существует простого решения для Silverlight. Безусловно, можно создать CLR свойство-обертку для зависимого свойства без метода доступа set, однако при этом любой компонент может установить значение свойству при помощи метода SetValue().
Таким образом, в данном случае приходится выбирать: совсем не использовать зависимые свойства только для чтения или использовать разделение кода (при помощи директив препроцессора или разделяемых классов) между WPF и Silverlight. Следует помнить, что в данном случае придется использовать различный код не только для объявление зависимого свойства, но и в вызове SetValue (т.к. необходимо вызывать SetValue для DependencyPropertyKey в случае зависимого свойства только для чтения). Легко понять, что в таком случае исходный код будет достаточно трудночитаем из-за многочисленных ветвлений препроцессора #if SILVERLIGHT.
Отсутствие класса Brushes
Класс Brushes в WPF содержит предопределенные сплошные кисти, которые достаточно полезны при использовании кистей в коде.
1: border.Background = Brushes.White;
Данный класс отсутствует в Silverlight. При написании WPF/Silverlight совместимого кода следует использовать класс Colors, который достаточно похож на класс Brushes, только вместо предопределенных кистей содержит предопределенные цвета. Таким образом, код выше может быть переписан на:
1: border.Background = new SolidColorBrush(Colors.White);
Конечно, символов стало больше, однако это лучше, чем дублирование кода из-за настолько небольшого отличия.
При использовании именованных кистей в XAML отличий между Silverlight и WPF нет:
1: <Border Name="border" Background="White"> 2: </Border>
Stroke и Pen
В WPF определен класс Pen, в то время как в Silverlight его нет. Класс Pen достаточно удобно инкапсулирует способ рисования контура фигуры в единственном объекте, который возможно повторно использовать. Так, в WPF он применяется в классе GeometryDrawing (которого, кстати, также нет в Silverlight).
Следует отметить, что во многих случаях даже в WPF его невозможно использовать – вместо него приходится применять свойства StrokeXxx. По-видимому, по этой причине в Silverlight этот класс даже не был реализован.