私のそばにいる誰かがASP.NET MVCを取得しないだけですか？[閉まっている]

私はCTP以来ASP.NET MVCをいじっていますが、彼らがしたことの多くは好きですが、得られないものもあります。

たとえば、beta1をダウンロードし、それと一緒に小さな個人用サイト/再開/ブログを作成しています。以下は、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を作成する方法を教えています。何だと思う？すべての人の1％が出力されたHTMLを見る。私にとって、保守が容易なコードがある限り、WebformsがレンダリングされたHTMLのインデントをめちゃくちゃにしてもかまいません...これはそうではありません！

だから、ハードなWebフォームの男である私を改宗させてください。なぜこれのためにうまく形成されたASPXページをあきらめる必要があるのでしょうか。

編集： "temp Html / css"の行を太字にしたので、人々はそれについて混乱するでしょう。

Webフォームと比較して、MVCは、HTML出力への低レベルのアプローチであり、ページ出力のより優れた制御と、より高レベルでよりアーキテクチャーに基づいたアプローチです。WebフォームとMVCをキャプチャして、従来のWebフォームトラップに陥らない限り、多くの状況で比較がWebフォームを支持すると思う理由を示します。

Webフォーム

Webフォームモデルでは、ページはブラウザからのページリクエストに直接対応しています。したがって、ユーザーを書籍のリストに誘導する場合、おそらくどこかに「Booklist.aspx」と呼ばれるページがあり、そこにユーザーを誘導します。そのページでは、そのリストを表示するために必要なすべてを提供する必要があります。これには、データをプルし、ビジネスロジックを適用し、結果を表示するためのコードが含まれます。ページに影響を与えるアーキテクチャロジックまたはルーティングロジックがある場合は、ページにもアーキテクチャロジックをコーディングする必要があります。 通常、優れた Webフォームの開発には、個別の（単体テスト可能な）DLLでのサポートクラスのセットの開発が含まれます。これらのクラスは、ビジネスロジック、データアクセス、アーキテクチャ/ルーティングの決定を処理します。

MVC

MVCは、Webアプリケーション開発のより「アーキテクチャ的」な見方をとります：構築する標準化された足場を提供します。また、確立されたアーキテクチャー内でモデル、ビュー、コントローラークラスを自動的に生成するためのツールも提供します。たとえば、Ruby on Rails（以降は単に「Rails」）とASP.NET MVCの両方で、Webアプリケーションアーキテクチャの全体的なモデルを反映するディレクトリ構造から常に開始します。ビュー、モデル、コントローラーを追加するには、Railsの「Railsスクリプト/生成足場{モデル名}」のようなコマンドを使用します（ASP.NET MVCはIDEで同様のコマンドを提供しています）。結果のコントローラークラスには、インデックス（リストの表示）、表示、新規、編集、破棄（少なくともRailsではMVCは同様）のメソッド（ "アクション"）があります。デフォルトでは、これらの "

MVCでは、ディレクトリとファイルのレイアウトが重要です。たとえば、ASP.NET MVCでは、「Book」オブジェクトのIndexメソッドには、おそらく「Return View（）;」という1行しかありません。これは、MVCの魔法を通して、Bookモデルを「/View/Books/Index.aspx」ページに送信します。このページには、Booksを表示するためのコードがあります。Railsのアプローチは似ていますが、ロジックは少し明示的で「マジック」が少なくなっています。A ビュー彼らは、ビジネスロジックやデータ処理のルーティングに関する限り心配する必要はありませんので、MVCアプリでページがWebフォームページより通常は簡単です。

比較

MVCの利点は、問題の明確な分離と、出力を生成するためのよりクリーンでHTML / CSS / AJAX / Javascript中心のモデルに関係しています。これにより、テスト性が向上し、より標準化された設計が提供され、より「Web 2.0」タイプのWebサイトへの扉が開かれます。

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

まず、デモサイトを導入するのは簡単ですが、全体的なアーキテクチャモデルには大きな学習曲線があります。彼らが "Convention Over Configuration"と言ったとき、それは良さそうに聞こえます-学ぶべき本の価値ある慣習があることに気づくまでは。さらに、明示的な呼び出しではなく魔法に依存しているため、何が起こっているのかを理解することは、多くの場合少し気が狂います。たとえば、 "Return View（）;" 上に電話しますか？まったく同じ呼び出しが他のアクションで見つかりますが、それらは別の場所に行きます。MVC規約を理解している場合そうすれば、なぜこれが行われるのかがわかります。ただし、これは確かに良い名前付けや簡単に理解できるコードの例としては適さず、Webフォームよりも新しい開発者が選択するのははるかに困難です（これは単なる意見ではありません。そして今年のMVCと生産性の違いが顕著になりました-Webフォームを支持しました）。ちなみに、Ruby on Railsは動的に名前が付けられたメソッドを備えているため、この点でRailsは少し優れています。

次に、MVCは、古典的なCRUDスタイルのWebサイトを構築していることを暗黙的に想定しています。アーキテクチャ上の決定、特にコードジェネレータはすべて、このタイプのWebアプリケーションをサポートするように構築されています。CRUDアプリケーションを構築していて、実績のあるアーキテクチャー（または単にアーキテクチャー設計を嫌う）を採用したい場合は、おそらくMVCを検討する必要があります。ただし、CRUDを超えることを行う場合や、アーキテクチャにある程度の能力がある場合は、基盤となるルーティングモデル（WebFormsアプリでの単純なルーティングよりもかなり複雑）をマスターするまで、MVCはストレートジャケットのように感じるかもしれません。それでも、いつもモデルと戦っていて、予期せぬ結果を心配しているような気がしました。

第3に、Linqを気にしない場合（Linq-to-SQLが消えてしまうのではないか、またはLinq-to-Entitiesが笑いすぎて生産力が不足していることがわかったため）、また、 ASP.NET MVC足場ツールはLinqを中心に構築されているので、この道を歩む必要があります（これは私にとってキラーでした）。Railsのデータモデルも、SQLに精通している場合（特に、TSQLとストアドプロシージャに精通している場合）に比べて、かなり扱いにくいものです。

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

第5に、MVCの純粋主義者はしばしばViewstateを軽視します。場合によっては、そうするのが適切です。ただし、Viewstateは優れたツールであり、生産性の向上にも役立ちます。比較として、Viewstateの処理は、サードパーティのWebコントロールをMVCアプリに統合するよりもはるかに簡単です。MVCではコントロールの統合が簡単になるかもしれませんが、私が見た現在のすべての取り組みは、これらのコントロールをビューのコントローラークラスにリンクするために（つまり、MVCモデルを回避するために）コードを構築する必要があります。）。

結論

私は多くの点でMVC開発を好みます（ただし、私は、ASP.NET MVCよりもRailsを優先しています）。また、ASP.NET MVCはASP.NET Webフォームの「アンチパターン」であると考える罠に陥らないことが重要だと思います。それらは異なりますが、完全にエイリアンではなく、確かに両方の余地があります。

ただし、ほとんどのタスクでは、物事を成し遂げるのが簡単なため、Webフォームの開発を好みます（例外は、CRUDフォームのセットの生成です）。MVCはまた、ある程度、理論の過剰に苦しんでいるようです。 実際、ページ指向のASP.NETを知っているがMVCを試している人たちがSOでここで尋ねた多くの質問を見てください。例外なく、開発者はフープを飛び越えたり、巨大な学習曲線に耐えたりしないと基本的なタスクを実行できないことに気づくと、多くの歯が食い物になります。これは、私の本の中でMVCに優れたWebフォームを作るものです：MVCはあなたが支払う作る現実世界の価格を、または、さらに悪いもう少しテスト容易性を得るためには、単にとして見られるようにクールなあなたが使用しているので、最新の技術。

更新：私はコメントセクションでひどく批判されました-かなり公平なものもあります。したがって、私は数か月かけてRailsとASP.NET MVCを学習し、次の大きなことを見逃していないことを確認しました。もちろん、質問に対するバランスの取れた適切な回答を提供するのにも役立ちます。上記の応答は、コメントが同期していないように見える場合に備えて、私の最初の回答を大幅に書き換えたものであることを知っておく必要があります。

MVCをさらに詳しく調べていると、しばらくの間、メジャーカルパができると思いました。結局、私はWebフォームのアーキテクチャとテスト容易性にもっと多くのエネルギーを費やす必要があると思いますが、MVCは私のための要求に実際に答えることはないと結論付けました。それで、私の最初の答えについてインテリジェントな批評を提供してくれた人々に心からの「ありがとう」。

これを宗教的な戦いとみなし、絶えず投票の洪水を仕掛けた人々については、なぜあなたが気になるのかわかりません（20秒以上の反対の投票が複数の場合に互いに数秒以内にあるのは確かに正常ではありません）。この回答を読んでいて、スコアが他の回答のいくつかよりもはるかに低いことを考えると、私の回答に本当に「間違った」ものがあるかどうか疑問に思っている場合は、一般的な感覚よりも同意しない少数の人についてのほうが多いと安心してください。コミュニティ（全体として、これは100回以上賛成されています）。

実際、多くの開発者はMVCを気にしていません。実際、これは少数派の見解ではありません（ブログで示されているように、MS内でも）。

MVCを使用すると、出力をより詳細に制御できます。この制御を使用すると、設計が不十分なHTMLやタグスープなどを作成するリスクが高まります。

しかし、同時に、以前にはなかったいくつかの新しいオプションがあります...

1. ページとページ内の要素をより詳細に制御
2. ViewStateや要素のIDが長すぎるなど、出力の「ジャンク」が少ない（誤解しないでください。ViewStateが好きです）
3. Javascriptを使用してクライアント側プログラミングを実行する機能の向上（Web 2.0アプリケーションはだれですか？）
4. MVCだけでなく、JsonResultも洗練されています...

だからといって、WebFormsを使用してこれらのことを行うことができないと言っているわけではありませんが、MVCを使用すると簡単になります。

サーバーコントロールなどを利用できるため、Webアプリケーションをすばやく作成する必要がある場合は、引き続きWebフォームを使用します。Webフォームは、入力タグと送信ボタンのすべての詳細を非表示にします。

WebFormsとMVCはどちらも、不注意な場合に絶対的なゴミを処理できます。いつものように、慎重な計画とよく考えられた設計は、それがMVCであるかWebフォームであるかに関係なく、高品質のアプリケーションをもたらします。

[更新]

それが何らかの慰めである場合でも、MVCはマイクロソフトからの新しい、進化するテクノロジーにすぎません。WebFormsが残るだけでなく、引き続き開発されるという投稿が多数あります...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... 等々...

MVCが取っているルートについて心配している人のために、私は「みんな」にフィードバックを与えることをお勧めします。今まで聞いているようです！

ASP.NET MVCに対する異論のほとんどは、アーキテクチャの中で最も「オプションの」モジュラービットの1つであるビューに集中しているようです。NVelocity、NHaml、Spark、XSLTなどのビューエンジンは簡単に入れ替えることができます（リリースごとに簡単になっています）。それらの多くは、表示されたHTMLを完全に制御しながら、プレゼンテーションロジックとフォーマットを行うための非常に簡潔な構文を備えています。

それを超えて、ほとんどすべての批判は、デフォルトのビューの<％％>タグ付けと、それがいかに「醜い」かに帰着するようです。その意見は、多くの場合、古典的なASPの醜さのほとんどを分離コードファイルに移動するWebFormsアプローチに使用されていることに根ざしています。

でもコード尻「間違った」を行うことなく、あなたは、リピータでOnItemDataBound、のようなものを持っているだけのように「タグのスープ」よりも、場合にのみ、別の方法で、審美的に醜いです。foreachループは、そのループの出力に変数が埋め込まれている場合でも、特に他の非ASP.NETテクノロジからMVCにアクセスする場合は、はるかに読みやすくなります。リピーターの1つのフィールドを変更する方法は、OnItemDataBound（および変更する適切な要素であるかどうかを確認するネズミの巣）をいじる方法であると理解するよりも、Google-fuでforeachループを理解するほうがはるかに簡単です。

ASPタグスープ駆動の「スパゲッティ」の最大の問題は、データベース接続などをHTMLの間に押し込むことでした。

<％％>を使用してそうしたのは、因果関係ではなく、従来のASPのスパゲッティの性質との相関にすぎません。ビューロジックをHTML / CSS / Javascriptに保ち、プレゼンテーションを行うために必要な最小限のロジックを維持する場合、残りは構文です。

特定の機能をWebフォームと比較するときは、MVCソリューションが実際にはそれほど単純ではないことを確認するために、デザイナーが生成したすべてのC＃、およびコードビハインドC＃と.aspxコードを必ず含めてください。 。

プレゼンテーションロジックの繰り返し可能なビットの部分的なビューの賢明な使用と組み合わせると、それは本当に素晴らしくてエレガントになります。

個人的には、初期のチュートリアルコンテンツの大部分が、テスト駆動型、制御の反転などにほぼ専念するよりも、この目的に焦点を当てていることを願っています。 「タグスープ」に反対する。

いずれにせよ、これはまだベータ版のプラットフォームです。それにもかかわらず、ほとんどのMicrosoftベータテクノロジよりも展開が多くなり、Microsoft以外の開発者が実際のものを構築しています。このように、話題は周囲のインフラストラクチャ（ドキュメント、ガイダンスパターンなど）よりもはるかに進んでいるように見える傾向があります。この時点で実際に使用可能であることは、その効果を増幅するだけです。

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

埋め込みCSSを含めずに、これを行う方法を尋ねる別の投稿を作成できます。

注：ViewData.Modelは、次のリリースでモデルになります。

そして、ユーザーコントロールの助けを借りて、これは

<% Html.RenderPartial("Pager", Model.PagerData) %>

ここで、PagerDataは、アクションハンドラーの匿名コンストラクターを介して初期化されます。

編集：私はあなたのWebForm実装がこの問題のためにどのように見えるか知りたいです。

どの時点で人々がコードを気にするのをやめたのかはわかりません。

HTMLはあなたの作品の最も一般的な表示であり、多くのWebサイトを構築するためにメモ帳、メモ帳++、およびその他のプレーンテキストエディターを使用する開発者がたくさんいます。

MVCは、Webフォームから制御を取り戻し、ステートレス環境で作業し、Model View Controller設計パターンを実装することです。このパターンの実装で通常行われる余分な作業は一切必要ありません。

コントロール、クリーンなコードが必要で、MVCデザインパターンを使用する場合は、これが適しています。マークアップを使用したくない場合は、マークアップがどのように変形されているかを気にせず、ASP.Net Webフォームを使用します。

どちらも気に入らない場合は、マークアップでほぼ同じくらいの作業を行うことになります。

編集 私はまた、WebフォームとMVCがそれぞれの場所にあると述べるべきですが、どちらかが他より優れているとは決して言いませんでした。

いくつか欠けていると思います。まず、Response.Writeは必要ありません<%= %>。タグを使用できます。次に、独自のHtmlHelper拡張機能を記述して、一般的なアクションを実行できます。3番目に、少しの書式設定が大きな助けになります。第4に、これらすべてがおそらくいくつかの異なるビュー間で共有されるユーザーコントロールに固定されているため、メインビューの全体的なマークアップがよりクリーンになります。

マークアップが希望どおりに整然としていないことを認めますが、いくつかの一時変数を使用することで大幅にクリーンアップできます。

さて、それはそれほど悪くはなく、SO用にフォーマットする必要がない場合はさらに良いでしょう。

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

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

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

MVCの大きな問題は、これは長い間使用されてきた概念的なフレームワークであり、Webアプリケーションとワークステーションアプリケーションの両方を水平方向と垂直方向に拡張できる生産的で強力な方法であることを証明しています。それは、AltoとSmalltalkに直接戻ります。マイクロソフトはパーティーに遅れている。ASP.NET MVCを使用して現在実現していることは、非常に原始的なものです。しかし、くそー、彼らは新しいリリースを速くそして激しく注いでいます。

Ruby on Railsの大きな問題は何でしたか？RailsはMVCです。口コミでプログラマーが生産的になる方法になっているので、開発者は変換を続けています。

それは大変なことです。MVCとjQueryの暗黙の裏付けは、プラットフォームに依存しないことが重要であるとMicrosoftが認めている転換点です。そしてそれについて中立なのは、Webフォームとは異なり、Microsoftは概念的にユーザーを固定できないということです。コード自体ではなく、移植可能なMVCの概念であるため、すべてのC＃コードを取得して、別の言語で完全に再実装することができます（たとえば、PHPまたはJavaなど）。（そして、デザインを変更して、コードをほとんど変更せずに、デザインを変更することなくワークステーションアプリとして実装できることがどれほど大きいかを考えてください。Webフォームでそれを試してください。）

マイクロソフトは、Webフォームが次のVB6ではないことを決定しました。

Rob Coneryの投稿を見てください。私はそれを言うだけだと思います。MVCを学ぶ必要があります

ASP.NET MVCフレームワークのWebフォームに対する2つの主な利点は次のとおりです。

1. テスト容易性-WebフォームのUIとイベントは、テストがほとんど不可能です。ASP.NET MVCを使用すると、コントローラーアクションとそれらがレンダリングするビューの単体テストが簡単になります。これには先行開発コストのコストが伴いますが、アプリをリファクタリングして維持する時期になると、長期的に見ればこれが報われることが研究により示されています。
2. レンダリングされたHTMLのより良い制御 -レンダリングされたHTMLは誰も見ないため、あなたはレンダリングされたHTMLを気にしないと述べています。それがHTMLを適切にフォーマットする唯一の理由である場合、それは有効な不満です。適切にフォーマットされたHTMLを必要とする理由は数多くあります。SEO、IDセレクターをより頻繁に使用する機能（CSSとJavaScript）、ビューステートの不足によるページフットプリントの縮小、途方もなく長いID（ctl00_etcetcなど）です。

さて、これらの理由から、ASP.NET MVCがWebフォームより白黒の点で良くも悪くもなりません。ASP.NET MVCには、Webフォームと同じように長所と短所があります。ただし、ASP.NET MVCに関する不満の大部分は、フレームワークの実際の欠陥ではなく、ASP.NET MVCの使用方法についての理解の欠如に起因するようです。コードが正しく感じられない、または見た目が悪いのは、数年のWebフォームの経験があり、1〜2か月のASP.NET MVCの経験しかないためです。

ここでの問題は、ASP.NET MVCが揺さぶられるほどではなく、それが新しく、正しく使用する方法についてほとんど合意がないことです。ASP.NET MVCは、アプリで発生していることをより細かく制御できます。それはあなたがそれらに近づく方法に応じて特定のタスクをより簡単にまたはより難しくすることができます。

ねえ、私もMVCへの切り替えに苦労しています。私は絶対に古典的なASPのファンではなく、MVCレンダリングは私に当時の多くのことを思い出させます。ただし、MVCを使用すればするほど、MVCは成長します。私は（多くの人がそうであるように）Webフォームの人であり、過去数年をデータグリッドなどの作業に慣れてきました。答えはHTMLヘルパークラスです。

つい最近、MVCの「グリッド」にページングを追加する最良の方法を見つけるために2日間を費やしました。これで、Webフォームを使用して、すぐにこれを作成できました。しかし、私はこれを言います... MVC用に構築されたページングヘルパークラスを取得すると、実装が非常に簡単になりました。私には、ウェブフォームよりも簡単です。

そうは言っても、そこにHTMLヘルパーの一貫したセットがあると、MVCは開発者にとってより使いやすくなると思います。近い将来、大量のHTMLヘルパークラスがWebにポップアップ表示されるようになると思います。

それは私が最初にウェブフォームを見たときに私が言ったことだから面白いです。

私はまだasp.net MVCを取得していないことを認めます。私がやっているサイドプロジェクトでそれを使用しようとしていますが、かなり遅くなります。

Webフォームで非常に簡単にできることができないことに加えて、タグスープに気づきました。その観点からは、一歩後退しているように見えます。私はそれが私がそれが良くなることを学んでいるのでそれを望み続けます。

これまでのところ、MVCを使用する最大の理由はHTMLを完全に制御するためであることに気づきました。また、asp.net MVCはWebフォームよりも多くのページを高速で提供でき、これに関連していると考えられます。個々のページサイズは、平均的なWebフォームページよりも小さいです。

主要なブラウザで動作する限り、HTMLがどのように表示されるかは特に問題ではありませんが、ページの読み込み速度とページ幅の使用量は気にします。

それが醜いマークアップであることに私は完全に同意しますが、醜いビュー構文を使用してASP.NET MVCを全体としてオフにすることは公平ではないと思います。ビュー構文はMicrosoftからほとんど注目されていません。私はそれについてすぐに何かが行われることを完全に期待しています。

他の回答では、MVC全体の利点について説明しているため、ビューの構文に焦点を当てます。

Html.ActionLinkおよびHTMLを生成するその他のメソッドを使用するように促すことは、間違った方向への一歩です。このサーバーコントロールのスマックは、私にとって、存在しない問題を解決しています。コードからタグを生成するのであれば、なぜHTMLを使用する必要があるのでしょうか。DOMまたはその他のモデルを使用して、コントローラーでコンテンツを構築するだけです。わかりません、それは悪いですね。ああそうです、懸念の分離、それが私たちが見ている理由です。

正しい方向は、ビューの構文をできるだけHTMLのようにすることだと思います。適切に設計されたMVCを使用すると、コードをコンテンツから分離できるだけでなく、レイアウトの専門家がビューで作業することで（ASP.NETを知らなくても）、生産を合理化できるはずです。後で開発者としてステップインして、ビューのモックアップを実際に動的にすることができます。これは、ビューの構文がHTMLに非常によく似ている場合にのみ実行できます。これにより、レイアウト担当者はDreamWeaverまたは現在人気のあるレイアウトツールを使用できます。一度に数十のサイトを構築していて、生産効率を上げるためにこの方法で拡張する必要がある場合があります。ビュー "language"がどのように機能するかを確認する例を挙げましょう。

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

これにはいくつかの利点があります。

• 良く見える
• より簡潔な
• HTMLタグと<％％>タグの間のファンキーなコンテキスト切り替えはありません
• 自明のキーワードで理解しやすい（プログラマー以外でもこれを実行できます-並列化に適しています）
• できるだけ多くのロジックをコントローラー（またはモデル）に戻します
• 生成されたHTMLはありません。これも、Htmlをいじる必要なしに、誰かがどこにスタイリングするかを簡単に知ることができるようにします。メソッド
• コードには、ブラウザにビューをプレーンHTMLとしてロードしたときにレンダリングされるサンプルテキストが含まれています（ここでも、レイアウト担当者に適しています）。

それで、この構文は正確に何をしますか？

mvc：inner = ""-引用符内のものはすべて評価され、タグの内部HTMLは結果の文字列に置き換えられます。（サンプルテキストは置き換えられます）

mvc：outer = ""-引用符内のものはすべて評価され、タグの外側のHTMLは結果の文字列に置き換えられます。（ここでも、サンプルテキストが置き換えられます。）

{}-<％=％>と同様に、属性の内部に出力を挿入するために使用されます

mvc：if = ""-insde qoutesは、評価されるブール式です。ifの終わりは、HTMLタグが閉じられる場所です。

mvc：else

mcv：elseif = ""-...

mvc：foreach

今、私はここで自分のために話すことができるだけです：

IMO、もしあなたが死ぬほど（何でも）なら、変換はあなたのためではありません。WebFormsが気に入ったのは、必要なことを達成できるからです。それが目標でもあります。

Webformsは、開発者からHTMLを抽象化するのに優れています。それが目的の場合は、Webフォームを使用してください。今日のデスクトップ開発を実現したすばらしい「クリックアンドドラッグ」機能がすべて備わっています。さまざまな機能を実現できる多くのコントロール（およびサードパーティ製のコントロール）が含まれています。データベースからDataSourceに直接関連付けられている「グリッド」をドラッグできます。インライン編集、ページングなどが組み込まれています。

現在のところ、ASP.NET MVCはサードパーティによる制御に関して非常に制限されています。繰り返しになりますが、多くの機能が組み込まれているRapid Application Developmentが好きな場合は、変換を試みるべきではありません。

以上のことをすべて踏まえた上で、ASP.NETの優れた点は次のとおりです。-TDD。コードはテストできません、とnuffは言いました。

• 関心事の分離。それがMVCパターンのバックボーンです。私はあなたがWebフォームでこれを達成できることを十分に承知しています。しかし、私は課された構造が好きです。Webフォームではデザインとロジックを混在させるのは簡単すぎました。ASP.NET MVCを使用すると、チームのさまざまなメンバーがアプリケーションのさまざまなセクションで作業しやすくなります。

• 他の場所から来る：私の背景はCakePHPとRuby on Railsです。だから、私のバイアスがどこにあるのかは明らかです。それは単にあなたが何に慣れているのかについてです。

• 学習曲線：最後のポイントを拡張します。さまざまな要素の機能を変更するために「テンプレート化」するという考えは嫌いでした。コードビハインドファイルで多くの設計が行われたという事実は好きではありませんでした。私がHTMLとCSSに既に精通していたとき、それは学ぶべきもう1つのことでした。ページの「要素」で何かを実行したい場合は、「div」または「span」を挿入し、その上にIDをたたき、次に進みます。Webフォームでは、これを行う方法を調査する必要があります。

• ウェブの「設計」の現状：jQueryのようなJavaScriptライブラリは、より一般的になりつつあります。WebフォームがIDをマングルする方法は、（Visual Studioの外で）実装をより困難にします。

• 分離（デザイン）：多くのデザインがコントロールに関連付けられているため、外部のデザイナー（Webフォームなし）の知識がWebフォームプロジェクトで作業することは非常に困難です。Webフォームは、すべての目的を達成するために構築されました。

繰り返しますが、これらの理由の多くは、Webフォームに慣れていないことが原因です。Webフォームプロジェクト（正しく設計されている場合）には、ASP.NET MVCの「ほとんど」の利点があります。しかし、それは警告です：「正しく設計されている場合」。これは、Webフォームでの実行方法がわからないものです。

Webフォームで優れた作業を行っている場合は、効率的で機能します。この場所にとどまる必要があります。

基本的に、長所と短所のリストを使用して、両方について簡単なレビューを行い（公平なソース[幸運]を見つけてみてください）、どちらが目標に合っているかを評価し、それに基づいて選択します。

結論として、あなたの目標を達成するために最も抵抗が少なく、最も利益のある道を選びます。Webフォームは非常に成熟したフレームワークであり、将来的にはより良くなるでしょう。ASP.NET MVCは、単に別の代替手段です（myself：PなどのRuby on RailsおよびCakePHP開発者で描画するため）。

Java EEのJSPは、最初に提案されたときはこのように見えました-醜いスクリプトレットコード。

次に、タグライブラリを提供して、よりHTMLタグ風にしています。問題は、誰でもタグライブラリを作成できることでした。HTMLを生成するタグライブラリに多くのロジック（およびスタイル）を埋め込んだため、一部の結果は悲惨なものでした。

最良の解決策は、JSP標準タグライブラリ（JSTL）だと思います。これは「標準」のHTMLタグのようなもので、ユーザーがページにロジックを挿入するのを防ぐのに役立ちます。

追加の利点は、Webデザイナーと開発者の間の境界線が維持されることです。私が目にする良いサイトは、美的感覚と使いやすさのために設計している人々によって設計されています。彼らはページとCSSをレイアウトし、動的データビットを追加する開発者に渡します。これらの才能が不足している開発者と言えば、スープからナッツまでのWebページを作成するように開発者に依頼するとき、私たちは重要なものを提供すると思います。FlexとSilverlightも同じ問題に悩まされます。デザイナーがJavaScriptとAJAXをよく知っているとは考えにくいからです。

.NETがJSTLに似たパスを持っている場合は、それらを調べることをお勧めします。

このサンプルが、ASP .NET MVC 3以降のデフォルトである光沢のある新しいRazorビューエンジンでどのように表示されるかを共有したいと思いました。

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

何か問題がありますか？
また、実際にはCSSスタイルをインライン化しないでください。そして、なぜ2か所ではなく3か所で無効性をチェックするのですか？エクストラはdivめったに傷つきません。これは私がそれをする方法です：

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

ASP.NET MVCプロジェクトと直接話すことはできませんが、一般的に言えば、MVCフレームワークがWebアプリケーション開発を支配するようになりました。

1. データベース操作、「ビジネスロジック」、およびプレゼンテーションを正式に分離します。

2. それらは、ビューに十分な柔軟性を提供し、開発者がHTML / CSS / Javascriptを微調整して複数のブラウザー、およびそれらのブラウザーの将来のバージョンで機能できるようにします

重要なのはこの最後のビットです。Webforms、および類似のテクノロジーを使用すると、ベンダーに依存してHTML / CSS / Javascriptを作成します。これは強力な機能ですが、現在のバージョンのWebformsが次世代のWebブラウザーで動作するという保証はありません。

それが見解の力です。アプリケーションのHTMLを完全に制御できます。欠点は、ビューのロジックを最小限に抑え、テンプレートコードをできるだけ単純にするために十分な規律が必要であることです。

つまり、それはトレードオフです。Webフォームが機能していてMVCが機能しない場合は、Webフォームを引き続き使用してください

それに対する私の不満のほとんどは、物事を「適切に」行う方法を知らないだけです。それがプレビューとしてリリースされて以来、私たちは皆、物事を見るのに少し時間がありましたが、彼らはかなり変化しています。最初は本当にイライラしていましたが、フレームワークは非常に複雑なUI（読み取り：Javascript）を素早く作成できるほど十分に機能しているようです。これまでと同じようにWebフォームを使用してこれを実行できることを理解していますが、すべてを正しくレンダリングしようとするとお尻が大変でした。多くの場合、正確な出力を制御するためにリピーターを使用することになりますし、上にある多くのスパゲッティの混乱も発生します。

同じ混乱を避けるために、ドメイン、サービスレイヤー、dtoの組み合わせを使用してビューに転送しています。これを、ビューエンジンであるsparkと組み合わせると、とても美しくなります。セットアップには少し時間がかかりますが、一度実行すると、アプリケーションの複雑さを視覚的に大幅に向上させることができましたが、コードを賢く実行するのは非常に悪臭を放っています。

私はおそらくこれとまったく同じことをすることはないでしょうが、ここにあなたの例があります：

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

それはかなり保守可能で、テスト可能で、私のコードスープでは美味しいです。

要点は、クリーンなコードが実際に可能であるということですが、それは、私たちが行っていた方法からの大きなお尻のシフトです。誰もがまだそれをグロスとは思わない。私はまだそれを理解していることを知っています...

Steve Sandersonが最近出版したApressの書籍「Pro ASP.NET MVC」[1] [2]は、別の代替案、つまりカスタムHtmlHelper拡張の作成を提案しています。彼のサンプル（110ページの第4章から）は、ページ付きリストの例を使用していますが、状況に合わせて簡単に調整できます。

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

次のようなコードを使用してビューで呼び出します。

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Phil Haackからの投稿を見たいと思っていましたが、ここにはなかったので、http：//blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-shouldからカットアンドペーストしました -learn-mvc /（コメントセクション）

ハッキング-2009年4月23日-ロブ、あなたは暴動だ！:) MVCでスパゲッティコードを書いて「見て！スパゲッティ！」ねえ、私もWebフォームでスパゲッティコードを書くことができます！Rails、PHP、Java、JavaScriptで記述できますが、Lispでは記述できません。しかし、それはまだLispで何も書くことができないからです。そして、私がスパゲッティコードを書くとき、マカロニを見ることを期待して不機嫌に私の皿を見ません。これを従来のASPと比較する場合、人々がしばしば指摘する点は、従来のASPでは人々が懸念を混同する傾向があるということです。ページには、ユーザー入力処理がモデルコードと混合されたビューロジックとビジネスロジックがすべて1つに混合されたビューロジックがあります。それがスパゲッティについてでした！懸念をすべて1つの大きな混乱の中に混在させること。ASP.NET MVCを使用すると、このパターンに従えば、そうする可能性は低くなります。うん、あなたはまだあなたのビューに少しのコードを持っているかもしれませんが、うまくいけばそれはすべてのビューコードです。このパターンでは、ユーザー操作コードをそこに配置しないことをお勧めします。コントローラーに入れてください。モデルコードをモデルクラスに配置します。そこ。スパゲッティはありません。今おとろ寿司です。:)

私も; ASP.NET MVCではなくSilverlightに時間を費やします。私はMVC 1.0を試し、数日前に最新の2.0 Beta 1リリースを調べました。

ASP.NET MVCがWebフォームより優れているとは（私は）感じることができません。MVCのセールスポイントは次のとおりです。

1. 単体テスト）
   
2. 設計（ビュー）とロジック（コントローラー+モデル）を分離する
   
3. ビューステートがなく、要素ID管理が向上
   
4. RESTful URLなど...

ただし、コードビハインドを使用したWebフォーム.Theme、Skin、およびResourceは、デザインとロジックを分離するのにすでに最適です。

ビューステート：クライアントID管理はASP.NET 4.0で提供されます。私は単体テストのみを心配していますが、単体テストだけではWebフォームからASP.NET MVCに切り替える理由にはなりません。

多分私は言うことができます：ASP.NET MVCは悪くありませんが、webformはすでに十分です。

私はプレビュー3がリリースされて以来、MVCを使用してきましたが、それでもまだ面倒が増していますが、チーム開発の領域でかなり役立ちます。1人のウェブフォームページで3人で作業してみると、壁に頭をぶつける概念が理解できます。ビューページのデザイン要素を理解している開発者や、コントローラーにすべてをまとめてモデルを機能させる上で、常駐のLinqの神と協力できます。私は、懸念の分離が非常に簡単に達成できる領域で開発することはできませんでした。

ASP.Net MVCの最大のセールスポイント-StackOverflow はMVCスタックで実行されます。

言われていることですが...あなたのコードは私が通常ビューページで行うよりもはるかにきれいです。また、私が作業している人の1人は、HTMLヘルパーをタグライブラリにラップする作業をしています。<％= Html.RandomFunctionHere（）％>の代わりに、次のように機能します

<hh：ランダム関数/>

私はMVCチームがいつかそれを乗り越えてくれることを願っています。彼らがより良い仕事をすると確信しているからです。

ファサードパターンを使用して、表示する必要のあるすべてのデータのすべてのロジックをラップし、それをビューでジェネリックとして使用します。スパゲッティコードは不要です。 http://en.wikipedia.org/wiki/Design_pattern_(computer_science）

さらにヘルプが必要な場合cgardner2020@gmail.com

ASP.NET MVCの実装は恐ろしいものです。平凡な製品は吸います。私はいくつかのデモを見て、MSFTを恥じています...それを書いた人たちは私より頭が良いと思いますが、まるでModel-View-Controllerが何であるかを知らないかのようです。 。

MVCを実装しようとしているのは、MSFTの新しいことを試してみたい人だけです。私が見たデモでは、プレゼンターは謝罪の口調を持っていました...

私はMSFTの大ファンですが、MVCの実装に悩む理由はないと思います。Web開発にWebフォームを使用するか、jqueryを使用するか、この嫌悪を選択しないでください。

編集：

Model-View-Controllerアーキテクチャ設計パターンの目的は、ドメインをプレゼンテーションからビジネスルールから分離することです。私は実装したすべてのWebフォームプロジェクトでパターンをうまく使用しました。ASP.NET MVC製品は、実際のアーキテクチャデザインパターンには適していません。