MVCは驚異的なアイデアです。 モデル、独立した状態の部分、UIの別個の部分であるビュー、および別個の部分であるコントローラーがあります...ええと？
なに？
これに気付くのは初めてではありませんが、MVCの問題は、コントローラーに押し込まれているコードが多すぎることです。
これを修正するには、新しいパターン
MOVEを使用します。 モデル、操作、ビュー、およびベント。
復習
詳細については後で説明しますが、この図はMOVEアプリケーションの基本構造を示しています。
- モデルは、アプリケーションが知っている必要があるすべてです。
- アプリケーションが行うのは操作だけです。
- ビューは、アプリケーションとユーザーの間の仲介です。
- イベントは、これらすべてのコンポーネントを安全に接続するために使用されます。
スパゲッティコードを回避するために、推奨事項、オブジェクトの種類、実行する権利があることに注意してください。 図に矢印で示しました。 たとえば、ビューはモデルによってトリガーされたイベントをリッスンできます。 操作はモデルの変更を許可されますが、モデルは表現または操作を示すべきではありません。
モデル
典型的なモデル、ユーザーオブジェクト。 メールと、場合によっては名前と電話番号があります。
MOVEアプリケーションでは、モデルは単なるデータラッパーです。 つまり、ゲッターとセッターに加えて、「これはユーザーのパスワードですか？」をチェックできる機能を含めることができますが、データベースにデータを保存したり、サードパーティAPIにロードしたりする機能は含めません。 これが「オペレーション」の仕事です。
運営
アプリケーションの一般的な操作：ユーザー認証。 これらは実際には2つのサブオペレーションを組み合わせたものです。1つ目はユーザーから電子メールとパスワードを取得し、2つ目はデータベースから「ユーザー」モデルを読み込み、パスワードの一致を確認します。
オペレーションは、MOVEの世界のパフォーマーです。 モデルの変更を担当し、適切なタイミングで正しいビューを表示し、ユーザーの操作によってトリガーされたイベントに応答します。 適切に構築されたアプリケーションでは、親に関係なく各サブ操作を開始できます。 そのため、上の図では、イベントはアウトバウンドになり、変更は下降しています。
興味深いことに、この方法で操作を使用すると、アプリケーション自体を、アプリケーションの起動時に開始するアクションと見なすことができます。 必要な数のサブ操作を生成します。同時に既存のサブ操作が同時に起動され、すべてのイベントが完了するとプログラムが終了します。
視聴回数
ログイン画面は、ユーザーに複数のテキストフィールドを表示するためのビューです。 ユーザーがログインボタンをクリックすると、ビューは、ユーザーが入力したユーザー名とパスワードを含む「loginAttempt」イベントを生成します。
ユーザーが表示または操作できるものはすべて、ビューに実装する必要があります。 アプリケーションの状態を理解可能な形式で表示するだけでなく、理解可能なイベントでのユーザーインタラクションのストリームでもあります。 重要なことは、ビューはモデルを直接変更せず、操作でイベントを発生させ、モデルによってトリガーされたイベントをリッスンすることで変更を待機することです。
イベント
ユーザーがログインボタンをクリックすると、loginAttemptイベントがビューを起動します。 さらに、ログイン操作が完了すると、currentUserモデルがイベントを発生させて、アプリケーションに変更が通知されます。
イベントをリッスンすると、MOVE（およびMVC）の制御の逆（IoC）が得られ、モデルが更新するビューを明示的に示すことなくビューを更新できるようになります。 これは、コンポーネントが互いに干渉することなく接続できるようにする強力な抽象化技術です。
どうして今？
私は誤解されたくありません。MVCが悪いことを意味します。 過去10年間、それは大規模なアプリケーションを構築するための非常に成功した方法でした。 しかし、それが造られた時点で、新しいプログラミング技術が一般的になりました。 クロージャ（または匿名ブロック）がなければ、イベントの割り当ては面倒です。 また、遅延可能オブジェクト（遅延または約束とも呼ばれます）がなければ、個々の操作をオブジェクトとして理解するという考え自体はあまり意味がありません。
MVCはクールですが、10年前にテクノロジーを使用して設計されています。 MOVEは、現在のツールをより適切に使用するための更新プログラムです。