ReactiveX、モバイルアプリのアーキテクチャとレイヤーについて

Question

私はRx（特にRxSwift）を学んでおり、アーキテクチャ、レイヤー、境界について質問があります。

私は通常、MVPまたはVIPER上の階層化されたアーキテクチャ（データ、ドメイン、プレゼンテーション）に慣れています。このプロジェクトでは、Reactiveアプリケーションの推奨アーキテクチャであるMVVMを使用しています。これらは、私の現在の協力者です：

**** Presentation ****************************************** 

       ________________________ 
       |      | 
       | GameViewController | 
       |      | 
       |  ____________  | 
       |  |   |  | 
       |  | BoardView |  | 
       |  |____________|  | 
       |      | 
       |________________________| 
          | 
          | 
          \|/ 
       ________________________ 
       |      | 
       |  GameViewModel  | 
       |________________________| 
          | 
**** Domain **************** | ***************************** 
          \|/ 
       ________________________ 
       |      | 
       |  GameController  | 
       |________________________| 

ユーザーがタップ（移動します）BoardViewがいるかどうかを確認するためにGameControllerと通信でメソッドを呼び出しますGameViewControllerによって観察されているイベントを、発します移動が正しいとし、チェーン内の各イベントで別のイベントが発生し、最後にBoardViewが移動の正確性に従ってその内容を描画します。

私の質問は、この流れは正しいですか？このようなやり方に固執しなければならないのですか、それともより良い対応方法がありますか？たとえば、おそらくBoardViewは、ビューコントローラが関与せずに、ビューモデルに直接話すことができ、境界の破損や「ルール違反」はありません。

私はRxアーキテクチャの面で少し失われていますが、MVVMはシンプルですが、SOLIDにするためにはより多くの共同作業者を作成しなければならず、オブザーバブルのチェーンが少し工夫される可能性があります。

本当にありがとうございます！ありがとう:)

Answer 1

あなたのロジックは、オブジェクトではなくステートレスな（静的な）関数にカプセル化される傾向があります。したがって、コードをより宣言的にする。

例として、GameViewModelは、観察する入力オブザーバの数を受け入れ、ビューを購読するための出力オブザーバの数を生成する必要があります。

struct MyViewModel { 
    let output: Observable<OutState> 
    init(input: Observable<InState>) { 
     output = input.map { 
      // transform input state into output state 
     } 
    } 
} 

変換が純関数であることに注意してください。また、オブジェクトそのものは余分であることに注意してください。それは容易に関数である可能性があります。

func myOutput(input: Observable<InState>) -> Observable<OutState> { 
    return input.map { 
     // transform input state into output state 
    } 
} 

この変換ブロックは、もちろん関数そのものになります。

func transform(in: InState) -> OutState { 
} 

テストするのが簡単で、アプリケーションの特定のユースケースを自然にカプセル化します。

Answer 2

通常、データ駆動アーキテクチャ（MVVMなど）を使用する場合は、ビジネスロジックを満たす複数のオブジェクトがあります（MVVMなど）。あなたのサービスとサービスを購読しているRxの世界ではDTOsをあなたのコントローラにプッシュし、どこにそれをViewModelにマップします。 の場合ViewModelはDTOのデコレータであり、異なるビューで受け入れることができるため、実際にSOAを調べることをおすすめします。ビジネスロジックをサービスに含める必要があります。

Rxは単純にプッシュインターフェイスのコレクションであり、オブジェクトのカプセル化と自己完結を可能にする時間による変換です。コントローラが決定したときにデータを引き出す代わりに、Rx手法を使用すると、ビジネスロジックが必要なときにオブジェクトがそのデータを提供できるようになります。 Rxを使用している場合、すべてのビジネスロジックシナリオでMVVMまたはVIPERの100％フィッティングルールを定義することはできません。ちょうど常識を使用して、あなたのオブジェクトが受信時に情報をプッシュするのは当然のことです。

補足：方法論を定義するデータ駆動型オブジェクト（MVVMまたはVIPER）から離れることをお勧めします。 Here is why。