WinForms мертвы или умирают?
Нет. Он не получил существенного развития (т. Е. Нет новых основных дополнений), но он полностью поддерживается, например, в .NET 4.
Является ли WPF хорошей технологией для изучения?
Да.
Это будущее, просто фаза или технология, которая может идти рука об руку вместе с WinForms?
Предполагается, что вы в конечном итоге перейдете на WPF, но также следует понимать, что существуют большие существующие кодовые базы, написанные в WinForms, и нет бизнес-обоснования для их переписывания в WPF. Следовательно, WinForms остается поддерживаемым.
Кроме того, любой опыт будет приятно услышать, особенно от людей, которые широко использовали оба. Как вы обнаружили реализацию аналогичной функции в обеих платформах?
Вообще говоря, WPF гораздо более выразителен. Если вы рассматриваете фреймворки как набор кубиков Lego, которые можно собрать различными способами, кубики WinForms будут намного больше - каждый из них делает много - и поэтому существует меньше способов собрать их все вместе. Довольно часто, когда вам нужно что-то, но не совсем то, что делает существующий кирпич, вы должны написать свой с нуля. В WPF кирпичи значительно меньше и могут комбинироваться многими интересными и даже удивительными способами.
В качестве конкретного примера рассмотрим, как WPF Button является контейнером, который может содержать произвольный контент - не просто изображение + текст, как в WinForms, но абсолютно любой другой элемент управления WPF или набор элементов управления.
В WPF гораздо проще писать динамические макеты по сравнению с WinForms. У последних тоже есть макеты, но проблема в том, что они являются королевским PITA для работы в визуальном конструкторе, и написание инициализации компонента WinForms с помощью кода очень утомительно. С WPF вы просто пишете разметку XAML вручную, и макеты (и деревья управления в целом) очень естественно представлены в XML.
Частично исходя из вышесказанного, я считаю, что WPF легче локализовать. Во-первых, это потому, что вам действительно нужны динамические макеты для локализуемости (поскольку вы не знаете заранее длину строк во всех локалях). Решение WinForms для этого состоит в том, чтобы рассматривать не только текстовые метки, но также контролировать положение и размер как «локализуемое свойство» - поэтому переводчик должен сам переставлять элементы управления в форме, если он обнаружит, что строки не подходят. В WPF динамический макет является подходом по умолчанию, поэтому локализатор работает только со строками.
Платформа связывания WPF довольно мощная (даже если многословная, из-за отсутствия встроенных преобразователей), и сильно продвигает MVP и, в общем, разделение модели / вида. Этого можно добиться с помощью WinForms в 2.0+, и я тоже пытаюсь это сделать, но это более утомительно, особенно в отношении обработки нуля, и иногда может быть довольно глючным .
Одной из особых проблем является то, как дизайнер WinForms взаимодействует с системой контроля версий. Здесь есть две похожие проблемы. Прежде всего, дизайнер сериализует отредактированную форму как код, и иногда очень незначительные изменения в макете могут заставить дизайнера генерировать совершенно другой код (это особенно заметно, если вы редактируете панели инструментов), потому что он перетасовывает строки кода вокруг - т.е. в действительности он изменил единственное значение свойства в одной строке, но оно также переупорядочивает все. Это приводит к очень большому шуму в истории (почти невозможно сказать, что именно было изменено при просмотре различий), но, что более важно, это означает, что объединение таких файлов является большой головной болью. Обычно это происходит, когда два человека работают с одной и той же формой одновременно, и затем один фиксирует свои изменения, а другой пытается зафиксировать, обнаруживает, что файл был изменен в то же время, пытается объединиться, видит различия, и выпрыгивает из ближайшего окна.
Очень похожая проблема возникает при использовании локализуемых форм WinForms, которые помещают некоторые свойства в файл ресурсов. Опять же, разработчик очень любит переупорядочивать значения свойств в файле ресурсов для любого тривиального изменения со всеми теми же проблемами, как описано ранее.
Теперь о недостатках в WPF. Главное, что это немного сложнее и может показаться незнакомым человеку, имеющему опыт работы только с WinForms, VCL, VB или другими подобными «традиционными» средами. Другая проблема заключается в том, что документация, на мой взгляд, не идеальна - она обычно дает хороший обзор, но редко охватывает угловые случаи, некоторые из которых могут быть довольно важными. Это относится и к WinForms, но там меньше возможных комбинаций, поэтому меньше угловых случаев.
Существует также проблема сторонних компонентов. WinForms существуют уже давно, и для этого есть множество доступных, и многие из них очень зрелые. WPF сравнительно молод и все еще переживает проблемы роста, как и большинство сторонних решений для него.
Одной из моих любимых мозолей в WPF является способ сглаживания текста, который воспринимается большинством людей гораздо хуже, чем обычный Windows ClearType, особенно для шрифтов небольшого размера; см. этот отчет об ошибках для получения дополнительной информации. Это исправлено в WPF 4, но оно еще не выпущено, и даже когда это произойдет, есть вероятность, что вам захочется какое-то время пользоваться проверенным и верным 3.5 SP1; и исправление не перенесено.