Django MVCまたはMVTですか？そしてMVCとMVTの違い
Is Django Mvc Mvt
最近、私はいくつかの質問に混乱しています：DjangoはMVCまたはMVTに従いますか？ MVCとMVTの違いは何ですか？ MVCは分割を続けることができますか？
私はインターネット上で多くの無関係な記事を閲覧しました。それは、それぞれM、V、およびCが表すもの、およびM、V、およびTが表すものにすぎません。これらのレイヤーの解釈はプログラマー向けです。それは問題を解決しないだけでなく、混乱を増大させます。したがって、いくつかの情報を確認した後、個人的な理解に基づいて要約し、覚えておいてください。これは個人的な視点と立場にすぎません。
MVCはどのようにして生まれたのですか？それは何ですか？
当初、MVCはアイデアです。これはModel-View-Controllerです。その中心的なアイデアは、分業、デカップリング、異なるコードブロック間のカップリングの削減、コードのスケーラビリティと移植性の強化、およびPost互換性の実現です。
その後、この分業のアイデアはますます多くの開発者に歓迎され、ソフトウェアエンジニアリングで広く使用されてソフトウェアアーキテクチャモデルになりました（一種のソフトウェアとして理解している場合）アーキテクチャモデル、私はいつも少し遠い感じ）。
フレームワークとデザインパターンの違い
- 多くのプログラマーは、フレームワークモードをデザインパターンと混同し、MVCがデザインパターンであると考えることがよくあります。実際、それらは完全に異なる概念です。
- フレームワークとデザインパターンの2つの概念は常に紛らわしいですが、それでも違いがあります。フレームワークは通常コードの再利用ですが、デザインパターンはデザインの再利用であり、アーキテクチャはその中間にあり、コードの再利用、デザインの再利用、分析の再利用が可能です。ソフトウェア生産での再利用には3つのレベルがあります。内部再利用。同じアプリケーションコードの再利用で公に使用できる抽象的なブロックであり、共通のモジュールをライブラリまたはツールセットに結合して、複数のアプリケーションやドメインで使用します。フレームワークの再利用最高レベルの再利用性を実現するために、プライベートドメインに共通または既製のインフラストラクチャを提供します。
- フレームワークとデザインパターンは似ていますが、根本的に異なります。デザインパターンは、環境内で繰り返し発生する問題の説明であり、問題の解決策です。フレームワークよりも抽象的であり、フレームワークをコードで表すことも、直接実行または再利用することもでき、パターンに使用できるのはインスタンスのみです。 codeDesignパターンで表現されるのはフレームよりも小さい要素であり、1つのフレームに1つ以上のデザインパターンが含まれることがよくあります。フレームワークは常に特定のアプリケーション領域を対象としていますが、同じモデルをさまざまなアプリケーションに適用できます。フレームワークはソフトウェアであり、デザインパターンはソフトウェアの知識であると言えます。
- フレームワークモードとは何ですか？
MVC、MTV、MVP、CBD、ORMなど。 - フレームワークは何ですか？
C ++言語QT、MFC、gtk、Java言語SSH、SSI、php言語smarty（MVCモード）、python言語django（MTVモード）など。 - デザインパターンは何ですか？
ファクトリモード、アダプタモード、ポリシーモードなど。 - つまり、フレームワークはソフトウェアデザインを分割するための優れた知恵であり、デザインパターンは小さなスキルであり、コードの再利用率を向上させ、結合を減らすための特定の問題の解決策を提案します。
最後に、MVCのアイデアは、WebMVCフレームワークとして知られるWeb開発に適用されます。
MVCコンテンツ：
- Mはモデルとして完全に綴られており、主にデータベースレイヤーへのアクセスをカプセル化し、データベース内のデータを追加、削除、変更、およびチェックします。
- Vはビューの全体像であり、結果をカプセル化し、ページに表示されるhtmlコンテンツを生成するために使用されます。
- Cは、要求を受信し、ビジネスロジックを処理し、モデルとビューと対話し、結果を返すフル機能のコントローラーです。
DjangoのフレームワークモードはMVCまたはMVTですか？
MVTコンテンツ：
- Mはモデルでいっぱいで、データ処理のためにデータベースと対話する責任があります。
- Vすべての呪文は、表示、要求の受信、ビジネス処理の実行、および応答の返送です。
- Tはテンプレートであり、返されるhtmlをカプセル化する役割を果たします。
注意を払う！ ！ ！
多くの記事によると、MVTのVはMVCのCコントローラーです。これは間違っています。MVTのDjango.Vはまだビューであり、コントローラーではありません。
MVTは、MVCでコントローラーの機能を分割します。つまり、MVTには、モデル、ビュー、およびテンプレートレイヤーに加えてURLディスパッチャーがあります。この関数は、1つのURLのページ要求を別のビュー処理に分散し、ビューが対応するモデルとテンプレートを呼び出すことです。
URLディスパッチャーの処理：ユーザーリクエストとパラメーターを受信した後、Djangoフレームワークは正規表現を介してURLを照合し、処理のために対応するビューに転送します。 ViewはMを呼び出してデータを処理し、次にTを呼び出してブラウザーに戻ります。
MVTとURLディストリビューターの関係を見てみましょう。
このアーキテクチャパターンの利点は、ユーザー入力を受け入れるコントローラーの部分がフレームワーク自体によって処理されることです。 Djangoはモデル、ビュー、テンプレートに関心があり、さまざまなコンポーネントが疎結合されています。 Djangoを利用したWebアプリケーションには明確な目的があり、他の部分に影響を与えることなく独立して変更できます。
私の結論
Djangoは間違いなくMVCの考え方に従いますが、具体的な実装に関しては、DjangoはMVTフレームワークモードであり、MVTとDjangoは切り離せないものであり、DjangoがMVTアーキテクチャパターンを使用しているため、混乱が生じています。
「MVCとは一体何ですか？ うめき声 。それは私が学ばなければならないもう1つの厄介なことだと思います！」
「MVCとは何ですか？」 不平を言う 。これは私が学ばなければならないもう一つの退屈なことだと思います！ '
いいえ、MVCについて学ぶ必要はありません。なぜなら、MVCは混乱を招き、回答よりも多くの質問につながる可能性が高いからです。
いいえ、MVCを学ぶ必要はありません。混乱を招き、回答よりも多くの質問につながる可能性があるためです。
参照： ジャンゴブック