WPF без XAML

Архитектурно, я думаю, что WPF довольно изумительный. В общем, я большой поклонник внутренней обработки рендеринга/анимации. Гибкость настройки шаблонов и стилей довольно впечатляет.

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

XAML - это всего лишь один способ создания и загрузки визуального дерева. Существуют ли какие-либо рамки для упрощения построения визуального дерева в не-XML, основанный на кодах (но все же в значительной степени декларативный) способ? В частности, меня интересуют рамки, которые смягчают любые из следующих проблем, сохраняя при этом подход MVVM:

  • Сильно типизированная привязка. Укажите, что ViewModel должен соответствовать определенному типу. Я предполагаю, что BaseBinding использует отражение под капотом, и я немного скептически отношусь к скорости этого, не говоря уже о том, что разбитые привязки раздражают.

  • Ускоренное связывание, не связанное с INotifyPropertyChanged. Кажется, что какой-то тип BindableProperty<T> может быть создан, и привязка может прослушиваться напрямую, а не получать все изменения свойств ViewModel. И использование прямого обратного вызова в сравнении с строковым аргументом также показалось бы полезным.

  • Другой подход к управлению ресурсами; опять же, сильно типизированные словари могут быть довольно приятными. Я почти хотел бы видеть стили как лямбды или что-то, чтобы зафиксировать строго типизированный аспект.

Итак, любые фреймворки, не основанные на XAML, хорошо подходят для MVVM и строго типизированы?

Ответы

Ответ 1

Desclaimer - я LOVE xaml. Я думаю, что самое лучшее, что может случиться с технологией UI с тех пор... ну... я хотел сказать "winforms", но это действительно сосало - так с самого начала истории!

Позвольте мне раскрыть ваши требования из этой новой и улучшенной структуры:

  • Сильно привязанные привязки. Хотя я согласен, что может быть полезно в некоторых настройках для конкретной привязки строго типизированным способом, я часто нахожу себя в том, что привязка полностью свободна, чтобы быть очень полезной, обнаружение свойств среды выполнения - невероятно мощное свойство Xaml и механизма привязки. По моему опыту вы очень быстро научились находить и исправлять проблемы с привязкой, а ошибки времени выполнения очень детализированы. Это может быть не идеально, но это довольно хорошо.
  • Быстрая привязка - производительность, довольно быстро для большинства ситуаций. Вы всегда можете предоставить ICustomTypeDescriptor для повышения производительности в крайних случаях. Что касается свойства Bindable с обратным вызовом - как насчет какого-то Dependency Property? (я признаю, что синтаксис несколько не хватает). Однако для большинства применений я нашел интерфейс INotifyPropertyChanged достаточным. Механизм привязки заботится только о том, что произошли изменения, и он очень хорошо работает в текущей форме. Почему вам небезразлично, как структура решает эту проблему - пока она работает хорошо?
  • Словари ресурсов. Это еще одна проблема с реализацией, которая в основном влияет на структуру и внутреннюю работу. Почему вам все равно, как они реализованы? Они работают очень хорошо.

Я подозреваю, что вы можете злоупотреблять кодом для решения проблем, которые могут и должны быть решены в Xaml. Это предоставляет вам базовый способ решения этих различных проблем и с которыми я почти никогда не сталкивался в WPF. Четкое разделение, предоставляемое Xaml между "вещами, которые являются графическим интерфейсом" и "Вещи, которые являются вашим кодом", затрудняет вам вмешательство в пользовательский интерфейс с помощью кода. Но WPF предоставляет MANY другой механизм для решения этих решений элегантным способом с помощью Xaml.

Если вам не нравится кодирование (лично мне не нравится возиться с пользовательским интерфейсом - он никогда не заканчивается) - нанимайте Xaml Expert. Они, как правило, имеют лучший вкус в пользовательском интерфейсе, а затем разработчики. И если вы не можете - узнайте об этом! это отличный инструмент, если вы потратите время, чтобы понять это. Никакая структура не решит проблему его использования.

Ответ 2

Я поддерживаю вас в Xaml-free WPF. Мне нравятся возможности компоновки и привязки WPF, но я тоже ненавижу XAML. Мне бы очень хотелось, чтобы WPF мог быть написан на простом С#, некоторые преимущества:

  • Инициализаторы объектов и коллекций могут заменить экземпляры Xaml. (жаль, что xaml предпочитает сверху вниз, чем кнопка вверх).
  • Связывающие преобразователи могут быть только лямбдами.
  • Стили могут быть просто лямбдами, которые изменяют объект после создания экземпляра, без раздутого синтаксиса <Setter>.
  • DataTemplates - это просто lambdas, которые создают элементы управления с учетом объекта
  • DataTemplateSelectors будет просто лямбдой DataTemplate, которая вызывает другие DataTemplates.
  • ItemsControl Будет просто Foreach, который принимает lambda (DataTemplate) и вызывает его снова, если новый элемент будет добавлен в базовую коллекцию.
  • x: Имена будут просто именами переменных.
  • Не нужно много MarkupExtensions
    • х: Static
    • x: Тип (специально для сложных дженериков тоже!)
  • UserControls будут просто функциями.

Я думаю, слишком много сложностей было добавлено в WPF, чтобы он мог быть спроектирован. Веб-разработка уже потеряла эту битву со старых дней FrontPage до Razor.

Ответ 3

Этот вопрос определенно нуждается в ссылке на Инструмент для веб-интерфейса Bling. Это супер-гениальная библиотека высокого уровня для анимации и богатый прототип пользовательского интерфейса поверх WPF. Связывание с button.Width = 100 - slider.Value, анимация следующая: button.Left.Animate().Duration(500).To = label.Right, компилятор пиксельных шейдеров - потрясающий.

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

Ответ 4

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

Вот несколько советов, которые могут улучшить ваш опыт.
1. Научитесь разбираться с XAML (я тоже ненавидел свои кишки, но теперь, когда я привык к этому, это замечательно)
2. Создайте свою собственную библиотеку, которая упрощает создание пользовательского интерфейса для вас, в коде. В конце концов, все, что сделано в XAML, можно сделать и в коде. 3. Если вы действительно ненавидите INotifyPropertyChanged и хотите, чтобы обратный вызов вместо этого использовал DependencyProperty. Нет событий для вас, и вы можете получить обратные вызовы и значения по умолчанию!
4.) Не используйте WPF. Даже если вы говорите, что вам нравится архитектура, ваш список недостатков/желаемых "улучшений" охватывает почти все.

Ответ 5

> non-INotifyPropertyChanged binding.

В вручную реализовать INotifyPropertyChanged в вашей модели viewmodell или modell довольно много ручной/речитативной работы. Однако я читал об этих альтернативах

  • DynamicViewModel: MVVM с использованием POCOs с .NET 4.0. Этот проект призван обеспечить способ реализовать архитектурный шаблон модели View ViewModel (MVVM) с использованием обычных объектов CLR (POCOs), в то же время в полной мере используя класс .NET 4.0 DynamicObject Class. Воспользовавшись .NET 4.0 и классом DynamicObject, мы можем создать тип, полученный из класса DynamicObject, и указать динамическое поведение во время выполнения. Кроме того, мы можем реализовать интерфейс INotifyPropertyChanged на производном типе, что делает его хорошим кандидатом для привязки данных.

  • Update Controls.NET: привязка данных WPF и Silverlight без INotifyPropertyChanged. Он автоматически обнаруживает зависимости, поэтому вам не нужно управлять ими в вашей модели просмотра. И это работает с Winforms. Свяжите код с помощью событий.

  • notifypropertyweaver: Использует прошивку IL (через http://www.mono-project.com/Cecil), чтобы ввести INotifyPropertyChanged код в свойства.

    • Не требуется никаких атрибутов
    • Не требуется никаких ссылок
    • Не требуется базовый класс
    • Поддерживает .net 3.5,.net 4, Silverlight 3, Silverlight 4 и Windows Phone 7.
    • Поддержка режима профиля клиента