「純粋な」モデルオブジェクトと消費者定義の集計（SQLカウントなど）を結合しますか？

Question

カスタム（通常は揮発性）データをエンティティモデルクラスに導入するベストプラクティスは何ですか？これは最初は悪い習慣のように聞こえるかもしれませんが、非常に一般的なシナリオのようです。最近のWebアプリケーションでは、適切なモデルを開発しました。ほとんどの場合、モデルエンティティの読み込みは問題ありません。ただし、エンティティの階層全体をロードする余裕がない場合があります。たとえば、いくつかのSQL COUNTの結果、または場合によってはモデルエンティティと共に（または内部に埋め込まれた）追加情報を読み込む必要があります。基本的に、要件と条件は次のとおりです。

1. これは、すべての操作の99.9999999999％が読み取り操作であるWebアプリケーションです。

2. これらは、複雑なビジネスロジックを処理または実行する必要はありません。データをHTMLにすばやく取得する必要があります。

3. いくつかのパフォーマンスが重要なケースでは、どのモデルプロパティにも適合しないSQL集計の結果を読み込む必要があります。

4. 必要に応じて、新しいカスタムデータを導入する拡張可能な方法が必要です。

通常、ORM（dbの生データなど）にあまり手を加えずに、この問題をどのように解決しますか？これは何度も議論されてきたと思いますが、有用なものを見つけるための良いGoogleクエリを見つけることはできません。

編集：質問の形式があまりよくないことに後で気付いたので、再定式化してを開始することにしました新しいもの。

Answer 1

ブラウザとの間で動作をほとんどまたはまったくせずにリレーショナルデータを取得しているだけの場合、オブジェクト指向パラダイムでリレーショナルの問題を解決しようとしているように聞こえます。

オブジェクト指向のアプローチを完全に省く傾向があるかもしれません。

私チームは最近、「動作する可能性のある最も単純なものは何ですか？」および「問題に最も近い言語は何ですか？」 OOに代わる新しいアプリは、最終的に10倍の小型、高速、低価格になりました。

SQL、ストアドプロシージャ、DBサーバー上のXMLライブラリ、XSLT（HTMLを取得するため）、およびjavascriptを使用しました。

Answer 2

OOPの純粋主義者は、私のようなデコレーターパターンに行きます。 http://en.wikipedia.org/wiki/Decorator_pattern

しかし、それは、一部の人々はそれが提供する柔軟性を必要としないかもしれません。さらに、個別の操作ごとに新しいクラスを作成するのはやり過ぎに思えるかもしれませんが、適切なコンパイルタイプチェックを提供します。

Answer 3

私の考えでは、アプリケーションはドメインモデルパターンを使用してデータを消費することがベストプラクティスです。 。ドメインモデルは、理にかなっており、アプリケーションのニーズに関連する種類のクエリを実行するためのビジネスロジックメソッドを提供できます。

これらは＆quot; live＆quot;を取得できます。データベース行に直接マッピングされる結果であり、編集および「保存」できます。

さらに、ドメインモデルは、データベースに簡単に保存するには複雑すぎる読み取り専用の結果を取得するメソッドを提供できます。これには、グループ化された集計クエリ結果の例と、結合されたクエリ結果セット、列としての式などが含まれます。

ドメインモデルパターンは、アプリケーションのオブジェクト指向設計を物理データベースの設計から分離する方法を提供します。