Зачем переходить на WPF для бизнес-приложений вместо использования Winforms

Question

Наша команда имеет опыт работы над проектами Winforms и ASP.net.

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

Теперь я начинаю разрабатывать свой первый проект с использованием WPF, для меня это немного сложно, так как это моя первая попытка использовать это.

Можете ли вы дать более глубокую информацию, почему нам нужно перейти на WPF вместо использования winforms?

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

Мы используем VS 2008.

Answer 1

1. Подберите хороший MVVM Framework.Я лично использую Microsoft Prism .Для других альтернатив см. этот вопрос StackOverflow .

2. Маршрутизация событий только для просмотра.Например, если вы хотите прокрутить текстовое поле до конца многострочного текста при изменении текста.

3. Команды используются для привязки событий, в которых находится логикамодель представления (бизнес-логика) ... Например, кнопка отправки.

4. Если в вашей команде есть дизайнеры, заставьте их начать играть с Expression Blend и понимать стили/ макет.Expression Blend позволяет использовать примеры данных для просмотра макета приложения без необходимости его постоянного запуска.

5. Понимание Разница между ContentControl и ContentPresenter.

6. Понять, как работает ItemsControl s.Существует разница между SelectedItem, SelectedValue и SelectedValuePath.

7. Посмотрите на множество примеров в Интернете. Dr.Wpf , WPFTutorial.net , Джош Смит на WPF и т. Д.

8. Если вы планируете воспользоваться тестированием пользовательского интерфейса кода(для проверки фактического пользовательского интерфейса), а затем убедитесь, что названы соответствующие элементы управления (большинство руководств по MVVM говорят вам, что вам не нужно называть какие-либо элементы управления).Если вы не планируете проводить кодированное тестирование пользовательского интерфейса, не называйте свои элементы управления, если вам не нужно ссылаться на них из самого представления.

9. IValueConverter и IMultiValueConverter должныиспользоваться только для преобразования свойств в элементы, связанные с просмотром.Наиболее часто используемый конвертер - это конвертер BooleanToVisiblity.

10. TargetNullValue, FallbackValue и StringFormat важны при использовании связывания.Не делайте предположений о том, что привязываемые данные всегда будут доступны и правильны.

11. Вы почти всегда будете выставлять ObservableCollection<T> или ReadOnlyObservableCollection<T> из своих моделей представления.Очень редко вы когда-нибудь вернете коллекцию другого типа, включая IEnumerable<T>.

12. Будьте осторожны при выборе BindingMode: OneWay, OneTime, TwoWay, OneWayToSource (ВНИМАНИЕ: OneWayToSource сложен ... ему все еще требуется геттер, потому что он не привязка только для записи).

13. Хорошая отладкабесплатный инструмент Snoop .Это похоже на проводник DOM для работающего приложения WPF.Более продвинутый (и не бесплатный) инструмент, который немного более мощный, - Крот .

Это все, что я могу думать сейчас ... О, иесли вы столкнетесь с препятствиями, StackOverflow станет вашим другом:)

Answer 2

Я написал серию для WPF с MVVM , специально предназначенную для разработчиков, имеющих опыт работы с Windows Forms и планирующих перейти к следующему этапу.

В нем рассматриваются некоторые основы WPF,демонстрируя, как это позволяет вам подходить к вашей разработке иначе, чем Windows Forms, включая введение (осторожно) шаблонов, команд и других концепций, которые связаны с чрезвычайно превосходной привязкой данных в WPF.

Это было бы хорошим введением вWPF, и покажет вам, почему он может быть лучше для бизнес-приложений, чем Windows Forms.

Answer 3

Для тех, кто читает и задается вопросом «почему WPF» вместо Winforms, ответ таков: привязка данных WPF делает это намного проще. MVVM на самом деле просто для того, чтобы помочь вам получить максимальную отдачу от этого, но вам это строго не нужно.

Как кто-то, кто изучает только сейчас, я бы рекомендовал просто взять WPF для запуска, открыть проект и начать делать то, что вы делали в WinForms, назначая свойства вручную и обрабатывая события. Это будет работать. Но как только вы поймете, что WPF делает это автоматически для вас, вы внезапно начнете обижаться по-старому и окажетесь на веселом пути MVVM.