MVCとモデル2。コンポーネントの知識と責任

長い間、MVCパターンを研究していました。 私が最初に彼に会ってから1年半以上が経過しましたが、この間、パターンの3つの要素の責任範囲を頭の中で並べ替えることはできませんでした。



MVCは、洗練された、驚くほどエレガントなアーキテクチャソリューションです。 このパターンがなければ、最新のアプリケーションがどうなるか想像できません。



インターネット上では、すべての情報がいくつかの断片に散らばっていますが、今では、1年半の知り合いと終わりのない研究の後、ついに言うことができます。はい、私はこのパターンを広く知っています。



不足しているすべての情報を1か所で収集することにしました。 これが記事を書く理由でした。



tl; dr：結果を読み取ります。 残りは快適になるようお願いします。





Gang of Fourによると、MVCは戦略+リンカー+オブザーバーに過ぎません。 コントローラーとビューは、オブザーバーとしてモデルに登録されます。 ビューは、それ自体でコントローラーを戦略のオブジェクトとして登録し、構成によってその動作を実現します。 モデルは、状態が変化したときにオブザーバーに警告を出します。 ビューはそれ自体に他のビューを埋め込みます。通常、ビューはモデルに依存し、他のコントローラーを介してユーザーに異なる動作を提供します。 これはHMVCではありません。 これはこのジャンルの古典です。



Web開発では、MVCが最も一般的なパターンです。 今日、MVCフレームワークの概念はごく一般的なものであり、コードを3つ以上のコンポーネントに正しく分割するために、これらのフレームワークについて私たちの周りの人々が十分に知っていると信じています。 残念ながら、MVCフレームワークの普及と、ユーザーに開発、アプリケーション開発、およびサポートの容易さを提供しようとする試みにより、基礎となるパターンの基本は失われています。



そもそも、MVCは、モデルの状態の変更中に一定のランタイムが不足しているため、クライアントサーバーアプリケーションには実装できません。 私は特にオブザーバーについて話しています。 モデルを変更した後、ビューを更新しても意味がありません。これは、クライアント上でビューを取得し、モデルはサーバー上にあるためです。 かつて、Java Webアプリケーションのこの問題を解決するために、古き良きMVCに基づいてモデル2パターンが開発されました。



このパターンの本質は、MVCをhttpプロトコルとインターネットの現実に合わせて微調整することです。 このパターンは、コントローラーをユーザーからのリクエストを受け取るオブジェクトと見なしました。 コントローラは、リクエストに基づいてリクエストを解析し、特定のモデルをインスタンス化し、モデルやその他のデータをビューに転送することにより特定のビューを導出する必要があります。 ビュー自体は通常のJSPです。 このモデルは、データベースと通信し、オブジェクト（ORM）のテーブル行を表示するために使用されました。 おなじみのようですね。 また、オブザーバーとリンカーはありません。



よく見ると、これら2つのパターンの違いは非常に大きいです。 コントローラーからビューへのデータの転送は、すでにMVCパターンの重大な違反です。 従来の実装では、ビュー自体はモデルから直接またはコントローラーを介してデータを取得しましたが、多くの場合、コントローラーはユーザーインターフェイスを使用してモデル上のユーザーアクションを処理するために使用されました。 つまり、コントローラーは、ビューの動作です。 奴隷。 マスターではありません。



残念ながら、このアプローチはhttpプロトコルには適していません。 サーバーへの接続が切断され、アプリケーションが動作を停止します。PHPの場合、次のリクエストの前に完全に停止します。



モデル2は、MVCと同様、3つのパターンすべてに固有のものであり、それらの実装のみが「4人のギャング」によって記述された従来のオブジェクト実装とは多少異なります。



リンカーは残りましたが、JSP、PHP、ERBなど、複雑なテンプレートファイルを作成することで実装されています。 しかし、それを操作する方法はほとんどありません。 現在のアプリケーションでは、 Vを部分全体の関係として使用できるとは考えられません。



戦略も消えませんでしたが、誰もが忘れてしまい、コントローラーに新しい役割、つまり要求ハンドラーを与えました。 現在のほとんどのアプリケーションでは、コントローラーは何を、どこで、どのように行うかを決定する神です。 コントローラーはモデルを呼び出し、コントローラーはモデルを保存し、コントローラーはモデルに書き込み、コントローラーはビューを生成し、コントローラーは...わかります。 コントローラーがすべてを行います。 通常の動作から、コントローラーはGodObjectに変わりました。



オブザーバー。 これが最も難しい部分です。 誰もがオブザーバーの仕組みを知っています。 誰もが、単一のhttpリクエストのコンテキストで従来のオブザーバーを実装することがどれほど難しいか、時には愚かであることを知っています。 このパターンは、画面上のデータを更新するように設計されており、Webソケット、長いプーリング、およびその他の魔法がなければ、これを実装するのは非常に困難です。 モデル2では、オブザーバーはコントローラーとビューの両方であり、常にではなく、http要求の後に状態変更の読み取りが行われます。



とても面倒です。 ただし、MVCとモデル2についてこのように話すと、多くのこと自体が成り立ちます。



次に、各コンポーネントの責任について説明します。 私は特定の言語に限定されていないので、本文には「クラス/構造」タイプの組み合わせが存在する可能性があります。これらは現在の異なる言語に関連しています。 私はこの記事がruby（railsl）/ php開発者だけでなく有用であることを望んでいます。 書かれたものはすべて、その構造、python、C＃、Java、そしてもちろんJavaScriptを備えたGolangにも関連しています。



この記事はいくつかのアプローチで書かれています。重複した情報を判断しないでください。

モデル

モデルについて新しいことは何ですか？ たとえば、 この素晴らしい記事では、モデルの本質が完全に明らかにされています。 モデルは状態であり、ビジネスロジックであり、テーブル/ mongoドキュメント/ファイルへの単一のエントリポイントです。 ユーザーのリクエスト間で状態を保存する必要がある場合、モデルがこれを担当します。 オブジェクトのコンテキストで説明する場合、フィールドが必要なのはモデルです。 モデルをステートレスにすることはできません。 モデルは、データの検証と関連性を担当します。



もちろん、UIなしでアプリケーションを記述できるエンティティがある場合、これらはモデルです。

ビューとコントローラー

クラシックMVCでは、ビューは画面に情報を表示する個別のオブジェクトです。 CLIアプリケーションについて説明する場合、これはある種のstdout.println（）です。 Webアプリケーションは、クラシックMVCの代わりにモデル2を使用します。これは、ビューがマークアップと組み込みテンプレートコードを持つ単なるファイルであることを意味します。 一見すると、単純なテンプレートはシステム内でそれほど重要ではないようです。 実際、ユーザーが使用できるアクションを決定するのはビューです。



ビューは、戦略とレイアウトの2つのパターンの一部です。 ビューの動作はコントローラーに実装されています。 コントローラーは特定のアイデアの一部にすぎないことがわかります。 また、特定のビューに対して異なる動作が必要な場合は、別のコントローラーに置き換えることができます。



実際、「魅力的な旅行者」の指をすり抜ける多くの魔法があります。



貪欲なコントローラー



「太いモデル、細いコントローラー」の概念により、コントローラーのアクションを1行に単純化する傾向に気付きました-レンダリング（「ビュー」）を返します。 この結果、ほとんどのアクションとデータサンプリングはビューで直接実行されます。 このアプローチは、ビューに転送されるデータが少ないほど、ビューとコントローラーが互いに独立するようになるという点で議論されています。 単純化は、テンプレートファイルでモデルを直接操作し始めると、不合理になります。 誰もがコントローラーでコードを書くことをとても恐れている理由がわかりません。 1ダースのデータをビューに渡しても、これは私のビューがそれらすべてを使用する必要があるという意味ではありません。 何かを集めて箱に入れ、特定の人に郵送したと想像してください。 これらのことはもう必要ありません。受信者がそれらをどうするかは絶対に重要ではありません。 彼はカップルまたは2つを選択し、残りを投げることができる。 私は自分自身のために「貪欲で怠zyなコントローラー」という言葉を作り出しました。



この記事では、フレームワーク用語のコントローラーアクションはMVC用語のコントローラーであると述べています。 記事自体が素晴らしいという事実にもかかわらず、私はこの声明に強く反対します。 アクションは、ビューに対するユーザーのアクションです。 これは行動の重要な部分です。 アクションを書き換えると、動作は変わりますが、完成したクラスのコードに侵入するため、クラスコードを何も変更しないでください。 コントローラーを交換すると、ビューの動作が変更されますが、戦略の既存のオブジェクトは変更されません。 たとえば、Angular.jsを取り上げます。 コントローラーの開始位置とメソッドの位置を明確にトレースします。 コントローラーメソッドは、ng-click、ng-submitなどのディレクティブを使用して、何らかの方法でプレゼンテーションと対話します。 結論として、コントローラーは本格的なクラスであり、そのメソッド（アクション）は、ユーザーがアプリケーションと対話するビューのアクションです。 ng-controllerディレクティブでコントローラーを置き換える場合、ビューの動作は特定のコントローラーのメソッド（アクション）の実装に応じて変わります。



本当に怖いのは、コントローラーがアプリケーションの中で最も再利用される部分だということです。 なに？ 私にとって、コントローラーは例外的に1回限りのコードです。 アクション（アクション）は再利用できます、私は同意します。 特にCRUDアクションでは、このアクションを関連付けるモデルのクラス/構造を簡単に指定できます。 コントローラでのコードの複製は通常の方法です。なぜなら、それらは微妙であり、すべてのロジックが配線されているモデルのメソッドを引き起こすだけだからです。 異なるコントローラーに対して同じ（またはほぼ同じ）アクションを2回続けて記述する必要がある場合は、ためらうことなくそれを行います。 異なるコントローラーで同じモデルメソッドを呼び出す必要がある場合は、それを行います。 コントローラーは、原則として、表現として破棄して再作成できます。



モデルは捨てるのが難しく、必要ありません。 原則として、モデルインターフェイスは、アプリケーションの開発中またはアプリケーションからアプリケーションへのモデルの転送中に変更されませんが、補足のみです。 ほとんどすべてのアプリケーションのコントローラーとビューは独自のものです。 あるフレームワークから別のフレームワークにコントローラーを移動してみてください。そうすれば、私が話していることを理解できます。 また、モデルをWebアプリケーションからモバイルまたはデスクトップに転送することもできますが、コードを変更することなく（またはほとんどなしで）、好みのテストや遊戯を行うことができます。



コントローラーは、簡単なリファクタリングに役立つはずです。 おそらく、同一のアクションを別々のオブジェクトに削除することは、コントローラーの再利用にすぎませんが、多くの注意を払うほど重要ではありません。 確かに、あらゆる場合に50のアクションクラスではありません。



振る舞いとしてのコントローラー



お気に入りのmp3プレーヤー（スマートフォンのアプリケーションを意味します）を見てみましょう。 ここでのプレゼンテーションは、隣接する曲に切り替えるボタン、停止、再生、プレイリストです。 停止ボタンと損失ボタンでは、すべてが明確であり、コントローラーの変更に応じてそれらの動作が変わるとは思いませんが、曲に切り替えるためのボタンは現在の曲の早送り/巻き戻し用のボタンにすることもできます。 全体として、同じ考えを持って、コントローラーを交換するだけでその動作を変更できます。



携帯電話の音楽再生中のロック画面では、巻き戻しボタンが便利なように構成を変更し、アプリケーション自体では曲を前後に巻き戻すことが想像できます。 また、イベントを介してランタイムでコントローラーを変更できます。 巻き戻しボタンに指を置くイベントは、現在の曲の巻き戻しでコントローラーを起動します。クイックタッチ-コントローラーを起動して、さまざまな曲に切り替えます。 ルーターを思い出させますよね？ 両方のコントローラーで、playアクションとstopアクションの実装が重複していますが、これはパターン戦略にとっては十分に受け入れられます。 そして、両方のコントローラーは同じ表現を使用します。



MVCでは、ビューのコントローラーだけでなく、単一のコントローラーのビューも置き換えることができます。 良い例は、お気に入りのファイルマネージャーにファイルを表示することです：タイル、リスト、テーブルなど。 オンラインストアの店頭のようですね。 まず、ファイルマネージャーをデータプロバイダー、ビュー、および動作（コントローラー）として想像してください。 そして、MVCが現実世界で私たちの周りにどのように適用されるかを見るでしょう。



同じ原則は、単一のインターフェースを備えたメディアセンターでも機能しますが、データのコレクション（写真、音楽、ビデオ）は異なります。 各コレクションは、ビューと動作の両方を変更できます。さらに、同じビューに対して複数の動作（コントローラー）を混在させることができます。 たとえば、ビデオの場合、ビヘイビアは画像（アクションの表示）と音楽（停止、再生、巻き戻し）の両方に適しています。

ウィジェット

ウィジェットは、 Vが意味するすべてのものです。



多くの場合、ウィジェットはシステムの独立したコンポーネントとして扱われます。 同様に、プラグインビューを持つオブジェクトは、 ほとんどコントローラーのようなものです。つまり、コントローラーのような責任を持っています。 はい、いいえ。 多くの場合、彼らはほとんど文字通りそれを取り込んで、モデルに関するすべての作業を貧弱なウィジェットに押し込みます。つまり、リクエストのフィルタリングを除くオーガナイザーのすべての作業です。 ほぼコントローラーですよね？



ウィジェット-神



Yiiの便利なユーザーモジュールを探してGitHubを調べたときに、ウィジェットの責任と知識の問題について考えました。 それ以前は、ウィジェットはカスタムテンプレートであり、ドロップダウンメニュー、Pjaxコンテナー、または同じYiiのGridViewなどのプラグインJavaScriptを使用している可能性がありました。 これに基づいて、データをモデル/モデルのコレクションとして取得し、内部ルール（慣習）および設定（構成）に従ってデータ/モデルを表示するクラスを取得します。 または、モデルではまったく機能せず、ユーザーインターフェイスにデザイン/動作を追加するだけです。



ウィジェットで、モデルを使用して他の操作を直接作成、作成、および実行するのを見たとき、私はショックを受けました。 一方では、LoginFormウィジェットとLoginFormモデルがある場合、クラスを使用して、モデルを操作することによりユーザーを検証し、システムにログインすることが論理的に思えます。 これはほんの数行です。 別のユニバースまたは小さなプロジェクトのどこかにあるかもしれませんが、中規模のプロジェクトまたはモジュール全体では、複数のコードの複製と、性質の異なるコンポーネントの責任の混合が生じます。



そのような設計の一例は、すべてのロジックと表現がウィジェットに埋め込まれているBitrixであり、何らかの未知の理由でコンポーネントと呼ばれます。



さまざまなフレームワークのネット上の同様の例の後、私は「突然これが正しい方法だ」と考えました。 そして、疑念が私の頭に忍び込んだ。 すべてのロジックをウィジェットにプッシュすると、コントローラーは特定のビューの表示のみを処理します。 しかし、これはパターンの重大な違反です。 ウィジェットがVの要素である場合、その中でモデルを操作することはありません。 モデルをインスタンス化することでさえ、コントローラで実行することをお勧めします。保存はもちろんです。



一方、ドロップインとその作業の概念は、ウィジェットの必須の構成には適合しません。 さらに、私は設定よりも規約が本当に好きです。これは、これまでのところ、Railsで「箱から出してすぐに」表現するのが最善だと思います。 その結果、私は次の結論を出しました：インスタンスがウィジェットに転送されず、ウィジェットが特定のモデルと同じ名前である場合にのみ、モデルをウィジェットでインスタンス化できます。 。 しかし、ウィジェットは決してモデルに書き込んだり、モデルを保存したりすることはできません。これはコントローラーのタスクです。



ユーザー入力の処理に関しては、上記のすべてが非常に論理的に思えます。 LoginFormにデータを入力した後、ユーザーを承認してページにとどまる必要がある場合、ウィジェットで直接処理せずにこれを行うにはどうすればよいですか？ 明らかに、これには別個のコントローラーが必要ですが、コントローラーは明示的なリダイレクトを指定しない場合、ユーザーをページから移動させます。 インターネットでは、ほとんどの場合、次の3つのシナリオが使用されます。

1. ユーザーはログインページにリダイレクトされ、エラーが表示される（パスワードが正しくない）か、個人アカウントの認証と表示が行われます。
2. ユーザーはログインページにリダイレクトされ、エラーが表示される（不正なパスワード）または認証が行われ、中間ビューのある（またはない）前/メインページにリダイレクトされます（phpBBなどのフォーラムを思い出してください）。
3. ユーザーはAJAXリクエストを介してログインし、ページに残ります。 承認に依存するすべてのブロック（バスケットなど）は、何らかの種類のPjax.reloadを介して、または単にページをリロードすることによって更新されます。

最初の2つのケースでは、ウィジェットは現在のプレゼンテーションと処理のファサードとしてのみ使用されます。 このオプションは場所です。 最後の例では、ウィジェットは暗黙的にコントローラーに接続されており、構成を介して置き換えることができます。



この場合、ウィジェットは最小限のロジックであり、表示するテンプレートです。 ユーザーが認証されていない場合、フォームを表示します。 許可されている場合、挨拶を表示します。 テンプレート内に他の要素がなければ、 Vで操作する必要はありません。



3つのシナリオはすべて簡単に実装でき、コードの重複は避けられますが、ウィジェットで直接モデルを操作するよりも複雑です。主なことは、間違ったアプローチの単純さに誘惑されないことです。

これは、アプリケーションの各「ページ」に個別のphpファイルを使用する古代の方法と実質的に違いはありません。

さらにウィジェットが必要です！



既製の小さなソリューションが多数あるため、フレームワークは開発者を劣化させます。 事前に定義されたウィジェットの使用を開始し、これらのウィジェットの問題を解決してアプリケーションの設計に何らかの形で適合するようにしていることに気付きましたが、2、3言語でコードのいくつかの行を書く方がはるかに簡単です。



通常のAJAXリクエストで十分な場合でも、再評価されたPJAXがどこにでも表示されます。 フレームワークに収まるようにJavaScriptコンポーネントを作成する人はほとんどいません。 GitHubで、開発者がPjaxまたはそれに関連する他の作業をリロードするのに必要なJavaScriptを議論する方法を何度も見てきました。「JSに邪魔されないように、より多くの設定を標準フレームワークウィジェットに入れる必要があります！」 しかし、PjaxReloaderのような独自のウィジェットを作成するには、テストと一緒に約10分かかります。 正直なところ、私は議論により多くの時間を費やします。

$js = "jQuery(document).on('pjax:success', '#$id', function() { jQuery.pjax.reload('$reloadSelector'); });"; $view->registerJs($js);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ウィジェットは、1つの責任のオブジェクトです。 良い方法では、OOP内のすべてのオブジェクトが1つの義務を負う必要がありますが、現実の世界では常にそうであるとは限りません。 記事のコメントのリストとコメントを追加するためのフォームは、異なるウィジェットです。 1つには他のオプションを含めることができます（オプション）が、混在させないでください。 最後に、 Vがリンカーであることを忘れないでください。 小さなウィジェットを1つの大きなウィジェットに結合できます。 いくつかの大きな1つに巨大。 そして、これはパターンの範囲を超えません。

合計

モデルには状態とビジネスロジックが格納されます。 彼女は自分のサブジェクトエリアに関するすべてを知っています。どのコントローラーを呼び出し、どの表現を表示するかは気にしません。 モデルは、アプリケーションの外部で独立した独立したクラスとしてインスタンス化できます。 モデルはTDDに簡単であるため、すべてのアプリケーションロジックをモデルに格納する必要があります（コンポーネント、サービス、リポジトリなどもモデルであることを思い出します）。



ビューは、モデルに関するすべての情報、さらにその状態（データベース、ファイル、RESTなど）を正確に保存する方法を 完全に把握しています。 ビューは、モデルが保存するフィールド、ビュー用にフォーマットされたプロパティが保存されるフィールドを認識します。 モデルについてアイデアが知らない唯一のことは、記録、変更、保存の方法です。 ビューには、必要なオブジェクトとモデルをインスタンス化し、データプロバイダーを収集する権利がありますが、コードの重複を避けるために、工場、ヘルパー、ウィジェットに持って行くことをお勧めします。



コントローラーは、モデルまたはビューについて何も知りません。 コントローラーは、モデルを呼び出すためのメソッドの種類を知っていますが、現時点でモデルで実際に何が起こっているかを表していません。 コントローラーはモデルでいくつかのアクションを要求しますが、モデルが生成するエラー（つまり、ランタイムエラーと例外）を認識してはならず、それらをインターセプトして処理することはありません。 コントローラーは 、特定のビュー（実際、コントローラーは1つまたは複数のビューの一部であるため）を通じて表示されるモデルを提供できます（ただし、必ずしも必要ではありません）。表示するにはビューが必要です。 彼が何かを送信しなかった場合、プレゼンテーションはこれに適切に応答し、開発中のアプリケーションに関しては自分の一部を表示したり例外をスローしたりしないでください。 コントローラーが処理できる唯一の例外はNotFound 404です！ タイプ403の残りのエラーは、フィルター（要求インターセプター）またはミドルウェアで生成されます。



コントローラは、少なくともデータを読み取るために使用する（またはまったく使用しない）必要があります 。 読書は、ウィジェットと同様のオブジェクトによって整理できます。



ウィジェットにはモデルを操作してデータベースに書き込む権利がありませんが、抽象化、ヘルパー、ファクトリ、モデルクラスを通じてデータベース/ファイルからデータを読み取り、テンプレートに渡すことができます。 ウィジェットは、モデルインスタンスがトップビュー（レイアウトモデル）またはコントローラーから転送されていない場合、自身内でモデルをインスタンス化できます。 これは読み取り操作であるため、ウィジェットはデータプロバイダーを収集できます。



結論として、私はお気に入りのHabréの記事から引用したいだけです。 記事の冒頭のモデルに関するセクションでリンクを提供しました。

一部の人々は、優れた独立したドメインモデルの必要性について話し、混乱を招くコードを書き続けるこれらすべての愚か者を単に笑うでしょう。 彼らを笑わせてください。 結局のところ、混乱を維持し、テストする必要があるのは彼らです。

そして、作曲があなたと共に来ますように！ すべてに良い！