「新しい」Model-View-Intentアーキテクチャと、MVCやMVVMのような「古い」アーキテクチャとの違いはありますか？
MVIはどの問題に対処しますか？MVC / MVVMとの類似点は何ですか？違いは何ですか？
MVC / MVV / MVPのスタックオーバーフローにはすでに同様の質問がありますが、これまでのところMVIを説明する質問はありません。
回答:
私の経験から、それらの各アーキテクチャパターンは、前の問題が無視するか、まだ観察されていない特定の問題を解決するために発明されました。
MVC-モデルビューコントローラー
UIアプリケーションでは、データを画面に表示する責任、またはビジネスロジックを最初にそれらにバインドする責任が明確ではありませんでした。したがって、MVCは3つのコンポーネントに対する責任を定義するようになりました。それぞれに1つの目的があり、図はこれら3つのコンポーネント間の関係を説明しています。
ビュー-色、形状、クリックイベントをリッスンするツールなどのすべてのプロパティを持つUIコンポーネントです。
モデル-ビューにレンダリングして適切に動作させるビジネスロジックを定義するコンポーネントです。
コントローラ-モデルを変更する人です。たとえば、ビューに保存する名前がある場合、ビューはそれをコントローラに渡し、コントローラは適切なアクションでモデルを操作します。
MVP-モデルビュープレゼンター
MVCの問題で、3つのコンポーネント間に大きな結合があるため、ビューの呼び出しを変更する場合は、コントローラーとモデルを更新する必要があります。これはMVCの図から明らかです。3つのコンポーネント間の関係は非常に緊密であり、これらのコンポーネントの1つを他のコンポーネントなしで置き換えることはできません。したがって、MVPは、モデルとビューを分離し、Presenterを介してそれらの間の相互作用を維持することにより、以前の問題によりクリーンなソリューションを提供するようになりました。Presenterは、ビューとモデルがそれぞれ呼び出す中間者です。したがって、お気に入りの映画のリストを保存する場合は、View listen to user（*）アクションを実行し、モデルを更新するpresenter関数を呼び出します。次に、モデルがそれを成功したかどうかをPresenterに通知し、PresenterがViewに正しいメッセージ。
MVVM-モデルビューViewModel
リアクティブパラダイムの台頭により、変更を観察してそれに基づいて動作するだけで、UIアプリケーションにさらに個別の懸念を提供できることが明らかになりました。したがって、たとえば、最新のテレビ番組を取得するためにAPIを呼び出す必要があるビューのクリックがあります。
このビューのクリックはViewModelで観察され、ViewModelはモデルと対話してデータを取得し、最後にViewModelが他のオブザーバーを使用してそれらのデータをビューにポストします。
つまり、ViewはViewModelを観察してUIの更新を取得し、ViewModelはViewを観察してモデルで適切なアクションを呼び出します。オブザーバーパターンは、分離ロジックでの価値があることが証明されているので、ここで新しいパターンに進みます。
したがって、最も一般的なアーキテクチャパターンについて説明した後、それぞれがビジネスコードからUIコードを分離しようとしました。ただし、以前のパターンは、異なる状態でのUIの更新を同時に制限しません。
読み込みに関連する問題が発生し、同時にエラーメッセージが表示される場合は、私が話していることを理解しているので、UIの状態を維持するには、間違った記述を調べてそれらを引き起こしていることを調べる必要があります一種の問題。
MVI-モデルビューインテント
MVIは有限状態マシンと呼ばれる古いアイデアに基づいています。システムまたはコンポーネントには予測可能な状態セットがあり、有限状態マシンです。MVIでは、UIの更新は新しい状態によって定義されます。これは圧倒的ですが、UIが変更されるたびにスクリーンショットがあることを想像してください。それが状態です。状態の問題をデバッグ、テスト、再現できます。
これを実現する方法は、実際にはMVIです。 UIとのユーザーインタラクションは、インテントによってMVIで定義されます。インテントは、このアクションからユーザーが必要とするものです。映画にスターを付けたり、画面を更新したり、画面を開いたりすることさえできます。その場合、インテントは必要なすべてのデータを画面に表示する最初の意図。
どのコンポーネントがこれらのインテントに基づいて動作するか、どのような定義を行うか、PresenterやViewModelを使用できますが、MVIは新しい中間コンポーネントを使用するよりも実践です。
ViewModelを続行します。ViewModelはこれらのインテントを取得し、呼び出すユースケースを決定します（モデルの動作）。
ビューに反映する必要がある状態を決定するすべてのユースケースは、ViewModelのsummer関数によって渡され、以前の状態も提供するため、画面を更新するための以前の状態と新しい状態があり、レンダリングの更新が少なくなります。 、およびビューは、それ自体を更新するための新しいヒントのみを取得します。
最後に、MVIは単方向フローであり、ビューで始まり、ビューで終わります。
...ビュー-> ViewModel / Presenter->モデル->ビュー-> ...
MVIは状態の管理方法が異なり、より安定したテスト可能なアプリを構築するためのいくつかのアイデアの組み合わせです。
本当に素晴らしい内訳がここにあります：https : //academy.realm.io/posts/mvc-vs-mvp-vs-mvvm-vs-mvi-mobilization-moskala/。中核となるのは、MVIがMVVM（ステートレスUI状態）のアイデアを取り入れ、ビジネスロジックとモデルを分離し、その上にリアクティブフレームワークを配置することです。個別のアクションではなくイベントのストリームを作成し、プレゼンテーション要素ではなく変換されたストリームの受信要素をコンシューマーにし、非常に構造化された方法で明示的に操作される読み取り専用の使い捨て可能なものを状態にします。
これには、アプリケーション、特にUI / Viewの部分を機能的なアプローチで作成する必要があります。状態は変更されません。新しい状態は、インテントと一連のユースケースから計算されます。これについては、https：//proandroiddev.com/mvi-a-new-member-of-the-mv-band-6f7f0d23bc8aでかなりよく説明されています。
これは、明示的に管理する必要のあるクライアント側の状態が重要なものとなっている、現代のUIアプリケーションの複雑化に対処することを目的としています。ほとんどの経験豊富なプログラマーが知っているように、最も複雑な障害は、予期しない方法で変更されている状態が原因です。この状態操作により、アプリケーションが処理できない「無効な」状態になる可能性があり、これは事実上クラッシュしたアプリケーションです。MVIは、システムが無効な状態になることがなく、状態が常に理解できるように、状態遷移を明示的かつ注意深く構成することにより、これに対処します。