シードスタックのリポジトリとファインダの違いは何ですか？

Question

私はSeedstack 16.7とそのビジネスフレームワークをJPAプラグインをサポートして使用しています。

データソースからデータを取得する2つの方法があります。

1. リポジトリhttp://seedstack.org/docs/business/manual/repositories/

   • 彼らはかなり型の安全性を保ち、JPAの伝統のEntityManagerの代わりに作用するものです。

2. ファインダhttp://seedstack.org/docs/business/manual/finders/

   • 彼らは、データソースからのDTOを取得します。

それらの間の唯一の明らかな違いは、ファインダのみデータソースにインターフェース読み出されることです。

ファインダーは、それらの間の任意の実際の差がある、または自分が意図した上でリポジトリを呼び出し、DTO

に集計から変換することによってだけで行うことができる必要があること、クエリのほとんどは？この質問に記載されている以外は です。そのモデリングdecissionはDDD、CQ（R）S、速いreadmodels、結果整合性の深い理解から来るので

Answer 1

など、いくつかの行でそれを説明するために、やや複雑である

• ファインダ

マニュアルには次のように記載されています。「アプリケーションのインタフェースに固有のオブジェクトを取得するために、永続性レイヤーまたは任意のデータソースを照会する」。 ここにキーワードはのインターフェイスです。グラフィカルUIの場合、ファインダーを使用すると、具体的なビューを取得してデスクトップフォームまたはWebページに表示することができます。 CRUD以外のアプリでは、UIはである必要があります。

1. ビューがエンティティと集計に一致しません。
2. あなたのエンティティと集約（いけない）選択データすなわちの完全なリストが含まれていません：米国および都市（古典的なカスケード依存コンボボックス）
3. あなたの集約と事業体は（いけない）、参照の完全なリストが含まれていませんエンティティ（オーダーの虚偽のリストを持つCustomerクラスは、すべての注文データが内部に置かれていますが、間違ったDDD集約モデリングです）、アプリのどこかに完全な注文リストを表示する必要があります。
4. ビューと集約は、さまざまなデータソースから取得できます（通常、クエリのパフォーマンスやイベントの一貫性のために）。すなわち、NoSqlリードモデル、正規化されていないリレーショナルデータベース、またはドメインリレーショナルデータベース内の（エンティティを表すテーブルの代わりに）事前計算ビュー。

このように、UIと集約/エンティティ間にインピーダンスのミスマッチがあります。これを解決する最善の方法は、明示的に永続性から表示に対処する方法を作成することです。ファインダーが場に出る。

• Repoisitories

ユーザーの問題、あなたがaggegateを取得し、アクションのエントリポイントとして集計ルートを使用する必要があなたのドメインの変更を意味しますコマンド。これにより、ドメインの整合性と不変量（ルール）が保証されます。集約モデリングには、ビューの集約とエンティティを使用しようとすると悪い考えをするニュアンスがたくさんあります（hereを参照）。したがって、データソースからメモリ集約を読み込んで構築する方法が必要です。これはリポジトリの仕事です。リポジトリによっては、エンティティの変更の追跡、一意のIDの作成などのビューのデータを取得するときに不要な機能が追加されていることがあります。ビューを扱うときは、このようなことは必要ありません。リポジトリは遊びに来る。