Как ускорить разработку WPF

Question

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

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

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

Я знаю, что могу просто забыть о «чистом XAML» и использовать конструктор графического интерфейса в Visual Studio 2008 (который просто размещает все в огромной сетке), но я боюсь, что потеряю многие преимущества XAML делает это.

Испытывали ли вы что-то подобное? Если да, что вы сделали для ускорения повседневной разработки WPF?

Answer 1

Что я делаю, чтобы ускорить ежедневную разработку WPF:

1. Игнорируй внешний вид так долго, как только смогу. В идеале, настройка выравниваний и полей, а также определение стилей - это последнее, что я делаю.

2. Используйте DockPanel перед использованием Grid и Grid перед использованием StackPanel.

3. При использовании сетки, все по размеру звезды. Я вернусь и исправлю это позже, но во время создания прототипа очень важно иметь четкое представление о том, сколько строк и столбцов у Grid на самом деле.

4. Прототип в Kaxaml, завершение в Expression Blend, тестирование в Visual Studio. Выяснение методологии для этого заняло много времени, и это все еще очень большая работа в процессе. Но Kaxaml отлично подходит для быстрого просмотра поведения прототипа XAML, а Blend отлично подходит для обработки визуальных элементов и инкапсуляции элементов в пользовательские элементы управления и стили.

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

6. Работайте над мельчайшими вещами. Это требует много дисциплины. У меня есть хороший большой сложный файл XAML, и я решил, что мне нужно отредактировать шаблон элемента управления. Сначала нужно создать крошечный файл XAML с этим элементом управления и отредактировать там шаблон элемента управления. Соблазн работать таким образом in situ очень силен, так как редактирование шаблона элемента управления происходит только при щелчке правой кнопкой мыши. Не делай этого.

7. Даже не думайте о том, стоит ли мне разрабатывать модель представления для моего крошечного одноразового приложения. Да, я должен.

8. Learn Blend. Действительно, действительно учиться этому. Узнайте, что означают все маленькие значки, которые окружают выбранный объект, и обратите на них внимание. (Вот кратчайший путь: я не устанавливал поля для этой вещи, но Blend сделал. Это ответ на, возможно, 30% моих вопросов «что, черт возьми, Blend делает сейчас?».) Используйте интерфейс Blend, даже если я знаю было бы быстрее отредактировать XAML вручную. Это опять-таки вопрос дисциплины, сопротивляющийся искушению сделать это сейчас, чтобы я мог улучшить свои возможности, чтобы сделать это позже.

Answer 2

Это все равно, что сказать: «Нарезанные яблоки легко приготовить, но яблочный пирог на вкус лучше. Как я могу сделать яблочный пирог так же легко, как я могу нарезать яблоки?»Что ж, вы можете сделать это проще, используя предварительно приготовленные пироги с пирогами или купив предварительно нарезанные яблоки, но это никогда не будет так просто, потому что давайте посмотрим правде в глаза, вы делаете что-то намного более сложное и потенциально вкуснее.

Звучит так, будто создание стилей задерживает тебя.Вы могли бы начать намного быстрее, если бы вы просто импортировали одинаковые стили для каждого проекта.Обычно я летаю сразу, как только у меня есть все мои стили.

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

Answer 3

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

И затем я делаю вещипросто - я решил использовать стандартную компоновку практически для всего - т.е.бит основного экрана -> DockPanel, панель инструментов ToolBar -> фрагмент.

Всплывающий экран -> DockPanel, панель инструментов ToolBar - верх, закрепленный внизу пользовательский постоянный раздел (кнопки «Сохранить» и «Отмена») - свойства модели представления -> UserControlс сеткой, метками и свойствами.

Для стилей - сначала сделайте это, когда у меня есть по крайней мере 3 экрана для каждого типа - создайте словари ресурсов для каждого типа.Определите общие стили - текстовый блок заголовка и т. Д. Импортируйте ResourceDictionary на каждом экране и применяйте стили.

Применение раскраски, полей, отступов и т. Д. В App.Xaml с неключевыми стилями.

Я могу 'не думаю о более быстром способе.По крайней мере, для меня, мне не нужно думать, когда я делаю это таким образом (поэтому я могу использовать свой мозг позже для сложных вещей) - и это дает последовательный «LOB-взгляд», который относительно легко стилизовать,тема и поменять позже.Это в основном вопрос ввода.

Answer 4

Советы по поводу VS2010 очень хорошие; его визуальный дизайнер действительно полезен по сравнению с XAML-дизайнером VS2008, который был менее чем бесполезным.

PR-машина Microsoft активно использует шаблон «Model-View-ViewModel» для бизнес-приложений до такой степени, что они действительно рекомендуют вещи, которые могут тратить ваше время.

Не не тратите часы, пытаясь вставить все в XAML, если только у вашей компании или клиента нет процедур, требующих этого. Если вы можете кодировать его быстрее в VB или C #, а код все еще можно обслуживать, тестировать и читать, сделайте это.

Не не стать пуристом MVVM; даже Microsoft не определила подходящий баланс для этого шаблона, и даже с помощью Silverlight 4 у них не было хорошего набора инструментов разработки или лучших практик для этого шаблона, хотя с тех пор прошло уже почти пять лет. это было впервые предложено; все еще есть очень веские причины отказаться от ICommand и INotifyPropertyChanged в пользу простого вызова метода в ViewModel из кода. Кроме того, ни один эксперт не из Microsoft WPF / Silverlight, которого я слушал в последние несколько месяцев, не смог сказать: «Я пока не уверен в MVVM, я не пурист».

Найдите баланс и используйте XAML для того, что работает для вас, и C # или VB для того, что работает для вас. Разработчики MS в своих блогах любят называть XAML «разметкой», а C # или VB - «кодом, к сожалению». Что ж, если вы набираете или раскладываете, то это весь код, и правда в том, что все, что XAML интерпретирует, а затем превращает в C # или VB в файлах, которые вы не можете увидеть или легко отредактировать, прежде чем его скомпилировать , (Например, Application.g.vb создается из Application.xaml как частичный класс.)

Существуют конструкции XAML, такие как анимации и раскадровки, для размещения которых в XAML требуется много строк, но в процедурных языках может потребоваться только одна или две строки кода, и их на самом деле легче читать, особенно если анимация реагирует на событие только при определенных условиях. Делай то, что работает лучше всего.

Кроме того, если вы программируете и продолжаете использовать исключения во время выполнения, которые не имеют смысла, сделайте шаг назад, найдите альтернативный ответ, который поможет вам функционировать, и внедрите его. Большинство ошибок XAML не может быть перехвачено Intellisense или компилятором. Можно неделями бить головой о проблему XAML, которая может быть закодирована в C # или VB с ранним связыванием за сравнительно гораздо более короткое время.

Короче говоря, расслабьтесь и используйте свои лучшие практики, используя инструменты VS2010, и вы сможете набрать скорость.

Answer 5

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

Answer 6

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

В конце концов, Blend намного лучше, чем Visual Studio (2010в комплекте), так что гораздо быстрее выполнять работу по проектированию в Blend, а работу по разработке в VS.(только мои два цента)

Answer 7

Если вы используете VS2010, я думаю, что визуальный дизайнер для XAML теперь лучше, и я думаю, что время разработки больше соответствует классическим разработкам winforms.

Если вам все еще нужно ориентироваться на .NET 3.5, вы можете, установив решение для компиляции 3.5 вместо 4.0. Это может быть хорошим вариантом для вас, если вы еще не используете VS2010.