Перемещение из 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, пока я сейчас на другом проекте:(, поэтому не совсем уверен в этом).
Надеюсь, что это поможет.