Перемещение из WPF в Silverlight: каковы ключевые отличия?

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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Надеюсь, что это поможет.