どのようにすればよいですか:DbContextの独自のラッパーを作成するか、ControllerでDbContextを使用します

asp.net-core asp.net-core-mvc c# entity-framework-core

質問

私のプロジェクトでは、 エンティティフレームワーク7asp.net mvc 6 \ asp.net 5を使用します。自分のモデルにCRUDを作成したい

私はどうすればよりうまくできますか:

  1. コントローラーからdbcontextを使用します。次のリンクの著者では、この方法がより優れていることを説明しますが、それがコントローラにとって正しいかどうかを説明します。
  2. 自分のラッパーを作る。いくつかのベストプラクティスでは、独自のリポジトリを実行するのに最適なものについて書いています

特定の実装からのデータにアクセスするための強力な接続性があっても、ef7 dbcontextではすぐにUnit Of WorkとRepositoryパターンが実装されていることがわかっています。

受け入れられた回答

あなたの質問に対する答えは主に意見に基づいています。他の多くの質問に答えるまで、誰もが「一方的に他のものより優れている」ということは間違いありません。あなたのプロジェクトの規模/範囲/予算は?何人の開発者がそれに取り組んでいますか? MVCコントローラのみ(ビューベース)、または(データベースの)APIコントローラも備えていますか?後者の場合、MVCとAPIのアクションメソッドがある場合は、そのオーバーラップはいくらですか? WPFのような非ウェブクライアントを持っていますか?アプリケーションをどのようにテストする予定ですか?

Entity Frameworkは、データアクセスレイヤ(DAL)ツールです。コントローラーは、HTTPクライアント要求および応答処理ツールです。あなたのアプリケーションが純粋なCRUD(疑わしい)でない限り、おそらくHTTP経由でWebリクエストを受け取ったときと、EFを使ってそのリクエストのデータをデータベースに保存するときに何らかのビジネスロジック処理が必要になるでしょうフィールドXが必要な場合は、フィールドYのデータを入力する場合は、フィールドZなどのデータも入力する必要があります)。したがって、コントローラでEFコードを直接使用すると、これはビジネス処理ロジックがほぼ確実にコントローラーに存在することを意味します。

.NETで非自明なアプリケーションを開発する経験のある人は、ビジネスやデータのアクセスロジックがコントローラに存在しないという意見が出てくる傾向があります。たとえば、ビジネスロジックとデータアクセスロジックと共にWeb / HTTPリクエスト&応答ロジックをコントローラに組み込むと、コントローラの動作自体からそれらのアプリケーションのすべての側面をテストする必要があります(これは、Single責任原則、あなたがSOLID設計を気にしている場合)。また、ビューを返すコントローラを備えた従来のMVCアプリケーションを開発し、iOS / Android / WPF /などの他のクライアントや、MVCビューを理解できない他のクライアントにアプリケーションを拡張することを決定したとします。 WebAPIデータベースコントローラアクションのセカンダリセットを実装する場合は、ビジネスとデータのアクセスロジックを少なくとも2か所で複製します。

それでも、これはコントローラ内のすべてのビジネス&データアクセスロジックを代替設計よりも本質的に「悪い」ものにするという決定を下すものではありません。 Webアプリケーションのアーキテクチャを設計する際には、長所と短所があります。どのルートを選択しても、常にトレードオフがあります。すべてのアプリケーションコードをコントローラに保存することのメリットは、低コスト、複雑性、および市場投入までの時間を含むことができます。非常に単純なアプリケーションのために、複雑なアーキテクチャーをオーバーエンジニアリングするのは意味がありません。しかし残念ながら、私は個人的に単純なアプリケーションを開発する喜びはありませんでした。そのため、ビジネスとデータのアクセスコードをコントローラに保存することは、おそらく長期的な設計上の決定ではないと思うのです。

あなたが本当に選択肢に興味があるなら、私はこれらの 2つの記事を 読むことをお勧めます。コントローラは、コントローラが消費できるコマンド&クエリ(CQRS)パターンをどのように実装するかについての優れた指針です。 EFは、リポジトリと作業単位の両方のパターンを実装していますが、データアクセスコードをコントローラ外に移動するためには、必ずしもラップする必要はありません。あなたのプロジェクトにこのような意思決定をする運がよい。

public async Task<ActionResult> Index() {
    var user = await query.Execute(new UserById(1));
    return View(user);
}

人気のある回答

通常、私はUnitOfWorkパターンと共にリポジトリパターンを使用することを好みます( http://www.asp.net/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository -asp-net-mvcアプリケーションの作業単位パターン ) - UnitOfWorkインスタンスオブジェクトでDbContextをインスタンス化し、そのDbContextをリポジトリに挿入します。その後、私はUnitOfWorkをコントローラでインスタンス化し、コントローラはDbContextについて何も知らない:

public ActionResult Index()
{
    var user = unitOfWork.UsersRepository.GetById(1); // unitOfWork is dependency injected using Unity or Ninject or some other framework
    return View(user);
}


Related

ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
このKBは合法ですか? はい、理由を学ぶ
ライセンスを受けた: CC-BY-SA with attribution
所属していない Stack Overflow
このKBは合法ですか? はい、理由を学ぶ