動的Webサイトの開発に関する私の経験は、主にJavaサーブレットに限定されています。Tomcatを使用してさまざまなJavaサーブレットを開発したので、ためらうことはありません。このテクノロジーと、クライアント側のフロントエンド用のHTML/CSS/Javascriptには、かなり上手です。
「動的なWebサイト」だと思うとき、ユーザーはクエリ文字列を使用してURLを要求し、サーバーはクエリを受信し、クエリに応答するために動的にHTMLを出力します。これは、要求されたデータをフェッチして表示するために、データベースとの通信を伴うことがよくあります。これは基本的に、Java doGet
のHttpServlet
メソッドの背後にある考え方です。
しかし、最近では、DjangoやRuby on Rails)などの新しいフレームワークについてますます耳を傾けています。これらはすべて、「モデルビューコントローラ」アーキテクチャ。MVCを説明する variousarticles を読みましたが、その利点を本当に理解するのに苦労しています。一般的な考え方は、ビジネスロジックを分離することです。 UIロジックからですが、これが通常のWebプログラミングとどう違うかはわかりません。Webプログラミングは、その性質上、UIプログラミング(クライアント側)からビジネスロジック(バックエンドサーバー側プログラミング)を分離する必要があります。 HTMLまたはJavascript)。これは、2つがまったく異なるプログラミング領域に存在するためです。
質問:MVCは、Javaサーブレットのようなものに対して何を提供しますか、そしてもっと重要なのは、正確には何ですかisMVCであり、Javaサーブレット(または何か古いもの)などの従来のアプローチを使用して動的Webサイトを開発するために通常行うこととどのように異なるかCGIのような)?可能であれば、MVCを説明するときに、MVCがWeb開発プロセスにどのように適用され、どのように有益であるかを示す例を提供してください。
最初に、MVCアーキテクチャとは何かについて話し、次に現在プログラミングしている方法に進むのが一番だと思います。
MVCアーキテクチャは、ソフトウェアシステム内のワークフローを整理する方法です。システムの動作を実装するための階層化された方法と考えてください。このレイヤーは次のとおりです。
Model:関連するすべての情報をローカライズする必要があるシステムコアであるデータモデルを表します。したがって、たとえば、ゲームを設計する場合は、プレーヤー、ルール、障害物、およびこの要素の相互作用に関連するいくつかのロジックが必要です。たとえば、いくつかのルールセットが適用される場合、プレーヤーは障害物を並べ替えることができます。
Modelは、最初に考える必要があると思いますitsあなたのアプリケーションの中心になります。
Controller:これは、魔法が発生する場所であり、レイヤードアーキテクチャが使用するオブジェクト指向パラダイムに出会う場所です。ここでは、一部のアプリケーションユーザーがユーザーインターフェイスを介してアプリについて何かを要求したときにシステムがどのように反応するかを実装します。
コントローラは、モデルオブジェクトを処理し、それらを使用してユーザーが要求したことを実現し、結果を対応するビューレイヤーに委任してユーザーにレンダリングできる必要があります。
View:これは、ユーザーインタラクションの開始点と終了点です。ここで、ユーザーがアプリケーションと対話する方法を定義します。最近では、たとえば、携帯電話、テーブル、PC、ラップトップなど、さまざまな種類のメディアからWebアプリケーションにアクセスしようとするユーザーはごく一般的です。
一般に、各テクノロジはビューを作成するために異なる言語を必要とするため、データモデルとそのモデルの相互作用方法、およびその相互作用のレンダリング方法がすべてハードコーディングされていると想像してください。CopyPaste以外の方法でコードを再利用する方法はまったくありません。 。結果は臭いがするコードであり、HOLEシステムを適応させるために多くの時間を浪費します。
分離したレイヤーにViewがあることで、現在取り組んでいるモデルとは無関係にで作業できるようになります。コントローラーが送信するオブジェクトのリストをどのようにレンダリングするかを知る必要があるだけです。どのようにして彼はそれを生成したのですか?
したがって、最後に独立したModelを取得しました。これは、現在のニーズに応じて適切に調整できます(今日はルールのないモノユーザーゲームを処理する必要があります。明日は友達と遊ぶために、そして今そのマルチユーザーなど)は、ユーザーにどのようにレンダリングするかには依存しません。次にControllerは、ビューからのユーザーリクエストをキャプチャし、モデルオブジェクトを処理し、ビューに情報を返してレンダリングします。
最初に尋ねた質問に戻ります。ご覧のように(私は願っています)、MVCはソフトウェアを作成するための技術ではなく、物事を行うための方法です。 Javaサーブレットを使用し、その下にMVC Achitectureを実装できます。
これは、MVCアーキテクチャを使用して少し明確にするためのQ&Aサンプルサイトです。
あなたの質問に答えるために
What does MVC offer over something like a Java servlet
MVCはパターンであり、テクノロジーではありません。そのため、サーブレットを使用してプログラミングする場合にもパターンを適用できます。
サーブレット自体でMVCパターンを説明してみましょう。したがって、MVCの適用について話すときに行うことは、モデル(ビジネスロジック)、ビュー(プレゼンテーションロジック)、およびコントローラー(コントローラーを適切なビジネスロジックに委譲するコントローラーサーブレット)を分離することです。
この場合、MVCは単にビジネスをプレゼンテーション層およびコントローラー層から分離するだけではなく、ビジネス層はコントローラーまたはプレゼンテーションが存在することさえ知りません。
Javaの主要なフレームワークはStrutsがこのパターンに従っているようです。コンセプトが間違っていると思います。インターネットで詳細を読むことができます。
MVCは非常に理解しやすく、単なる設計パターンですが、最も難しい/監視されているのはモデルパーツです。
Model-View-Controller の概念は新しいものではありません。それは1979年頃のSmalltalkで始まりました。
中核となるのは、MVCがコードの責任を整理してモジュール化し、予測可能で堅牢な方法にすることです。
分離により、次の自由が可能になります。
注意して、モデルとコントローラーを設計して、デスクトップアプリケーションをフロントエンドとしてのWebアプリケーションに完全に置き換えることができるようにすることができます。
最近では、MVCへのRuby on Railsアプローチにより、ほとんどすべてのMVCスタイルのWebアプリケーションフレームワークにコピーされたいくつかの新しい概念が導入されました。これには、 "構成に関する規約」、コントローラのアクションをクラスメソッドにマッピングし、URLリクエストを基になるコードにルーティングします。