ReactiveUI Production Est-Elle Prête?

Je réponds en tant que quelqu'un qui a utilisé ReactiveUI dans quelques systèmes de production, a eu des problèmes avec la façon dont rxui fait des choses, et a soumis des correctifs pour essayer de résoudre les problèmes que J'ai eu.

Avertissement: je n'utilise pas toutes les fonctionnalités de RxUI. La raison étant que je ne suis pas d'accord avec la façon dont ces fonctionnalités ont été mises en œuvre. Je détaillerai mes changements au fur et à mesure.

1. Nommer. J'ai pensé que c'était bizarre aussi. Cela a fini par être l'une des fonctionnalités que je n'utilise pas vraiment. J'utilise PropertyChanged.Fody à tisser dans la notification de changement en utilisant AOP. En conséquence, mes propriétés ressemblent à des propriétés automatiques.

2. Doco. Oui, il pourrait être plus. Surtout avec les nouvelles pièces comme le routage. C'est peut-être une raison pour laquelle je n'utilise pas tout RxUI.

3. La Journalisation. J'ai eu des problèmes avec cela dans le passé. Voir pull request 69. À la fin de la journée, je vois RxUI comme un cadre très opiniâtre. Si vous n'êtes pas d'accord avec cette opinion vous pouvez suggérer des changements, mais c'est tout. Opiniâtre ne le rend pas mauvais.

4. J'utilise RxUI avec Caliburn Micro. Cm Poignées vue-ViewModel emplacement et liaison, écran et conducteurs. Je n'utilise pas la convention de cm. Rxui gère les commandes et le code INPC ViewModel, et me permet de réagir aux changements de propriété en utilisant Reactive au lieu des approches traditionnelles. En gardant ces choses séparées, je trouve beaucoup plus facile de mélanger les deux ensemble.

Est-ce que l'un de ces problèmes a quelque chose à voir avec être prêt à la production? Nope. ReactiveUI est stable, a une base d'utilisateurs de taille décente, les problèmes sont résolus rapidement dans le google group et Paul est réceptif à la discussion.

Je l'utilise en production et Jusqu'à présent RxUI a été parfaitement stable. L'application a eu des problèmes de stabilité, certains à voir avec EMS, d'autres avec un gestionnaire UnhandledException qui causait plus de problèmes qu'il ne résolvait, mais je n'ai eu aucun problème avec la partie ReactiveUI de l'application. Cependant, j'ai eu des problèmes concernant ObservableForProperty ne tirant pas du tout, que j'ai peut-être utilisé incorrectement et qui a fonctionné de manière cohérente (incorrectement) dans mon code de test ainsi que dans L'interface utilisateur au moment de l'exécution.

-1. Paul explique que le _Upper est dû à l'utilisation de la réflexion pour accéder au champ privé de votre classe. Vous pouvez utiliser un bloc comme ci-dessous pour gérer les messages StyleCop et Resharper, ce qui est facile à générer (à partir du SmartTag Resharper)

    /// <summary>The xxx view model.</summary>
    public class XXXViewModel : ReactiveObject
    {
    #pragma warning disable 0649
    // ReSharper disable InconsistentNaming

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private readonly bool _IsRunning;

    [SuppressMessage("StyleCop.CSharp.NamingRules", 
      "SA1306:FieldNamesMustBeginWithLowerCaseLetter",
      Justification = "Reviewed. ReactiveUI field.")]
    private string _Name;
    ....

Ou modifiez vos propriétés à partir de

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _IsSelected; }
        set { this.RaiseAndSetIfChanged(x => x.IsSelected, value); }
    }

À ses composants tels que

    /// <summary>Gets or sets a value indicating whether is selected.</summary>
    public bool IsSelected
    {
        get { return _isSelected; }
        set 
        { 
            if (_isSelected != value)
            {
                this.RaisePropertyChanging(x => x.IsSelected); 
                _isSelected = value;
                this.RaisPropertyChanged(x=>x.IsSelected);
            }
        }
    }

Ce modèle est également utile lorsque vous ne fournissez pas réellement une propriété "simple" accesseur, mais peut nécessiter une variante plus dérivée où la définition d'une valeur affecte plusieurs autres.

-2. Oui, la documentation n'est pas idéale mais j'ai trouvé qu'après Rx, ramasser les échantillons RxUI était assez facile. Je note également que les sauts de 2 - > 4 semblent avoir tous venir avec les changements pour prendre en charge Windows 8 / Windows 8 Phone, et après avoir ramassé ReactiveUI pour une application Windows Store, le support DotNet 4.5 est excellent. c'est-à-dire que l'utilisation de [CallerName] signifie Maintenant que vous ce.RaiseAndSetIFChanged (value) pas besoin de l'expression.

-3. Je n'ai pas de commentaires du côté de la journalisation car je n'ai pas choisi de l'utiliser.

-4. Je n'ai pas non plus mélangé et assorti avec d'autres cadres.

Il y a aussi une liste d'autres contributeurs à ReactiveUI 4.2 à http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released / , y compris Phil Haack.