Как ускорить разработку WPF
Я разрабатывал с WPF в течение многих месяцев теперь. Это - большая платформа, и я могу сделать необычный, изящный материал, который был бы намного более трудным с WinForms.
Однако у меня действительно есть чувство, что для нормального типа "направления деятельности" приложений без любых специальных требований UI, это все еще берет меня дольше для кодирования UI в XAML, чем это сделало для перетаскивания его в WinForms.
Например, в WinForms, я просто отбросил бы дополнительную маркировку и дополнительное текстовое поле на форме и расположил бы все (использование строк помощника), пока это не выглядит хорошим. В WPF я запустил бы путем факторизации свойств существующей маркировки и текстового поля в стиль, таким образом, я могу снова использовать их; думайте о самом подходящем элементе макета, возможно, осуществите рефакторинг некоторый dockpanels/stackpanels в сетку (или наоборот); попробуйте различные значения за поля и т.д., Хотя у меня есть большой опыт в WPF, все еще требуется много времени.
Я знаю, что мог просто забыть о "чистом XAML" и использовать разработчика GUI в Visual Studio 2008 (который просто абсолютно располагает все в огромной сетке), но я боюсь, что потерял бы много преимуществ, которые XAML предлагает путем выполнения этого.
Вы испытали что-то подобное? Если да, что Вы делали для ускорения повседневной разработки WPF?
7 ответов
Что я делаю, чтобы ускорить повседневную разработку WPF:
Не обращайте внимания на внешний вид как можно дольше. В идеале настройка выравнивания и полей, а также определение стилей - это последнее, что я делаю.
Используйте DockPanel перед использованием Grid и Grid перед использованием StackPanel.
При использовании сетки выделяйте все звездочкой. Я вернусь и исправлю это позже, но во время прототипирования очень полезно иметь четкое представление о том, сколько строк и столбцов на самом деле имеет Grid.
Прототип на Kaxaml, завершение в Expression Blend, тестирование в Visual Studio. На разработку методологии для этого ушло много времени, и эта работа все еще продолжается.Но Kaxaml отлично подходит для быстрого просмотра того, как будет вести себя прототип XAML, а Blend отлично подходит для разработки визуальных элементов и инкапсуляции вещей в пользовательские элементы управления и стили.
При использовании Blend не создавайте макеты в монтажной области, создавайте их в контуре объекта. Когда я впервые разрабатываю пользовательский интерфейс WPF, иерархия объектов в сто раз важнее, чем то, как она выглядит на экране. Я все еще учусь этому, и кажется возможным, что, как только я стану достаточно хорошим, мне больше не нужно будет создавать прототип на Kaxaml.
Работайте над малейшим возможным. Это требует большой дисциплины. У меня есть хороший большой сложный файл XAML, и я решаю, что мне нужно отредактировать шаблон элемента управления. Первое, что нужно сделать, - это создать крошечный файл XAML с этим элементом управления и отредактировать там шаблон элемента управления. Соблазн работать таким образом in situ велик, так как редактирование шаблона элемента управления выполняется только щелчком правой кнопки мыши. Не делай этого.
Даже не думайте о том, стоит ли мне разрабатывать модель представления для моего крошечного одноразового приложения. Да, я должен.
Learn Blend. Действительно, действительно научитесь этому. Узнайте, что означают все крошечные значки, окружающие выбранный объект, и обратите на них внимание. (Вот ярлык: я не устанавливал поля для этой штуки, но Blend установил. Это ответ примерно на 30% моих вопросов «что, черт возьми, Blend сейчас делает?».) Используйте интерфейс Blend, даже если я знаю , что было бы быстрее редактировать XAML вручную.Это опять же вопрос дисциплины, противостояния искушению сделать это сейчас, чтобы я мог улучшить свои способности, чтобы сделать еще больше позже.
Если вы используете VS2010, я думаю, что визуальный дизайнер для XAML сейчас лучше, и я думаю, что время разработки больше соответствует разработке классических winforms.
Если вам все еще нужно настроить .NET 3.5, вы можете установить для решения значение 3.5 вместо 4.0. Это может быть хорошим вариантом для вас, если вы еще не используете VS2010.
Я чувствую вашу боль ... Каждый раз, когда мы добавляем новое поле в базу данных, в форму необходимо добавить еще один TextBox / ComboBox. Я обнаружил, что использование Expression Blend позволяет мне намного быстрее разложить форму. Обратной стороной является то, что использование Blend имеет тенденцию создавать больше xaml, чем писать его вручную, поэтому я обычно немного очищаю xaml.
В конце концов, Blend является гораздо лучшим дизайнером, чем Visual Studio (включая 2010), поэтому гораздо быстрее выполнять дизайн в Blend, а разработку - в VS. (всего два цента)
Это похоже на высказывание «Нарезанные яблоки легко приготовить, но яблочный пирог вкуснее. Как я могу приготовить яблочный пирог так же легко, как нарезать яблоки?» " Что ж, вы можете упростить это, используя готовые корочки для пирогов или покупая предварительно нарезанные яблоки, но это никогда не будет так просто, потому что, давайте посмотрим правде в глаза, вы делаете что-то гораздо более сложное и потенциально более вкусное.
Похоже, создание стилей поддерживает вас. Вы могли бы начать гораздо быстрее, если бы просто импортировали одни и те же стили в каждый проект. Обычно я летаю сразу после того, как сделаю все свои стили.
В противном случае, единственный способ сделать это так же просто, как конструктор WinForms с перетаскиванием, - это использовать конструктор WPF с перетаскиванием.
Я использую WPF уже пару лет - для оптимальной скорости я отключил design-view, использую сниппеты, интенсивно использую intellisense (и, конечно, ReSharper).
И затем я делаю все просто - я решил использовать стандартную компоновку почти для всего - т.е. основной экран -> DockPanel, ToolBar в доке сверху -> сниппет.
Всплывающий экран -> DockPanel, ToolBar сверху, пользовательский постоянный раздел снизу (кнопки Save и Cancel) - свойства viewmodel -> UserControl с сеткой, метками и свойствами.
Для стилизации - сначала делаю это, когда у меня есть по крайней мере 3 экрана для каждого типа - создаю словари ресурсов для каждого типа. Определите общие стили - текстовый блок заголовка и т.д. Импортируйте ResourceDictionary в каждый экран и примените стили.
Применить раскраску, поля, отступы и т.д. в App.Xaml с помощью неключевых стилей.
Я не могу придумать более быстрого способа. По крайней мере, для меня, мне не нужно думать, пока я делаю это таким образом (так что я могу использовать свои мозговые способности позже для сложных вещей) - и это дает последовательный "LOB-вид", который относительно легко стилизовать, оформлять и изменять позже. По сути, это просто набрать.
Совет по VS2010 очень хороший; его визуальный конструктор действительно полезен по сравнению с конструктором XAML VS2008, который был менее чем бесполезным.
PR-машина Microsoft широко продвигает шаблон «Модель-Представление-Модель представления» для бизнес-приложений до такой степени, что они фактически рекомендуют вещи, которые могут тратить ваше время зря.
Не тратьте часы, пытаясь встроить все в 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, и вы сможете набрать скорость.
Моя самая большая проблема на данный момент заключается в том, что я постоянно думаю о том, как можно динамически компоновать пользовательский интерфейс с помощью шаблонов данных, что часто может мешать более простым решениям, когда дополнительная гибкость не требуется. В остальном, я стал работать быстрее, когда привык к различным контейнерам и их причудам. Это настолько кардинально другая технология, что потребуется время, прежде чем я выработаю соответствующий ментальный набор инструментов для своих повседневных задач пользовательского интерфейса, тем более что мне все еще нужно регулярно использовать WinForms. Однако я думаю, что это лишь вопрос времени, когда у меня в голове появятся стандартные шаблоны, которые я смогу быстро и легко внедрить.