3

私は最近 MVC プロジェクトを開始しましたが、現在、5 分ごとに、このことをどのように進めたいかについて、大きな重要な設計上の決定に直面しているようです。いつも通りですよね？

ドメイン モデル クラスをビューから完全に除外することにしました。似たようなViewModelが大量に生成されますが、AutoMapperを使用しても問題はないと思いますし、きれいなアプローチだと思います。

ただし、私の最近の議論は表示ロジックに関するものです。MyDatatype のプロパティを持つモデルがあるとしますStatus。これは次のような列挙型です。

public enum Status {
   Ok,
   NotTooGreat,
   CouldBeBetter,
   Awful
}

ビューでは、このモデルをレンダリングするときに、ステータスを出力し、さらに状況の悪さに応じて出力を色付けしたいと考えています。たとえば、 の場合Okは緑、NotTooGreatまたはのCouldBeBetter場合は黄色、それ以外の場合は赤を表示しAwfulます。

このロジックはどこに置くべきですか? 最終的に、色の選択自体はビュー内にあります (たとえば、出力する css クラスを決定し、そのクラスが色を制御します)。可能なオプションは次のとおりです。

  1. カスタム 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 を作成する可能性はありますか? 現在の状態に応じて、ユーザーがどのアクションを実行できるかについても述べる必要がある場合、これらは肥大化しないでしょうか?

  2. ViewModel をシンプルに保ち、マッピング コードに依存してロジックを格納します。

    public class MyDataViewModel {
     /* Amongst other MyData properties required... */
     public string StatusText; 
     public DisplayState Status;
}

    これは、ViewModel が、どの状態がどの DisplayState に関連付けられているかについての知識を持たないことを意味します。それは、存在する可能性のあるさまざまな DisplayStates (つまり、OK、警告、またはエラー) を知っているだけです。ただし、これには、「マッピング」のように感じられないマッピングコード内にそのロジックを配置する必要があります-これまで、Model + ViewModel間のマップはコントローラーによる非常に単純な呼び出しでした-しかし、おそらくそれは不必要な恐れですか?

  3. これはビュー内にある必要があり、ViewModel はモデルと同じままである必要があり、View または HtmlHelper 内のコードによって、出力するクラスが何であるかに基づいて決定されますStatus。

1番に傾いていると思いますが、他の方のご意見をいただければ幸いです。頭に浮かぶことの 1 つは、これは非常に単純な例ですが、View がもっと複​​雑な場合はどうなるでしょうか? たとえば、MyDataステータスが の場合Ok、Model からさらに多くのプロパティをMyDataユーザーに表示したり、他の Model クラスからもデータを取得したりしたいとしますか?

4

1 に答える 1

1

この特定のケースでは、3.の方が簡単だと思います-Statusビューモデルに列挙型プロパティを残し、それをフォーマットするカスタムヘルパーを用意します。1 は好きではありません。同じ列挙型を複製していて、多くのデータ注釈が作成される可能性があるためです。不要なようです。

ちなみに2.も良い選択肢のようです。変換をマッピング ロジックに入れることについて心配する必要はありません。

于 2012-11-21T06:59:08.267 に答える