WPF или WinForms для внутренних инструментов?

Question

В моей компании мы разрабатываем ряд внутренних инструментов, от простых утилит до полноценных редакторов. Приоритетами этих инструментов являются стабильность, удобство использования и время оборота (то есть, как быстро можно добавлять новые функции).

Мы использовали WinForms до сих пор, но на чертежной доске есть пара новых инструментов, и я взвешиваю, стоит ли нам продолжать работать с WinForms или перейти на WPF. Поскольку мы контролируем среду, нам не нужно беспокоиться о версиях .NET и т. Д. (Хотя нам пока нужно работать на XP).

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

Спасибо

Answer 1

Не стоит недооценивать кривую обучения. С WPF очень приятно работать, и это может быть кошмаром. Я видел только разработчиков WinForms, более беспомощных с WPF, чем с ASP.NET (даже с очень небольшим знанием веб-разработки). Хотя большинство разработчиков смогли начать работать с WinForms и ASP.NET, не читая никаких книг, и до некоторой степени были продуктивными, это кажется невозможным с WPF.

И не забывайте о сторонних компонентах. Да, на рынке есть даже новые игроки, и года после .NET 3.0 e. г. Наконец, SoftwareFX удалось выпустить свое графическое решение для WPF (просто в качестве примера), но рынок компонентов для WPF все еще значительно меньше (как коммерческих, так и с открытым исходным кодом), и часто компоненты WPF все еще менее мощны, чем их аналоги WinForms. 1005 *

Я согласен, что архитектура, эл. г. Концепция привязки данных хороша, если вы следуете шаблону, подобному MVVM, однако в MSDN очень мало документации по наилучшей практике e. г. о MVVM, поэтому вам придется указывать своей команде статьи в Интернете, книги и т. д.

И привязка данных уже очень мощная и на самом деле очень похожа в WinForms 2.0. Похоже, мало кто знает об этом и использует его в полной мере. (Может быть, они только попробовали это в 1.1 и думали, что это было слишком сложно ...)

Answer 2

Выберите небольшой проект для работы в WPF и будьте готовы к его рефакторингу, узнав, что может делать WPF и как его правильно использовать. Относитесь к проекту как к «обучающему», потому что потребуется некоторое время, чтобы освоиться с WPF. Продолжай, хотя, потому что оно того стоит.

Answer 3

Я согласен с Алексом - переходи на WPF. Одно из возможных ограничений - WPF работает только на XPSP2 и более поздних версиях.

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

Answer 4

Мне нравятся многие архитектурные изменения, представленные WPF. Обновленная модель DataBinding сама по себе стоит того, чтобы изменить ее, IMO. Тем не менее, я бы сравнил это с любыми потенциальными накладными расходами, связанными с группой, которая поддерживает инструменты, набирающие скорость благодаря WPF.

Answer 5

Я бы перешел к WPF для новых приложений, потому что в целом работать лучше и, как говорится, «Будущее».

В WinForms нет ничего плохого, поэтому, если вы хотите придерживаться этого, проблем не должно быть.

Answer 6

Я бы использовал WPF в зависимости от размера и количества проектов. Чем больше работы у вас впереди, тем больше смысла использовать возможности WPF. Для приложений CRUD вы не получите много преимуществ с точки зрения функциональности от WPF, кроме некоторой привлекательности. Вы выиграете в среднесрочной продуктивности, так как WPF следует чистому подходу, а не тому, который уже много лет развивался, и к тому же сильно исправлен, хотя и очень хорошо одет, как Windows Forms. Размещение экранов в XML имеет свои преимущества.

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

Answer 7

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