MVCのM：モデルが誤解され、過小評価される理由（翻訳）

（記事は非常に古く、この記事で提起された質問によると、この日に関連しており、さまざまな議論で定期的に提起されています）



皆さんの多くは、私がZend Frameworkに関する本を書いていることにおそらく気づいているでしょう。 私は最近、「Zend Frameworkでのアプリケーションアーキテクチャ」と「Zend Frameworkを理解する」という2つの章の下書きを完成させました。 最初の章では、Model-View-Controller（MVC）アーキテクチャパターンと、それがWebアプリケーションの事実上の標準になった理由について説明します。 2番目は、MVCとZend Frameworkコンポーネントの関係、それらの構造、および相互作用を調査します。



両方の章を完了した後、私はほとんどの場合、モデルとZend Frameworkに実際に存在しないことを説明していることに気付きました。 実際、単一のWebフレームワークが完全なモデルを提供するわけではありません（理由については後で説明します）。 そして、この状況を明確に説明している人はいません。 代わりに、モデルの概念を、データへのアクセスという同一ではないが関連する概念に一貫して結び付けているため、誰もがかなり混乱しています。



フレームワークのこちら側は、これまであまり注目されていませんでした。 それでも、Webアプリケーションフレームワークのイメージと類似性でMVCを使用しようとするアプリケーションでは、まさにこれがクラスの問題の根底にあります。 さらに、モデルのアイデアを他の開発者に伝える試みは、多くの場合、壁に頭を打ちつけているように見えます。 すべての開発者が愚かであるとか、アイデア自体を理解していないとは言いたくありません。PHPで動作するかどうかに関係なく、誰もモデルを意味のある領域（オブジェクト指向プログラミングの原則）に関連付けません。



この投稿では、開発者がモデルをアプリケーションのコントローラーと表現に関連付ける方法に照らしてモデルを調べ、適切なモデルで使用できるいくつかの戦略について説明します。



理解されていないモデル



モデルはさまざまな方法で説明できます。 実際、これだけで1冊の本を書くことができます。多くの人がそうしました！ 通常、2つのモデルロールについて説明します。



1.モデルはHTTPリクエスト間で状態を維持する責任があります



実際、すべてのデータ-データベース、ファイル、セッションに保存されている、またはAPC内にキャッシュされているデータは、最後のリクエストの時点でアプリケーション状態の形式でリクエスト間で保存する必要があります。 モデルはデータベースに限定されないことを忘れないでください。 Webサービスから取得したデータでさえ、モデルとして表すことができます！ はい、Atomニュースフィードも！ モデルフレームワークをすぐに知りたい人はこれを決して説明せず、誤解を強めます。



たとえば、私が開発しているZend_Feed_Readerというコンポーネントを考えてみましょう。これは実際にはモデルです。 彼はニュースフィードを読み、それらを処理し、データを解釈し、制限、ルールを追加し、基本的に、基礎となるデータの便利なプレゼンテーションを作成します。 これがない場合、Zend_Feed（現時点でニュースフィードを読むのに最適なツール）があり、本格的なモデルを取得するには多くの作業が必要です。 つまり、Zend_Feed_Readerはモデルであり、Zend_Feedはデータアクセスに制限されています。



2.モデルには、すべてのルールと制限が含まれ、この情報の動作と使用を制御します。



たとえば、調達アプリケーションで注文モデルのビジネスロジックを記述し、会社の内部規則に従って、現金購入に500ユーロの制限が課される場合があります。 注文モデルでは500ユーロ以上の購入は禁止する必要があります（上位の当局の承認が必要な場合があります）。 モデルには、このような制限を設定する手段が必要です。



「モデル」という言葉の意味を振り返るとすぐに、すべてが明確になります。 気候学では、データ、プロセス、予想される動作を記述し、可能な結果の計算を可能にする気候モデルがあります。 MVCのMは、理由によりモデルと呼ばれます。 モデルはデータを表すだけでなく、このデータが役立つシステム全体を表します。 システム自体は非常に複雑なため、相互作用するいくつかのモデルが必要になりますが、その考えは理解できます。



これらの2つのポイントを読んだ後、あなたはおそらく驚くべき何かに気づき始めました。 インターフェイスを除き、すべてのアプリケーションをモデルとして表すことができます。 データが集中しているのはそれらであり、それらに基づいた動作のルール、そして場合によってはこれらのデータの出力ですらあります。 データを理解、解釈、提示できるモデルであり、データを有意義に使用できます。



プログラミングでは、サイズがゼロのモデルよりも厚いモデルの方が適しています。



Jamis Buck（Jamis Buck、Capistranoの著者、現在37signalsで働いています）は、かつて「Skinny Controller、Fat Model」の概念を説明しました。 クリス・ハートジェスもこのテーマに関する記事を書いています。 MVCの重要な機能を示しているため、この概念のシンプルさが常に好きでした。 この概念のフレームワーク内で、可能な限りアプリケーションロジック（上記の例のビジネスロジックなど）はモデルに配置するのが最適であり、コントローラーやビューには配置しないと考えられています。



ビューは、ユーザーが自分の意図をモデルに通知できるインターフェースの作成と表示のみを処理する必要があります。 コントローラーは、インターフェイスに入力されたデータをモデルのアクションに接続し、このモデルがどの表現を表示していても出力を送り返すオーガナイザーです。 コントローラーは、ユーザー入力をモデル呼び出しに接続するという点でのみアプリケーションの動作を決定する必要がありますが、そうでない場合は、すべてのアプリケーションロジックがモデル内にあることを明確にする必要があります。 コントローラーは、秩序ある作業の条件を提供する最小限のコードを持つ控えめな生き物です。



概して、PHP開発者はモデルが何であるかをよく理解していません。 多くの人は、このモデルをデータベースへのアクセスにとって美しい言葉だと考えていますが、他の人は、モデルをアクティブレコード、データマッパー、テーブルデータゲートウェイなどのデータベースにアクセスするための異なるテンプレートと見なしています。 フレームワークは、しばしばこの誤acyを意図せずに促進しますが、私は確信していますが、精力的に。 モデルが何であるか、なぜそれが素晴らしいアイデアであり、どのように開発および展開されるべきかを完全に理解していないため、開発者は不注意に貧しいと呼ばれる開発方法につながる暗い道に乗り出します。



少し考えてみると、考えの土台が得られます。 Zend Frameworkを使用して、世界で最も素晴らしいWebアプリケーションを作成したと想像してください。 クライアントは驚き、彼の喜び（そしてお金）は非常に楽しいです。 残念ながら、彼らは彼らの新しいCTOがすべての新しいアプリケーションでSymfonyを使用することを要求し、アプリケーションを変換するために非常に興味深い量を提供することを忘れていました。 質問：それはどれくらい簡単ですか？ 少し考えてみてください...



アプリケーションのロジックがモデルに関連付けられている場合-あなたは馬に乗っています！ symfonyは、多くの（すべてではありませんが）フレームワークと同様に、何を書いてもモデルを受け入れます。 モデル、その単体テスト、ヘルパークラスを、ほとんどまたはまったく変更せずにSymfonyに移植できます。 これらすべてをコントローラーに接続すると、問題が発生します。 SymfonyはZend Frameworkコントローラーを使用できると本当に思いますか？ Zend FrameworkのPHPendn拡張機能を使用した機能テストは、魔法のように機能しますか？ 両方オン。 これが、コントローラーがモデルを交換できない理由です。 再利用することはほとんど不可能です。



誤解され、過小評価され、愛されていない：意気消沈したモデル



フレームワークの99.9％でデフォルトで行われているように、開発者はモデルの役割を過小評価してデータベースへのアクセスを制限することが非常に多いため、モデルに関連付けられた理論的な理想に感銘を受けないことは驚くことではありません。 データへのアクセスに焦点を当てることで、開発者は1つの非常に重要なポイントを見逃します。モデルクラスは現在のフレームワークに関連していません。 それらは複雑なインストールを必要とせず、オブジェクトを作成して使用するだけです。



たぶん、私たちは平均的な開発者を非難すべきではありません。 Webアプリケーションには、この曲線道路をより魅力的にする特定の行動パターンがあります。そのほとんどは、非常に大きなデータリーダーです。 データがほとんど処理されず、読み取りのみの場合、モデルは古き良きデータアクセスと非常によく似ています。 幸運ではないので、データの読み取りの単純さに惑わされないでください。 すべてのアプリケーションが読み取りに限定されているわけではありません。一部のアプリケーションは、データを変更せずに適切なデータベース形式で表示する以上のことを行う必要があります。



PHPのモデルは敗者です。 スマーティーとその親sの出現以来、誰もがパフォーマンスに情熱を注いでいます。 また、コントローラーは非常に重要です。コントローラーはデータベースからデータを読み取り、それらをテンプレートに渡します（一般的に受け入れられているVCの解釈）。 はい、コントローラーは脳に染み込んだページコントローラーの論理的な進化であり、PHP3以降、すべてのPHP開発者と彼の犬によって使用されています。 少なくともこれはほとんどの人には明らかなようです。 「controller = page controller」という神話は後ほど破壊します。



モデルはどうですか？ イデオロギー的な魅力や古い習慣との類似性がないため、人々はそれらを平凡な「データへのアクセス」と見なしています。 メモリ内の同じ値を指すPHP参照型のように。 言語は変わりましたが、古いアイデアはまだカーテンの後ろに隠れており、ニューラルネットワークを混乱させています。



しかし、待ってください...結局のところ、開発者はまだ動作中のアプリケーションを書いています！ そして、アプリケーションロジックを含むモデルを使用しない場合、何を使用していますか？！



太くて愚かな、いコントローラー：平和を作りましょう （太い愚かなUいコントローラー：SUC It Up）



開発者はモデルについてほとんど何も知らなかったため、彼らは新しい概念を開発しました：厚くていコントローラー（TTUK）。 ある理由でこのような鮮明な定義を思いつきました。ビールを2、3杯飲んだ後、午後10時に非常に面白いように見えます。 そして、私が本当に考えているよりもさらに丁寧です。 （脂肪愚かなUいコントローラ-FSUC-FUC）。 モデルは珍しく、エイリアンで、テロリストのような存在であり、少なくともデータへのアクセスの制限を超えるものを誰もあえて委ねなかったため、それらは発明されました。



典型的なTTUKは、データベースからデータを読み取り（開発者がモデルと呼ぶデータ抽象化レベルを使用）、それらを処理し、チェックし、書き込み、表示のためにプレゼンテーションに転送します。 彼は非常に人気があります。 フレームワークのほとんどのユーザーは、ページコントローラーの作成に使用したのと同じくらい自然にそれらを作成すると思います。 開発者がコントローラーをページコントローラーとほぼ同じ方法で処理できることに気付いたため、これらは人気があります。これは、アプリケーションの「ページ」ごとに個別のphpファイルを使用する古代の手法と事実上違いはありません。



異常なことに気づきませんでしたか？ TTUKは、データに対して可能なすべてのアクションを実行します。 なんで？ モデルが存在しない場合、すべてのアプリケーションロジックがコントローラーに移動するため、一種のミュータントモデルになります。 「変異」という言葉だけを使用したわけではありません。 TTUKは非常に大きく、かさばり、く、間違いなく厚いです。 何が起こっているかを非常に正確に説明する擬似プログラマーの用語があります-「 肥大化 」。 彼らは、決して意図されていないタスクを実行します。 これは、オブジェクト指向プログラミングのすべての原則の正反対です。 そして、彼らは無意味です！ いくつかの神秘的な理由から、開発者は、モデルの代わりにTTUKiを使用することを好みますが、そのようなコントローラーは実際には単なるミュータントモデルであるという事実にもかかわらずです。



私たちのメンタルエクササイズを覚えていますか？ すべてをコントローラーに入れると、アプリケーションを別のフレームワークに移植することは非常に難しいタスクになります。 ケント・ベックのファンは、このように緊密に結び付けて「コード臭」と呼んでいます。 そして、これはTTUKの臭いの唯一の原因ではありません。 TTUKは大規模で、大規模なメソッド、複数のロール（通常はメソッドごとに1つ）、機能によって外部クラスに持ち込まれない複数のコードの繰り返し...テスターの悪夢です。 多くのフレームワークがあるため、独自のアドオンを作成したり、リクエストオブジェクト、セッション、Cookieを処理したり、入力コントローラーをリセットしたり（フロントコントローラーのリセット）することなく、テスト（TDD）で開発を正しく適用することさえできません。 この場合でも、ビューに依存しない出力メソッドがないため、コントローラーによって作成されたビューをテストする必要があります！



質問を続けましょう！ コントローラーをどのようにテストしますか？ コントローラーをどのようにリファクタリングしますか？ コントローラーの役割をどのように制限しますか？ コントローラーのパフォーマンスはどうですか？ アプリケーションの外部にコントローラーインスタンスを作成することはできますか？ 気を失うことなく、一貫して複数のコントローラーを1つのプロセスに統合できますか？ なぜもっと単純なクラスを使用してモデルと呼ばないのですか？ これらの問題について考えたことはありますか？



モデルは避けられない（死や税金など）



TTUKでは、古典的な間違いが犯されます。 モデルのアイデアは愚かで、データへの簡単なアクセスが最適であると考えると、開発者は無意識のうちにすべてのアプリケーションロジックをコントローラーに結び付けます。 おめでとうございます！ コントローラーであると主張して、モデルを作成しました。 しかし、この自称コントローラーは、転送、テスト、保守、およびリファクタリングするのが非常に困難です（実世界からの概念のリファクタリングを考えてみてください...それは起こります！）コントローラーの性質は、基礎となるフレームワークに密接に関連しているということです。 指定されたフレームワークのMVCのセット全体を初期化した後にのみコントローラーを実行できます（これは、他の多くのクラスへの依存を意味する可能性が高いです！）



あなたは他の方法で行くことができます-アプリケーションロジックをどこかに持って行きます。 コントローラーからモデルに移動すると、使用するフレームワークに依存しない多くのクラスが取得されます。 これで、コントローラーやビューを見ることなく、また各テストの後にフレームワークの愚かな再起動で苦労することなく、PHPUnitを使用して、これらのグリッチの苗をテストできます 。 それらを明確に定義されたロールを持つ実際のクラスと考えると、それらを正しい観点から見て、対応するリファクタリングを実行し、多くのクラスで重複することなく真にサポートされるコードを書くことができます。



モデルは避けられません。 TTUKコントローラーと呼ぶ人もいますが、実際にはコントローラー+モデルであり、非常に効率の悪いモデルの代替品です。 一部の人々は、優れた独立したドメインモデルの必要性について話し、混乱を招くコードを書き続けるこれらすべての愚か者を単に笑うでしょう。 彼らを笑わせてください。 結局のところ、混乱を維持し、テストする必要があるのは彼らです。



これは、ほとんどのWebアプリケーションフレームワークがユーザーに失敗する場所です。 彼らは膨大な量のマーケティングのナンセンスに囲まれており、完全なモデルを提供することを暗示的に示唆しています。 他に何かを直接言うフレームワークを見たことがありますか？ 結局、これは同じMVCフレームワークです。 開発者が自分でMを記述する必要があることを認識すると、悪い印象を与える可能性があります。 そのため、データアクセスドキュメントに散在する多くの詳細に真実を隠しているか、まったく言及していません。



実際、それらはデータアクセスクラスのみを提供します-現在のモデルは特定のアプリケーションの機能を反映し、クライアントとの通信後に独立して開発する必要があります（このために美しい名前を選択できます-私は個人的に「極端なプログラミング」を好みます）。 テスト、検証、更新する必要があり、使用されるフレームワークに関係なく、成功/失敗の確率は変化しません。 悪いRailsアプリケーションは、悪いCode Igniterアプリケーションのままです。



コントローラーはデータを保護してはいけません



モデルに対する一般的な不信のもう1つの結果は、開発者が最小限にモデルを使用し、データストレージの新しい役割（TTUKにおける突然変異の主な理由の1つ）を持つコントローラーを信頼しようとすることです。 私との普遍的な不一致の火をさらに照らしてほしいですか？



しばらく前に、私はプロジェクト（Zend_View Enhanced）を作成しました。このプロジェクトは遅かれ早かれZend Frameworkに採用され、複雑なビューを作成するオブジェクト指向のアプローチを導入します。 ビューは仲介なしで実行でき、代わりにビューヘルパーを使用してモデルから直接データを読み取ることができると考えました。 これにより、読み取り専用の多くのページで、コントローラーアクションが空になるアーキテクチャになります。 コードはありません。 アーメン！



私にとって最高のコントローラーは、コントローラーがないことです。



私はすぐに大量抵抗に遭遇しました。 モデルとのすべての対話がシンプルで再利用可能なビューヘルパーでレンダリングされる空のコントローラーがコントローラー内の繰り返しコード（非常に多数の繰り返しコード！）を削減し、コントローラーアクションのチェーンを構築する必要性を排除することに気づいた人はほとんどいませんでした。その代わりに、私は多くのキャッチーな表現を聞いた。 MVCは次のように機能すると考えられていました。要求はコントローラーに送られ、コントローラーはモデルからデータを受け取り、コントローラーはモデルからビューにデータを転送し、コントローラーはビューを描画します。つまり、コントローラー、コントローラー、コントローラー、コントローラーです。私はかつて、コミュニティが単にコントローラーに取り付かれていることに気づきました。誰かが表現オブジェクトにデータを与え、自分でモデルからデータを読み取らせることを保証するのはまだ非常に困難です...



注：すべてがそれほど悪いわけではありません-一部の人々はそれが何であるかを理解しました



これは実際には非常に古いアイデアであることに異議を唱える人はいませんでした。Javaでは、ビューアシスタントという用語が何年も前にJ2EEのデザインパターンとして導入され、ビューヘルパーがビューアクセスモデルを支援できることを示しています（すべての書き込み操作はコントローラーを経由する必要があるため、読み取り専用です！）中間コントローラーなし。MVCのすべては、ビューがコントローラーが口に入れる配列だけでなく、表示するモデルについても知っているべきだと言っています。



では、さらに進んでみませんか！1つのモデルにいくつのアイデアがあれば十分ですか？私のアイデアの多くはいくつかのモデルを使用しており、その呼び出しはしばしば繰り返されます。ビューヘルパーは1つのクラスですが、コントローラーに繰り返し呼び出しを追加するには、これらの呼び出しをさまざまなメソッドで繰り返す必要があります！



ビューアシスタントを削除するために、コントローラのアクションが再利用可能なコマンドとして再発明された1つのクレイジーなソリューションが発明されました。ビューに複数のモデルが必要な場合、複数のコントローラーを順番に呼び出します。私はよくこの考えをコントローラーチェーンと呼びます。その目的は、コントローラーの再利用を可能にするユーティリティコードを作成することです。次のように翻訳できます。特定のコントローラーアクションを実行するために必要なクラスを再利用します。忘れないでください-フレームワーク全体を初期化せずにコントローラーを使用することはできません。ただし、例外はあります（常に存在します！）。



モデル-クラス、コントローラー-プロセス



私の型にはまらないアイデアはおそらくあなたを退屈させましたが、前述のクラッチコントローラーにはさらに詳細な検討が必要です。リンクは、多くの場合、複数のモデルへのアクセス、複数のビューの結果の結合、またはその両方を同時に行うために使用されます。後者は最も頻繁に発生します-プロセスを簡素化するためにビューアシスタントを使用しない場合、コントローラーはほとんど常にモデルにアクセスし、ビューにデータを渡します。



3つのコントローラーを作成し、それぞれがビューを作成するとします。新しいWebページを作成するには、テンプレート（またはレイアウト）に従って3つのビューを1つのページに結合する必要があります。これは、Zend_Layout（またはビューを1つのレイアウト/セクションにアセンブルするためのその他のソリューション）を使用して、3つすべてのコントローラーを順番に呼び出すことによって行われます。ここで何が起こったのかを見てみましょう-3つのコントローラーは、MVCスタックを3回実行することを意味します。アプリケーションによっては、これによりリソースのオーバーヘッドが大きくなる可能性があります。これらのコストの大きさの例として、Symfonyはパフォーマンスへの影響を軽減するためだけに設計された特殊なタイプのコントローラーとして「コンポーネント」を使用しますが、Zend Frameworkには他に類を見ません。Railsでの同様のアイデアは、パフォーマンスの低下について多くの苦情を引き起こしました。フレームワークで複数の完全なコントローラを使用することは非常に非効率的であり、他の再利用戦略がない場合の最後の手段であると一般的に知られています。



繰り返しになりますが、コントローラークラッチはストックコードです。これは非効率的で不器用であり、通常は必要ありません。



もちろん、代替手段は、ビューアシスタントを介してモデルと直接対話できる部分表現（1つの親表現に結合できるテンプレートの断片）の使用です。一般的にコントローラーを取り除きます-最終的に、コントローラーはユーザー入力を対応するモデル呼び出しに渡す以外のアプリケーションロジックを持ちません（TTUKを除く）。



基本的な考え方は、モデルは疎結合クラスの単なるコレクションであるということです。他のモデル、コントローラー、ビューなど、どこでもインスタンスを作成して使用できます！一方、コントローラーはプロセス全体の不可欠な部分です。要求オブジェクトの作成、ディスパッチ、アクションアシスタントの使用、プレゼンテーションの初期化、返された応答オブジェクトの処理のプロセス全体を開始せずにコントローラーを再利用することはできません。それは高価で厄介です。



会話の終わりに



お気づきかもしれませんが、この記事は非常に重要です。私は、MVCフレームワークでオブジェクト指向プログラミングのエレガントな原則を実装する必要性を確信しています。だからこそ、私はZend FrameworkでZend_View Enhancedを宣伝するために最善を尽くし、それがどのように承認され、議論され、非常にうまく使用されているかを見ました。これは主に、このアイデアの推進に参加したマシューワイアーオピニーとラルフシンドラーによるものです。 OOPの簡単な方法と原則を忘れて、MVCとの戦いに取り残され、その意味を忘れます。 MVCは優れたアーキテクチャテンプレートですが、最終的に、MVCの解釈や一般的な信念はいずれもOOPの原則に基づいています。これを忘れて、悪いこと（TM）を始めます。



モデル-コントローラー-表現のモデルについてのこの考えの流れが、啓発的なものであり、あなたに考えさせることを願っています。自分自身を目標とするべきだと思う-すべてを疑い、あなたにとって何かがおかしいと思われるときは反抗する。盲信に頼って、私たちは私たちに起こるすべてに値します。



MVCのM：モデルが誤解され、評価されない理由