Являются Windows Forms старой технологией?
Пора записать GUI для моего проекта, и я задаюсь вопросом что технологию использовать. Я сделал большую часть своей разработки GUI.NET в.NET 1 и 2, таким образом, я знаю Windows Forms обоснованно хорошо. Я неопределенно знаю о WPF, но еще не предпринятый для "вхождения в него".
Windows Forms мертвы или умирают? Действительно ли WPF является хорошей технологией для изучения? Действительно ли это - будущее, просто фаза или технология, которая может идти рука об руку вместе с Windows Forms?
Кроме того, любые события будут хороши для слушания, особенно от людей, которые использовали обоих экстенсивно. Как Вы находили реализование подобной опции в обеих платформах?
10 ответов
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; и исправление не поддерживается.
WinForms aren't dead or dying...they just can't provide the same User Experience that WPF can (without A LOT of work). They're just older technology.
WPF is a good technology to learn. It provides the ability to provide a much richer User Experience with less work.
The model for working with WPF is definitely different than WinForms. I've used both (WinForms more heavily than WPF/Silverlight) and the most difficult transitions for me were:
XAML, which isn't as bad if you have experience with another markup language like MXML.
DataBinding
Interface Event Handling (MouseOver effects, Timelines, etc.)
WinForms далеко не мертв / умирает. WPF - это просто новый способ решения проблемы пользовательского интерфейса, поскольку он продвигает вещи, которые были более сложными в WinForms. Такие вещи, как разделение модели, стоящей за пользовательским интерфейсом, от фактического пользовательского интерфейса, чтобы ее можно было легко протестировать, являются важным фактором.
Это определенно стоит изучить, но обязательно изучите "способ WPF" создания экранов, а не просто подгоняйте WinForms - путь внутрь. Это другой способ кодирования.
Конечно, нет.
Winforms проще в использовании (учитывая, что вы еще не знакомы с WPF), а WPF - это отход от модели Winforms.
Если вам нужен простой GUI (стандартная форма) идет с Winforms. Если вам нужно что-то более яркое и у вас есть время, перейдите на WPF.
Я уверен, что в будущем наступит момент, когда WPF станет стандартом де-факто. Но пока я придерживаюсь Winforms, если мне нужно что-то быстрое и чистое.
Стоит упомянуть, что многие приложения уже используют Winforms - это означает, что часто возникают работы по обслуживанию, связанные с WinForms, так что не откладывайте это просто пока нет.
WinForms не умер. Google "winforms C # jobs", и вы найдете много. WPF - горячая штука, но все еще относительно новая. ИМХО, он не станет мейнстримом еще два-три года.
мы начинаем использовать wpf в новом проекте, у нас есть
новое приложение включает в себя много устаревшего кода в winforms.
всякий раз, когда мы хотим использовать старый диалог winforms, это возможно.
когда вы getr использовать в WPF, вы действительно не хотите возвращаться к winforms. гораздо проще делать вещи с графическим интерфейсом, которые отнимут у вас много времени в winforms.
в любом случае потребуется некоторое время, чтобы изучить материал и иметь возможность использовать все его возможности (не только пользовательский интерфейс, но и привязку данных и
иметь опыт, который может помочь с первой архитектурой, может быть очень полезным.
WinForms, вероятно, еще долго будут использоваться в корпоративных средах. Они подходят для многих целей. Многие проекты основаны на WinForms, и многие компании будут придерживаться этой технологии на протяжении всего проекта, а не смешивать и сочетать.
Сказав это, будущее за WPF. Это гораздо более эффективная, более функциональная технология пользовательского интерфейса, и ее стоит изучить
. WinForms и WPF могут сосуществовать в одном приложении. Это, вероятно, будет для них наиболее распространенным способом познакомиться с компанией (это и небольшие экспериментальные проекты).
Мы начали использовать WPF для нового проекта и, честно говоря, трудно вернуться к WinForms. Множество интересных вещей, без которых я больше не могу.
Но один совет. Несмотря на то, что вы можете сделать гораздо более сложный макет с помощью WPF (как уже упоминалось, кнопка или почти что-нибудь действительно может содержать другие вещи, такие как изображение, текстовое поле и многое другое), некоторые другие `` базовые '' вещи, найденные в WinForm, трудно воспроизвести . Пример: до того, как появился инструментарий WPF, в WPF не было датагрид и средства выбора даты и времени, поэтому вам приходилось делать это самостоятельно. Кроме того, в нем по-прежнему нет MaskTextBox, вам придется делать это самостоятельно или скачивать у третьих лиц. Последний случай, с которым я столкнулся и на самом деле обнаружил, что аннотирование - это Treeview: линии между листьями и родителями не видны.
Тем не менее, все же намного лучше, чем WinForm по большинству аспектов.
Я думаю, что определенно стоит изучить WPF, прежде чем он станет более популярным. Всегда полезно улучшить свои навыки, а иметь опыт и знания в области новых технологий - это всегда плюс, особенно если WPF будет более широко используется в будущем.
Кроме того, хотя написание разметки xaml сильно отличается от создания форм, это не более чем на миллион миль от написания html и, вероятно, не станет для вас слишком большим отклонением, если вы занимались веб-разработкой.
Хотя WinForms - более старая технология, что не означает, что она когда-либо исчезнет, у нас все еще есть приложения, в которых я работаю, написанные на VB6. Только половина нашего отдела разработки работает с .NET - мы разделены на 3 команды, одна команда все еще использует .NET 1.1, другая команда использует .NET 2, а моя команда использует.
Вот хороший блог о WinForms и WPF. Общая идея состоит в том, чтобы выбирать с умом, а это означает, что одно не может победить другого. У каждого свой набор функций.
Однако выбор между WPF и WinForms - это отдельная история. Конечно, WPF - это новая популярность, а WinForms - старый и сломанный, но правильный ли это выбор? Очевидно, что «это зависит» от ситуации, и Microsoft продолжает поставлять и поддерживать WinForms, так что в ближайшее время они не исчезнут. Итак, каковы убедительные факторы в пользу выбора WPF вместо WinForms? Карл намекает на выбор WPF вместо WinForms в своей серии статей о бизнес-приложениях WPF, но для некоторых причины могут быть тонкими.
Лично я предпочитаю WPF, потому что я начинал как веб-разработчик и считаю, что разметка XAML более естественная.
WPF - это новая популярность, а WinForms - старый и разорившийся, но правильный ли это выбор? Очевидно, что «это зависит» от ситуации, и Microsoft продолжает поставлять и поддерживать WinForms, так что в ближайшее время они не исчезнут. Итак, каковы убедительные факторы в пользу выбора WPF вместо WinForms? Карл намекает на выбор WPF вместо WinForms в своей серии статей о бизнес-приложениях WPF, но для некоторых причины могут быть тонкими.Лично я предпочитаю WPF, потому что я начинал как веб-разработчик и считаю, что разметка XAML более естественная.
WPF - это новая популярность, а WinForms - старый и разорившийся, но правильный ли это выбор? Очевидно, что «это зависит» от ситуации, и Microsoft продолжает поставлять и поддерживать WinForms, так что в ближайшее время они не исчезнут. Итак, каковы убедительные факторы в пользу выбора WPF вместо WinForms? Карл намекает на выбор WPF вместо WinForms в своей серии статей о бизнес-приложениях WPF, но для некоторых причины могут быть тонкими.Лично я предпочитаю WPF, потому что я начинал как веб-разработчик и считаю, что разметка XAML более естественная.
но для некоторых причины могут быть тонкими.Лично я предпочитаю WPF, потому что я начинал как веб-разработчик и считаю, что разметка XAML более естественная.
но для некоторых причины могут быть тонкими.Лично я предпочитаю WPF, потому что я начинал как веб-разработчик и считаю, что разметка XAML более естественная.