41

プロダクション コードで Reactive UI を使用する可能性を調べてきました。一部の機能は非常に魅力的ですが、このライブラリに依存することに懸念があります。これらには以下が含まれます:

  1. 風変わりなネーミングと慣習。たとえば、小文字で始まる保護されたメンバーであり、RaiseAndSetIfChangedメソッドはアンダースコアで始まるプライベート メンバーに依存します。Paul Betts (ReactiveUI の作成者) が Ruby のバックグラウンドを持っていることは理解しています。ただし、(Stylecop による) 標準の命名が私のプロジェクト全体に適用されるため、これは私にとって実際の問題を引き起こします。強制されなかったとしても、これが原因でネーミングに矛盾が生じることを懸念しています。

  2. ドキュメント/サンプルの欠如。いくつかのドキュメントと孤独なサンプルがあります。ただし、ドキュメントは一連の (古い) ブログ投稿にすぎず、サンプルはライブラリの V2 に基づいています (現在は V4 にあります)。

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

    とにかく、ここでの私の関心は、ライブラリの全体的な設計です。これに噛まれた人いますか?

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

本番環境でリアクティブ UI を使用した経験のある人はいますか? もしそうなら、あなたは私の上記の懸念のいずれかを緩和または対処することができますか?

4

3 に答える 3

34

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

#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ライト」と考えてください。

于 2013-01-21T21:42:09.330 に答える
13

私は、いくつかの本番システムで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グループですばやく解決され、Paulは議論を受け入れます。

于 2013-01-22T00:42:36.263 に答える
5

私は本番環境で使用していますが、これまでのところ 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 を採用したことで、DotNet 4.5 のサポートが優れていることにも注意してください。つまり、[CallerName] を使用すると、単純に this.RaiseAndSetIFChanged(value) 式が不要になります。

-3. 使用することを選択していないため、ロギング側に関するフィードバックはありません。

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

http://blog.paulbetts.org/index.php/2012/12/16/reactiveui-4-2-is-released/には、Phil Haack を含むReactiveUI 4.2 への他の貢献者のリストもあります。

于 2013-01-21T13:48:50.250 に答える