web-dev-qa-db-ja.com

カスタムfindByXメソッドをDAOに追加する際の保守性

私は、可能な限り最高のテスト性と保守性を実現したいプロジェクトを始めています。これを達成するために、私は主にDDD領域の概念についてたくさん読んでいます。

コンテキスト化するために、次のエンティティを想定します。

  • ユーザー
    これは基本的に、アカウント（以下を参照）と構成のコンテナーです。
  • アカウント
    これは、ユーザーがログインするための方法です。各ユーザーは、OAuthプロバイダー（Facebook、Googleなど））ごとに1つずつ、さまざまなアカウントを持つことができます。
  • セッション
    これは、ユーザー+有効期限を指すトークンです。ログインするたびに、新しいセッションが生成されます。

アカウント（ログインしているとき）またはセッション（すでにログインしているとき）でユーザーを見つける必要があります。

ただし、DAOをfindByXメソッドで肥大化させるのではないかと心配しています。これらは最もパフォーマンスが高く、理解しやすいようですが、DB構造をビジネスルールに結び付けているのでしょうか。違う？

この投稿 は、Specificationインターフェイスを使用する必要があることを示しています。このインターフェイスの実装では、適切なクエリ条件が返されます。

DAOをfindメソッドで肥大化させるなど、事前に直面する可能性のある問題はありますか、それともこのアーキテクチャに関心がありますか？

domain-driven-designmaintainability
1
gustavohenke

FindByメソッドは、データベース構造に結合するのではなく、ビジネス要件に結合します。個人的には、クリーンでクリーンである限り、複数のfindByメソッドを持つリポジトリを気にしません。例えば：

User findById(string id);
User findByEmail(string email);
User findByUserName(string userName);

私には、すっきりとしたインターフェースのように思えます。長期的には少し大きくなる可能性がありますが、メソッドが小さくて読みやすいのであまり気になりません。

一方、これを比較してください：

IList<User> findByEmailLikeAndNameLike(string email, string name);
IList<User> findByEmailWithStatusAndLastLoginAfter(string email, UserStatus status, DateTime lastLogin);
IList<User> findByEmailAndStatus(string email, UserStatus status);

これらは非常に特殊な方法であり、依然としてビジネス要件ですが、長期的には非常に扱いにくくなり、多くのロジックが重複します。これらの3つのメソッドを、仕様を渡すことができる一般的なfindByに置き換えます。

0
JDT