このサイトをしばらくチェックした後、いくつかの MVC チュートリアルを実行しました。それは私だけですか、それとも MVC View ページは、HTML と ASP.NET に出入りし、いたるところに黄色の区切り文字があり、読むことができない古典的な ASP スパゲッティ コードの恐ろしいフラッシュバックをもたらしますか? コードとデザインの分離の重要性はどうなりましたか?? チュートリアルがビューページ開発セクションに到達するまで、私は本当に新しいテクノロジーに夢中でした.
または、何か不足していますか？（そして、スパゲッティを別の場所に移動するだけなので、テンプレートを使用して役立つとは言わないでください-敷物の下に一掃します-問題は解決しません）
Jeff の投稿 ( http://www.codinghorror.com/blog/archives/001155.html ) と、Rob Conery の回答 ( http://blog.wekeroad.com/blog/asp-net-mvc-回避タグスープ/ )
要約すると、ASP.NET MVC を使用すると、開発者は自分自身を撃つ選択肢を得ることができますが、それをきれいに行うことは確かに可能です。そのため、Web 開発に慣れていてクリーンなスタイルの開発者には適していますが、マークアップを深く掘り下げずに Widgetized 動作を winforms にしたい開発者には適していません。
Finlay Microsoft は、ASP-Classic から ASP.NET ステップへのエラーを修正しています。ASP.NET が複雑すぎたため、古い ASP プログラマーの 70% が PHP に移行しました。
彼らは、ASP.NET のドラッグ アンド ドロップ メニューですべてを解決できると強く主張しています。そして最後に、すべてがフォームタグ内にあります! Web サイトではなく、大きな「Web フォーム」を構築しています。ASP.NET サイトの HTML を見てください。絶対に恐ろしい！
ASP.NET MVC は、すっきりと整理された HTML コードと強力なビジネス ロジックに対する新しい希望です。
デフォルトのビュー エンジンが気に入らない場合は、別のビュー エンジンを使用できます。
Scott Guthrie のブログによると:
チームが ASP.NET MVC で行ったことの 1 つは、任意の種類の "ビュー エンジン" を使用できるようにすることです。これにより、必要に応じてレンダリング エンジンを柔軟にカスタマイズできます。
将来的には、さらに宣言的なビュー エンジンを調査する予定ですが、具体的な計画はまだありません。
代替ビュー エンジンの例としては、ここで説明するNHaml 、ここで説明するSpark 、およびここで説明するNVelocityがあります。
MVC と汎用 ASP.NET は、自動送信と手動送信の違いと同様です。どのギアをどの目的に使用するか、いつシフトするかを決定し、効率を最適化する場合は、マニュアルを使用してください。うまく動作するが、あまり最適化されていないか、柔軟性がなく、デバッグが容易でない可能性がある場合は、自動を使用します (頻繁に行う必要はありません)。
クラシック ASP は 2 速のみのマニュアル トランスミッションでした。
違いは、MVC では、ビューが行う唯一のことはディスプレイのレンダリングであるということです。ビジネス ロジック、I/O 処理、およびモデル関連のコードはすべて、コントローラーとモデル クラスにあります。ビューに含まれるコードの量は比較的少なく、コンパクトです。一般的に使用されている場合は、ユーザー コントロール (部分ビュー) に抽象化できます。
個人的には、ビューをさらに制御できる点が気に入っています。Webフォームでの私の時間のほとんどは、クライアント側で多くのことを行うのを困難にする、作成されたデフォルトの仮定 (およびマスター/子ページによって導入された名前マングリング) を回避するために費やされたようです。
編集: HtmlHelper 拡張メソッドを作成する機能について言及するのを忘れていました。これにより、多くのものをバックエンドにも移動できます。全体として、コントローラー、モデル、および拡張メソッドの間で、従来の ASP または ASP.NET Web フォームのいずれかよりも MVC で簡単にテストできるコードがさらに多くなります。
しばらく MVC をプログラミングした後、ASP.NET に戻ります。
MVC は確かに従来の ASP や PHP から一歩前進したものですが、ASP.NET と比較すると大きく後退しています。
ASP.NET では数ステップでプログラミングできる多くのことを、MVC ではさらに多くの作業が必要になります。締め切りに間に合わせるのが難しくなります。
この技術にはメリットがありますが、まだ成熟していません。
たぶんバージョン3.0で...
ASP.NET ビュー エンジンの問題は、XHTML に埋め込まれた .NET 言語にすぎないため、実行できることに制限がないことだと思います。
対照的に、Django テンプレート エンジンを見てください。Django フレームワークでは、コントローラとモデルは本格的な Python 言語を使用して記述されますが、ビュー テンプレート エンジンは、基本的なプログラミング構造 (条件付き、ループなど) のみを提供する制限された言語を定義します。この制限付き言語は Python に似ていますが、実際には Python ではないため、外部ライブラリのような任意のコードを呼び出すことはできません。ビューに渡されたモデル データにのみアクセスできます。
汎用言語を組み込んだビューエンジンには、人々がそれを悪用し、ビューですべきではないことを行うという問題があります。そのため、これらのエンジンでは、モデル データへのアクセス以外のことを行わないように十分な注意を払う必要があります。
asp.netmvcの最も騒々しいサポーターの何人かによって示されているn層/層の設計の理解の欠如にいつも驚いています。SOCは常にWebフォームで実現可能です。MVPなどのUIパターンは、常にWebフォームで実現可能です。多くの開発者が設計方法を知らないのは、プラットフォームの障害ではありません。
スパゲッティの質問に戻ると、私は同意する必要があります。ビューに条件付きロジックまたはテスト不可能なコードスニペットが大量に含まれている場合、ビューは「ダム」ではありません。
個人的には、MVCパターンよりもMVPパターンの方がはるかに好きです。
StringTemplateビュー エンジンをチェックしてください。見栄えがよく、きれいに見えます。
これは PDC で言及されましたが、<%=. しかし、彼らは標準の ASP.Net タグ付けとコントロールを追加することにも言及しました。
彼らの全体的な方向性は、安定したリリースを取得してから、作業を容易にすることです。
PDC ビデオ: http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv
関心の分離についてです。従来の ASP では、ビジネス ロジックとプレゼンテーション ロジックが混在し、厄介なインクルードがライブラリに投入されていました。
この時点で構文は似ていますが、目的は異なります。ビューでは、プレゼンテーション ロジックのみを実行する必要があります。そこにビジネス ロジックを配置することはできますが、それを止めるものは何もありません (残念ながら)。それは開発者次第ですが、これは今でも私の最大の関心事です。
従来の ASP では、ビジネス ロジックを UI レイヤーの外に移動するという選択肢はありませんでした。ASP.Net MVC では、「スパゲッティ」コードは UI レイヤーであるビューに分離されています。ロジックの 90% は、通常の非スパゲッティ C# クラスである "M" レイヤーと "C" レイヤーにあります。
ビューは「ダム」であることを意図しています。ビジネス ロジックの観点からは、重要なことは何もありません。それはほとんど使い捨てであることを意味します。
構造に損傷を与えることなく、部屋を乱雑にペイントできます。きれいにして再塗装することにした場合は、建築家に電話する必要はありません。ビューと同じです。
記録のために ：
ASP MVC の本当の問題はコントローラーだと思います。(ほとんどの言語で) いくつかのテンプレート スキームを使用 (またはエミュレート) するのは簡単で (ASP クラシックでも)、どの言語でも (オブジェクトを使用するかどうかに関係なく) モデルを実行できますが、MVCコントローラーをビューとモデルから分離することを強制し、プロセスのコードを肥大化させます。
一般的な Web サイトは full-form-post/get と AJAX に依存しています。両方を使用すると、MVC から "C" を混乱させることになります。
最終的に、ほとんどのプログラマーは「不正行為」を終了し、Ajax 呼び出しを VIEW レイヤーに配置します。
MVC の背後にいる人々は ASP/JSP ページを非常に気に入っており、もう一度実装したいと考えているからです。彼らは次のことを嫌っているようです。
彼らは次のことを愛しているようです：
MVC は本質的に、コードをプレゼンテーションから強制的に分離する方法です。開発者が十分に気を配っていれば、通常の Asp.Net で簡単に実現できます。とにかく「分離」システム全体をパンクさせることは可能であるため、私にはそのポイントがよくわかりません.
そうは言っても、それにはいくつかのメリットがあります..しかし、問題を上回るほどではありません. MVC バージョン 3 は素晴らしいものになると確信しています。
そして、だれかが私に -1 の評価を下す前に、私が回答した MVC の質問の数を確認してください。私は私が話していることを知っています。
更新 分離を真剣に考えている場合、それを見ると、chaiguy1337 は良い方向に進んでいます。 String Template は、フロント エンドでコードを許可しないため、見栄えがします。私の意見では、ASP.net MVC チームは MVC にボールを落としました。