私は最近 MVC プロジェクトを開始しましたが、現在、5 分ごとに、このことをどのように進めたいかについて、大きな重要な設計上の決定に直面しているようです。いつも通りですよね?
ドメイン モデル クラスをビューから完全に除外することにしました。似たようなViewModelが大量に生成されますが、AutoMapperを使用しても問題はないと思いますし、きれいなアプローチだと思います。
ただし、私の最近の議論は表示ロジックに関するものです。MyData
type のプロパティを持つモデルがあるとしますStatus
。これは次のような列挙型です。
public enum Status {
Ok,
NotTooGreat,
CouldBeBetter,
Awful
}
ビューでは、このモデルをレンダリングするときに、ステータスを出力し、さらに状況の悪さに応じて出力を色付けしたいと考えています。たとえば、 の場合Ok
は緑、NotTooGreat
またはのCouldBeBetter
場合は黄色、それ以外の場合は赤を表示しAwful
ます。
このロジックはどこに置くべきですか? 最終的に、色の選択自体はビュー内にあります (たとえば、出力する css クラスを決定し、そのクラスが色を制御します)。可能なオプションは次のとおりです。
カスタム ViewModel クラスで DataAnnotations を使用します。
public class MyDataViewModel { /* Amongst other MyData properties required... */ public StatusViewModel Status; } public enum StatusViewModel { [StatusDisplay(DisplayState.Ok)] Ok, [StatusDisplay(DisplayState.Warning)] NotTooGreat, [StatusDisplay(DisplayState.Warning)] CouldBeBetter, [StatusDisplay(DisplayState.Error)] Awful }
これは、私のマッピングがかなりばかげており、列挙型を値でマッピングできることを意味します。その後、View は HtmlHelper に依存して、DataAnnotation に従って出力を変更します。これはかなり単純明快に思えますが、これは ViewModel に「ビジネス」ロジックを入れすぎているのでしょうか? とはいえ、これは単なる UI の問題ではないので、ViewModel が表示状態を定義することは完全に有効ですか? このようにして大量のカスタム DataAnnotations を作成する可能性はありますか? 現在の状態に応じて、ユーザーがどのアクションを実行できるかについても述べる必要がある場合、これらは肥大化しないでしょうか?
ViewModel をシンプルに保ち、マッピング コードに依存してロジックを格納します。
public class MyDataViewModel { /* Amongst other MyData properties required... */ public string StatusText; public DisplayState Status; }
これは、ViewModel が、どの状態がどの DisplayState に関連付けられているかについての知識を持たないことを意味します。それは、存在する可能性のあるさまざまな DisplayStates (つまり、OK、警告、またはエラー) を知っているだけです。ただし、これには、「マッピング」のように感じられないマッピングコード内にそのロジックを配置する必要があります-これまで、Model + ViewModel間のマップはコントローラーによる非常に単純な呼び出しでした-しかし、おそらくそれは不必要な恐れですか?
これはビュー内にある必要があり、ViewModel はモデルと同じままである必要があり、View または HtmlHelper 内のコードによって、出力するクラスが何であるかに基づいて決定されます
Status
。
1番に傾いていると思いますが、他の方のご意見をいただければ幸いです。頭に浮かぶことの 1 つは、これは非常に単純な例ですが、View がもっと複雑な場合はどうなるでしょうか? たとえば、MyData
ステータスが の場合Ok
、Model からさらに多くのプロパティをMyData
ユーザーに表示したり、他の Model クラスからもデータを取得したりしたいとしますか?