Краткие итоги

В приведенном приложении все данные и реализация логики вынесены в отдельное место. В фоновом коде формы мы не добавили ни строчки. XAML понятен. Благодаря паттерну MVVM в коде легко разобраться и его легко сопровождать. Стоит добавить, что рассмотренный MVVM Toolkit содержит весьма полезный набор классов, особенно хорошо подходящий для небольших задач, не требующих модульности или необходимости использовать IoC. Для сложных приложений, можно рекомендовать более «тяжелые» Toolkit’ы, один из них мы будем рассматривать в последующих лекциях.

Литература

1. MVVM Light Toolkit http://www.galasoft.ch/mvvm/

2. WPF Model-View-ViewModel Toolkit http://wpf.codeplex.com/releases/view/14962

Лекция 10. Проектирование приложения с учетом использования единого опыта разработки для настольных и Web-проектов.

Краткая аннотация лекции: в лекции рассматривается подходы к разработке Silverlight/WPF приложений с максимальным разделением общего кода и XAML разметки.

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

Подходы к решению задачи

Как и многие другие вопросы, проблему разделяемого Silverlight/WPF кода можно решить несколькими способами:

• Разрабатывать кроссплатформенный проект с самого начала;

• Сначала разработать продукт для одной платформы, а затем адаптировать его для другой.

Разработка кроссплатформенного проекта с самого начала

Данное решение оптимально для случая, когда первым приоритетом в разработке стоит качество конечного результата. К сожалению, зачастую в реальном мире приходится жертвовать качеством для быстрого создания готового продаваемого продукта. Сложно спорить с тем, что результата можно добиться раньше, сконцентрировав всё внимание на одной платформе.

Разработка для одной платформы с последующим портированием на другую

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

Процесс портирования будет проще, если начать разработку с Silverlight и затем перейти на WPF. Следует учесть, что проще не значит лучше. Во многих случаях придется довольствоваться сокращенным функционалом Silverlight, используя сложные конструкции, повторяющие встроенные компоненты WPF.

Если же начать с WPF, то наиболее вероятно, что при портировании на Silverlight придется поплатиться за все удобства WPF и полностью переработать части кода, использующие недостающий в Silverlight функционал.

Инструментарий

Существует несколько способов организовать синхронное использование кода между Silverlight и WPF версиями приложения так, чтобы при этом было возможно реализовать некоторые участки кода специфично для определенной платформы. Наиболее удобный из них – использование ссылок на файлы для общего функционала и локализация различий при помощи директив препроцессора (в случае если отличается небольшая область кода) и разделяемых классов (для серьезных отличий).