Действительно ли WPF является хорошим выбором для разработки пользовательских интерфейсов направления деятельности?

Зная и то, и другое, я действительно надеюсь, что будущее за WPF. У Windows Forms есть невероятные болевые точки, например касательно привязки данных, и это в значительной степени тонкий слой .NET для многих существующих вещей. Когда мне приходилось отлаживать классы вроде BindingSource, меня это чертовски напугало. Я не знаю, как классы WPF выглядят внутри, но Microsoft наверняка кое-чему научилась между 2001 и 2006 годами.

Мне нравится WPF из-за

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

Я могу только надеяться, что Microsoft будет больше использовать эту технологию пользовательского интерфейса внутри компании, тем самым уменьшив ее недостатки, которые в основном связаны с делать с производительностью. WPF довольно требователен. В VS2010 я надеюсь увидеть дизайнеров, которые продемонстрируют мощь пользовательского интерфейса (конструктор XML-схемы в бета-версии уже выглядел довольно полезным). Я думаю, что такое приложение, как MS Word, получит большую выгоду от всех возможностей преобразования WPF.

WPF похоже, собирается заменить Winforms, по крайней мере, на устройствах Windows Mobile, с будущей разработкой, ориентированной на Silverlight (дополнительный продукт WPF) и XNA.

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

WPF изменил правила игры для меня. Флагманское приложение моей компании - это программа WinForms, пользовательский интерфейс которой создается динамически во время выполнения из метаданных. В общей сложности потребовалось около шести месяцев, чтобы сделать пользовательский интерфейс хотя бы стабильным , не говоря уже о привлекательном. Есть еще некоторые ошибки, которые мне не удалось исправить, в основном потому, что код пользовательского интерфейса безнадежно и неизбежно переплетается с кодом модели данных. И не заставляйте меня начинать с оконных ручек.

Теперь, когда система находится в разработке около года, клиенты обращаются ко мне с такими просьбами, как: «Мы хотели бы иметь возможность переупорядочивать информацию на этом экране, перетаскивая ее» и «Можем ли мы получить эту информацию для отображения в сетке в этой части этой вкладки? " и - мой любимый - "Можно ли проверить орфографию и автоматический текст?" Эти запросы попадают в очередь, которая становится чертовски длинной.

Мне потребовалось довольно много времени, чтобы выяснить, как реорганизовать дизайн приложения, чтобы оно могло поддерживать пользовательский интерфейс WPF. (На самом деле, это значительное преуменьшение. Я боролся с этим время от времени в течение полутора лет, и я начал получать поддержку только после того, как я отказался от книг WPF, над которыми работал от и изучил MVVM.) Как только я это сделал, результаты впечатляющие.

Код намного проще. Гораздо меньше логики для отладки. Все в пользовательском интерфейсе намного быстрее, что важно, потому что вся причина, по которой это настольное приложение, в первую очередь, заключается в том, что нам нужен очень отзывчивый пользовательский интерфейс. Моя программа может создавать тысячи элементов управления пользовательского интерфейса, не беспокоясь о дескрипторах окон.Легкость, с которой я могу изменить внешний вид программы, потрясающая.

(Пример: пользовательский интерфейс представляет DataRow с различными шаблонами. Поскольку на данном экране могут быть десятки строк, а курсор небольшой, пользователю полезно быть в состоянии с первого взгляда определить, в какой строке находится курсор. Мне потребовалось десять минут, чтобы реализовать стили, которые теперь делают эту визуальную аффорданс доступной повсюду в моем приложении. Это меньше времени, чем мне потребовалось бы, чтобы оценить эту функцию, если бы я хотел добавить ее в свое приложение WinForms. Конечно, это заняло бы намного больше времени, если бы этого нельзя было сделать путем добавления двух стилей. WPF - это серьезно не волшебство.)

Есть ли недостатки ? Как любит говорить мисс Пэйлин, вот и все. Просмотрите некоторые из вопросов, которые я задавал по SO - хороший вопрос о том, как безоперационный преобразователь значений изменил поведение привязки данных . Весь подход к отладке привязок «потри свой живот, погладив голову» довольно разочаровывает, тем более что очень легко иметь ошибки привязки, даже не подозревая об этом. (Теперь я постоянно держу свое окно вывода на экране, чтобы, если во время тестирования будут какие-либо ошибки привязки, движение регистрируемых сообщений привлекло бы мое внимание.) Было бы неплохо иметь возможность получить настоящая трассировка стека, когда ваше окно выдает исключение XamlParseException . Не заставляй меня говорить, я могу говорить всю ночь.

И инструменты! Визуальные инструменты Visual Studio для создания пользовательских интерфейсов WPF для меня совершенно бесполезны.У меня есть Blend, и я использовал его для повторного шаблона элемента управления, но в целом я считаю, что использование Blend похоже на попытку пробежки по болоту, набитому колпаками и тюками. Я уверен, что это действительно здорово, если все, что вы знаете, это Blend, но если то, что вы узнали в первую очередь, - это объектная модель WPF и XAML, поведение Blend будет довольно загадочным. Редакторы XML в Visual Studio и Kaxaml меня огорчают, а функциональность Resharper WPF, скажем так, находится в стадии разработки. Я очень, очень предпочитаю инструменты для WinForms, которые позволяют мне плавно и быстро создавать медленное, причудливое и неподдерживаемое «воронье гнездо», которое я ненавижу.

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

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

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

Поскольку они по существу отказались от мобильных устройств для Windows Phone 7, которые будут использовать только WPF и XNA в качестве основного уровня пользовательского интерфейса, я должен сказать, что да. Этот шаг можно было бы даже рассматривать как завершение срока для гораздо более широко распространенной ОС Windows. Это и большинство пользователей любят тупые конфеты для глаз ИМХО.

Я сам задавался вопросом. Но тот факт, что VS2010, как вы сказали, много использует WPF, говорит мне, что Microsoft пытается рассказать миру, что это не просто очередная причуда MS, но она будет оставаться в течение некоторого времени.

Я думаю, MS ясно дает понять, что WPF и Silverlight - это настоящее и будущее. PM Winforms сказал об этом. Кроме того, ожидается, что в будущем WPF и Silverlight объединятся.

Мы пережили ту же дилемму около 6 месяцев назад в моем офисе. Мы запускали большое LOB-приложение, и никто в команде не имел большого опыта работы с WPF или Winforms. В таком случае мы не могли найти веских причин для использования Winforms, и мы чувствовали, что WPF предлагает нам гораздо более четкое разделение проблем. Мы решили пойти с WPF и использовать PRISM в качестве платформы приложения. По прошествии 6 месяцев, думаю, мы сделали правильный выбор.

Одна вещь, о которой следует помнить, - это Silverlight. Возможно ли, что вы захотите написать свое приложение для запуска из браузера в будущем или, возможно, даже с устройства Windows Phone 7? Хотя Silverlight и WPF не совсем одно и то же, они очень похожи. Это был бы мой главный аргумент в пользу «будущего» в пользу WPF.

Лично мне нравится модель композиции WPF, а также декларативный способ представления пользовательского интерфейса и лучшая система компоновки, чем WinForms. Не то чтобы я вообще пользователь пользовательского интерфейса.

Что касается инструментария, я признаю, что для создания приложений WPF и Silverlight в Visual Studio 2008 от дизайнера потребовалось немало опыта. Однако я надеюсь, что вы познакомитесь с улучшенным конструктором в Visual Studio 2010 - в нем есть еще много функций, которые, как мы надеемся, будут понятны разработчику Windows Forms для создания бизнес-форм, будь то в Silverlight или WPF.

Посмотрите эти видео: Инструменты привязки данных и форм Инструменты стилей Futures Новые функции в бета-версии 2

И получите Release Candidate здесь:

У команды есть новый блог здесь

Надеюсь, вы найдете эту полезную информацию - если вы уже пробовали Visual Studio 2010, я хотел бы услышать ваши отзывы. Отправьте мне письмо на адрес mwthomas на microsoft dot com.

Спасибо, Марк Уилсон-Томас , руководитель программы, WPF и Silverlight Designer, Visual Studio

IMHO, Microsoft дала некоторые подсказки о своем будущем пути, разработав VS 2010 в WPF.

WPF - это не больше и не меньше WinForms. У него совершенно другой и расширяемый способ UX-дизайна.