XAML или код C# - позади

Этот вопрос подходит к одной из моих старых заметок. Я надеюсь, что эта иллюстрация поможет:

enter image description here enter image description here

45
задан Noldorin 16 June 2009 в 16:43
поделиться

14 ответов

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

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

71
ответ дан 26 November 2019 в 20:49
поделиться

Изначально я пришел с веб-стороны разработки и в настоящее время изучаю WPF / Silverlight. Для меня модель XAML имеет для меня гораздо больше смысла, чем когда-либо существовало WinForms. Я отношусь к XAML как к HTML, а файлы .cs - как к выделенному коду.

1
ответ дан 26 November 2019 в 20:49
поделиться

Check out this video on MVVM in WPF. If you want wrap your head around how to organize a WPF application vis-a-vis what goes in XAML, code behind and other abstractions, this is a great place to start.

27
ответ дан 26 November 2019 в 20:49
поделиться

It's not just about you, it's also about your team, some of whom may be designers.

3
ответ дан 26 November 2019 в 20:49
поделиться

Some things are easier to maintain or debug in code.

0
ответ дан 26 November 2019 в 20:49
поделиться

The urge to want to write your UIs in C# instead of XAML is really just a manifestation of how comfortable you are in XAML.

For me, is is a personal goal to write as little code-behind as possible. Quite simply put, code behind is hard to unit-test, but can (and usually does) include logic that doesn't get tested. XAML is declarative (like HTML) and doesn't include any logic, so there is nothing to unit-test. I keep my view code in XAML and I keep my view logic in my ViewModel (MVVM) which is VERY easy to test.

Once you become more comfortable with XAML, the more you will realize its benefits over view construction in procedural code... Using a pattern like MVVM, you take it a step further, and realize that code-behind is only useful in rare cases.

5
ответ дан 26 November 2019 в 20:49
поделиться

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

11
ответ дан 26 November 2019 в 20:49
поделиться

Not to Mention that you will be able to do more in Xaml2009 that has to be done in code behind now.

Unfortantly BAML won't fully support xaml 2009 in vs 2010 time frame so you can't compile xaml in 2010 time frame. And will have to wait for a later version of blend to do the full dev design loop. (later than 3)

Douglas

0
ответ дан 26 November 2019 в 20:49
поделиться

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

Для меня использование XAML похоже на использование LINQ. Если я могу написать однострочное выражение, которое легко читать, и позволить фреймворку решить, как лучше всего реализовать то, что я хочу, я чувствую себя хорошо. Я определенно стараюсь, насколько могу, использовать декларации того, что я хочу, вместо того, чтобы жестко указывать, как я хочу, чтобы это было сделано. F # - еще один хороший пример этой парадигмы.

1
ответ дан 26 November 2019 в 20:49
поделиться

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

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

4
ответ дан 26 November 2019 в 20:49
поделиться

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

Представьте, что вы заменяете свой XAML-файл файлом, который ВЫГЛЯДИТ совершенно по-другому, но все же использует те же данные - вот где должно быть разделение.

4
ответ дан 26 November 2019 в 20:49
поделиться

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

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

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

Лично мне очень нравится объединять UI с выражением Linq!

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

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

14
ответ дан 26 November 2019 в 20:49
поделиться

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

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

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

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

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

Я использую такую ​​практику:

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

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

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

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

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

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

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

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

8
ответ дан 26 November 2019 в 20:49
поделиться

XAML can be seen as being similar to a combination of XHTML and CSS or XML and XSL which are used for structure and design. Any form of logic should be in C#. This way structure and design are seperated from logic. Your code should be cleaner too by using this approach. Another positive thing is that tasks can be easier to separate between designers and programmers.

One more thing... this is the definition of XAML from MSDN:

Extensible Application Markup Language (XAML) is a markup language for declarative application programming. Windows Presentation Foundation (WPF) implements a Extensible Application Markup Language (XAML) loader and provides Extensible Application Markup Language (XAML) language support for Windows Presentation Foundation (WPF) types such that you can create the majority of your application UI in Extensible Application Markup Language (XAML) markup. In addition, the SDK includes a Extensible Application Markup Language (XAML) editing tool called XAMLPad. You can use this tool to experiment with Extensible Application Markup Language (XAML) in real time.

Link to quote.

0
ответ дан 26 November 2019 в 20:49
поделиться
Другие вопросы по тегам:

Похожие вопросы: