ASP.NET Web APIアプリケーションは、APIコントローラーでEntity Frameworkを使用する必要がありますか？
Entity FrameworkとASP.NET Web APIを使用する際のベストプラクティスについて少し混乱しています。
IOS/Androidアプリと、アプリが通信に使用するAPIを含むプロジェクトに取り組んでいます。
現時点では、プロジェクトは次のように分離されています。
Project.Core（このプロジェクトには、DbContext、Entityモデル、システムのロジックを制御するサービスなどのすべてのデータベースアクセスが含まれ、サービスはマップされたモデルのみを返します。Entityモデルがこのプロジェクトから公開されることはありません）
Project.Models（このプロジェクトには、アプリとAPIが使用するすべてのマップされたモデルが含まれます）
Project.Api（すべてのAPIコントローラー、アクション、および承認ロジックが含まれています。このプロジェクトはProject.Coreサービスを使用して目的のアクションを実行し、マップされたモデルでのみ機能します）
今私の質問は：
Entity FrameworkモデルとDbContextをAPIプロジェクトで直接使用しないのは悪い習慣ですか？
Entity FrameworkモデルとDbContextをProject.Core以外の他のすべてのプロジェクトから非表示にすることは悪い習慣ですか？
私のアイデアは、データベースに関連するすべてのロジックを別のプロジェクトに分離することでした。
これは私の意見ですが、いくつかの点で私はEwanに反対しているように感じます。
場合によります。
私は間違いなくEFオブジェクトをクライアントに返さないと思います。 AutoMapperなどのパッケージを使用して、クライアントとの間のデータ転送にのみ使用されるDTOオブジェクトにそれらをマップします。
ただし、APIレイヤーから直接EFを呼び出すことは必ずしも悪い習慣だとは思いません。
単体テストの場合、メモリ内データベースを使用して、EFクエリを使用してコントローラーメソッドをテストできない理由はわかりません。私は経験から、それを単にモックするよりもはるかに便利だと思います-予期しない動作があった場合は、LINQクエリに含まれることになることが多いです。
EFはすでにGeneric Repositoryパターンを実装しています。これが基本的に各DbSetオブジェクトです。さらに、最高のインターフェイスを備えています。EFを使用したことがなくても、すべての.NET開発者がすでに知っているLINQを使用しているためです。
常識だと思います。複雑なクエリの場合は、サービス内に配置するか、別のリポジトリレイヤーを導入してください。しかし、EFのリポジトリパターンを再実装している人が多すぎて、標準ではLINQクエリの代わりにカスタムインターフェイスを作成しているので、それは不要であり、多少最悪と感じています。
ベストプラクティスは、EFのものを非表示にすることです。
これにより、EFの依存関係を強制せずにモデルを共有したり、個別のデータレイヤーを維持したり、単体テストを実行したりできます。
これを行うには、生成されたEFをモデルにマッピングするか、属性を追加する必要がない場合はコードファーストモデルを使用します。
追加のProject.Repositoryを追加して、すべてのDB関連のものを含める