ReactiveUI Production est-il prêt?

Question

J'ai été regarder dans la faisabilité de l'utilisation de Réactifs de l'INTERFACE utilisateur dans le code de production. Certaines des fonctionnalités sont vraiment attrayant, mais j'ai des inquiétudes au sujet de la dépendance sur cette bibliothèque. Elles comprennent:

1. Déjanté et les conventions de nommage. Par exemple, les membres protégés de départ avec des minuscules, et l' RaiseAndSetIfChanged méthode dépend de votre membre privé commençant par un trait de soulignement. Je comprends Paul Betts (ReactiveUI auteur) a un Rubis de fond, donc je suppose que c'est là l'étrange appellation provient de. Cependant, cela va provoquer un réel problème pour moi, depuis la norme de nommage (comme par Stylecop) est appliquée tout au long de mon projet. Même si elle n'était pas forcée, je serais intéressé par la résultante de l'incohérence dans l'appellation que cela entraîne.
2. L'absence de documents/échantillons. Il y a certains de documentation et d'un seul échantillon. Toutefois, la documentation est juste une série de (vieux) les messages du blog et l'échantillon est basé sur la V2 de la bibliothèque (c'est maintenant sur la V4).

3. Étrange conception, dans les pièces. Par exemple, la journalisation est prélevée afin de ne pas prendre une dépendance sur un de journalisation. Juste assez. Cependant, depuis que j'utilise log4net (et pas NLog), j'aurai besoin de mon propre adaptateur. Je pense que cela va m'obliger à mettre en oeuvre IRxUIFullLogger, ce qui a une métrique criss c'est n'importe méthodes (plus de 50). J'aurais pensé à une bien meilleure approche consisterait à définir une interface très simple, et ensuite fournir les méthodes d'extension au sein de ReactiveUI afin de faciliter l'ensemble des surcharges. En outre, il y a cette étrange IWantsToRegisterStuff interface de l'NLog assemblée dépend, que je ne vais pas être en mesure de compter sur (parce que c'est une interface interne). J'espère que je n'ai pas besoin de ça...

   De toute façon, ma préoccupation ici est que l'ensemble de la conception de la bibliothèque. Quelqu'un a été mordu par cette?

4. Je suis déjà en utilisant MVVM Light largement. Je sais que Paul a fait un blog où il explique que vous pouvez utiliser techniquement à la fois, mais mon inquiétude est plus autour de la maintenabilité. Je soupçonne il serait horriblement confus d'avoir à la fois mêlés dans la base de code.

Quelqu'un aurait-il les mains sur l'expérience avec l'utilisation de Réactifs de l'INTERFACE utilisateur dans la production? Si oui, êtes-vous en mesure de dissiper ou de l'adresse de l'un de mes préoccupations ci-dessus?

Answer 1

Allons par le biais de vos préoccupations pièce par pièce:

#1. "Déjanté de nommage et les conventions."

Maintenant que ReactiveUI 4.1+ a CallerMemberName, vous n'avez pas à utiliser les conventions à tous (et même alors, vous pouvez les remplacer par RxApp.GetFieldNameForPropertyFunc). Il suffit d'écrire une propriété:

int iCanNameThisWhateverIWant;
public int SomeProperty {
    get { return iCanNameThisWhateverIWant; }
    set { this.RaiseAndSetIfChanged(ref iCanNameThisWhateverIWant, value); }
}

#2. L'absence de documents/échantillons

C'est légitime, mais voici quelques docs / échantillons:

• https://github.com/reactiveui/ReactiveUI.Samples
• https://github.com/reactiveui/RxUI_QCon
• https://github.com/play/play-windows

#3. "J'aurais pensé à une bien meilleure approche consisterait à définir une interface très simple, et ensuite fournir les méthodes d'extension au sein de ReactiveUI afin de faciliter l'ensemble des surcharges"

Mettre en oeuvre IRxUILogger au lieu de cela, il a un peu des deux méthodes :) ReactiveUI de remplir le reste. IRxUIFullLogger n'est là que si vous en avez besoin.

"En outre, il y a cette étrange IWantsToRegisterStuff interface "

Vous n'avez pas besoin de savoir à ce sujet :) C'est seulement pour les ReactiveUI initialisation de lui-même, de sorte que vous n'avez pas besoin de code réutilisable.

1. "Je soupçonne il serait horriblement confus d'avoir à la fois mêlé à un code de base."

Pas vraiment. Suffit de penser que "MVVM Light avec les grandes Puissances".

Answer 2

Je réponds 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 trucs, et a soumis des patchs pour corriger 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 caractéristiques ont été mises en œuvre. Je détaillerais mes modifications que je vais.

1. De nommage. 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 modification de l'utilisation de l'AOP. Suite à mon propriétés ressemblent à des auto propriétés.

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 la totalité de 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 beaucoup d'opinions cadre. Si vous n'êtes pas d'accord avec cet avis, vous pouvez suggérer des modifications, mais c'est tout. Opiniâtre ne fait pas de mal.

4. J'utilise RxUI avec Caliburn Micro. CM poignées View-ViewModel emplacement et de la liaison, l'Écran et les Conducteurs. Je n'utilise pas de CM de la convention liant. RxUI gère les Commandes et les ViewModel INPC code, et me permet de réagir à des modifications de la propriété à l'aide de Réactif au lieu de l'approche traditionnelle. En gardant ces choses je trouve ça beaucoup plus facile de mélanger les deux ensemble.

N'importe laquelle de ces questions ont rien à voir avec le fait d'être prêt pour la production? Nope. ReactiveUI est stable, a un décemment de la taille de l'utilisateur de base, les problèmes seront résolus rapidement dans le groupe google et Paul est ouvert à la discussion.

Answer 3

- Je l'utiliser dans la production et la mesure RxUI a été parfaitement stable. L'application a eu des problèmes avec la stabilité, certains avec EMS, d'autres avec un UnhandledException gestionnaire qui provoque plus de problèmes qu'il a des problèmes, mais je n'ai pas eu de problèmes avec la ReactiveUI partie de l'application. Cependant, j'ai eu des questions au sujet de la ObservableForProperty pas de tir à tous, j'ai peut-être mal utilisés et ne fonctionne toujours (à tort) dans mon code de test ainsi que dans l'INTERFACE utilisateur au moment de l'exécution.

-1. Paul explique que la _Upper est due à l'utilisation de la réflexion pour se rendre au domaine privé dans votre classe. Vous pouvez soit utiliser un bloc comme ci-dessous pour traiter la StyleCop et Resharper messages, ce qui est facile à générer (à partir de la Resharper SmartTag)

    /// <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 modifier vos propriétés de l'intégrale

    /// <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 parties composantes, telles 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 l'on ne fait pas de fournir un "simple" propriété de l'accesseur, mais peuvent nécessiter un plus dérivé variante, où la définition d'une valeur affecte plusieurs autres.

-2. Oui la documentation n'est pas l'idéal, mais j'ai trouvé qu'après Rx, ramasser le RxUI échantillons a été assez facile. Je remarque aussi que les sauts à partir de la 2->4 semblent avoir tous viennent avec les changements de prise en charge de Windows 8/Windows 8 Phone, et avoir ramassé ReactiveUI pour une Application du Windows Store, puis le DotNet 4.5 soutien est excellent. c'est à dire l'utilisation de [CallerName] maintenant, signifie que vous simplement cette.RaiseAndSetIFChanged(valeur) pas besoin de l'expression.

-3. Je n'ai pas de commentaires sur la journalisation côté que j'ai décidé de ne pas l'utiliser.

-4. Je n'ai pas mélangé avec d'autres cadres de soit.

Il y a également 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.