フロントエンドとバックエンド、および MVC モデルの 1 対 1 の類推はありません。たとえば、(Django) サイトの管理者は一般にバックエンドの一部と見なされます。ユーザーが見るサイトの一部ではありませんが、管理者の一部は間違いなく MVC モデルのビューの部分です。通常の Web ユーザーが見たり直接やり取りしたりするものはすべてフロントエンドの一部であり、それ以外はすべてバックエンドの一部です。
Django で使用されている MVC フレームワークとは何ですか? 我々は持っています:
- モデル: これは、アプリケーションの状態を保持するアプリケーションの一部です。Django では、これの大部分はデータベースであり、抽象化レイヤーである Django モデルです。その他の部分は、ユーザー セッションと
request
変数です。
- ビュー: これは、アプリケーションの状態をユーザーに提示するアプリケーションの一部です。Django のビューとテンプレートがこれを担当します。Web サイトを開いたときに表示されるデータはすべて、MVC のビュー部分です。全体的なプレゼンテーションもこれの一部です。
- コントローラー: これは、ユーザーが実行するアクションを表すアプリケーションの一部です。View 部分と Controller 部分が非常に密接に絡み合っているため、Django は真に分離された MVC フレームワークではありません。サイトに表示されるリンク、フォーム、またはボタンはすべてコントローラーです。別のビュー (リンクなど) を表示したり、モデルの状態を変更 (編集フォームなど) するなどのアクションを実行するようにサイトに指示します。
Backbone または Angular はどうですか? 1 つのアプリケーションで 2 つの異なる MVC フレームワークが必要なのはなぜですか?
Django はサーバー側のフレームワークです。すべてのアクションはサーバー上で発生します。リンクをクリックするか、フォームを送信すると、サーバーにリクエストが送信され、サーバーは完全な静的応答を返します (ページがブラウザーに入ると変更されないという意味で静的)。Django は、クライアントのブラウザーではなくサーバー上で実行される Python フレームワークであるため、クライアント側でロジックを使用するために Django を使用することはできません。代わりに、クライアント側のロジックを追加するのは Javascript の仕事です。たとえば、ページ上のアイテムのリストを並べ替えたり、新しいアイテムを動的に追加したりします。これで、各ページはある種のミニ アプリケーションと見なすことができます。
Backbone と Angular は、このようなクライアント側アプリケーションの MVC フレームワークの例です。Django などのサーバー側フレームワークに欠けているクライアント側アプリケーション ロジックを提供します。驚くべきことに、MVC フレームワークを使用してサーバー側アプリケーションを開発するのが好きな人は、通常、MVC フレームワークを使用してクライアント側アプリケーションを開発することも好みます。 .