Код XAML или C #

Question

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

В каких случаях лучше использовать XAML и когда вы используете C #? Каков ваш опыт?

Answer 1

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

Я буду использовать C #, когда мне понадобится создавать динамические элементы управления, но я склонен сохранять свой общий дизайн, статические раскадровки, стили, шаблоны данных и т. Д. В XAML.

Answer 2

Проверьте это видео на MVVM в WPF. Если вы хотите обдумать, как организовать приложение WPF с учетом особенностей XAML, кода и других абстракций, это отличное место для начала.

Answer 3

Конечно, вы можете зайти слишком далеко с XAML. Те, кому нужен весь пользовательский интерфейс (включая логику, отношения обработки событий и т. Д.), Определенные в XAML, вероятно, упускают суть.

Цель XAML - предоставить общий формат для определения того, как вещи должны выглядеть . Это должно быть просто описание того, как раскладывать вещи, как их раскрашивать и стилизовать.

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

Лично мне очень нравится создавать пользовательский интерфейс с выражением Linq!

Абсолютный абсурд был достигнут с помощью примера, который я видел, когда они использовали действия рабочего процесса в качестве дочерних элементов кнопки для предоставления обработчика Click, поэтому вся программа была на XAML. Это звучит «круто», но проблема заключалась в том, что он был значительно более уродливым и нечитаемым, чем эквивалентная программа на C # или VB.NET, и поэтому все, что готово для использования в C #, должно быть заменено более многословным, нестабильным эквивалентом. На самом деле ничего не получилось благодаря этому переводу в более уродливый синтаксис - это та же самая программа, только более отвратительная. XML - плохая основа для синтаксиса общего языка программирования. Начните с того, что символ больше чем должен быть записан как >!

В параллельной вселенной Microsoft выпустила C # 3.0, прежде чем они закончили XAML. Команда XAML приняла синтаксис инициализатора объекта / списка C # 3.0 вместо XML в качестве своего синтаксиса. И вся эта дискуссия не состоялась.

Answer 4

По моему опыту, некоторые вещи гораздо быстрее выполняются в C #, а большинство быстрее в XAML. Когда требуется 5 строк кода на C #, чтобы сделать то, на что способна одна строка кода XAML, мне довольно легко выбрать, что лучше.

Answer 5

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

Любой визуальный дизайн должен быть выполнен в XAML, любая логика должна быть реализована в C #.

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

- Это также означает, что вы можете заменить либо логику, либо визуальный дизайн, не «ломая» ни одного.

- Соединение между ними должно быть сделано с привязками данных и с привязками команд.

Практика, которую я использую:

1. Определите модель (объектную модель бизнес-данных) в отдельном коде C #.

2. Определите постоянные части представления (постоянные части графического пользователя интерфейс, например окна, меню, ...) в XAML (для этого лучше использовать Blend, а не VS).
* Не определяйте стили (цвета, шрифты, ...) здесь.
* Не пишите обработчики событий для кнопок (в большинстве случаев) в code-behind-the-XAML, вместо этого используйте привязки команд.

3. Определите, как модель будет представлена ​​в представлении (графический интерфейс для просмотра / редактирования объектов данных) с помощью XAML «ResourceDictionary», расположенного в отдельных файлах.

- Напишите, используя blend, затем добавьте привязки к XAML, используя VS (дополнение Jetbrains 'Resharper для VS поможет с выражениями привязки).

- Если типы объектов неизвестны во время разработки, вы можете использовать «свободный XAML» и поместить XAML в папку, в которой могут быть файлы, добавленные в / отредактированные в нем без перекомпиляции.

4. Создайте соединение между моделью и представлением (контроллер / модель представления) в C #, которое:
* Создает виды по мере необходимости (для динамических объектов)
* Data-привязывает представление к модели (устанавливает DataSource представления как соответствующий объект в модели)
* Реализует команды
* Command-связывает представление с реализациями команд внутри себя

5. В Application.xaml удалите StartupUri = "MainWindow.xaml" и вместо этого добавьте Startup = "ApplicaitonStartUp".
Внутри обработчика событий ApplicationStartUp ():
* Загрузите все свободные XAML
* Создать контроллер
* Создать главное окно
* Создать модель
* Подключите контроллер к модели и главному окну
* Показать главное окно
* (Сохраните модель, контроллер и главное окно в приватных полях здесь, чтобы убедиться, что они все остаются в живых)

6. Добавьте стили (цвета, шрифты) в отдельный файл XAML в ResourceDictionary (для этого используйте смесь или купите готовый файл темы / обложки XAML).

Answer 6

Желание написать свой пользовательский интерфейс на C # вместо XAML на самом деле является лишь проявлением того, насколько вам удобно в XAML.

Для меня это личная цель - написать как можно меньше кода. Проще говоря, код позади трудно тестировать модулем, но может (и обычно включает) логику, которая не проверяется. XAML декларативен (как HTML) и не содержит никакой логики, поэтому нет ничего для модульного тестирования. Я храню свой код представления в XAML, и я сохраняю свою логику представления в моей ViewModel (MVVM), которую ОЧЕНЬ легко проверить.

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

Answer 7

Самое важное, что нужно иметь в виду, это то, что XAML предназначен для презентации. Вся ваша презентация должна быть в XAML. Если у вас есть логика, вы держите ее вне своего XAML - в своем C #.

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

Answer 8

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

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

XAML - это презентация. Привязка данных не является представлением. логика его представления. поместить всю логику представления в коде позади (привязка данных и обработчики). Разработчики имеют собственный код, а дизайнеры - собственный XAML. если вы разработчик и касаетесь XAML, переместите эту часть в код.

мы также можем писать приложения WPF без XAML ..

Спасибо Винот Кумар Р (Достигнуто достаточно, используя привязку данных Flex MXML)

Answer 9

Одна из приятных сторон XAML - это разделение представления и логики. Это разделение не только теоретическое, но и практическое. В моем случае большинство моих пользовательских интерфейсов теперь обрабатываются дизайнером. Этот дизайнер использует blend и не знает C #, не интересуется изучением c # и, честно говоря, не должен этого делать. Этот дизайнер - настоящий дизайнер, художник, который знает, как использовать эти инструменты, чтобы вещи выглядели действительно очень красиво. По сути, моя философия такова: чем больше я использую XAML, тем меньше мне приходится работать над пользовательским интерфейсом, потому что он может это делать. Это хорошо сработало для нас. Обычно я создаю свой элемент управления без внешнего вида, придаю им базовый вид без излишеств, использую DataContext для привязки моего объекта (кстати, DataTriggers - отличный способ сократить код). В результате я часто проверяю свой код, возвращаюсь на следующий день, синхронизирую его, и пользовательский интерфейс будет выглядеть совершенно по-другому, но все по-прежнему работает !!!

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

Конечно, бывают времена, когда требуется девелопер, чтобы заставить XAML / WPF петь и танцевать, и иногда нам нужно обучать дизайнеров правильному способу делать что-то, но я думаю, что эти затраты окупаются многими в крупных проектах (может быть, не так коротко)

Answer 10

Это касается не только вас, но и вашей команды, некоторые из которых могут быть дизайнерами.