モデルビューコントローラーの説明

動的Webサイトの開発に関する私の経験は、主にJavaサーブレットに限定されています。Tomcatを使用してさまざまなJavaサーブレットを開発してきましたが、このテクノロジーとフロントエンドのクライアント側のHTML / CSS / Javascriptにかなり精通していると言うことをためらいません。

「動的なWebサイト」と思うとき、ユーザーはクエリ文字列でURLを要求し、サーバーはクエリを受信し、クエリに応答するためにHTMLを動的に出力します。これには、表示用に要求されたデータをフェッチするために、データベースとの通信が含まれることがよくあります。これは基本的にdoGetJavaのメソッドの背後にある考え方HttpServletです。

しかし、最近では、DjangoやRuby on Railsなどの「Framework Controller」アーキテクチャを活用する新しいフレームワークについてますます耳にしています。MVCを説明するさまざまな 記事を読みましたが、その利点を本当に理解するのに苦労しています。一般的な考え方はUIロジックからビジネスロジックを分離することであると理解していますが、これが通常のWebプログラミングと実際に異なることを理解できません。Webプログラミングは、その性質上、ビジネスロジック（バックエンドサーバー側プログラミング）をUIプログラミング（クライアント側HTMLまたはJavascript）から分離することを余儀なくされます。これは、両者がまったく異なるプログラミング領域に存在するためです。

質問： Javaサーブレットのようなものに対してMVCが提供するもの、さらに重要なことは、 MVCとは何であり、Javaサーブレット（またはCGIのような古いもの）？可能であれば、MVCを説明するときに、MVCがWeb開発プロセスにどのように適用され、どのように有益であるかを示す例を提供してください。

最初にMVCアーキテクチャとは何かについてお話しし、次に現在のプログラミングの方法についてさらに詳しく説明します。

MVCアーキテクチャは、ソフトウェアシステム内でワークフローを整理する方法であり、システム動作を実装する階層化された方法と考えてください。この層は次のとおりです。

1. モデル：データモデルを表します。データモデルは、それに関連するすべての情報をローカライズするシステムコアです。たとえば、ゲームを設計する場合は、プレイヤー、ルール、障害物、およびこの要素の相互作用に関連するロジックなどが必要になります。プレイヤーは、ルールのセットが適用されるときに障害物をソートできる必要があります。

   モデルは、最初ので、あなたがオフに考えるべきだと思いますです、そのは、アプリケーションの中心になるだろう。

2. コントローラー：これは、魔法が発生する場所であり、レイヤードアーキテクチャが使用することを意図したオブジェクト指向のパラダイムを満たします。ここでは、アプリケーションユーザーがユーザーインターフェイスを介してアプリに関する何かを要求したときに、システムがどのように反応するかを実装します。

   コントローラーは、モデルオブジェクトを処理し、ユーザーが要求したものを達成するためにそれらを操作してから、対応するビューレイヤーに結果を委任してユーザーに戻す必要があります。

3. 表示：これは、ユーザーインタラクションの開始点と終了点です。ここで、ユーザーがアプリケーションと対話する方法を定義します。最近では、たとえば、携帯電話、テーブル、PC、ラップトップなどのさまざまな種類のメディアからWebアプリケーションにアクセスしようとするユーザーは非常に一般的です。

   一般に、各技術はビューを作成するために異なる言語を必要とするため、データモデルとモデルの相互作用とその相互作用のレンダリング方法がすべてハードコーディングされていることを想像してください。CopyPaste以外の方法でコードを再利用する方法はまったくありません。 。その結果、コードの匂いがして、HOLEシステムの適応に多くの時間が無駄になります。

   ビューを別のレイヤーに持つことで、現在作業中のモデルから独立して作業することができます。コントローラが送信しているオブジェクトのリストをどのようにレンダリングするかを知る必要があるだけです。彼がそれをどのように生成したかは完全に簡単です

だから、最終的に、現在のニーズに合わせて適応できるように適応できる独立したモデルを得ました（今日はルールなしでモノユーザーゲームを処理する必要があり、明日は友人と一緒にプレイし、そのマルチユーザーなどになります）それはユーザーにどのようにレンダリングするかに依存しません。次に、ビューからのユーザー要求をキャプチャするコントローラーは、モデルオブジェクトを処理し、ビューに情報を返してレンダリングします。

最初の質問に戻ります。ご覧のように（希望）MVCは物事を行う方法であり、ソフトウェアを作成する技術ではありません。Javaサーブレットを使用して、MVCアーキテクチャをその下に実装できます。

MVCアーキテクチャを使用したQ＆Aのサンプルサイトは、以下のとおりです。

あなたの質問に答えるために

What does MVC offer over something like a Java servlet

MVCはテクノロジーではなくパターンです。したがって、サーブレットを使用してプログラミングしているときにもパターンを適用できます。

サーブレット自体でMVCパターンを説明してみましょう。したがって、MVCの適用について話すときにやろうとしているのは、モデル（ビジネスロジック）、ビュー（プレゼンテーションロジック）、およびコントローラー（適切なビジネスロジックにコントロールを委任するコントローラーサーブレット）を分離することです。

この場合、MVCはプレゼンテーション層とコントローラー層からビジネスを分離するだけではなく、ビジネス層はコントローラーまたはプレゼンテーションが存在することすら知りません。

StrutsのようなJavaの主要なフレームワークはこのパターンに従います。あなたはコンセプトを間違っていたと思います。インターネットで詳細を読むことができます。

MVCは非常に理解しやすく、単なるデザインパターンですが、最も難しい/監督されているのはモデルパーツであることがわかりました。

• モデル：データ（データベースだけではありません！モデルは、iniファイルまたはxmlファイル、またはWebサービスからのデータですらあります）。モデルクラスは、データを定義、組み立て、処理する目的に役立ちます。「MVCのM：モデルが誤解され、評価されない理由」という優れた記事を読んでください。モデルには、コントローラーのみがアクセスする必要があります。
• ビュー：GUI（プレゼンテーション）コード。コントローラーにのみアクセスする必要があります
• コントローラー：ロジック。モデルとビュー間の通信を処理します。

の モデル-ビュー-コントローラの概念は新しいものではありません。1979年頃のSmalltalkで始まりました。

中核となるMVCは、コードの責任を整理し、モジュール化され、予測可能で、堅牢になる方法です。

この分離により、次の自由が得られます。

• アプリケーションロジックに影響を与えたり、データを表示したりせずにモデルを進化させる機能
• モデルに影響を与えずにビジネスロジックを変更する機能（新しいステップの追加など）
• 複数の異なる方法でモデルを表現する機能

注意して、モデルとコントローラーを設計して、フロントエンドとしてデスクトップアプリケーションをWebアプリケーションに完全に置き換えることができるようにする可能性があります。

最近では、MVCへのRuby on Railsアプローチにより、ほぼすべてのMVCスタイルのWebアプリケーションフレームワークにコピーされた新しい概念が導入されました。これには、「構成より規約」の概念、コントローラーアクションのクラスメソッドへのマッピング、URL要求の基になるコードへのルーティングが含まれます。