WebおよびMVC：デブリーフィング

MVCの死というテーマに触発されました。



何が起こっているのかを理解するために、OOPの原則から始めましょう。

OOPのオブジェクトクラスは、オブジェクトデータとその動作をカプセル化します。

サブジェクト領域をオブジェクトに分割する際の複雑さ。

ここでは、「サブジェクトエリア」によって、技術環境（DB、ネットワークなど）も理解しています。



最近の一般的なプラクティスは、軽量のPOJOオブジェクトとそのプロキシの作成であり、MVCのすべての部分（それぞれM、V、C）に分散するロジックを使用します。

これは、アプリケーションのM、V、およびC部分にそれぞれさまざまなテクノロジーを実装するという点で便利です。 出力には、Mフレームフォーク、Vフレームフォーク、Cフレームフォークがあります（混乱が生じる場合があります）。 このパラダイムでは、ロジックをモデルのPOJOクラスに転送し、データベースに反映（マッピング）すると自殺します。



どのような選択肢がありますか？





OOPのオブジェクトがオブジェクトのデータをその動作とともにカプセル化するという原則から始めましょう。 また、単一責任の原則を使用します。

「これから何が続くの？」 本質的にデータベースで動作するようにコードを実行しますか？当然です。

それを理解しましょう。 これらの同じPOJOオブジェクトは、実際に明確に定義されたセマンティクス-データベースエンティティのマッピングを保持しています。 ただし、それらのクラスを呼び出すことは正しくありません。 OOPの観点から見ると、それはむしろ単なるデータ構造です。 また、ここではget / setメソッドは必要ありません-これは単なるデータキャストです。



これは紛らわしいです。 そして、OOPはどこにありますか？ サブジェクト領域、つまり操作、ユーザーアクションから始めましょう。 最初に、MVCからのビューをその場所に残しましょう。すべてが多かれ少なかれ明確であり、通常は質問はありません。 MとCのまま。何とは？

ほとんどすべてのWebアプリケーション（Webを例として考えてください、残りは似ています）、外部データソースとの連携、入力と出力の両方の外部システムとの統合、および要求/応答パラダイムがあります。 要求と応答がオブジェクトで適切にラップされていることは論理的です。このパスは長い間カバーされてきました。 入力および出力の両方の外部システム用の外部（技術）インターフェイスもあります。 つまり これらのクラスとオブジェクトは既に定義されていると考えます。 宣言型スタイルの利便性も考慮してください。



だから、私たちに操作があるとしましょう。 リクエストを1つ言ってみましょう。 テンプレートとデータマネージャーは、最終的なハンドラーを決定します。 さらに、これは最後のものです。URLの構造、特権、および送信されるデータに依存するすべてのブランチは、ディスパッチャによって作成される必要があります。 同時に、ディスパッチャはフレームワークによって部分的に提供されますが、ほとんど完全に提供されることはありません。 そのため、コントローラーは割り当てられ、残りのロジックから厳密に分離されました。 同時に、クエリデータまたはエンティティオブジェクトのいずれか、つまり データ構造。



次に、リクエストが処理されます。 すべての操作は、さまざまな条件下で実行されるプリミティブなCRUDコンポーネントに分割できます。 質問：操作はオブジェクトですか？ 操作は、オブジェクトの相互作用です。 彼女は自分のデータを持っていません-彼女はそれらを借ります。 それ自体が受動的なオブジェクトの相互作用を提供します。 そして、彼らは誰も操作を実行する知識を持っていないため、受動的です。 したがって、オブジェクトの相互作用に責任を持つ仲介者が必要です。 これはコントローラーではありません。 これはモデルではありません。 これは別のパターンです。

しかし、MとCはどうですか？ コントローラーは操作を呼び出し、その結果に基づいて、表示するビューを選択する必要があります。 すべてのロジックが動作します。 モデルはどこにありますか？ モデルは、変更についてビューに通知する必要があり、コントローラーによって変更する必要があります...私たちが持っているモデルはデータベースです。 データベース自体はモデルです。 そして、通知ビューなし。 Web開発では、サイトの単一のコンポーネントがモデルのイベントのビューを更新しません。 操作後に取得したデータに基づいてビューを構築します。



それはMVCですか？

正規の形式で-いいえ。 別のパターンは、モデルが受動的であるWebで機能します。

名前については議論しませんが、相互作用と役割の構造はここでは異なります。



本格的なMVCを作成することは可能ですか？

このテーマについては、別の記事を書く必要があると思います。