私はリポジトリ パターンについて調べており、返されたデータが単なる標準モデルではない (つまり、 NOT Customer 1..* Account)状況に人々がどのようにアプローチするかについて、確固たる答えを見つけるのに苦労しています。
集計されたデータを返す分析システムを構築しており、多くのテーブルにまたがることがあります。さらに、これらのテーブルには、結合されている数百万のレコードが含まれている場合があります。要するに、私の典型的な結果セットはコア ドメイン モデルではなく、(時には極端な) スパン、順列、およびそれらの集約です。
以前は、単純にクエリを作成し、結果をカスタム結果セットとして返していました (これにより、システムの上位レイヤーから ORM にアクセスできるようになり、使用されている ORM の知識からシステムを分離しませんでした)。 .
リポジトリ パターンはここに適していませんか? 他の人はこの種のシナリオにどのようにアプローチしましたか? 角ペグ/丸穴のような感じです。
参考までに、MSSQL DB で ASP MVC を使用して C# .Net で開発しています。
アップデート
私のシナリオは主にレポートに基づいていますが、レポートの基になるデータを構成する個々のエンティティを扱っています。
（ちょうど）例として：私はまだ自分のCustomerエンティティを必要としており、その顧客Ordersはシステムを通じて生成したエンティティをまだ必要としています。私のドメインの POCOS は、このシナリオでうまく機能します。この問題は、多数を受信Ordersし、既存のドメイン オブジェクトのどこにも一致しない形式で多数の結合され、集計されたテーブルと共にそれらについて報告する必要がある後に発生します。