WPF только с кодом

Question

Я видел много вопросов о достоинствах WPF здесь, и практически каждый ответ говорит, что это колени пчелы, но по сути каждый ответ также говорит о таких вещах, как XAML, во многих случаях графические дизайнеры, Expression Blend и т. Д. Вопрос в том, стоит ли заходить в WPF, если вы работаете соло-программистом только на C #?

В частности, у меня нет ни графического дизайнера, ни большого таланта в этой области; Я не использую инструменты "укажи и нажми"; Я пишу все на C #, а не на XML.

Winforms отлично работает в этих условиях. То же самое относится и к WPF, или оказывается, что важные функции могут быть выполнены только в XAML, настройки по умолчанию не предназначены для фактического использования, и вам нужен графический дизайнер в команде, чтобы все выглядело хорошо, и т. Д. ., а кому-нибудь на моем месте было бы лучше придерживаться Winforms?

Answer 1

Я сам человек кода, и, честно говоря, это не имеет значения. Даже если вы ничего не знаете о графическом дизайне, вы все равно можете использовать редактор в Visual Studio для разработки пользовательского интерфейса. В конструкторе есть дизайнер Drag & Drop, как в Win Forms, так что это не представляет проблемы. Несмотря на то, что я работаю в коде, у меня нет проблем с xaml, так как это опять-таки код. Сначала у меня тоже были проблемы с xaml, но я к этому привык, и вещи, которые мне приходилось делать в коде в Win Forms, были довольно просты в xaml.

Привязка данных просто рушится, вам не нужно заботиться о получении данных в пользовательском интерфейсе, у вас просто есть ObservableCollection<T> или подобное, и одно свойство в коде xaml, и все сделано для вас. Хотите отформатировать данные? Просто добавьте свойство форматирования в привязку. Хотите раскрасить текст в соответствии со значением? Класс селектора шаблонов с 15 строками кода, привязкой и выбором шаблона в коде xaml длиной около 10 строк. Я действительно полюбил это, и со временем (как и с любой другой новой технологией) вы привыкаете к этому и производите хорошо выглядящие вещи.

Answer 2

Краткий ответ : да, вы можете делать WPF только с кодом.

Более длинный ответ : Часть, касающаяся способности дизайнера работать с пользовательским интерфейсом и разработчика над функциональностью, на самом деле является лишь побочным эффектом отделения функциональности от представления.

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

• Различные MVVM-фреймворки поощряют соглашение о конфигурации, позволяющее вам писать меньше кода для достижения тех же целей.
• Эта развязка также имеет приятный побочный эффект - приложение становится более тестируемым (вам не нужно писать тесты, если вы этого не хотите, но, по крайней мере, опция есть).

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

Если вы еще этого не видели, серия Scott Hanselman BabySmash довольно интересна.

Answer 3

Все, что может быть сделано в XAML, также может быть выполнено в коде, поскольку XAML является просто DSL для создания экземпляров и настройки графиков объектов - в частности, графов объектов в библиотеке WPF (System.Windows). Если вы создаете линейку бизнес-приложений, то WPF предлагает очень мало предложений, которые вообще не доступны в WinForms. Ключевое отличие заключается в том, что WPF позволяет вам гораздо проще и гибче выполнять многие задачи благодаря более продвинутой объектной модели.

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

Стоит также учитывать, что многие разработчики WPF пишут XAML вручную (тогда как их коллеги-дизайнеры с большей вероятностью будут использовать Blend в первую очередь) частично по необходимости (дизайнер WPF до Visual Studio 2010 был не очень хорош) ) и отчасти потому, что объектная модель поддается более краткому выражению в XAML, чем в C #. XAML сам по себе довольно маленький язык, но объектная модель, которую он использует для определения (объектная модель WPF), огромна - и вот откуда возникает сложность.

Если у вас нет веских причин прекратить использование WinForms, не делайте этого. Однако, если вы можете отложить в сторону свои предубеждения о написании кода на XML, а не на C #, то я думаю, что вы можете быть удивлены, как этот другой подход к созданию пользовательского интерфейса может очистить ваш код.

Answer 4

ИМХО, стоит пойти по маршруту WPF хотя бы для того, чтобы убедиться, что вы развиваете эти навыки. Я играл с Silverlight, который основан на XAML, и я мог бы перенести большую часть этих знаний в WPF, хотя SL является подмножеством.

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

Answer 5

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

Answer 6

это старый пост, но ... На мой взгляд, нет границ, когда вы кодируете себя в любой среде, и что всегда нужно что-то открывать. В прошлом люди создавали макеты в коде в течение многих лет, но определенные факторы побудили сообщество создавать графические и пользовательские инструменты. Но опять же, ничто не длится вечно, и тенденции быстро меняются. Также помните переход от встроенного кодирования ASP к стилю компоновки компоновки ASP.NET, а затем обратно к встроенному ASP.NET MVC. Был ли это шаг назад? Конечно, нет, потому что он был поддержан другими методами и инструментами, такими как бритва, динамический язык, связыватели моделей и многое другое. Так что на самом деле никто не может сказать вам правильный способ работы, если вы следуете основным правилам и стандартам и понимаете, что это не просто код, а сегодняшний код со всеми лямбдами, linq, выражениями, анонимными, DLR и т. Д. Кто знает? Может быть, вы будете тем, кто создаст новый способ выражения и управления контентом.