JsonResultの動作が変更されました
JsonResultのようなクラスから始めましょう。 JQuery Gridは私と一緒に働いています。 MVC 2では、デフォルトでJsonResultがJSONの回転を開始しましたが、これはGETリクエストには無効です。 グリッドが無効なJSONを受信し、それを撃退できませんでした。 これは、呼び出しを変更することで処理されます。
//convert to JSON and return to client
// GET MVC1
return Json(result);
//convert to JSON and return to client
// MVC2,
return Json(result,JsonRequestBehavior.AllowGet);
HTMLヘルパーは有効なフォーム要素IDのみを生成するようになりました
私のプロジェクトでは、MS EnterpriseLibraryのバリデーターと属性に基づいて、クライアント側とサーバー側の検証ライブラリを使用しています。 クライアントでの検証用のコードは、特別なクラスによって生成されます。 クライアント（スクリプト）で検証するためのフォーム要素の選択は、IDに基づいています。 MVC1は、レンダリングされるオブジェクトプロパティの名前に基づいてIDを生成しました。
<%= Html.TextArea("_", Model._, 2, 30)%>
生成者：
textarea cols="30" id="_" name="_" rows="2"
MVC2では、この動作が変更されました。ヘルパーは、有効なIDのみ、つまり、キリル文字を含まないIDのみを生成します。 そして...クライアントの検証が機能しませんでした、なぜなら エレメント「Real_Name」のIDは生成されず、スクリプトはそれを見つけようとしました。
MVC2の問題を解決する：
<%= Html.TextArea("_", Model._, 2, 30, new { id = "_" })%>
これは良い解決策ではありません、なぜなら ハードコーディングを使用しています。 しかし、MVCパターンのおかげで、ほとんどの場合、名前を変更した場合にどこで何を変更する必要があるかがわかります。 MVC2では、ビュー内の文字列のこの悪い動作を取り除くのに役立つ型付きヘルパーが登場しました。
String.Emptyの代わりに空のHTMLフォームフィールドをバインダーはnullを割り当てます
その本質はタイトルに反映されています。 クラスにnullableプロパティがありますが、それにバリデーターがあるとします：
[StringLengthValidator(250, MessageTemplate = " 250 ")]
public string {get; set;}
MVC1では、バインダーは空のフィールドにString.Emptyを設定し、バリデーターはエラーなしで実行されます。 String.Emptyはゼロ文字の文字列であり、スキップします。
MVC2では、バインダーはnullに設定され、バリデーターは例外をスローします。 検証は失敗します。
問題を解決するために、バインダーを作成しませんでした。 これにより、プロジェクトがさらに複雑になります。 このプロジェクトには、できる限り少ない数の自己記述要素を含める必要があると思います。このような小さな修正のために、独自のバインダーを記述することは実用的ではありません。
オブジェクトのプロパティを次のように変更しました。
（この機能の部分は十分にローカライズされており、追加の依存関係を導入しないと言えます）
[StringLengthValidator(250, MessageTemplate = " 250 ")]
public string
{
get
{
return this._.;
}
set
{
if (value == null) this._. = string.Empty;
else
this._. = value;
}
}
バインダーはbind = excludeでマークされたフィールドを読み取ります
次のクラスがあります。
[System.Web.Mvc.Bind(Exclude = "_,_")]
public class View : IView
{
public View()
{
this._ = new ();
this._.Reference.EntityKey =
new System.Data.EntityKey("ModelWebUchetCon.", "_", 0);
this._.Reference.EntityKey =
new System.Data.EntityKey("ModelWebUchetCon.", "_", 0);
this._.Reference.EntityKey =
new System.Data.EntityKey("ModelWebUchetCon.", "_", 0);
this._.Reference.EntityKey =
new System.Data.EntityKey("ModelWebUchetCon.", "_", 0);
this._.Reference.EntityKey =
new System.Data.EntityKey("ModelWebUchetCon.", "_", 0);
this._. = string.Empty;
}
public View( Base)
{
this._ = Base;
}
}
コンストラクターは2つあります。1つ目は完全に新しいオブジェクトを作成し、2つ目は既存のものに基づいてオブジェクトを作成します。 最初のコンストラクターは、上書きされる値でフィールドを初期化します。 MVC1では、バインダーは（検証、読み取り、書き込みの目的で）Bind属性によってフィルター処理されていないフィールドでのみ機能するため、最初のコンストラクターでは初期化しません。 MVC2では、モデル全体の検証が使用されます。つまり、オブジェクトのすべてのプロパティの有効性がチェックされるため、最初のコンストラクターによって初期化されていないプロパティを含むすべてが読み込まれ、NullReference例外が発生します。 この動作を克服するには、これらのプロパティの初期化ロジックを含める必要がありました。 おそらく誰かが完全なモデル検証を無効にするクラスの属性を書くでしょう。 コントローラー全体のこのような属性の例があります 。
web.configファイルへの変更
.NET 4.0では、web.configは顕著にクリーンアップされています。 以前は、.NET 2.0以降に登場したすべてのアドオンがこのファイルに登録されていました。 新しいCLRがリリースされたため、この必要性はなくなり、構成を大幅にクリーンアップできます。 すべてがスムーズに進むために、これを行うことをお勧めします。
- 古い構成のバックアップを作成します。
- 新しいMVC2プロジェクトを作成します。
- 「構成をクリーンアップする」プロジェクトで必要なすべてのアセンブリを新しいプロジェクトに接続します。
- 古い構成から新しい構成に追加します。接続文字列、アプリの設定、データプロバイダー、セキュリティに関連するすべてのもの、もしあれば、汎用モジュール、ハンドラー。
- ターゲットプロジェクトに新しい構成を追加します。
おわりに
私たちが知っているように、.netの新しいバージョンへの移行は必ずしも簡単ではありません。 Microsoftは2年ごとに私たちを幸せにして失望させています。 この記事では、主に私が少しがっかりして汗をかいた原因について説明しましたが、プロジェクトを再テストし、明らかでないランタイムエラーを探して修正する必要がありました（以前はすべて機能していました）。 確かに、IEがAjaxリクエストをキャッシュするという事実に関連するエラーを見つけることができました。 つまり、プロジェクトで起こった本当の間違いを見つけました。 プラスがあります。