WPF без XAML - PullRequest
       11

WPF без XAML

41 голосов
/ 20 апреля 2011

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

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

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

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

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

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

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

Ответы [ 6 ]

26 голосов
/ 25 января 2012

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

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

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

4 голосов
/ 27 мая 2012

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

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

1 голос
/ 20 апреля 2011

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

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

0 голосов
/ 21 сентября 2018

Упрощен?Нет. Но все, что вы можете сделать в XAML, вы можете просто сделать в коде.Например, вот простое приложение для рисования Windows Ink - настолько простое, насколько вы могли бы его сделать:

who needs visual studio? green ink on purple background

Без сохранения, без изменения чего-либо -но вы можете через код.

Sketchpad.cs

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Media;
using System.Windows.Ink;

public class Sketchpad : Application {

    [STAThread]
    public static void Main(){
        var app = new Sketchpad();
        Window root = new Window();
        InkCanvas inkCanvas1 = new InkCanvas();

        root.Title = "Skortchpard";

        root.ResizeMode = ResizeMode.CanResizeWithGrip;
        inkCanvas1.Background = Brushes.DarkSlateBlue;
        inkCanvas1.DefaultDrawingAttributes.Color = Colors.SpringGreen;
        inkCanvas1.DefaultDrawingAttributes.Height = 10;
        inkCanvas1.DefaultDrawingAttributes.Width = 10;

        root.Content = inkCanvas1;
        root.Show();
        app.MainWindow = root;
        app.Run();
    }

}

Sketchpad.csproj

<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="15.0">
  <PropertyGroup>
    <AssemblyName>Simply Sketch</AssemblyName>
    <OutputPath>Bin\</OutputPath>
  </PropertyGroup>
  <ItemGroup>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.CSharp" />
    <Reference Include="System.Core" />
    <Reference Include="System.Xml.Linq" />
    <Reference Include="System.Data.DataSetExtensions" />
    <Reference Include="System.Net.Http" />
    <Reference Include="System.Xaml">
      <RequiredTargetFramework>4.0</RequiredTargetFramework>
    </Reference>
    <Reference Include="WindowsBase" />
    <Reference Include="PresentationCore" />
    <Reference Include="PresentationFramework" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="SketchPad.cs" />
  </ItemGroup>
  <Target Name="Build" Inputs="@(Compile)" Outputs="$(OutputPath)$(AssemblyName).exe">
    <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" />
    <Csc Sources="@(Compile)" OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
  </Target>
    <Target Name="Clean">
    <Delete Files="$(OutputPath)$(AssemblyName).exe" />
  </Target>
  <Target Name="Rebuild" DependsOnTargets="Clean;Build" />
  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

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

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

Но возможен WPF без XAML .

Вам даже не нужна Visual Studioдля этого установлены только .NET CLI и командная строка разработчика.Перетащите эти два файла в папку и запустите msbuild, а затем вы сможете запустить файл в каталоге Bin.

0 голосов
/ 20 апреля 2011
> non-INotifyPropertyChanged binding.

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

  • DynamicViewModel: MVVM, использующий POCO с .NET 4.0 : Этот проект призван предоставить способ реализации архитектурного шаблона View View Model (MVVM) модели с использованием Plain Old CLR Объекты (POCO) при полном использовании преимуществ класса .NET 4.0 DynamicObject. Используя преимущества .NET 4.0 и класса DynamicObject, мы можем создать тип, производный от класса DynamicObject, и указать динамическое поведение во время выполнения. Кроме того, мы можем реализовать интерфейс INotifyPropertyChanged для производного типа, что делает его хорошим кандидатом для привязки данных.

  • Обновление элементов управления .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
    • Поддерживает режим профиля клиента
0 голосов
/ 20 апреля 2011

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

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

  1. Строго типизированные привязки - Хотя я согласен, что в НЕКОТОРЫХ настройках может быть полезно конкретизировать привязку строго типизированным способом, я часто использую тот факт, что привязка совершенно свободна, чтобы быть очень полезной. обнаружение свойств во время выполнения является невероятно мощным свойством Xaml и механизма привязки. По моему опыту, вы довольно быстро учитесь находить и исправлять проблемы с привязками, а ошибки времени выполнения очень детализированы. Это может быть не идеально - но это довольно хорошо.
  2. Более быстрое связывание - производительность , довольно быстро для большинства ситуаций. Вы всегда можете предоставить ICustomTypeDescriptor для повышения производительности в экстремальных случаях. Что касается этого свойства Bindable с обратным вызовом - как насчет Свойство зависимости ? (Я признаю, что синтаксис несколько не хватает). Однако для большинства применений я обнаружил, что интерфейса INotifyPropertyChanged достаточно. Механизм привязки заботится только о том, что произошли изменения, и он очень хорошо работает в своей текущей форме. Почему вас волнует, как фреймворк решает эту проблему - если он работает хорошо?
  3. Ресурсные словари - Это еще одна проблема реализации, которая в основном влияет на фреймворк и его внутреннюю работу. Почему вас волнует, как они реализованы? Они работают довольно хорошо.

Я подозреваю, что вы могли бы чрезмерно использовать код для решения проблем, которые могут и должны быть решены в Xaml. Которая предоставляет вам способ решения этих проблем в рамках фреймворка, и с которым мне почти никогда не приходилось сталкиваться в WPF. Четкое разделение, обеспечиваемое Xaml между «вещами, которые являются графическим интерфейсом» и «вещами, которые являются вашим кодом», затрудняет вам вмешательство в пользовательский интерфейс с помощью кода. Но WPF предоставляет МНОГО другого механизма для элегантного решения этих решений с использованием Xaml.

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

...