エンティティフレームワーク-拡張OR DBコンテキストへのサービスの注入
少しばかげた質問をしているのではないかと心配していますが、どの原則に従うべきか迷ってしまいました。
私の理解-単一の責任の原則に関しては、私たちはしないことをお勧めします微調整ORサービスを注入するORDBコンテキストに追加フィールドを導入する 。
単にDBコンテキストの目的がデータベースアクセスを提供することであるためです。
単一責任の原則は、すべてのモジュールまたはクラスがソフトウェアによって提供される機能の単一の部分に対して責任を負うべきであり、その責任はクラスによって完全にカプセル化されるべきであると述べているコンピュータプログラミングの原則です。すべてのサービスは、その責任と密接に連携している必要があります。ロバートC.マーティンは原則を「クラスは変更する理由が1つだけあるべきです」と表現しています。
これを投稿する理由-サービスレイヤーコードをリファクタリングしようとしていて、アプリにいくつかのフィールドを自動的に設定させたい（例：CreatorUserId、ModifierUserId、DeleterUserId）毎回それらをすべて手動で設定するのではなく-fore more info check this 。
answer を見ると、人は言う
ここでのUserIdとTenantIdは、リポジトリサービス（ここではDbContext）が必要とするデータの一部です。サービスにデータが必要な場合は、サービスに挿入する必要があります。
またコメントの一つ
DbContextにセッション状態またはHttpコンテキストへのオープンアクセスを与えることは明らかに間違っています。ただし、DbContextを少数の固定パラメーターに依存させることは問題ありません。正しいIDを使用して正しいデータベースに接続し、監査データを記録するには、UserIdとTenantIdの両方が必要になる場合があります。すべて、リポジトリの単一の責任の範囲内です。
しかし、私は この投稿 の下で別の人から異なるフィードバックも受け取りました。
これが answer です
テナントプロバイダーに依存しているデータベースコンテキストが正しいことであるかどうかを本当に考える必要があります。 SRPに従って、データベースは1つのことだけを実行する必要があり、それがデータベースアクセスを提供します。
テナントプロバイダーがデータベースアクセスに与える影響によっては、この依存関係を1レベル上に移動して、データベースコンテキストとテナントプロバイダーの両方を使用して適切な方法でデータをクエリするサービスに移行する方が適切な場合があります。
意見が違うようです。誰か推奨事項はありますか？
あなたがしようとしていること、DBContextを継承し、オーバーライドされたメソッドを使用して追加のロギング機能を追加することは、アーキテクチャ上は問題ありませんが、独自のクラスの1つではなく、そのDBContextが原因で、異常で複雑になる可能性があります。
独自のロジックを正しく追加するにはクラスがどのように機能するかを深く理解する必要があるという理由だけで、独自のDBContextを実装しようとすることは誰にもお勧めしません。
簡単に言うと、たとえば、SaveChangesAsync（）をオーバーライドできますが、SaveChanges（）はオーバーライドできません。
たとえば、DBContext呼び出しをリポジトリレイヤーでラップし、監査機能をそこに配置する方がはるかに簡単です。
これがあなたが別のアドバイスを受けている理由だと思います。 DBContextの理解に自信がある場合は、それをサブクラス化して、UserContextを注入し、DBContextWithUserAuditingと呼びます。
DBContextの動作を理解する必要がない場合は、UserContextと共に標準の機能をRepositoryWithUserAuditingに挿入します。