Зачем оставлять код "чистым" и делать все в XAML?

В чем преимущество сохранения кода "чистым"?

Много раз я встречаюсь с сообщениями о том, кто пытается сделать эквивалент в XAML вместо кода. Их единственная причина в том, что они хотят сохранить свой код за "чистым". Исправьте меня, если я ошибаюсь, но это не так:  

XAML тоже скомпилирован - в BAML - тогда во время выполнения все равно нужно разбираться в коде.   XAML может потенциально иметь больше ошибок во время выполнения, поскольку компилятор не будет выбран во время компиляции - от неправильного написания - эти ошибки также сложнее отлаживать.   Здесь уже есть код - вроде этого или нет 
InitializeComponent();
должен быть запущен, а файл .g.i.cs, в котором он находится, содержит кучу кода, хотя он может быть скрыт.

Это чисто психологический? Я подозреваю, что разработчики приходят из веб-фона и вроде разметки, а не кода.

РЕДАКТИРОВАТЬ: Я не предлагаю код вместо XAML - используйте оба варианта - я тоже предпочитаю делать привязку в XAML - я просто против того, чтобы делать все возможное, чтобы не писать код за esp в приложение WPF - это должно быть слияние обоих, чтобы максимально использовать его.

ОТВЕТЫ

Ответ 1

1. Проектная перспектива

Пользовательские интерфейсы часто создаются дизайнерами с использованием инструментов-разработчиков (выражение blend и друзей). Если у меня такой рабочий процесс, просто он просто не работает, если вы введете в код код значительного количества UI-кода. По крайней мере, тот опыт, который мы сделали. Код и поведение/функциональность, которые он определяет, недоступны дизайнеру:

  • По большей части этот код выполняется во время выполнения, а не во время проектирование. Таким образом, дизайнер не видит полной истории при проектировании.
  • Дизайнеры не программисты и только ограничены (если вообще) навыки программирования, чтобы они вероятно, неспособны Определено поведение пользовательского интерфейса.

Кроме того, мы убедились в том, что довольно сложно найти способ предоставить издеваемое время разработки (d:DesignInstance, d:DesignData, d:DataContext) для дизайнера, с которым можно работать, если есть код.

2. Перспектива разработчика

Код, связанный с UI, в коде (я предполагаю, что нет необходимости говорить о шансах поставить логику домена в codebehind) - это код, который не может использоваться повторно. Это код, который вечно привязан к определенному UserControl/Window/Page. Если бы я вместо этого написал пользовательское прикрепленное свойство или поведение Я получаю resuablity плюс я делаю наших desginers счастливыми, потому что они могут использовать это также.

Весь код, который я вводил в codebehind, - это код, который трудно проверить. Конечно, в основном это не облегчается, просто помещая его в XAML или в пользовательское прикрепленное свойство. Но в зависимости от того, какой тип функциональности я использую в коде, есть случаи, когда я мог бы инкапсулировать его в тестируемые (многоразовые) классы.

Определение внешнего вида и поведения в XAML имеет тенденцию быть меньше (в отличие от аргумента опроса) ошибкой, чем в коде. Я просто не могу сделать столько ошибок в XAML, сколько могу в коде. Если я сделал что-то не так, то я сразу увидел его в дизайнерской/визуальной студии. Конечно, инструменты все еще могут улучшить здесь. Infact, если я дополнительно использую ReSharper те "неправильные орфографические" miskates в XAML, о которых упоминает вопросник, почти невозможно. Я сразу понял этот код. Я уверен, что стандартные инструменты подберут это. XAML является предпочтительным способом определения пользовательского интерфейса в WPF, и Microsoft делает гораздо больше усилий, чтобы гарантировать, что он работает так, как ожидалось, чем с использованием кода. Infact. Я уже потратил довольно много времени на отладку памяти и исключений во время выполнения кода, который сделал материал, связанный с пользовательским интерфейсом, и его можно было перемещать в XAML без особых усилий.

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

Использование codebehind редко действительно необходимо. Как только вы привыкнете к интерфейсам, управляемым ViewModel, существует alomst, который никогда не является оправданной необходимостью для codebehind. Это не требует больших усилий, чтобы поместить его в другое место. Так зачем беспокоиться?

Ответ 2

Я думаю, что это связано с

  • Testability - это связано с идеей сохранения в представлении тонких моделей ModelViewController/MVP/MVVM для построения графических интерфейсов. Таким образом, в представлении просто есть элементы управления, которые привязаны к классу презентаторов, которые затем могут быть легко протестированы без привлечения GUI. Вы можете добиться замечательной степени уверенности, просто испытав через докладчиков. Это значительно быстрее, чем тестирование через интерфейс.
  • Переход к декларативному программированию по сравнению с императивным программированием - XAML является декларативным программированием. Вам не нужно проверять разметку XAML. Кроме того, MS-код более или менее гарантированно работает и продолжает работать. Таким образом, вы можете быть абсолютно уверены, что initializeComponent не сломается с регистрацией, которую вы только что создали. Таким образом, теоретически, вы могли бы обойтись без проверки своих взглядов - если ваш код не имеет пользовательской/рукописной логики.

Ответ 3

Вы должны держать весь свой код в чистоте, и перемещение работы из кода, расположенного на XAML, не поддерживает его чистоту, оно просто перемещается там, где оно расположено. Вы должны поместить код (и XAML - это форма кода), где это имеет смысл, если попытаться следовать принципам OOD, насколько это возможно.

Ответ 4

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

Если вы ограничиваете логику кода только поведением самого представления, вы можете полностью взаимодействовать с вашим приложением через ViewModels. Это также подразумевает, что если вы каким-либо образом поместите бизнес-логику в сам xaml (не переданный обратно в ViewModel), это также неверно.

Чтобы ответить на вопрос более подробно: Я вижу, что "делаю все в XAML", как привязываю все к вашей ViewModel/всей бизнес-логике в ViewModel.

Ответ 5

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

Ответ 6

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

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