BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Chad Myers氏およびJeremy Miller氏:ASP.NET MVCデベロッパに対する意見

Chad Myers氏およびJeremy Miller氏:ASP.NET MVCデベロッパに対する意見

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オブジェクトの一部のビューをレンダリングする。

原文はこちらです:http://www.infoq.com/news/2008/12/ASP-MVC-Opinions

この記事に星をつける

おすすめ度
スタイル

BT