WPF - Где вы рисуете линию между кодом и XAML?

Я долгое время программист на С#/.NET, но совершенно новый для WPF и пространства имен System.Windows.Controls и XAML. Чем больше я узнаю об этом, тем больше я понимаю, что вы можете сделать почти все свои инициализации GUI и обработчик событий в XAML или в коде (например, код С# или код VB.Net).

Мой вопрос касается тех, кто работал над WPF дольше и в идеале тех, кто отправил приложения с ним - где вы нашли лучшее место для рисования линии между XAML и кодом? Вы использовали XAML, где бы вы ни находились? Только там, где сопрягаются с некодирующими дизайнерами пользовательского интерфейса?

Любые советы в этой области будут очень полезны для меня и других кодеров, которые просто попадают в программирование WPF и как бы парализованы всеми возможными решениями!

Ответ 1

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

Например, это помогает вам сохранить четкую границу между разработчиком и дизайнером и даже допускает разработку, основанную на тестах.

На нем есть целая куча информации, но я бы начал с сообщений в блоге Джона Госсмана:

Update: Просто хочу указать людей на другой столбец StackOverflow с большим количеством информации о нем на M-V-VM.

Ответ 2

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

Ответ 3

Как и другие, попробуйте следовать шаблону Model-View-ViewModel. Однако, это нормально, чтобы положить вещи в код! Правило состоит в том, что если он связан с "View", вы помещаете его в Xaml или codebehind (в зависимости от того, что вам больше удобно). Если это больше бизнес-логики связано с тем, как пользователь взаимодействует с системой, то он принадлежит ViewModel. Если это просто бизнес-логика, не связанная с взаимодействием, она принадлежит модели.

Примеры каждого из них:

Модель: определяет свойство ModifiedDate, которое сохраняет последний раз, когда оно было изменено.
ViewModel: преобразует ModifiedDate в свойство перечисления с именем ModifiedAge на основе того, когда он был изменен: вчера, в последнюю неделю, в последний месяц, в прошлом году и т.д..
Вид: преобразует свойство ModifiedAge в фоновый цвет, где более недавно полученные данные выделены ярко-желтым цветом, а менее недавно полученные данные более бежево-хаки-серого, которые ваш дизайнер настаивает, называется "Цветочный горшок Loud Lilly Lilly".

Ответ 4

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

Недавно я немного написал сообщение в блоге здесь.

Ответ 5

Не упускайте из виду тот факт, что XAML является кодом. Он декларативный и все такое, но он все еще является языком программирования. Фактически, он проходит через преобразование в С# или Visual Basic, прежде чем превратиться в IL для компилятора .NET, чтобы пережевывать.

Я буду отзывать комментарий Скотта Уитлока: MVVM - отличный способ разделить проблемы и сосредоточиться на архитектурных деталях. Это действительно, действительно хорошо, чтобы поместить материал в ваш код, особенно тот материал, который он описывает. Если у вас нет требования отделить разработчика от разработчика, то адаптируйте шаблон MVVM к вашим конкретным потребностям; не пытайтесь заставить себя быть чистым или идеалистическим.

Также отлично использовать вызовы методов ViewModel прямо в коде View, если вам не нужна гибкость в управлении с классами ICommand. Или, если вы знаете, что представление, которое вы создаете, всегда будет связано с классом ViewModel, который вы создаете. Или вы можете сделать еще один шаг, определить интерфейс для вашего ViewModel и привязать только к реализации этого интерфейса. Затем вы все равно можете поменять ViewModel, когда захотите.

Такие вещи.

Ответ 6

Когда вы будете следовать правильному шаблону, например Mode-View-ViewModel, у вас будет возможность сделать больше на стороне XAML и меньше на код. Максимизируйте использование RoutedEvents и Команды в коде WPF.

Ответ 7

При создании UserControls я стараюсь как можно больше Xamlize.

Один совет, который я нашел в поле, заключается в том, что создание ControlTemplate и DataTemplates вручную - это действительно боль в ***... Я всегда пишу их в XAML....

Ответ 8

Я бы сказал, что использовать как можно больше xaml, используя Binding, commands, styles, templates и т.д. Мне пришлось поддерживать функциональность сохранения и загрузки шаблонов с помощью XAMLReader/XAMLWriter, и это проще для элементов управления имея больше xaml.