web-dev-qa-db-ja.com

リポジトリには、特定のデータベース操作ごとにメソッドが必要ですか?

標準のサービスおよびリポジトリパターンに従っている場合、リポジトリにすべてのデータベース操作の特定のメソッドが含まれているのか、または一般的なメソッドだけを使用しているのか、たとえば更新?次のサービスメソッドを例にとります。

DisableUser(User user) {
    user.enabled = false;
    userRepo.update(user); // General user update method
}

これは、ユーザーレコードに対して変更を実行し、一般的なユーザー更新メソッドを呼び出してデータベースの更新をリポジトリに要求します。

または、次のように具体的にする必要があります。

DisableUser(User user) {
    userRepo.disable(user); // Specific operation, matching the service
}

明らかにこれは非常に単純な例ですが、結論はリポジトリの一般的な進め方に影響を与えると感じています。この同じロジックが多くのシナリオに適用されます。

さらに混乱するのは、最初のケースでは、標準の更新方法を使用すると、レコードのすべての列が更新されるため、非効率的であると見なされる可能性があることですが、Entity Frameworkを使用しているため、変更されたフィールドのチェックを処理します変更されたフィールドのみを更新します。しかし、私は自分のサービスからその仮定をするべきですか?

リポジトリIDの代替のプレーンSQL実装を作成する場合は、そこですべてのフィールドを更新するか、フィールド変更検出を自分で実装する必要があります。そのため、その部分は特定の実装に傾いていますが、それにより、さらに多くのメソッドを追加しており、おそらく少し不必要に感じています。

つまり、簡単に言えば、リポジトリに標準のメソッド(update、insert、findById、findAll、delete)があるだけです。または、ストアドプロシージャのような特定のデータベース操作ごとにメソッドが必要です。

おそらく私が把握していない他の考慮事項がいくつかあるでしょう。何かアドバイスをいただければ幸いです。

5
matthewrk

既存の回答とは異なる視点を提供するために、私は依存すると言います。

一般的な方が再利用可能ですが、ドメイン固有のものは意図を示し、ドメインモデルを永続性の選択からより適切に分離します。もし、するなら

var user = repo.GetUser(id); user.Enabled = false; repo.Update(user);

その場合、レポはそれが何をしているのか本当の考えを持っていません(これは再利用性の観点からは良いことです)。しかし、操作の意図を思い出す可能性も失います。

ドメイン固有のものを実行する場合:

repo.DisableUser(id);

まず、リポジトリをより効率的に実装できます。ユーザーに彼を無効にするように要求する必要はないかもしれません-多分あなたはUPDATEをしてそれで終わらせることができますまた、あなたは知っている何をしているのか、監査ログやリポジトリレベルで同様の適切なログメッセージを追加することもできます。より一般的なバージョンでも監査ロギングを実行できますが、ドメイン固有の「顧客無効」エントリではなく、一般的な「顧客更新」エントリを取得します。多くの場合、これは非常に優れた価値のあるものです。

ただし、これはより手間がかかります。そのため、一般的なソリューションがより一般的で実装しやすいため、一般的な人々は一般的なソリューションを採用します。しかし、ドメイン固有のリポジ​​トリを使用不可または不良として無視しないでください。答えは常に依存しますです。

2
wasatz

より一般的なメソッドであるupdate、insert、findById、findAll、deleteを使用すると、コードが再利用可能になる可能性があります。つまり、すべてのシナリオに特定のメソッドを記述する代わりに、より一般的なメソッドを公開して、必要な特定のケースにそれらを使用できることがわかります。たとえば、ユーザーを無効にする必要がある場合があります。これを行うには、更新メソッドを呼び出します。ユーザーを無効にする必要のある他のインターフェースが後である可能性があり、その特定のケースに対処するためにまったく新しいメソッドを作成する代わりに、同じ更新メソッドを再度呼び出すことができます。私はSOA(Services Oriented Architecture))で多くの仕事をしてきましたが、より一般的に言えば、適切なコードを維持するために見つけやすくすることができます。組織は、さまざまなサービスをすべて維持するためにサービスバスに移行したいと考えています。より一般的な方法を使用すると、この移行がはるかに簡単になります。

0
Jim Krueger