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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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