3

エンティティ、データ マッパー、およびサービス クラスを含むモデル レイヤーを使用して MVC アプリケーションを構築しました。ここまでは順調ですね。しかし今、モデル内のエンティティとは関係のない複数の db テーブルからのデータを含むレポートを表示する必要があるコントローラーがあります。レポートは、結合、SUM/AVG 選択を含む高度な MySQL クエリから作成されます。私が欲しいのはデータの配列だけなので、VIEWに表示されます。

  1. エンティティを返すメソッド ("getById()") と、データベース クエリからデータの配列を返すメソッド ("getAdvancedReport()") をサービス レイヤーで混在させることはできますか?

  2. db-queries をサービス層に配置しても問題ありませんか? そうでない場合、彼らはどこに行くべきですか？データ マッパーは、カスタム データを取得するのではなく、エンティティをデータベースにマップするだけであるため、気分が悪くなります。

たぶん「コーディング官僚主義」かもしれませんが、これを正しく行う必要があります。

ドメイン モデルの単純な CRUD の例以外は、ネット上で何も見つかりません。

4

3 に答える 3

4

本当の答えではありません..ビールのボトルを使ったポンティフィケーションのようなものです

データマッパーを使用することのポイントについて、さらにはドメインオブジェクト全般について、少し混乱しているようです。

データマッパーは、ストレージ（SQLデータベースの場合もあります）とドメインオブジェクト間の情報交換を担当します。少しでも正規化されたDB構造がある場合、データベースエンティティとドメインオブジェクトは1：1でマップされません。マッパーは、データベーステーブルではなく、特定のドメインオブジェクト用に作成されます。1つのドメインオブジェクトに複数のマッパーを含めることもできます（たとえば、データをDBに格納するマッパーとセッションにデータを格納するマッパー）。

オブジェクトにドメインロジックがない場合Reportは、アクティブレコードを使用することもできます。実用的なアプローチは、潜在的なドメインオブジェクトにドメインロジックのないCRUDしかない場合にそれらを使用することです。計算がある場合は、ドメインオブジェクトとデータマッパーのペアを使用してください。

サービスレイヤーはアプリケーションロジック用であり、ストレージロジック用ではありません。SQLは含まれていないはずです。サービスは主に、ドメインオブジェクトとマッパーの未決定の組み合わせ間の相互作用を管理する必要があります。郵送サービスおよび同様の構造を除いて。

また、通常、オンラインレポートは動的です。データを並べ替えたり、フィルタリングしたり、その他の方法で操作したりできます。最終的には、Reportオブジェクトを操作したり、フィルターを適用したり、オブジェクトからデータを抽出したりできるサービスになります。このいじくり回しはすべて「アプリケーションロジック」です。

それだけです...ビールが足りなくなりました

于 2012-11-27T10:51:18.790 に答える
2

エンティティを返すメソッド ("getById()") と、データベース クエリからデータの配列を返すメソッド ("getAdvancedReport()") をサービス レイヤーで混在させることはできますか?

はい、しかし、私はあなたの文を次のように修正します:エンティティを返すものと、データの配列を返すだけのもの

=>サービスのユーザーは、エンティティ/データがどこから来たのか気にしません。したがって、サービスはエンティティと生データ (プリミティブ型の配列) を返すことができます。

db-queries をサービス層に配置しても問題ありませんか?

いいえ

そうでない場合、彼らはどこに行くべきですか？

リポジトリ/DAO 内。リポジトリでネイティブ クエリを実行しても問題ありません。また、エンティティをマップする必要がないという理由だけで、ここではデータ マッパーを使用しません。

総括する：

Service->getMyData() > Repository->getMyData() > DBクエリ

于 2012-11-27T10:59:25.797 に答える
0

db-queriesをサービスレイヤーに配置しても大丈夫ですか？そうでない場合、彼らはどこに行くべきですか？

「サービス」はデータの出所を知らないため、DBクエリは常にデータマッパーに配置する必要があります。

于 2012-11-27T10:10:16.743 に答える