[解決済み] ASP.NET MVCを理解していない人がいる？[クローズド］

質問

CTPの頃からASP.NET MVCをいじっていて、彼らがやった多くのことが好きなのですが、どうしても理解できないことがあります。

たとえば、私はベータ 1 をダウンロードし、それを使って小さな個人サイト/履歴書/ブログを構築しています。これは ViewSinglePost ビューからのスニペットです。

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

ムカツク! (なお、ここにあるHTMLは仮のプレースホルダーHTMLです。機能が動作するようになったら実際のデザインを作成します) .

私は何か間違ったことをしているのでしょうか？なぜなら、私はクラシックASPで多くの暗い日々を過ごしたので、このタグスープはそれを強く思い起こさせるからです。

誰もが、いかにきれいなHTMLを作ることができるかを説いています。出力された HTML を見る人は全体の 1%です。私にとっては、メンテナンスが簡単なコードがある限り、Webforms がレンダリングされた HTML で私のインデントを台無しにしようが気にしません。

では、Webformsをよく使う私に、なぜこのためにきれいに作られたASPXページをあきらめなければならないのでしょうか？

編集してください。 人々がそれについてstfuするように"temp Html/css"の行を太字にした。

どのように解決するのですか？

Web Forms と比較して、MVC は同時に HTML 生成の下位アプローチであり、ページ出力に対するより大きな制御が可能です と より高レベルで、よりアーキテクチャに依存したアプローチです。ここでは Web Forms と MVC をとらえ、古典的な Web Forms の罠にはまらない限り、多くの状況で Web Forms が有利であると私が考える理由を説明します。

Web フォーム

Web Forms モデルでは、あなたのページはブラウザからのページ要求に直接対応します。したがって、ユーザーに本のリストを表示させる場合、おそらくどこかに "Booklist.aspx" というページがあり、そこにユーザーを誘導することになるでしょう。 そのページでは、そのリストを表示するために必要なすべてを提供する必要があります。 これには、データを取得し、ビジネスロジックを適用し、結果を表示するためのコードが含まれます。 ページに影響を与えるアーキテクチャやルーティングのロジックがある場合は、そのアーキテクチャのロジックもページでコーディングしなければなりません。 良い Web Forms の開発では、通常、個別の (ユニットテスト可能な) DLL で一連のサポートクラスを開発します。 これらのクラスは、ビジネス ロジック、データ アクセス、およびアーキテクチャ/ルーティングの決定を処理します。

MVC

MVC は、Web アプリケーションの開発において、より建築的な視点を取り入れています。 また、確立されたアーキテクチャの中で、モデル、ビュー、およびコントローラーのクラスを自動的に生成するためのツールも提供します。 例えば、Ruby on Rails (以下、Rails) と ASP.NET MVC の両方では、常に、Web アプリケーションのアーキテクチャの全体モデルを反映したディレクトリ構造で開始します。 ビュー、モデル、コントローラを追加するには、Railsの "Rails script/generate scaffold {modelname}" のようなコマンドを使用します (ASP.NET MVCではIDEで同様のコマンドを使用できます)。 生成されたコントローラクラスには、Index (リストを表示)、Show、New、Edit、Destroy用のメソッド ("Actions") が存在します (少なくともRailsでは、MVCも同様です)。 デフォルトでは、これらの "Get" アクションはモデルをバンドルして、"View/{modelname}" ディレクトリにある対応する view/html ファイルにルートするだけです ("Post" を処理して Index または Show にルートバックする Create, Update, Destroy アクションも存在することに注意してください).

MVCでは、ディレクトリやファイルのレイアウトが重要です。 例えば、ASP.NET MVCでは インデックス メソッドは、おそらく次の 1 行だけでしょう: "Return View();" MVC のマジックによって、これは Book モデルを "/View/Books/Index.aspx" ページに送信し、そこには書籍を表示するコードが含まれています。 Railsのアプローチも同様ですが、ロジックはもう少し明示的で、マジックも少なくなっています。 表示 ページは、ルーティング、ビジネスロジック、データ処理についてそれほど心配する必要がないため、通常、Web Forms ページよりもシンプルです。

比較

MVC の利点は、懸念事項の明確な分離と、出力を生成するための、よりクリーンで HTML/CSS/AJAX/Javascript 中心のモデルを中心に展開されます。 これは、テスト容易性を高め、より標準化されたデザインを提供し、より多くの Web 2.0 タイプの Web サイトへの扉を開きます。

しかし、いくつかの重大な欠点もあります。

まず、デモ サイトを立ち上げるのは簡単ですが、全体的なアーキテクチャ モデルには大きな学習曲線があります。 構成より規約」と言えば聞こえはいいですが、本1冊分の規約を学ばなければならないことに気づくまでは、そうとは言えません。 さらに、何が起こっているのかを理解するのは、しばしば少し気が狂いそうになります。 は は明示的な呼び出しではなく、マジックに依存しているためです。 例えば、上記の "Return View();" の呼び出しはどうでしょうか。全く同じ呼び出しが他のActionで見つかりますが は異なる場所に移動します。 を理解すれば MVC の規約 を理解しているのであれば、なぜこれが行われるのかがわかるでしょう。しかし、これは確かに良い命名や理解しやすいコードの例として適格ではありませんし、新しい開発者が Web Forms よりも習得するのがずっと難しいです (これは単なる意見ではありません。これは単なる意見ではなく、私は夏のインターンに去年は Web Forms を、今年は MVC を学ばせ、その生産性の違いは顕著で、Web Forms に軍配が上がりました）。ちなみに、Ruby on Railsは動的に名前が付けられるメソッドを特徴としていますが、この点ではRailsの方が少し優れています。

第二に、MVCは、古典的なCRUDスタイルのWebサイトを構築していることを暗黙のうちに想定しています。 アーキテクチャーの決定と特にコード ジェネレーターはすべて、このタイプの Web アプリケーションをサポートするために構築されています。もしあなたがCRUDアプリケーションを構築していて、実績のあるアーキテクチャを採用したいのであれば（あるいは単にアーキテクチャ設計が嫌いなだけなら）、おそらくMVCを検討すべきでしょう。しかし、もしあなたがCRUD以上のことをしようとしていて、かつ/またはアーキテクチャにそれなりの能力があるならば、基礎となるルーティングモデル（これはWebFormsアプリの単なるルーティングよりもかなり複雑です）を本当にマスターするまで、MVCが窮屈に感じるかもしれません。それでも、私は常にモデルと戦っているように感じ、予期しない結果について心配しています。

第三に、もしあなたが がLinqを気にしないのであれば (ASP.NET MVC scaffolding toolsはLinqを中心に構築されているためです (これが私にとっては致命的でした)。Railsのデータモデルも、SQLの経験者（特にTSQLとストアドプロシージャに精通している場合！）が達成できることに比べると、かなり不器用です。

第四に、MVC支持者はしばしば、MVCビューがWebのHTML/CSS/AJAXモデルに精神的に近いと指摘します。 たとえば、HTML ヘルパーは、コンテンツを交換し、HTML コントロールに配置する、Web ページ内の小さなコード呼び出しですが、Web Forms コントロールよりも Javascript と統合するのがはるかに簡単です。 しかし、ASP.NET 4.0ではコントロールに名前を付ける機能が導入され、この利点がほとんどなくなりました。

第 5 に、MVC 純粋主義者はしばしば Viewstate を嘲笑します。 いくつかのケースでは、彼らがそうするのは正しいです。 しかし、Viewstate は素晴らしいツールであり、生産性に貢献することもあります。ちなみに、Viewstate を処理することは <項目 多く は、サードパーティの Web コントロールを MVC アプリに統合しようとするよりもはるかに簡単です。MVC ではコントロールの統合はより簡単になるかもしれませんが、私が見た現在の取り組みのすべては、これらのコントロールをビューのコントローラ クラスにリンクする (すなわち を回避する を回避するためです)。

結論

私は多くの点で MVC 開発が好きです (ただし、ASP.NET MVC よりも Rails のほうが断然好きです)。 また、ASP.NET MVC が ASP.NET Web Forms のアンチパターンであると考える罠にはまらないことが重要であると思います。 これらは異なるものですが、完全に異質なものではありませんし、確かに両方が存在する余地はあります。

しかし、私はWeb Formsの開発を好むのは、以下の理由からです。 ほとんどのタスクに対して というのも、ほとんどのタスクにおいて、単純に物事を成し遂げるのが簡単だからです (例外は、一連の CRUD フォームの生成です)。MVC もまた、ある程度は 理論が過剰であること。 実際、ページ指向のASP.NETを知っていてMVCを試している人たちが、ここSOで質問した多くの内容を見てください。 例外なく、開発者は、輪をくぐったり、大きな学習曲線に耐えなければ基本的なタスクができないことに気づき、歯ぎしりすることが多くあります。 これは は、Web Forms が MVC よりも優れている理由だと思います。MVC では 現実的な価格 を支払わなければならないのです。 クール を使用しているので 最新技術を使っているからです。

更新: 私はコメント欄で激しく批判されました - そのうちのいくつかはかなり公平なものでした。そのため、私は数か月かけて Rails と ASP.NET MVC を学び、次の大きな話題に乗り遅れていないことを確認しました。 もちろん、質問に対してバランスのとれた適切な回答ができるようにするためでもあります。上記の回答は、コメントが同期していないように見える場合に備えて、私の最初の回答を大幅に書き直したものであることを知っておく必要があります。

MVC についてより詳しく調べている間、私は少しの間、重大な過ちに終止符を打つことになるだろうと思いました。最終的に私は、Web Forms のアーキテクチャとテスト容易性にもっと多くのエネルギーを費やす必要があると思う一方で、MVC は私にとって本当にその要請に応えられないと結論づけました。 ですから、私の最初の回答に対して知的な批評を提供してくれた人たちに、心から感謝します。

これを 宗教的な戦い として、執拗にダウンボートの洪水を仕組んだ人たちについては、なぜあなたが悩むのか理解できません (何度も数秒のうちに 20 以上のダウンボートがあるのは確かに普通ではありません)。もしあなたがこの回答を読んで、他のいくつかの回答よりもスコアがはるかに低いことから、私の回答について本当に何か"間違った"があるのではないかと思っているなら、それはコミュニティの一般的な感覚よりも、反対する少数の人々について言っているので安心してください（全体で、これは100回以上アップボートされています）。

事実、多くの開発者が MVC を気にしておらず、実際、これは少数意見ではありません (ブログが示しているように MS 内部でさえも)。