データベースに対するASP.NETコアのカスタム検証

Question

他の登録済みサービスを使用している可能性があるデータベースに対してフィールドを検証する必要があります。私はdocumentationを読んでいますが、実際の答えは見つかりませんでした。

コントローラーメソッドを呼び出すリモート検証がありますが、クライアント側のみであるため、JSを無効にすると検証が無効になります。検証属性を使用し、ModelState.IsValidにうまく収められているカスタム検証もありますが、そのコンストラクタに依存性を注入することはできません。

私はthis questionを依存関係リゾルバと同様に回答していますが、それに関する有用な情報は見つかりませんでした。

私はそれを研究しようとしましたが、私が遭遇したのは依存症注射またはIServiceProviderについてのもので、私にとってはうまくいきませんでした。ここに私の失敗した試みのいくつかは以下のとおりです。

protected override ValidationResult IsValid(object value, ValidationContext validationContext) 
    { 
     //--1------------------------------- 
     var container = new ServiceContainer(); 
     var _context = container.GetService<ApplicationDbContext>(); 
     //---------------------------------- 

     //--2------------------------------- 
     var services = new ServiceCollection(); 
     IServiceProvider servicesProvider = services.BuildServiceProvider(); 
     var _context = servicesProvider.GetService<ApplicationDbContext>(); 
     //---------------------------------- 

     return ValidationResult.Success; 
    } 

各取り出さ_contextがnullでした。私は本当にここですべてのアイデアを使い果たしてしまったので、私はどんな助けにも感謝します。

Answer 1

私は同様の問題に直面しています。私はいくつかの「不気味な」方法を試しました（ちょうどあなたが「する必要がある」場合）。私は電子メールのDuplicateMatch属性に悩まされていました。データベースへのアクセスが必要で、カスタムvalidationAttributeで何も利用できませんでした。

1. 私のDALはそうではなく、純粋なDI（依存性注入）の独立したプロジェクトである - 私は、DALでDBConextの初期化を保った（それは、独自のappSettings.jsonを持っている）ので、どれも他にはDBContextなどを渡すためにわざわざされていません。..ちょうどDAL（またはサービス層）を呼び出すと、それ自身でDBContextを初期化することができます。
2. 何らかの形で "Service Locator"パターンを使用して、DBContextのインスタンスとDI用に構成された他のオブジェクト（まだテストされていないオブジェクト）を取得します。
3. DIパターンに従い、DuplicateMatchまたはその他のそのような検証（コントローラアクション自体またはサービスレイヤでのDALアクセスが必要）、検証属性ではありません。

これらのいずれかが役立つかどうかを教えてください。そして私はDIパターンに違反しない方法（例えば3）についてコミュニティからもっと知ることに興味があります。