web-dev-qa-db-ja.com

ReactiveUI Productionは準備ができていますか？

私は本番コードでリアクティブUIを使用することの実現可能性を調査してきました。いくつかの機能は本当に魅力的ですが、私はこのライブラリに依存することに懸念を抱いています。これらには以下が含まれます：

  1. 奇抜な命名と慣習。たとえば、小文字で始まる保護されたメンバー、およびRaiseAndSetIfChangedメソッドは、アンダースコアで始まるプライベートメンバーに依存します。 Paul Betts（ReactiveUIの作者）がRubyの背景を持っていることを理解しているので、それが奇妙な命名の由来だと思います。しかし、これは私にとって本当の問題を引き起こします。 Stylecop）は私のプロジェクト全体で実施されています。実施されていなくても、名前の不一致が原因で発生するのではないかと心配しています。
  2. ドキュメント/サンプルの欠如。 someドキュメントと孤独なサンプルがあります。ただし、ドキュメントは一連の（古い）ブログ投稿であり、サンプルはライブラリのV2に基づいています（現在はV4になっています）。

  3. 部分的に奇妙なデザイン。たとえば、ロギングは、特定のロギングフレームワークに依存しないように抽象化されています。けっこうだ。ただし、（NLogではなく）log4netを使用しているため、独自のアダプターが必要になります。 IRxUIFullLoggerを実装する必要があると思います。これには、メソッドのメトリッククラップロードが含まれています（50をはるかに超えています）。非常に単純なインターフェイスを定義してから、ReactiveUI内に拡張メソッドを提供して、必要なすべてのオーバーロードを容易にするのが、はるかに優れたアプローチだと思いました。さらに、NLogアセンブリが依存するこの奇妙なIWantsToRegisterStuffインターフェイスがあり、私は依存できません（これは内部インターフェイスであるため）。私はそれを必要としないことを望んでいます...

    とにかく、ここでの私の懸念は、ライブラリの全体的なデザインです。誰かがこれに噛まれたことがありますか？

  4. 私はすでにMVVMLightを広範囲に使用しています。 Paulがブログ投稿を行って、技術的に両方を使用できると説明していることは知っていますが、私の懸念は保守性にあります。両方がコードベースに混在していると、ひどく混乱するのではないかと思います。

本番環境でReactiveUIを使用した経験のある人はいますか？もしそうなら、あなたは私の上記の懸念のいずれかを和らげるか、対処することができますか？

wpfmvvmreactiveui
39
Kent Boogaart

あなたの懸念を少しずつ見ていきましょう：

＃1。 「奇抜な命名と慣習。」

ReactiveUI 4.1以降にCallerMemberNameが含まれるようになったので、規則を使用する必要はまったくありません（それでも、RxApp.GetFieldNameForPropertyFuncを介して規則をオーバーライドできます）。プロパティを次のように記述します。

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

＃2。ドキュメント/サンプルの欠如

これは合法ですが、ここにいくつかのドキュメント/サンプルがあります：

＃3。 「はるかに優れたアプローチは、非常に単純なインターフェイスを定義してから、ReactiveUI内に拡張メソッドを提供して、必要なすべてのオーバーロードを容易にすることだと思いました。」

代わりにIRxUILoggerを実装しますが、2つのメソッドはほとんどありません：）ReactiveUIが残りを埋めます。 IRxUIFullLoggerは、必要な場合にのみ存在します。

「さらに、この奇妙なIWantsToRegisterStuffインターフェースがあります」

これについて知る必要はありません:)これは、ReactiveUIがそれ自体を初期化するのを処理するためだけのものであるため、定型コードを用意する必要はありません。

  1. 「両方がコードベースに混在していると、恐ろしく混乱するだろうと思います。」

あんまり。 「スーパーパワーを備えたMVVMライト」と考えてください。

33
Ana Betts

私は、いくつかの本番システムでReactiveUIを使用し、RxUIの処理方法に問題があり、問題を修正するためのパッチを提出した人として回答しています。

免責事項：私はRxUIのすべての機能を使用しているわけではありません。その理由は、これらの機能の実装方法に同意できないからです。変更内容について詳しく説明します。

  1. ネーミング。これも変だと思いました。これは、私が実際には使用しない機能の1つになりました。 PropertyChanged.Fodyを使用して、AOPを使用して変更通知を織り込みます。その結果、私のプロパティは自動プロパティのように見えます。

  2. ドコ。はい、もっとあるかもしれません。特にルーティングのような新しいパーツでは。これが、私がすべてのRxUIを使用しない理由である可能性があります。

  3. ロギング。私は過去にこれに問題がありました。 プルリクエスト69 を参照してください。結局のところ、私はRxUIを非常に意見の分かれるフレームワークと見なしています。その意見に同意しない場合は、変更を提案できますが、それだけです。意見はそれを悪くしません。

  4. CaliburnMicroでRxUIを使用しています。 CMは、View-ViewModelの場所とバインディング、画面とコンダクターを処理します。 CMのコンベンションバインディングは使用していません。 RxUIはコマンドとViewModelINPCコードを処理し、従来のアプローチの代わりにReactiveを使用してプロパティの変更に対応できるようにします。これらを別々に保つことで、2つを混ぜ合わせるのがはるかに簡単になります。

これらの問題のいずれかは、本番環境の準備ができていることと関係がありますか？いいえ。 ReactiveUIは安定しており、適切なサイズのユーザーベースがあり、問題は google group ですぐに解決され、Paulは議論を受け入れます。

12
Cameron MacFarland

私はそれを本番環境で使用していますが、これまでのところRxUIは完全に安定しています。アプリケーションには安定性の問題があり、EMSに関係するものもあれば、UnhandledExceptionハンドラーに問題があり、解決するよりも多くの問題を引き起こしていましたが、アプリケーションのReactiveUI部分に問題はありませんでした。ただし、ObservableForPropertyがまったく起動しないという問題がありました。これは、誤って使用し、テストコードと実行時のUIで一貫して（誤って）機能した可能性があります。

-1。 Paulは、_Upperは、リフレクションを使用してクラスのプライベートフィールドに到達するためであると説明しています。以下のようなブロックを使用して、（Resharper SmartTagから）簡単に生成できるStyleCopメッセージと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;
    ....

またはプロパティを完全から変更します

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

のようなその構成部品に

    /// <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);
            }
        }
    }

このパターンは、実際には「単純な」プロパティアクセサーを提供しない場合にも役立ちますが、1つの値を設定すると他の複数の値に影響する、より派生したバリアントが必要になる場合があります。

-2。はい、ドキュメントは理想的ではありませんが、Rxの後、RxUIサンプルを取得するのは非常に簡単であることがわかりました。また、2-> 4からのジャンプはすべて、Windows 8/Windows 8 Phoneをサポートするための変更が加えられたようであり、Windowsストアアプリ用のReactiveUIを選択したので、DotNet4.5のサポートは優れています。つまり、[CallerName]を使用するということは、単にthis.RaiseAndSetIFChanged（value）式が不要であることを意味します。

-3。私はそれを使用することを選択しなかったので、ロギング側についてのフィードバックはありません。

-4。私は他のフレームワークと混合したり一致させたりしていません。

ReactiveUI 4.2への他の貢献者のリストも http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/ にあります。フィル・ハーク。

5
AlSki