Зачем иметь минимальный пользовательский / рукописный код и делать все на XAML?

Я чувствую, что сообщество MVVM стало слишком усердным, как программисты OO в 90-х - это неправильное обозначение MVVM является синонимом отсутствия кода. Из моего закрытого вопроса StackOverflow :

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

XAML тоже компилируется - в BAML - тогда во время выполнения все равно должен быть разобран в код. XAML потенциально может иметь больше ошибок времени выполнения, так как они не будут обнаружены компилятором во время компиляции - из-за неправильного написания - эти ошибки также сложнее отлаживать. Там уже есть код - нравится это или нет InitializeComponent (); должен быть запущен, и файл .gics, в котором он находится, содержит кучу кода, хотя он может быть скрыт. Это чисто психологическое? Я подозреваю, что это разработчики, которые приходят из веб-фона и любят разметку, а не код.

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

ОБНОВЛЕНИЕ: Это даже не идея Microsoft, каждый пример на MSDN показывает, как вы можете сделать это в обоих случаях.

Я никогда не слышал, чтобы кто-нибудь предлагал поместить все в XAML.

На самом деле, это была бы ужасная идея, ИМО.

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

Следовательно, View оставлен для обработки только того, что лучше всего, а именно пользовательского интерфейса.

Теперь, если у вас есть ситуации, когда ваш пользовательский интерфейс требует кода, то непременно сделайте это и поместите его в свой код. Тем не менее, я бы сказал, что для 95% сценариев вам, скорее всего, будет лучше оставить пользовательский интерфейс в файле разметки, и если вам нужен какой-то код позади, возможно, вы пытаетесь выписать какую-то логику это более уместно оставить для модели представления. Исключениями являются такие вещи, как «Поведение», но они полностью отдельные животные и требуют особого места (т.е. не в вашем коде позади).

Чтобы прямо ответить на ваш вопрос и предположить, что, когда вы говорите «код», который в каждом случае вы имеете в виду конкретно за кодом (код, который находится в классе визуального управления), причина в том, что ваш пользовательский интерфейс может быть полностью реализован и манипулировать в Blend, используя только одну технологию. Предполагается, что ваши UX-дизайнеры не являются разработчиками и не хотят работать с кодом, и что они являются экспертами по макету и XAML, а не специалистами по кодированию. Если вы реализуете все без кода, вы можете предоставить таким дизайнерам инструменты, которые им нужны, чтобы работать полностью на своем языке.

Это обеспечивает четкое разделение между императивным программированием и декларативным дизайном.

Это движущая причина существования «поведений» в Silverlight и WPF - вместо того, чтобы вставлять какой-то код в программный код, сделайте поведение его собственным небольшим повторно используемым модулем. Если вы это сделаете, Blend дает вам возможность буквально перетаскивать его на элемент управления. Теперь, вместо того, чтобы иметь какую-то одноразовую движущуюся деталь для элемента управления, все-таки в XAML, вы абстрагировали движущиеся части в красивый контейнер, которым можно манипулировать с помощью инструментов конструктора.

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

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

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

Тем не менее, я считаю, что вы правы, полагая, что иногда вам лучше идти на компромисс по принципу дизайна. Некоторые вещи очень трудно сделать в xaml. Я потратил часы или даже дни, пытаясь заставить поведение в xaml работать так, как я мог бы сделать за гораздо меньшее время, используя программный код. Я пришел к тому, что code-behind - это последнее средство, но я бы никогда не сказал кому-то, что он никогда не должен его использовать. Это просто еще один компромисс, который должен понять хороший инженер.

редактировать: из комментариев звучит так, будто мой пост интерпретируется как аргумент против xaml. Моим намерением было спорить об обратном. Чистый xaml всегда предпочтительнее, потому что он хранит все поведение в одном месте. Смесь xaml и code-behind может быть запутанной, поэтому минимизация code-behind идеальна. Xaml предпочтительнее чистого кода по многим причинам. WPF и Silverlight предназначены для написания на xaml.

У меня есть только очень поверхностное знание XAML, но это сбивает меня с толку, что компилятор не обнаруживает опечатки.

Основное отличие состоит в том, что XAML является декларативным , а C #, например, является обязательным.

Проще говоря:

Pane p = new Pane(200, 100);
Button foo = new Button("foo");
Button bar = new Button("bar");
p.addChild(foo);
p.addChild(bar);

против

<Pane width="200" height="100">
    <Button label="foo"/>
    <Button label="bar"/>
<Pane>

Верхний код действительно создает иерархию по побочным эффектам, а нижний просто объявляет ее. Стоит также отметить, что хотя addChildметод, например, можно переименовать, отношения child-parent являются ядром семантической модели и представлены именно так в декларативном фрагменте. Это очень далеко от реализации, которая допускает большую оптимизацию, такую ​​как ленивая реализация, совершенно прозрачно.
Декларативное программирование имеет ряд преимуществ. Это более лаконично, выразительно и очень близко к вашей модели. Я бы пошел так далеко, как это предпочтительнее.

Тем не менее, это не значит, что вы должны попытаться вложить все в XAML. C # имеет много конструкций высокого уровня, которые допускают декларативный стиль.

В конце вы хотите, чтобы ваш код был коротким и легким для чтения. Поэтому, если вы можете добиться того же в C # с меньшим количеством кода, чем в XAML, использование C # логично. Имейте в виду, что, однако, код XAML является более «переносимым» в том смысле, что он гораздо менее уязвим к изменениям в используемых компонентах, абстрагируя инфраструктуру .NET (например, от деталей реализации привязок).