Являются ли Windows Forms старыми технологиями?

Ответ 1

Являются ли 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 в течение некоторого времени; и исправление не задерживается.

Ответ 2

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

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

Модель для работы с WPF определенно отличается от WinForms. Я использовал оба (WinForms более сильно, чем WPF/Silverlight), и самые сложные переходы для меня:

• XAML, что не так плохо, если у вас есть опыт работы с другим языком разметки, например MXML.

• DataBinding

• Обработка событий интерфейса (эффекты MouseOver, временные рамки и т.д.)

Ответ 3

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

Это определенно стоит изучить, но не забудьте изучить "способ WPF" для создания экранов, а не просто подгонять ваш WinForms-путь. Это другой способ кодирования.

Ответ 4

WinForms, вероятно, будет долгое время находиться в корпоративной среде. Они работают достаточно хорошо для многих целей. Многие проекты основаны на WinForms, и многие компании будут придерживаться этой технологии на протяжении всего проекта, а не смешивать и сопоставлять.

Сказав это, WPF - это будущее. Это гораздо более эффективная, гораздо более эффективная технология пользовательского интерфейса и хорошо стоит изучить.

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

Ответ 5

Перспектива с 2016 года:

Я не часто выступаю за то, чтобы ответить на этот вопрос, но подумал, что эпилог может быть уместным на этом. Зачем? Потому что даже сейчас (2016), я слышал, что разработчики в корпоративных средах все еще задают этот вопрос.

Да, семь лет спустя, WinForms все еще жив в корпоративной среде и по-прежнему поддерживается Microsoft. Google Trends показывает медленное, неуклонное снижение процентных ставок с середины 2005 года, с текущим интересом около одной трети 2005 года.

WPF сделал всплеск в 2009 году, но никогда не принимал во внимание стандарт де-факто для разработки новых пользовательских интерфейсов. Google Trends показывает, что интерес WPF достигает максимума с 2009-2011 годов, а затем снижается быстрее, чем WinForms. Текущий интерес представляет собой примерно половину 2011 года, но все же почти двойной интерес к поиску WinForms.

Итак, что сейчас используют разработчики ARE? Веб-интерфейсы постепенно взорвались в значительной степени из-за роста мобильного просмотра. Вы можете спорить о том, как лучше всего писать веб-интерфейс (AngularJS + WebAPI? ASP.NET MVC? React? Все тренды вверх в Google Trends). Какую бы технологию вы ни использовали, трудно отрицать привлекательность написания пользовательского интерфейса (отзывчивого) и работать с ним практически на всех устройствах и платформах. Облачные услуги хостинга стимулировали толчок к Интернету, предлагая практически мгновенное/бесконечное масштабирование с низкими инвестициями в инфраструктуру.

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

Ответ 6

Конечно, нет.

Winforms проще в использовании (учитывая, что вы еще не знаете WPF), и WPF довольно сильно отличается от модели Winforms.

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

Я уверен, что в будущем наступит момент, когда WPF является стандартом defacto. Но на данный момент я придерживаюсь Winforms, если хочу что-то быстрое и чистое.

Стоит упомянуть, что многие приложения уже используют Winforms - это означает, что работа по техническому обслуживанию часто возникает с использованием WinForms, поэтому пока еще не обходите ее.

Ответ 7

WinForms не мертв. Google "winforms С# jobs", и вы найдете много. WPF - это горячий материал, но он все еще относительно новый. Это не будет мейнстримом еще два-три года ИМХО.

Ответ 8

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

Однако принятие решения между WPF и WinForms - это совсем другая история. Несомненно, WPF - это новая жара, а WinForms старая и разоренная, но это правильный выбор? Очевидно, что "это зависит" от ситуации, и Microsoft продолжает поставлять и поддерживать WinForms, чтобы в ближайшее время не уйти. Итак, каковы привлекательные факторы для выбора WPF над WinForms? Карл намекает на выбор WPF над WinForms в своей серии бизнес-приложений WPF, но для некоторых причин это может быть тонким.

Я лично предпочитаю WPF, потому что я начал работать как веб-разработчик и считаю, что XAML разметки является более естественным.

Ответ 9

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

Кроме того, в то время как написание xaml очень отличается от создания форм, это не на расстоянии в миллион миль от написания html и, вероятно, не будет слишком большим для вас отправлением, если вы сделали какую-либо веб-разработку.

В то время как WinForms - это более старая технология, которая не означает, что она когда-либо исчезнет, ​​у нас все еще есть приложения, в которых я работаю, которые написаны на VB6. Только половина нашего отдела разработки работает с .NET - мы разделены на 3 команды, одна команда все еще использует .NET 1.1, другая команда использует .NET 2, а команда, в которой я работаю, использует .NET 3.5 (вы можете скажем, мы счастливые!)

Ответ 10

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

Одно слово совета, хотя. Несмотря на то, что вы можете сделать гораздо более сложную компоновку с WPF (например, упоминание, кнопка или почти что-нибудь действительно, могут размещать другие вещи, такие как изображение, текстовое поле и даже больше), некоторые другие "основы", найденные в WinForm, трудно воспроизвести, Пример. До того, как появился инструментарий WPF, у WPF не было datagrids и datetime picker, поэтому вы должны были сделать это сами. Кроме того, он все еще не имеет MaskTextBox, вам нужно сделать это самостоятельно или загрузить его у третьих лиц. Последний, с которым я столкнулся, в котором я нахожу аннотацию, связан с Treeview: линии между листьями и родителями не отображаются.

Это, как говорится, намного лучше, чем WinForm по большинству аспектов.

Ответ 11

мы начинаем использовать wpf в новом проекте

новое приложение включает много устаревшего кода в winforms.

когда мы хотим использовать старый диалог winforms, возможно.

когда вы используете getr для WPF, вы действительно не хотите возвращаться к winforms. проще всего сделать GUI-материал, который заставит вас много времени в winforms.

каким-либо образом потребуется некоторое время, чтобы изучить материал и иметь возможность использовать все его способности (а не только пользовательский интерфейс, но также привязку данных и команды pattens).

имеющий опыт, который может помочь с первой архитектурой, может быть очень полезен.