Где вы проводите грань между кодом и XAMLin WPF?

Question

Чем больше я узнаю о WPF и XAML, тем больше понимаю, что вы можете в значительной степени выполнить весь процесс инициализации GUI и обработки событий в XAML или в коде (например, код C # или код VB.Net).

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

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

Answer 1

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

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

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

• http://blogs.msdn.com/johngossman/archive/2005/10/08/478683.aspx
• http://blogs.msdn.com/johngossman/archive/2005/10/09/478894.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/26/539598.aspx
• http://blogs.msdn.com/johngossman/archive/2006/02/27/540304.aspx
• http://blogs.msdn.com/johngossman/archive/2006/03/04/543695.aspx
• http://blogs.msdn.com/johngossman/archive/2006/04/13/576163.aspx

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

Answer 2

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

Answer 3

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

Примеры каждого будут:

• Модель : определяет свойство с именем ModifiedDate, которое хранит время последнего изменения.

• ViewModel : преобразовывает ModifiedDate в свойство перечисления с именем ModifiedAge, основываясь на том, когда оно было изменено: вчера, в последнюю неделю, в последний месяц, в последний год и т. Д.

• Вид : преобразует свойство ModifiedAge в цвет фона, при котором данные, к которым недавно обращались, выделяются ярко-желтым цветом, а данные, к которым к недавнему доступу обращаются, больше бежево-хаки-серого, на чем настаивает ваш дизайнер называется "Горшок Луг Ларк Лилли".

Answer 4

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

Некоторое время назад я написал кое-что в блоге здесь .

Answer 5

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

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

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

В таком духе.

Answer 6

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

Answer 7

При создании UserControls я стараюсь максимально использовать Xamlize.

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

Answer 8

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