2

Active RecordパターンとRepositoryパターンを最大限に活用しようとする次のアプローチの欠点 (たとえば、テスト容易性の観点から) は何でしょうか?

各永続オブジェクトは、save() および delete() メソッドを公開しますが、それ自体をロードしたり、同様のオブジェクトのリストをロードしたりするための静的メソッドはありません。上位層からのロードは、永続オブジェクトの静的メソッドを回避するために、リポジトリを直接呼び出すことによって行われます。

「save()」および「delete()」メソッドは単なるファサードであり、リポジトリに委譲されます。

テスト可能性は本当にこのアプローチの問題ですか? 純粋なアクティブ レコード アプローチを使用しても、データベース ロジックがビジネス ロジック全体のほんの一部を表している情報システムはありますか。

EDIT：このアプローチは、永続オブジェクトが「save（）」と「delete（）」を実装するAbstractPersistentObjectから継承する必要があり、ビジネスの継承を防ぎますが、ビジネスの継承を避け、構成に置き換える方が良いと読みました。デメリットじゃなくてメリットかも…？

EDIT2：おそらく、この記事は私が解決しようとしている問題をよりよく説明するでしょう：http://moleseyhill.com/blog/2009/07/13/active-record-verses-repository/

4

1 に答える 1

6

少し気になる点が2点あります。最初のものはこの引用です（強調は私のものです）：

[...]データベース ロジックがビジネス ロジック全体のほんの一部を表している情報システムはありますか? また、データベース アクセスをモック化すると興味深いのはどこですか?

ビジネスロジックをデータベースに入れていますか? そうである場合: しないでください。データベースをモックするのが非常に難しくなります。データベースからモックにすべてのビジネス ロジックを複製 (および維持) する必要があります。そうしないと、テストが役に立たなくなります。

しかし、モックがビジネス ロジックを正しく実装しているかどうかは、どうすればわかりますか? モックの単体テストを作成することも、データベースの単体テストを再利用することもできます (ありますよね?) が、それは絶対に避けたいアプローチです! 繰り返しますが、モックの単体テストを作成しないでください (作成する必要はありません)。このような状況に陥った場合は、何か非常に問題があるため、数歩戻って設計を見直してください。

ビジネス ロジックをデータベースに配置すると、モデルとデータベースの間に不要な結合が生じるだけであり、テスト レイヤーが非常に複雑になります。ここでは、関心の分離が重要です。モデルはビジネス ロジックのみに焦点を当て、データベースは永続性のみに焦点を当てており、他には何もありません。

次の懸念事項は次のとおりです。ドメイン モデルで永続性に関連するsave()andメソッドが必要なのはなぜですか? 永続性はドメイン モデルには属しません。delete()

これらのメソッドはリポジトリに委譲するとおっしゃっていましたが、ドメイン モデルには (願わくば) 実際の永続化ロジックが含まれていません。しかし、どのリポジトリに委任する必要があるかをどのように知るのでしょうか?

メソッドでサービス ロケーターを呼び出すとsave()、エンティティを複数のリポジトリに保存できなくなります。また、リポジトリへの依存関係を呼び出し元から隠していますが、これは悪いことだと思います。

これらの問題を解決するには、次のsave()ようにリポジトリ インスタンスをメソッドに渡すことができます。

public class Foo extends AbstractPersistentObject {
    public void saveTo(IFooRepository repository) {
        repository.save(this);
    }
}

ただし、このようなメソッドは、呼び出し元が既にリポジトリ インスタンスを持っていることを意味するため、save()リポジトリで直接メソッドを呼び出すこともできます。ドメイン モデルの永続化メソッドは廃止されます。

おそらく私はあなたの問題を単純化しすぎています。あなたが達成しようとしていることは何ですか？構文だけentity.save()が必要ですか、それともより大きな問題を解決しようとしていますか?

于 2011-04-16T14:46:24.797 に答える