WPF sans XAML

Question

Sur le plan architectural, je pense que WPF est assez étonnant. En général, je suis un grand fan des mécanismes de rendu et d'animation sous-jacents. La flexibilité de la mise en place des modèles et des styles est assez impressionnante.

Mais je déteste XAML - j'ai l'impression qu'il complique beaucoup de choses. Je l'ai utilisé sur de grandes et petites applications et je me suis souvent retrouvé à essayer de comprendre comment faire quelque chose en XAML pour lequel le principe sous-jacent est basique mais la syntaxe est excentrique. De plus, je me suis souvent demandé à quel point certaines parties de l'analyse syntaxique et de la liaison étaient lourdes. (Je sais que c'est compilé, mais je ne suis pas sûr de la part qui est encore évaluée au moment de l'exécution).

XAML n'est qu'une façon de construire et de charger l'arbre visuel. Existe-t-il des cadres permettant de simplifier la construction de l'arborescence visuelle d'une manière non XML, basée sur le code (mais toujours largement déclarative) ? Plus précisément, je suis intéressé par les cadres qui atténuent l'un des problèmes suivants tout en conservant une approche MVVM :

1. Reliure fortement typée. Spécifier que le ViewModel doit se conformer à un type spécifique. Je suppose que BaseBinding utilise la réflexion sous le capot et je suis un peu sceptique quant à la rapidité de cela, sans parler des liaisons cassées qui sont ennuyeuses.

2. Reliure plus rapide, non INotifyPropertyChanged la reliure. Il semble qu'une sorte de BindableProperty<T> pourrait être créé et la liaison pourrait l'écouter directement plutôt que de recevoir tous les changements de propriétés du ViewModel. L'utilisation d'un rappel direct plutôt que d'un argument de type chaîne semble également avantageuse.

3. Une approche différente de la gestion des ressources ; là encore, des dictionnaires fortement typés pourraient être très utiles. J'aimerais presque voir les styles sous forme de lambdas ou autre pour capturer l'aspect fortement typé.

En résumé, existe-t-il des frameworks qui ne sont pas basés sur XAML, qui s'adaptent bien à MVVM et qui sont fortement typés ?

Answer 1

Je vous soutiens dans le WPF sans Xaml. J'aime les capacités de mise en page et de liaison de WPF, mais je déteste aussi XAML. J'aimerais que WPF puisse être écrit en C#, ce qui présente quelques avantages :

• Initialisateurs d'objets et de collections pourrait remplacer les instanciations Xaml. (c'est dommage que xaml préfère le top-down au button-up).
• Convertisseurs de reliure pourraient être juste des lambdas.
• Styles pourraient n'être que des lambdas qui modifient un objet après son instanciation, sans que les <Setter> la syntaxe.
• Modèles de données ne seraient que des lambdas qui créent des contrôles à partir d'un objet.
• DataTemplateSelectors serait juste un lambda DataTemplate qui appelle d'autres DataTemplates.
• ItemsControl Ce serait juste un Foreach qui prend un lambda (DataTemplate) et le rappelle si un nouvel élément est ajouté à la collection sous-jacente.
• x:Noms ne seraient que des noms de variables.
• Pas besoin de nombreuses MarkupExtensions
  • x:Statique
  • x:Type (spécialement avec des génériques complexes aussi !)
• Contrôles de l'utilisateur ne seraient que des fonctions.

Je pense que beaucoup trop de complexité a été ajoutée à WPF pour permettre sa conception. Le développement Web a déjà perdu cette bataille depuis l'époque de FrontPage jusqu'à Razor.

Answer 2

Cette question doit absolument être accompagnée d'un lien vers le Boîte à outils Bling UI . Il s'agit d'une bibliothèque de haut niveau super géniale pour l'animation et le prototypage d'interfaces utilisateur riches au-dessus de WPF. Liaison avec button.Width = 100 - slider.Value une animation comme celle-ci : button.Left.Animate().Duration(500).To = label.Right un compilateur de pixel shader - incroyable.

Malheureusement, je ne pense pas que le projet soit encore en cours de réalisation. Mais beaucoup d'idées très intelligentes pour donner matière à réflexion.

Answer 3

Il n'existe pas de frameworks de ce type pour WPF. Les trois choses que vous mentionnez dans votre liste de souhaits seraient des remplacements directs (et différents) des composants déjà fournis par WPF. En outre, le remplacement des systèmes de liaison et de ressources par vos versions rendrait inutilisables les éléments que vous appréciez dans WPF (animation, templating, etc.), car ils dépendent fortement de la liaison, des ressources, etc.

Voici quelques suggestions qui pourraient améliorer votre expérience.
1. Apprendre à utiliser XAML (j'avais l'habitude de détester ses entrailles aussi, mais maintenant que je m'y suis habitué, c'est génial).
2. Construisez votre propre bibliothèque qui vous permet de créer facilement l'interface utilisateur, dans le code. Après tout, tout ce qui est fait en XAML peut tout aussi bien être fait en code.
3. Si vous détestez vraiment INotifyPropertyChanged, et que vous voulez un callback à la place, utilisez plutôt un DependencyProperty. Vous n'aurez pas d'événement à déclencher, et vous pourrez avoir un rappel et des valeurs par défaut !
4.) N'utilisez pas WPF. Même si vous dites que vous aimez l'architecture, votre liste de défauts / "améliorations" souhaitées couvre presque toute l'architecture.

Answer 4

> non-INotifyPropertyChanged binding.

A implémenter manuellement INotifyPropertyChanged dans votre viewmodell ou votre modell est un travail manuel/répitatif assez important. Cependant, j'ai lu à propos de ces alternatives

• DynamicViewModel : MVVM à l'aide de POCOs avec .NET 4.0 Ce projet vise à fournir un moyen de mettre en œuvre le modèle architectural Model View ViewModel (MVVM) à l'aide de Plain Old CLR Objects (POCO) tout en tirant pleinement parti de la classe DynamicObject de .NET 4.0. En tirant parti de .NET 4.0 et de la classe DynamicObject, nous pouvons créer un type dérivant de la classe DynamicObject et spécifier un comportement dynamique au moment de l'exécution. En outre, nous pouvons implémenter l'interface INotifyPropertyChanged sur le type dérivé, ce qui en fait un bon candidat pour le Data Binding.

• Contrôles de mise à jour .NET : Liaison de données WPF et Silverlight sans INotifyPropertyChanged. Il découvre automatiquement les dépendances afin que vous n'ayez pas à les gérer dans votre modèle de vue. Et il fonctionne avec Winforms. Liez à travers le code en utilisant les événements.

• notifypropertyweaver : Utilisations IL tissage (via http://www.mono-project.com/Cecil ) pour injecter du code INotifyPropertyChanged dans les propriétés.

  • Aucun attribut requis
  • Aucune référence requise
  • Aucune classe de base requise
  • Prise en charge de .net 3.5, .net 4, Silverlight 3, Silverlight 4 et Windows Phone 7
  • Supporte le mode profil client

Answer 5

Avis de non-responsabilité - J'AIME xaml. Je pense que c'est la meilleure chose qui soit arrivée à la technologie des interfaces utilisateur depuis eh bien je voulais dire "winforms" mais c'était vraiment nul - donc depuis l'aube de l'histoire !

Permettez-moi de décomposer vos besoins à partir de ce nouveau cadre amélioré :

1. Liaisons fortement typées - Si je reconnais qu'il peut être utile, dans CERTAINS cas, de spécifier la liaison d'une manière fortement typée, je me retrouve souvent à utiliser le fait que la liaison soit complètement libre pour être très utile. La découverte des propriétés au moment de l'exécution est une propriété incroyablement puissante de Xaml et du mécanisme de liaison. D'après mon expérience, on apprend assez rapidement à trouver et à corriger les problèmes de liaison, et les erreurs d'exécution sont très détaillées. Ce n'est peut-être pas idéal, mais c'est très bien.
2. Une fixation plus rapide - performance est assez rapide pour la plupart des situations. Vous pouvez toujours fournir un ICustomTypeDescriptor pour améliorer les performances dans les cas extrêmes. Pour ce qui est de la propriété Bindable avec une fonction de rappel, que diriez-vous d'une sorte d'attribut Propriété de dépendance ? (je reconnais que la syntaxe est quelque peu déficiente). Cependant, pour la plupart des utilisations, je trouve que l'interface INotifyPropertyChanged est suffisante. Le mécanisme de liaison ne se soucie que du fait qu'il y a eu un changement, et il fonctionne très bien dans sa forme actuelle. Pourquoi vous préoccuper de la manière dont le framework résout ce problème - du moment que cela fonctionne bien ?
3. Dictionnaires de ressources - Il s'agit d'un autre problème de mise en œuvre qui influence principalement le cadre et son fonctionnement interne. Pourquoi vous préoccuper de la façon dont ils sont mis en œuvre ? Ils fonctionnent plutôt bien.

Je soupçonne que vous utilisez trop le codebehind pour résoudre des problèmes qui peuvent et doivent être résolus en Xaml. Ce qui vous expose à la façon dont le framework résout ces différents problèmes, et que je n'ai presque jamais eu à traiter dans WPF. La séparation claire fournie par Xaml entre "les choses qui sont l'interface graphique" et "les choses qui sont votre code" rend plus difficile pour vous d'interférer avec l'interface graphique en utilisant le code. Mais WPF fournit de nombreux mécanismes différents pour résoudre ces solutions de manière élégante en utilisant Xaml.

Si vous n'aimez pas le coder (personnellement, je n'aime pas m'occuper de l'interface utilisateur - ça ne finit jamais), engagez un expert en Xaml. Ils ont généralement un meilleur goût pour l'interface utilisateur que les développeurs. Et si vous ne pouvez pas le faire, apprenez-le ! C'est un outil formidable si vous prenez le temps de le comprendre. Aucun framework ne résoudra le problème de la compréhension de son utilisation.