Каковы основные точки трения при перемещении от WPF до Silverlight и как Вы заполняете разрывы в функциональности? [закрытый]
4 ответа
Во-первых, хотя это относится к Silverlight 3, в этом документе подробно рассматриваются различия между WPF и Silverlight:
Microsoft WPF-Silverlight Differences White Paper http://wpfslguidance.codeplex.com/releases/view/30311
Это отличный первый шаг для ознакомления с различиями.
Возможно, вы также захотите взглянуть на проект Prism. Одной из целей этого проекта является создание набора функциональности, совместимой с Silverlight и WPF, чтобы вы могли создавать корпоративные приложения, ориентированные на обе платформы и повторно использовать большую часть кода. Знакомство с проектом поможет выявить и различия:
http://compositewpf.codeplex.com/
Наконец, хотя Silverlight может не иметь триггеров данных, вы можете использовать комбинацию таких функций, как поведение и триггеры:
http://www.silverlightshow.net/items/Behaviors-and-Triggers-in-Silverlight-3.aspx
И Visual State Manager (VSM):
http://timheuer.com/blog/archive/2008/06/04/silverlight-introduces-visual-state-manager-vsm.aspx
Для достижения большей части того, что вам нужно.
Предоставляя порт Silverlight как таковой для нашего приложения WPF, следующие две «болевые точки», с которыми мы столкнулись.
- Разделение и группировка XAML / модулей для повышения производительности и загрузки XAP по запросу с использованием MEF.
- Проблема достижения двоичной совместимости с использованием той же кодовой базы для WPF / Silverlight.
- Некоторые из наших Функциональных возможностей требовали OOB и согласия пользователя.
- Мы немного оптимизировали функциональность, полагаясь на IsolatedStorage.
Надеюсь, это поможет.
[Теперь, когда Silverlight 4.0 имеет стабильную сборку, у нас было несколько сбоев в работе Visual Studio в последних нескольких выпусках, которые разрешились со временем. (Мы придерживались Silverlight 3.0 и где-то в середине марта перешли к бета-версии SL 4.0 и финальной версии)].
Примечание.: Я старался держать вещи абстрактными, чтобы не раскрывать личность клиента.
- MarkupExtension
- IMultiValueConverter
- Template.Triggers
- Style.Triggers
- Привязка RelativeSource = {RelativeSource AncestorType ...
- Binding.IsAsync
- {x : Статический ...
- {DynamicResource ...
- Сетка.IsSharedSizeScope / SharedSizeGroup
Все это не поддерживается в Silverlight, и вы должны их обходить. В каждом случае необходимо собственное суждение о том, как «заполнить пробелы»
Что касается триггеров, единственным решением является использование VisualStateManger. В следующей статье приведен хороший пример перехода от триггеров к VSM: http://blogs.msdn.com/b/wpfsdk/archive/2009/02/27/the-visualstatemanager-and-triggers .aspx
Затем OnApplyTemplate запускается в другом порядке, что может повлиять на любые настраиваемые элементы управления или пользовательские элементы управления, которые вы могли создать.
WPF:
- Конструктор UserControl
- Конструктор MyControl
- MyControl.OnApplyTemplate
- Пользовательское управление загружено
- MyControl загружено
Silverlight:
- Конструктор UserControl
- Конструктор MyControl
- MyControl Загружен
- UserControl Loaded
- MyControl.OnApplyTemplate
И, конечно же, в Microsoft есть статья об этом под названием «Совместимость с WPF», в которой дается более подробный обзор различий и изменений между WPF и Silverlight:
http : //msdn.microsoft.com/en-us/library/cc903925 (VS.95) .aspx
Надеюсь, это поможет
Silverlight заставляет вас внести некоторые изменения в ваши шаблоны проектирования, которые, если они распространены в вашем программном обеспечении, могут сделать повторное использование кода весьма сомнительным.
Например, отсутствуют селекторы шаблонов данных - я был шокирован этим.