Переход от WPF к Silverlight: в чем основные отличия? - PullRequest
11 голосов
/ 05 ноября 2010

Я выполнил один полный проект, используя WPF, и (по крайней мере) довольно хорошо разбираюсь в основных понятиях, таких как XAML, Databinding и MVVM. Мы делали все «вручную» - мы не использовали фреймворк MVVM или сторонние инструменты. Весь XAML тоже был написан от руки (без Blend).

Новый проект, который я начну через несколько недель, - это довольно мощный Silverlight, и я стремлюсь набрать скорость как можно быстрее. Однако большинство статей, которые я прочитал о начале работы с SL, посвящено XAML и привязке данных. Поскольку мое введение в эти концепции все еще очень свежо в моей памяти, я, конечно, могу понять, почему эти учебные пособия будут тратить много времени на эти предметы - кривая обучения может быть очень крутой. Однако это те концепции, с которыми я уже знаком, и мне приходится пробираться через множество скрытых областей, чтобы узнать что-то новое и убедительное.

Итак, что я ищу, так это советы о том, что мне нужно выучить и понять, чтобы перейти от путника WPF'er к подмастерью Silverlight'er. Это может быть в форме:

  • Общие советы
  • Ключевые отличия
  • Правила большого пальца
  • Ресурсы / Ссылки ("Руководство WPFer по Silverlight "был бы идеальным:)
  • Основные Подводные камни / Вещи, на которые стоит обратить внимание

Заранее благодарим за понимание.

Ответы [ 2 ]

9 голосов
/ 06 ноября 2010

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

День 1 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/25/porting-nhprof-from-wpf-to-silverlight-day-1.aspx

День 2 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/29/porting-nhprof-from-wpf-to-silverlight-day-2.aspx

День 3 http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/31/porting-nhprof-from-wpf-to-silverlight-day-3.aspx

День 4 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/01/porting-nhprof-from-wpf-to-silverlight-day-4.aspx

День 5 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-5.aspx

День 6 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-6.aspx

День 7 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-7.aspx

День 8 http://devlicio.us/blogs/rob_eisenberg/archive/2010/04/02/porting-nhprof-from-wpf-to-silverlight-day-8.aspx

Некоторые мысли о моей голове:

  • Привязка по умолчанию к одностороннему
  • Нет DynamicResource
  • TabControl довольно отличается
  • Нет возможности определять неявные шаблоны данных для типов
  • Нет CoerceValue в свойствах зависимостей
  • Маршрутизация событий очень проста
  • Нет встроенной структуры команд. У вас есть интерфейс ICommand, а у элементов управления ButtonBase есть свойство Command, хотя нет класса, реализующего интерфейс ICommand.
  • Отсутствует x: Статический, x: Тип
  • Все сервисные вызовы должны быть в другом потоке, чем в потоке пользовательского интерфейса. По сути, это требует от вас изучения / реализации стратегий асинхронного программирования. См. здесь и здесь .
  • Как уже упоминалось, это другая структура, поэтому вам доступны не все библиотеки. Пример: XmlDocument отсутствует - вам нужно использовать XElement (что, возможно, лучше, хотя и так)
  • Структура навигации полностью отличается от WPF. Держись подальше от этого. Это только причинит вам боль. ;]
  • Несколько элементов управления, которые вы найдете в базовой структуре в WPF, вы найдете в Silverlight Toolkit . Скачайте, вам это понадобится.
  • Нет встроенных триггеров, хотя можно использовать поведение / действия, предоставляемые в Blend SDK (что, по сути, дает вам то же самое)
  • Если вам нужно взаимодействовать с базой данных, она должна осуществляться через службы, размещенные где-либо, или через COM (что означает Silverlight 4 OOB с повышенными разрешениями).
  • Я не согласен с Кевином в том, что на самом деле тестирование довольно простое, и все основные тестовые фреймворки и фреймворки поддерживают Silverlight. То, где вы сталкиваетесь с проблемами, - это охват кода. Среда тестирования Microsoft поддерживает покрытие кода (Premium и выше), иначе вы можете использовать dotCover . Я считаю, что более новые версии nCover поддерживают Silverlight, хотя я не уверен на 100%. Используйте StatLight для запуска тестов Silverlight (независимо от среды тестирования) из командной строки.
  • Если вы еще не используете контейнер IoC, заберите его. Autofac, Ninject, StructureMap, Unity, MEF. (Еще один мой уклон;])

Я бы настоятельно рекомендовал изучить доступные фреймворки MVVM. Это сократило значительную часть кода платформы, который мне обычно приходится писать. Фреймворки, вероятно, только дадут вам 80% того, что вам нужно, хотя это 80%, что вам не нужно было писать самостоятельно. В настоящее время я неравнодушен к Caliburn Micro, хотя большинство популярных дадут вам то, что вам нужно.

Я добавлю больше, если подумаю больше. Удачи в вашем путешествии!

2 голосов
/ 05 ноября 2010

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

  • Вы 'Возможно, вам понадобится использовать службу WCF и т. д. для асинхронных запросов к вашему сервисному / бизнес-уровню
  • Вы используете подмножество .NET Framework, поэтому вы не можете включить ЛЮБУЮ из своих библиотек классов.в качестве ссылки, могут быть включены только библиотеки классов Silverlight.Однако вы можете делать такие вещи, как наличие «ссылки на существующий файл» в библиотеке silverlight, которая ссылается на файл в других библиотеках ... при условии, что код все еще компилируется только с сокращенным набором.Это небольшой кошмар обслуживания, но если вы используете WPF и Silverlight с одним и тем же кодом, это, вероятно, избавит вас от большого количества репликации.Убедитесь, что это ссылка на файл, а не копия файла, иначе изменения в одном не изменят другого.
  • Юнит-тестирование ваших ViewModels будет не таким простым.Нужно Moq вашего сервиса и использовать проект модульного тестирования Silverlight.
  • Некоторая ограниченная функциональность раздражает ветеранов WPF.
  • Я думаю, что наш парень из WPF жаловался на невозможность связать такие вещи, какметод CanExecute так же легко в его командах, как он мог сделать в WPF.Он должен был вызвать метод непосредственно из команды или что-то.(У меня только был шанс взглянуть на MVVM немного, поскольку я сейчас нахожусь в другом проекте :(, так что я не совсем уверен в этом).

Надеюсь, это поможетмаленький.

...