2

IEnumerable に入力された詳細ビューがあります。レンダリングされたレコードのリストにフィルターを追加できる一連のドロップダウンを備えたビュー。

これらのドロップダウンはすべて、MVC モデルのプロパティに対応しています。

public class Record
{
    public string CustomerNumber { get; set; }
    public string CustomerName { get; set; }
    public string LineOfBusiness{ get; set; }
    public DateTime? Date { get; set; }
}

現在、モデルを dto として使用して、コントローラーとレポの間でデータをシャッフルしています。ドロップダウン フィルターはすべてモデル プロパティを表しているため、モデルをレポ検索メソッドに渡し、そのプロパティをチェックし、その値に基づいてフィルター処理しますか? 言い換えると：

 public IEnumerable<TradeSpendRecord> Get(TradeSpendRecord record)
    {
        IQueryable<tblTradeSpend> query = _context.tblRecords;


        if (!String.IsNullOrEmpty(record.CustomerName))
            query = query.Where(x => x.CustomerNumber == record.CustomerNumber);

        if (!String.IsNullOrEmpty(record.LineOfBusiness))
            query = query.Where(r => r.LOB == record.LineOfBusiness);

をちょきちょきと切る

これが主観的すぎないことを願っていますが、これが良い/悪い習慣であるかどうかについて誰かが意見を持っているかどうか疑問に思っています. 必要な動的フィルタリングの例はあまり見たことがなく、ガイダンスを探しています。

ありがとう、

クリス

4

1 に答える 1

0

あなたがやっていると思うことをしているなら、これが最善の方法であるかどうかはわかりません。

「モデル」を MVC/プレゼンテーション レイヤー (これが 1 つの物理アセンブリであるかどうかにかかわらず) に保持し、プレゼンテーション レイヤー専用にします。それらに触れる必要があるのは、ビューとコントローラーだけです。独立したエンティティであるべきものを、ビュー モデルと密接に結合させたくありません。

別のクラスを作成することをお勧めしますTradeSpendFilter。これは、最も単純には、ドメイン エンティティのフィルター可能なプロパティを公開します (特定のビュー モデルよりも多くの可能性があります)。次に、これを「フィルタリング サービス」などに渡します。これは、ドメイン モデルと MVC アプリの両方に関係なく、フィルタリング機能を拡張できることも意味します。たとえば、突然複数のオブジェクトをフィルタリングしたい場合は、単純に変更できます...

public class TradeSpendFilter
{
    public string CustomerName { get; set; }
    ...
}

...に...

public class TradeSpendFilter
{
    public IEnumerable<string> CustomerNames { get; set; }
    ...
}

... MVC アプリにあらゆる種類の問題を引き起こすことはありません。

さらに、 MVC アプリに追加のコンポーネントを結びつけたり、ブートストラップの混乱に陥ったりすることなく、フィルタリング機能を他の場所で利用できることも意味します。

于 2013-03-27T18:28:14.577 に答える