これはアプリの設計に大きく依存しますが、2 つの選択肢を提供するだけです。
IActionFilter
リクエストごとにデータ コンテキストを実行している場合は、グローバルを使用してIActionFilter
アクション前の実行をグローバルにフックし、舞台裏でデータ コンテキストにクエリ フィルターを適用できます。
これの主な欠点は、コントローラーをテストするには、actionfilter が適切に適用されるように MVC パイプラインを完全にセットアップする必要があることです。
依存性注入
サブクラス化(あなたが言うようにベースコントローラー)を使用する代わりに、依存性注入を使用できます。物事をより緩く保つことで、クエリ文字列、Cookie、データベースのユーザー設定などからフィルターを取得できます-コントローラーがどこから来たのかを知る必要はありません。
Entity Framework や Nhibernate などを使用している場合の疑似コードを次に示します (他のテクノロジにも適用できると確信しています)。
public Car
{
public string Year { get; set; }
}
public class CarsDataContext : DbContext
{
private IQuerable<Cars> _cars = null;
private Func<Car, bool> _carsFilter = null;
public IQuerable<Car> Cars {
get {
if (_carsFitler != null)
return _cars.Where(_carsFitler);
return _cars;
}
set { _cars = value; }
}
public void ApplyCarsFilter(Func<Car, bool> predicate)
{
_carsFilter = predicate;
}
}
依存性注入のセットアップ (NInject またはその他のフレームワーク) が既にあると仮定すると、コンテキストを初期化する方法を構成できます。
Bind<CarsDataContext>().ToMethod(() => {
string yearFilter = GetYearFilter(); // can be coming from anywhere
CarsDataContext dataContext = new CarsDataContext();
dataContext.Applyfilter(car => car.Year == yearFilter);
return dataContext;
}).InRequestScope();
次に、コントローラーはデータのフィルタリングについて何も知らないので、簡単にテストできます。
class MyController : Controller
{
public MyController(CarsDataContext dataContext)
{
}
...
}
ただし、これを行うのは、データセットのフィルタリングが多くのコントローラーと私のソフトウェアの重要な部分にまたがっていることだけです。そうでなければ、それは純粋なオーバーエンジニアリングです。