0

私が苦労しているのは、もっと哲学的に、DropDownListアイテム(または実際にはあらゆる種類の選択リストアイテム)をモデルの一部にするべきか、それともUIまたはビジネスレイヤーにハードコーディングするべきかということです。それとも、これはViewModelの良い使い方ですか?

ドロップダウンリストの種類によっては、明らかにそれらをモデルの一部にする必要があります。たとえば、顧客に関連付けられている注文IDのドロップダウンリストは、モデルによって生成される必要があります。

私が「ルックアップ」データと呼ぶ他の種類は、私にはあまり明確ではありません。たとえば、性別。フィールドに2つのアイテムを入力するために、ラウンドトリップルックアップを強制するのはなぜですか?おそらくこれは時期尚早の最適化ですが、50個のフィールドがある場合、1ページに入力するだけで多くのラウンドトリップになります。確かに、キャッシュはそこで役立つかもしれませんが、それは厄介なようです。

また、これらすべてのルックアップリストをモデルに追加すると、モデルが不必要に乱雑になるのではないかと心配しています。特にあなたがそれらをたくさん持っているなら。

UIでハードコーディングするのではなく、ビジネスレイヤーでハードコーディングするオプションもあります。おそらく、このデータを入力するだけのクラスを作成することさえあります。

答えが「データモデル」の一部である場合でも、データモデルにルックアップフィールドのセットごとに異なるテーブルを設定する必要があるかどうかという問題があります。データモデルにそのようなフィールドが200または300ある場合、それは200または300のテーブルであり、データモデルの保守が実際に複雑になります。

しばらく前に共通のルックアップテーブルを使用することについて質問しましたが、これは悪い考えであるというコンセンサスがありました。しかし、フィールドがたくさんある非常にデータ量の多いアプリケーションの場合、私は自分自身に疑問を感じます。

さて、多くの方が「状況次第」とおっしゃる方もいらっしゃると思いますが、私は「一般的な」答えを見ています。一般的に、ここでの経験則は何ですか?

4

3 に答える 3

2

私はたくさんの辞書を使って1つのシステムを構築することに参加してきました。それらのほとんどは、辞書のID、アイテムのID、その名前、およびその他の基本的な値を含む1つの単純なテーブルに格納されていました。このテーブルの一部のアイテムには事前定義されたIDがあり(たとえば、male = 1001、female = 1002)、テーブルにgender_idフィールドがある場合、男性を検索するために辞書テーブルを検索する必要はなく、そのIDを知っていました。これらのIDは、コードでは定数として定義されていますが、表示のためにデータベースから取得されています。それはうまく機能し、パフォーマンスは悪くありませんでした(数百の辞書、数千のアイテム)。それらは、ビューモデルで表示するために渡すことができます。編集者のビューモデルは次のようになります。

public class PersonViewModel {
    public Person Person { get; set; };
    public SelectList Genders { get; set; };
    public SelectList Departments { get; set; };
    public SelectList Positions { get; set; };
}

ビューに次のコードを入力できます。

Genders = DictionaryService.GetDictionary(Dictionaries.Genders);
Departments = DictionaryService.GetDictionary(Dictionaries.Departments);
Positions = DictionaryService.GetDictionary(Dictionaries.Positions);

Dictionaries列挙型はどこですか。

メソッドではDictionaryService.GetDictionary()、ある種のキャッシングを導入できます。

アイテムの数に制限がないドロップダウンにデータを入力する場合(フィールドの場合、他のテーブルへの参照があり、時間の経過とともに大きくなる)、動的に(ajax)ロードされたアイテムで何らかのインクリメンタルサーチを使用します。

于 2011-02-12T21:35:25.160 に答える
1

私はあなたの質問を言い換えるつもりです。モデルはモデルです。選択肢のコレクションがモデルの一部である場合、それらはモデルの一部です。データモデルには、実装方法に関係なく、内部整合性と整合性があります。

では、問題は、モデルに含まれている代替案のセットをドロップダウンリストとして実装する必要があるかどうかということです。私の答えはイエスです、時々。

「性別」のような場合、質問は「近い将来、性別のセットに追加される可能性はどのくらいあるか」です。可能性が非常に高い場合は、往復料金を支払う方がよい場合があります。可能性がゼロの場合は、選択肢をUIにハードコーディングすることをお勧めします。

数年前、私はセット[男性、女性]への追加は完全にありそうになかったと言っていたでしょう。今日、違った意見をする人がいます。

于 2011-02-12T20:31:02.450 に答える
0

大きなリストがあり、サーバー上で動的にフィルタリングする必要がある場合は、アクションへのajax呼び出しが必要です。

一連のオプションを使用して選択をレンダリングする場合、またはクライアント側でフィルタリングする値のjson配列のみをレンダリングする場合は、ドロップダウンアイテムをViewModelに追加し、このコレクションをControllerに入力することをお勧めします。リストは当面ハードコーディングされる可能性がありますが、ViewModelやUIにまったく触れずにコントローラーを変更するだけで、後で動的にする(つまり、データベースから読み取る)ことができます。

コードサンプルについては、次のリンクを確認してください:http: //odetocode.com/blogs/scott/archive/2010/01/18/drop-down-lists-and-asp-net-mvc.aspx

于 2011-02-12T20:28:52.563 に答える