Реализовать WinForms с помощью WPF?

Question

Этот вопрос является результатом беседы в обеденный перерыв с коллегой ... Я читал такие вопросы, как WPF против Winforms ... и лично я думаю, что долго термин WPF - это путь. Проблема / вопрос в том, что делать тем временем.

Да, WPF, безусловно, имеет свои преимущества; не строится на GDI / USER является одним из них. Но на данный момент (то есть в конце 2009 года; с использованием VS2008 или, возможно, даже VS2005; Silverlight3 недавно выпущен и еще не получил широкого распространения / развертывания), WPF почти выглядит как «чрезмерно спроектированное» решение. Хотя я уверен, что со временем все изменится, это не облегчит ни сегодня, ни в ближайшем (скажем, <36 месяцев) будущем. </p>

И давайте посмотрим правде в глаза, WinForms действительно просто и легко; особенно для многих сотрудников, которые все еще «счастливо» используют MFC. Да, может быть сложно делать гладкую анимацию, 3D-графику, градиенты и т. Д .; но это очень практичное решение, которое многие люди (т.е. разработчики на C ++ / MFC) с готовностью понимают сегодня .

С этим длинным вступлением - кто-нибудь думал / устал / и т.д. о идее реализации (большей части) WinForms с использованием WPF (то есть WinForms sans GDI / USER)? Я уверен, что с учетом таких вещей, как Control.Handle, 100% повторная реализация невозможна. Но, безусловно, кажется, что многие элементы управления WinForms могут быть повторно реализованы с использованием WPF «под капотом». Или это действительно невозможно?

Путем «повторной реализации» я предполагаю удалить ссылки на сборки для System.Windows.Forms , заменив их (скажем) Microsoft.Wpf.WinForms , а затем перестроив мое приложение. После этого я ожидал бы исправить некоторые (относительно небольшое количество) ошибок компилятора и / или среды выполнения (скажем, P / вызывает Win32 API).

Нечто подобное выглядит как хорошее дополнение к различным стратегиям взаимодействия Microsoft WinForms / WPF, таким как WindowsFormsHost . Например, разработчики могут начать использовать / изучать WPF гораздо более инкрементально.

Редактировать: Хотя различные "почему?" обсуждения интересны, они не отвечают на основной технический вопрос: «да., вот как .... или нет, потому что ...».

Answer 1

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

Но сначала ты должен это сделать. Сохранять кодирование в стиле WinForms в WPF действительно легко, так что вы должны заставить себя не делать этого, или вы никогда не сделаете этот следующий шаг. Заставьте себя начать с чистого листа, научитесь применять MVVM, взгляните на Prism, создайте несколько действительно простых приложений, а затем добавьте к ним, чтобы узнать, как управлять сложностью с помощью WPF. Вы можете реализовать WinForms в WPF, но все, что у вас когда-либо будет, это люди, кодирующие WinForms в WPF. В итоге вы получаете эквивалент (из Imperative -> OO days), превращающий каждый класс в единый объект со всеми статическими методами. Возможно, вы «используете» WPF, но вы (и / или ваши коллеги) никогда не дойдете до этой стадии.

Из того, что я могу почерпнуть из вашей ситуации, я бы порекомендовал вам , а не , пытаться переключиться на WPF, если вы не пишете новое приложение с небольшой командой. Если это действительно так, то небольшая команда может стать ядром перемен, потому что, как только один человек в вашей организации «получит это», они будут учить окружающих, пока лампочки не начнут светиться повсюду. Это то, что мы сделали в моей нынешней организации, и оглядываемся на прогресс, которого все достигли за последние 6 месяцев, просто поражают.

Answer 2

Я не совсем уверен, что понимаю ваш вопрос - уже возможно использовать библиотеки WPF в виде Winforms аналогично (собрать все в коде без XAML), и большинство общих элементов управления Winforms имеют свои прямые аналоги WPF.

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

И я даже не говорю о причудливых визуальных эффектах, которые просто требуют слишком много работы в winforms, а просто что-то вроде визуализации списка произвольных элементов в коллекции.

Кроме того, если вы собираете все в стиле кода Winforms, вы не получаете поддержку редактирования времени разработки.

Answer 3

Во-первых, WPF не "перепроектирован". Я бы сказал, что он просто идеально спроектирован, так как это чрезвычайно сложный процесс для реализации инфраструктуры пользовательского интерфейса, которая поддерживает богатую возможность компоновки, богатую привязку данных, 2D и 3D на одной платформе.

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

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

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

Answer 4

Аналогия для ваших коллег:

Что лучше, автомобиль или лошадь и багги?

1. Автомобили - не такая зрелая технология, как лошадь и багги. Лошади и багги существуют уже более 2000 лет, автомобили менее 200 лет.

2. Автомобили чрезмерно спроектированы и чрезвычайно сложны. Лошадь и багги просты.

3. Люди во многих частях света не знают, как водить автомобиль, но у них хорошие навыки работы с лошадью и багги.

Вопрос: Можем ли мы упростить наши автомобили, чтобы они контролировались поводьями, ели сено и ремонтировались ветеринарами и каретниками?

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

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

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

Answer 5

Вы действительно должны смотреть на это с точки зрения долгосрочной перспективы жизни создаваемого вами приложения. Хотя WPF может и не быть таким зрелым, как Windows Forms, он позволяет программисту разделять дизайн (XAML) и логику (C # / VB). Я не верю, что было бы хорошо, если бы вы создавали свои элементы управления в WPF в стиле Windows Forms. Представьте себе, что по какой-то причине в будущем все это можно будет вернуть в XAML!

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

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

Если вы продолжите использовать Windows Forms, вы упустите новые функции в WPF, которые ускоряют разработку. Например, у вас могут быть люди, работающие над дизайном, в то время как другие работают над логической стороной приложения из-за более явного разделения дизайна и логики.

Answer 6

То, что называется WindowsFormsHost , может помочь с первоначальным перемещением элементов управления. Тем не менее, я нашел это довольно медленно. Вам гораздо лучше потратить время на изучение WPF и написание всего с нуля, а также использовать все возможности, особенно привязку данных!