サービス層とデータマッパー: 複雑なクエリ条件を処理するのは誰ですか?

複雑なクエリにおける条件処理の責任の決定: サービス層とデータ マッパー

データの取得と操作を追求する際に、問題が発生します: 複雑なクエリ条件を処理する負担はデータ マッパーとサービス層のどちらが負うべきですか?

データ マッパー

データ マッパー パターンは単純なインターフェイスを指示します、主な役割はデータの取得、保存、削除です。ただし、実装の詳細はまだ解釈の余地があります。

その最小限のインターフェイスにもかかわらず、データ マッパーは、特定の識別子や作成者名に基づいてオブジェクトを取得するなど、条件付きロジックを組み込むように拡張できます。

サービス層

一方、サービス層は、コントローラーとデータ マッパーの間の仲介者として機能します。 BookDataMapper->getByAuthorAndPublisher() など、より具体的なメソッドを直接呼び出すことで、複数の条件を処理する複雑さを軽減できます。

サービス層条件処理の利点

いくつかの理由から、サービス層でクエリ条件を解析することを主張する人もいます。

• データ マッパーの複雑さを軽減します。
• 条件付きロジックをモデル層内に保持し、コントローラーへの漏洩を防ぎます。 .

データ マッパーの条件処理の利点

データ マッパー内で条件付きロジックを一元化することを好む人もいます。

• サービス層は、単なる仲介者になります。
• 必要に応じて、データ マッパーが追加の条件ベースのメソッドを組み込むことができます。

最適なアプローチ

最適なアプローチは、特定のアプリケーションとドメイン固有のロジックによって異なります。ただし、いくつかの一般的なガイドラインを考慮することができます。

• フェッチ、保存、削除などの重要な操作を備えたデータ マッパー インターフェイスをできるだけシンプルにしてください。
• ドメイン オブジェクトを使用します。それ自体を使用して、データ取得の条件パラメータを保持します。
• Tell Don't Ask 原則を利用して、ドメイン オブジェクトとマッパー間の通信を最小限に抑えます。
• オブジェクトのグループを処理するには、ArticleCollectionMapper のような追加の構造を使用することを検討してください。条件は異なります。

以上がサービス層とデータマッパー: 複雑なクエリ条件を処理するのは誰ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。