Chad Myers氏およびJeremy Miller氏は、ASP.NET MVCがどう動作すべきかに関して意見を述べている。一連のガイドラインとして、KaizenConf(リンク)にてこれらの意見を示した。Jeremy氏の要旨(リンク)は以下のとおりである。
その提案の中核は、Controllersのパワーを制限することに重点が置かれている。その設計では、Controllersの面が非常にデータ中心で、入力と出力がそれぞれ単一のViewModelに制限されている。HttpConextのいずれの側面も公開しないことで、Controllererはますます容易にユニットテストすることができる。
ControllersがHTTP成果物に公開されていないだけでなく、ビジネスロジックはないほうがよい。
Controllersは、 シンであるべきである。Controllerの動作での唯一のジョブは、適切なサービスコールに入ってくるモデルを変換して、出力モデルオブジェクトを作 成することである。ビジネスロジックのすべての責務は、UI以外のサービスクラスに委任することで完了する。言い換えれば、ビジネスロジックは、 Controllerに立ち入らない。
その通りである。計画では、MVCはすべてではなく、それ以外にもデータ操作やストレージの実作業を処理するものがある。
検討することはさらにあるが、省略し、HTMLやJavaScriptを取り囲む問題に進む。
サーバサイドのマークアップは、クライアントサイドのJavaScriptと混合しない。あまりにも一般的過ぎる技法が読み取り不可能なコードの原因となり、クライアントサイドの JavaScriptをTDDする機能を削除するというのが、われわれの意見である。callFunction(‘<%=Model.Variable%>’)が許可されていない。サーバサイドデータがクライアントサイドJavaScriptにパスされる必要がある場合、「var something = <% =Model.Variable%>」を記述することで実行する。
ビューは、非常に単純でなければならない。if/thenステートメントまたはある種のループ表現を使用している場合、間違ったことをしている。条件付きロジックは、ControllerもしくはQUnitでテスト可能なJavaScriptライブラリに属する。ビューの最小のロジック、もしくはまったくないことが、ロジックをハードからテストコードに移行し、エラーを減少させ、コードのテストを簡単にする。また、JavaScriptはユニットテストが簡単だと言える。Tag Soupは回避可能である。ループ構造を以下のような、独自の一部の実装に移行しがちである：<%= this.RenderPartialForEachOf(m => m.Solution.Resolutions).Using
()%>コードのブロックで、EditResolutionはASCX 制御を参照し、m.Solutution.ResolutionsはタイプIList のプロパティである。このス テートメントは、リストで繰り返し適用され、各Resolutionオブジェクトの一部のビューをレンダリングする。