この記事では、MVCフレームワークに関する一連の記事を開きたいと思います。 最近、私は彼と彼の内面と非常に緊密に協力しており、共有したいいくつかの考え、興味深い観察、知識を蓄積しました。 あなたがASP.NETプログラマであり、MVCフレームワークに精通していない、またはあまり精通していない場合、私の記事がこのツールをよりよく理解するのに役立つと信じたいです。 いずれにせよ、あなたが主題を非常によく知っていたとしても、私はあなたと私が提起された各トピックのコメントで議論する何かを持っていると思います。
そのため、最初の入門ノートでは、クラシックASP.NETからMVCフレームワークを使用またはアップグレードする必要性の問題について説明します。 この質問は単純ではなく、インターネットで見つけることができるテンプレートの推奨事項と比較を繰り返さないという答えです。 それどころか、視点を変えて、問題を別の視点から見たいと思います。
MVCフレームワークが不要な理由
最初に、MVCフレームワークが不要な理由を検討します。
* MVCフレームワークは、従来のASP.NETよりも優れていると思われる場合は必要ありません。 そう考えると、ASP.NETについてあまり知らないので、まだ成長する余地があり、何を勉強する必要があります。 MVCフレームワークがASP.NETより優れていると思う場合、ASP.NETが好きではなく、そのイデオロギーの魅力全体を理解していません。 この場合、MVCフレームワークに切り替えるのは時期尚早です。 基本的なメカニズムに対する適切な理解と愛がなければ、新しいフレームワークに切り替える場所はどこにもありません。 ASP.NETを学習するには、そこですべてが配置されている理由と方法を理解します。 MVCフレームワークは必要ありません。
* MVCパターンを使用するためにMVCフレームワークは必要ありません。 実際、MVCは特定のライブラリとは関係ありません。 MVCフレームワークは、古典的なASP.NETで自分自身を作成して使用することに煩わされることのないパターンの実装です。 試してみてください、難しくありません。 唯一の理由がMVCである場合、MVCフレームワークは必要ありません。
*ビューステートを削除する場合は、MVCフレームワークは必要ありません。 MVCフレームワークは、「ビューステートを取り除く」ことを目的としていません。 ビューステートを削除する場合は、このメカニズムの仕組みを学びます。 なぜそれが何のためであるか。 有能な手にあるビューステートは非常に便利です。 また、大きくて重いビューステートページは、開発者による不十分な設計または知識不足の結果です。
*識別子の自動生成を削除する場合は、MVCフレームワークは必要ありません。 歴史は繰り返されます。 ビューステートに関連するすべては、htmlマークアップ要素のid自動生成に適用されます。 識別子が生成される方法と理由を理解している場合、それらを削除する必要はなくなります。 さらに、ASP.NET 4.0では、生成をより柔軟に制御する機会があり、これがMVCフレームワークを必要としないもう1つの理由です。
*「マークアップを完全に制御」したい場合、MVCフレームワークは必要ありません。 古典的なASP.NETでは、開発者もマークアップを完全に制御でき、他の何かを取得したいという願望は、開発者がASP.NETをよく理解していないことの明確な兆候です。 ASP.NETがマークアップでどのように機能し、リクエストをどのように処理するかを理解したら、クラシックモデルとMVCフレームワークモデルを比較できます。 これらのメカニズムの両方がどのように機能するかについて十分に理解している場合、この段落の要件はそれ自体で消滅します。 マークアップを管理するためにMVCフレームワークは必要ありません。
*読み取り可能なURLが必要な場合、MVCフレームワークは必要ありません。 人間が読めるURLを表現できるルーティングメカニズムはASP.NETの一部ですが、MVCフレームワークの内部部分ではないため、ルーティングを使用して、このための古典的なASP.NET、MVCフレームワークで人間が読めるURLを作成できます。
これらの点のいくつかに同意しないことを願っています。 これは良いことです。たぶん私の論文では、質問を違った視点で見ることができます。
MVCフレームワークが必要な理由
MVCフレームワークが必要な理由を検討してください。
*コードの大部分を単体テストでカバーするため、MVCフレームワークが必要です。 これは、MVCフレームワークに切り替える正当な理由です;そのモデルは、フレームワークの任意の部分が任意の段階でテストできることを想定しています。 従来のASP.NETでは、ポストバックコールバックメカニズムによりテストの記述が困難になることがよくありました。
*コードのほとんどがASP.NETの一部ではない場合、MVCフレームワークが必要です。 このようなコードは、クライアントjavascriptと部分的にAJAXです。 ASP.NETクライアント最適化の基盤が構築され、クライアント側のコードにほとんど注意が払われなかったとき、当時はAJAXやWeb 2.0の概念はありませんでした。 時代は変わり、古典的なASP.NETは変わり、AJAX機能をサポートする多くのツールを備えていますが、強力なクライアントコードを作成することは依然として困難な作業です。 クライアント側に、おそらくサーバー側と同じくらいの量の大量のコードがある場合は、MVCフレームワークが必要です。これにより作業が容易になります。
*また、MVCフレームワークが必要な主な理由は、絶対的な拡張性です。 この点で、MVCフレームワークは本当に必要に応じて入力できるフレームワークです。 次の比較を行うことができます。古典的なASP.NETはウィザードによって描かれた絵であり、MVCフレームワークはスケッチであり、自分でスケッチして完成したスケッチです。 MVCフレームワークでは、リクエストの処理から結果の送信まで、あらゆる段階でメカニズムのアクションを再定義できます。
MVCフレームワークへの切り替えは、「問題」を取り除くための検索ではありません。 問題を詳しく見てみると、それらはすべて古典的なASP.NETモデルのフレームワーク内で解決されていることがわかります。 多くの人は、MVC Frameworkを使用する主な長所と能力が、ほとんどの場合主題の理解が不十分なために発生する従来のASP.NETモデルの「欠点」ではないことを理解していません。 MVCフレームワークの強みは、その機能と拡張性の可能性にあります。 MVCフレームワークは、実績のあるツールで完全に飽和状態になった後に希望するコンストラクタの一種です。 ASP.NETメカニズムでは不十分な場合、拡張または変更できない提案モデルのフレームワークに制約されている場合に問題が発生した場合は、MVCフレームワークが本当に必要です。 それ以外の場合、「欠陥」または「MVCパターンへの切り替え」を取り除こうとする試みは、MVCに切り替える必要性の不十分な理由であり、ほとんどの場合、質問に対する誤った視点です。
「MVCフレームワークに切り替える必要がありますか？」という質問についてお伝えしたいことはこれだけです。 私がこの記事で述べたポイントがあなたに興味を持ち、あなたが異なる角度から質問を考えたり見させたりすることを願っています。 次のパートでは、「MVCフレームワークメカニズムの仕組み」という質問に終止符を打とうとします。