15

StackOverflow について初めて聞いたとき、それが ASP.Net MVC で構築されていると聞いたとき、少し戸惑いました。ASP.Net は常に MVC アーキテクチャの例だと思っていました。ビューを提供する .aspx ページとコントローラーを提供する .aspx.vb ページがあり、モデルとなる別のクラスを作成できます。ASP.Net で MVC を使用するプロセスについては、このMicrosoft の記事で説明されています。

だから私の質問はです。ASP.Net MVC は、通常の ASP.Net (ASP.Net 1.1 までさかのぼっても) ではできないことを提供しますか? それはただの派手な URL ですか？MS が Ruby On Rails のような新しいテクノロジーと自分たちを比較して、「私たちにもできる」と言うのは自慢する権利のためだけですか? File->New メニューのいくつかの追加のテンプレートではなく、ASP.Net MVC が実際に提供するものはありますか?

私はおそらく今、本当に懐疑的で否定的に聞こえるので、やめておきます。しかし、ASP.Net MVC が実際に提供するものを知りたいと思っています。また、上から下に行くか、その逆かによって、View-Controller-Model または Model-Control-View のレイヤーの順序ではなく、Model-View-Controller である理由を誰かが教えてくれれば、私はそれも本当に感謝しています。

編集

また、私は Web フォーム (別名サーバー コントロール) モデルもあまり気にしたことがないことを指摘しておく価値があるでしょう。私はそれを最小限しか使用しておらず、仕事で使用したことはありません。

4

7 に答える 7

14

aspx ページ (「ビュー」) がコード ビハインド (「コントローラー」) の前に呼び出されるため、.aspx は MVC パターンを満たしません。

これは、コントローラーがビューに「強い依存関係」を持っていることを意味し、これは MVC の原則に非常に反しています。

MVC の主な利点の 1 つは、実際のビューをインスタンス化せずに (多くのロジックを含む) コントローラーをテストできることです。.aspx の世界では、これを行うことはできません。

コントローラーを単独でテストする方が、asp.net パイプライン全体 (アプリケーション、要求、応答、ビュー ステート、セッション ステートなど) をインスタンス化するよりもはるかに高速です。

于 2008-09-17T23:56:12.090 に答える
7

Scott Guthrie は、この投稿 " ASP.NET MVC Framework "で説明しています。

  • デフォルトで、懸念事項、テスト容易性、および TDD を明確に分離できます。MVC フレームワーク内のすべてのコア コントラクトはインターフェイス ベースであり、簡単にモック可能です (インターフェイス ベースの IHttpRequest/IHttpResponse 組み込み関数が含まれます)。ASP.NET プロセス内でコントローラーを実行しなくても、アプリケーションの単体テストを実行できます (単体テストが高速になります)。このテストを実行したい任意のユニット テスト フレームワークを使用できます (NUnit、MBUnit、MS Test などを含む)。

  • 拡張性が高く、プラグ可能です。MVC フレームワークのすべては、簡単に置き換え/カスタマイズできるように設計されています (たとえば、オプションで独自のビュー エンジン、ルーティング ポリシー、パラメーターのシリアル化などをプラグインできます)。また、既存の依存性注入および IOC コンテナー モデル (Windsor、Spring.Net、NHibernate など) の使用もサポートしています。

  • これには、クリーンな URL を使用してアプリケーションを構築できる非常に強力な URL マッピング コンポーネントが含まれています。URL に拡張子を含める必要はなく、SEO および REST に適した命名パターンを簡単にサポートするように設計されています。たとえば、/products/edit/4 URL を上記のプロジェクトの ProductsController クラスの「編集」アクションに簡単にマップしたり、/Blogs/scottgu/10-10-2007/SomeTopic/ URL を「 BlogEngineController クラスの DisplayPost" アクション。

  • MVC フレームワークは、既存の ASP.NET .ASPX、.ASCX、および .Master マークアップ ファイルを「ビュー テンプレート」として使用することをサポートします (つまり、ネストされたマスター ページ、<%= %> スニペット、宣言などの既存の ASP.NET 機能を簡単に使用できます)。サーバー コントロール、テンプレート、データ バインディング、ローカリゼーションなど)。ただし、サーバーへの相互作用に既存のポストバック モデルは使用しません。代わりに、代わりにすべてのエンドユーザーの対話を Controller クラスにルーティングします。これにより、懸念事項とテスト可能性を明確に分離できます (MVC ベースのビューではビューステートやページのライフサイクルがないことも意味します)。

  • ASP.NET MVC フレームワークは、フォーム/ウィンドウ認証、URL 承認、メンバーシップ/ロール、出力およびデータ キャッシュ、セッション/プロファイル状態管理、ヘルス モニタリング、構成システム、プロバイダー アーキテクチャなどの既存の ASP.NET 機能を完全にサポートします。

于 2008-09-18T09:43:30.570 に答える
1

主に、責任の分離が明確に定義されたテスト可能な Web サイトの作成が非常に簡単になります。また、新しい MVC フレームワークを使用して、有効な XHTML UI を作成するのがはるかに簡単になります。

私は 2 番目の CTP (現在は 5 だと思います) を使用して Web サイトで作業を開始しました。以前にいくつかの Web アプリケーションを作成したことがありますが、サーバー制御モデルを使用するよりも何百倍も優れていると言わざるを得ません。

自分が何をしているのかわからない場合、サーバー コントロールは問題ありません。Web アプリケーションがどのように機能するべきかを学び始めると、それらとの戦いが始まります。最終的には、現在のコントロールの欠点を克服するために独自のものを作成する必要があります。この時点で、MVC が輝き始めます。そして、それはあなたのウェブサイトのテスト容易性を考慮していません...

于 2008-09-17T23:58:02.613 に答える
1

自動生成された html ID はもうありません!!! あらゆる種類の JavaScript を実行している人は、この事実を高く評価しています。

于 2008-09-18T00:12:43.220 に答える
0

Article about ASP.net MVC Vs ASP.net Web form

http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx

于 2008-09-18T09:36:29.633 に答える
0

コード ビハインドを含む ASP.Net はほぼMVC ですが、MVC の大きなコンポーネントである aspx にコード ビハインドが直接結び付けられていることが大きな原因の 1 つです。コードビハインドをコントローラーと考えている場合は、ビューから完全に分離する必要があります。新しい .NET MVC はこれを完成させ、完全な MVC フレームワークをもたらします。.NET 用の既存のものは既にありますが (Spring.NET を参照)。

于 2008-09-17T23:54:18.317 に答える
0

このようないくつかの簡単な例を調べました。なんとなく違いがわかります。ただし、MVC がコントローラーからビューを切り離す方法はよくわかりません。ビューはまだコントローラー内のものを参照しています。テストがはるかに簡単になり、少なくともMVCではコントローラーがビューの知識を持っていないことがわかります。また、コントローラーでメソッドを呼び出すためにビューを処理する必要はありません。一見大したことないように見えるかもしれませんが、これはかなりの飛躍であることがわかります。

サーバー制御との戦いについては @Will に同意します。私はそれらが実際に使用された状況で働いたことはありませんが、私が知っている多くの人々は、それらを使用してかなりの制限に遭遇しました.

于 2008-09-18T00:10:40.417 に答える