「カナダ/オンタリオ/トロント」など、「国/州/市」のようなデータベースの列があります。それらを分割し、3 つの個別の Java Bean プロパティにマップする必要があります。
これをどこで行うのが最善か疑問に思っています。
(1) 行が取得されるときの DAO (2) セッターがゲッターであるドメイン (Bean) が呼び出される (3) クエリ内の行を解析するための SQL 関数 (4) ResultSetExtractor の使用
「Anemic Domain」アンチパターンは、Bean がこれに適した場所であることを示しているように見えるため、私は #2 または #4 に傾いています。
私はあなたに同意するかどうかわかりません。ドメイン エンティティがデータ表現の影響を受ける必要はないと主張することもできます。
データベースのレイアウトが異なっていた場合、セッターとゲッターを備えた Bean を検討しますか?
あなたの答えが「いいえ」の場合、おそらくそのオプションは必要ありません。
個人的には、データアクセス層がある場合、データ表現をドメイン表現に変換するのはその仕事の一部だと思います。
私見、これを行うのに最適な場所はデータベースです。この列をテーブルの 3 つの列に分割し、列ごとに 1 つの情報を格納します。
これが従来の理由で実際にオプションでない場合は、実際にドメイン オブジェクトで直接実行します。これは、他のエンティティに影響を与えることなく、ドメイン オブジェクトに直接カプセル化できる動作です。
これが JPA の場合@Entity、プライベート String を DB 列に直接マップし、アクセスをラップする public ゲッターを作成します。そうすれば、ドメイン モデルのコンシューマーは、連結された文字列の内部/DB 表現から分離されます。@PostLoadまたは、コールバックで翻訳を行うこともできます。(永続化の逆変換は、コールバックで実行でき@PrePersistます。)
あなたの 1. と 4. は実際には同じ解決策ではありませんか? ResultSetExtractorDAO コード内で使用すると思います。SQL 関数を使用することは、他のテクノロジから再利用できるため悪い考えではありませんが、メンテナンスの問題があります。
時間がかかるまで解析を遅らせることはお勧めしません。パフォーマンスの面では良くなく、それらのフィールドで他のタスクを実行するときに作業が複雑になる可能性があるためです。Bean にすでに 3 つのフィールドがある場合は、よりクリーンになります。