ReactiveUIの概要：ViewModelのポンピングプロパティ

私のC＃プロジェクトでは、GUIを実装するときに、ReactiveUIフレームワークをよく使用します。



ReactiveUIは本格的なMVVMフレームワークです。バインディング、ルーティング、メッセージバス、コマンドなど、ほぼすべてのMVVMフレームワークの説明にある他の単語があります。 WPF、Windowsフォーム、UWP、Windows Phone 8、Windowsストア、Xamarinなど、.NETが存在するほぼすべての場所で使用できます。



もちろん、あなたがすでにそれを使った経験があれば、ここであなた自身のために何か新しいものを見つけることはまずありません。 この記事では、ViewModelでのプロパティの操作に関する基本的な機能に精通し、将来、他のより興味深い複雑な機能に到達することを望んでいます。

はじめに

ReactiveUIはリアクティブプログラミングモデルを中心に構築され、 Reactive Extensions （Rx）を使用します。 ただし、リアクティブプログラミングガイドを作成するという目標は設定していません。必要な場合にのみ、その仕組みを説明します。 すぐに、基本的な機能を使用するために、それがどんな怪物であるかを掘り下げる必要さえないことがわかります：リアクティブプログラミング。 あなたはすでに彼に精通していますが、イベントはそれだけです。 通常、「反応性」が現れる場所でさえ、コードは非常に簡単に読み取られ、何が起こるかを理解できます。 もちろん、ライブラリ（およびReactive Extensions）を最大限に使用する場合、リアクティブモデルに真剣に精通する必要がありますが、ここでは基本を説明します。



個人的には、ReactiveUIの直接的な機能に加えて、控えめな機能が気に入っています。他の機能に注意を払ったり、アプリケーションをフレームワークに合わせたりせずに、機能の一部のみを使用できます。 たとえば、非互換性を超えて実行することなく、他のフレームワークと並行して適用します。 かなり快適です。



軟膏にハエがあります。 彼女の名前はドキュメントです。 彼女のすべてが非常に悪いです。 何かがここにありますが、多くのページは単なるスタブであり、すべてが非常に乾燥しています。 ここにはドキュメントがありますが、問題は同じです：スタブ、開発者のチャットからのコピーペースト、さまざまなソースのサンプルアプリケーションへのリンク、将来のバージョンの機能の説明など。 開発者はStackOverflowの質問に答えるのに非常に積極的ですが、通常のドキュメントがあれば多くの質問はありません。 しかし、そうではないのはそうではありません。

議論されること

詳細に移りましょう。 この記事では、ViewModelsのプロパティに関する一般的な問題と、ReactiveUIでの解決方法について説明します。 もちろん、この問題はINotifyPropertyChangedインターフェイスです。 何らかの方法で何らかの形で解決される問題。



従来の実装を見てみましょう。

private string _firstName; public string FirstName { get { return _firstName; } set { if (value == _firstName) return; _firstName = value; OnPropertyChanged(); } } public event PropertyChangedEventHandler PropertyChanged; protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null) { PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何の問題？ はい、いいえ。 まあ、セッターの3行、それは問題ではありません。 一般に、私は通常、自動プロパティを記述し、身体の動きを最小限に抑えたリゾルバを使用して自動リファクタリングを行います。



しかし、まだ問題があります。 FirstNameを変更するときにFullNameプロパティを同期する必要がある場合はどうなりますか？ これには2つのオプションがあります。これは計算プロパティであり、変更に関するイベントを生成する必要があるか、FirstNameと同様に実装する必要があり、変更する必要があります。 最初のバージョンでは、FirstNameプロパティセッターは必要な通知を生成します。

 set { if (value == _firstName) return; _firstName = value; OnPropertyChanged(); OnPropertyChanged(nameof(FullName)); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目では、プロパティの更新が呼び出され、通知自体が生成されます。

 set { if (value == _firstName) return; _firstName = value; OnPropertyChanged(); UpdateFullName(); } private void UpdateFullName() { FullName = $"{FirstName} {LastName}"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まだ比較的単純に見えますが、それは地獄への道です。 LastNameもあり、FullNameも変更する必要があります。 次に、入力した名前で検索を固定すると、すべてがさらに複雑になります。 そして、別の、別の...そして、コードの連続的な生成イベントで、多くのアクションがセッターから起動され、考えられるすべての実行パスが考慮されていないか、何かが呼び出されていないという事実のためにいくつかのエラーが発生する状況にありますその順序、および他の悪夢。



そして一般的に、なぜFirstNameプロパティはFullNameがどこかにあること、そして名前で検索を実行する必要があることを知っているのでしょうか？ これは彼の関心事ではありません。 これを変更して報告する必要があります。 はい、あなたはこの方法でそれを行うことができ、あなた自身のPropertyChangedイベントに固執して追加のアクションを呼び出すことができますが、これにはあまり喜びはありません-手で、行に来る変更されたプロパティの名前でこれらのイベントを分解してください

そして、冒頭に示した単純な実装は、いらいらし始めます。ほとんど同じコードで、まだ読まなくてはなりません。

ReactiveUIは何を提供しますか？

宣言的で依存関係を整理します。



Nugetからインストールします。 「reactiveui」を探しています、現在のバージョン6.5.0を置きます。 それでは、利用可能な更新プログラムのリストに移動し、そこに表示されたSplatを最新バージョン（現在は1.6.2）に更新しましょう。 これがなければ、ある時点で、すべてが落ちました。



フレームワークをインストールしたので、最初の例を少し改善してみましょう。 まず、ReactiveObjectから継承し、プロパティセッターを書き換えます。

  public class PersonViewModel : ReactiveObject { private string _firstName; public string FirstName { get { return _firstName; } set { this.RaiseAndSetIfChanged(ref _firstName, value); UpdateFullName(); } } private string _lastName; public string LastName { get { return _lastName; } set { this.RaiseAndSetIfChanged(ref _lastName, value); UpdateFullName(); } } private string _fullName; public string FullName { get { return _fullName; } private set { this.RaiseAndSetIfChanged(ref _fullName, value); } } private void UpdateFullName() { FullName = $"{FirstName} {LastName}"; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まだ厚くない。 このようなRaiseAndSetIfChangedは、手で書くことができます。 しかし、ReactiveObjectがINPCだけでなく実装していることをすぐに言っておく価値があります。







ここでは、特にINotifyPropertyChanged、INotifyPropertyChanging、およびいくつかの3つのIObservable <>の実装を確認します。

リアクティブモデルの詳細を読む

ここでは、それがどのようなIObservableであるかについていくつかの言葉を言う価値があります。 これらはプッシュベースの通知プロバイダーです。 原理は非常に単純です：古典的なモデル（プルベース）では、データプロバイダーに対して実行し、更新のためにポーリングします。 事後対応-このような通知チャンネルに登録し、調査について心配する必要はありません。すべての更新は私たち自身に届きます：

 public interface IObservable<out T> { IDisposable Subscribe(IObserver<T> observer); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

IObserver <>として動作します-オブザーバー：

  public interface IObserver<in T> { void OnNext(T value); void OnError(Exception error); void OnCompleted(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OnNextは、次の通知が表示されたときに呼び出されます。 OnError-エラーが発生した場合。 OnCompleted-通知が終了したとき。

新しい通知はいつでも登録解除できます。このため、SubscribeメソッドはIDisposableを返します。 Disposeを呼び出します-新しい通知はありません。



これで、ChangedをサブスクライブしてFirstNameを変更すると、OnNextメソッドが呼び出され、パラメーターはイベントPropertyChangedと同じ情報（つまり、送信者とプロパティの名前への参照）を持ちます。



また、ここでは多くのメソッドを自由に使用できますが、その一部はLINQからのものです。 すでに試したものを選択してください。 さらに何ができますか？ Whereを使用して通知のストリームをフィルター処理し、Distinct繰り返し通知またはDistinctUntilChangedを作成して同じ連続通知を回避し、Take、Skipおよびその他のLINQメソッドを使用します。





ここで、これらすべての通知を時間内に移動して、何が機能するかを確認できます。



かなり簡単に判明しましたが、今のところこれで十分だと思います。 詳細については、たとえばhereまたはhereを参照してください 。

ReactiveUIを使用してプロパティをバインドする

問題のあるコードの改善に戻りましょう。 依存関係を整理しましょう：

 public class PersonViewModel : ReactiveObject { private string _firstName; public string FirstName { get { return _firstName; } set { this.RaiseAndSetIfChanged(ref _firstName, value); } } private string _lastName; public string LastName { get { return _lastName; } set { this.RaiseAndSetIfChanged(ref _lastName, value); } } private string _fullName; public string FullName { get { return _fullName; } private set { this.RaiseAndSetIfChanged(ref _fullName, value); } } public PersonViewModel(string firstName, string lastName) { _firstName = firstName; _lastName = lastName; this.WhenAnyValue(vm => vm.FirstName, vm => vm.LastName).Subscribe(_ => UpdateFullName()); } private void UpdateFullName() { FullName = $"{FirstName} {LastName}"; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

見て、プロパティには余分なものは含まれていません。すべての依存関係は1つの場所、つまりコンストラクターで記述されています。 ここでは、FirstNameとLastNameの変更をサブスクライブし、何かが変更されたときにUpdateFullName（）を呼び出します。 ところで、次のことができますが、少し異なります。

 public PersonViewModel(...) { ... this.WhenAnyValue(vm => vm.FirstName, vm => vm.LastName).Subscribe(t => UpdateFullName(t)); } private void UpdateFullName(Tuple<string, string> tuple) { FullName = $"{tuple.Item1} {tuple.Item2}"; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通知パラメーターは、現在のプロパティ値を含むタプルです。 フルネームを更新するメソッドにそれらを渡すことができます。 更新方法は通常、次のように削除して実行できますが、

 this.WhenAnyValue(vm => vm.FirstName, vm => vm.LastName).Subscribe(t => { FullName = $"{t.Item1} {t.Item2}"; });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もう一度FullNameを見てみましょう。

 private string _fullName; public string FullName { get { return _fullName; } private set { this.RaiseAndSetIfChanged(ref _fullName, value); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には名前の一部に完全に依存し、読み取り専用である必要があるのに、おそらく可変プロパティが必要なのはなぜですか？ これを修正しましょう：

 private readonly ObservableAsPropertyHelper<string> _fullName; public string FullName => _fullName.Value; public PersonViewModel(...) { ... _fullName = this.WhenAnyValue(vm => vm.FirstName, vm => vm.LastName) .Select(t => $"{t.Item1} {t.Item2}") .ToProperty(this, vm => vm.FullName); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ObservableAsPropertyHelper <>は、出力プロパティの実装に役立ちます。 内部はIObservableで、プロパティは読み取り専用になりますが、変更が行われると通知が生成されます。



ちなみに、LINQから来たものに加えて、IObservable <>には、Throttleなどの他の興味深いメソッドがあります。

 _fullName = this.WhenAnyValue(vm => vm.FirstName, vm => vm.LastName) .Select(t => $"{t.Item1} {t.Item2}") .Throttle(TimeSpan.FromSeconds(1)) .ToProperty(this, vm => vm.FullName);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通知はここで破棄され、1秒以内に以下が続きます。 つまり、ユーザーが名前入力フィールドに何かを入力する限り、FullNameは変更されません。 彼が少なくとも1秒間停止すると、氏名が更新されます。

結果

プロパティ間の関係が1つの場所で宣言的に記述されているViewModelを取得しました。 これは私にとって素晴らしい機会のように思えます。これらのプロパティまたはこれらのプロパティが変更されたときに何が起こるかを理解しようとして、コード全体をシャベルする必要はありません。 副作用はありません-すべてが明らかです。 もちろん、これらすべての操作の結果はパフォーマンスの低下です。 深刻な問題ではありませんが、これはシステムのコアではなく、可能な限り生産的である必要がありますが、ViewModelレイヤーです。



誰かがこの記事が有用で興味深いものになり、プロジェクトで説明されているテクノロジーを使用してみてください。 将来的には、リアクティブコレクションやコマンドなどについて説明し、ViewレイヤーとViewModelレイヤー間の相互作用、ルーティング、ユーザーの相互作用を示すより複雑な例に取り掛かりたいと考えています。



ご清聴ありがとうございました！