1

私が間違っている場合は、私を修正してください:

Dao/Vo パターンまたは TDG パターンを使用すると、各テーブル (または少なくとも多くのテーブル) に関連するクラスを持つことで、適切なコード構成が得られます。

このアプローチの問題は、データが特定のテーブル内で閉じられていないことです。またはのようなドメイン固有のデータがいくつかありますが、上記のパターンはこれをうまく処理していないようです。findDogBreed();findBookBestSellerAuthor();

解決策としては、マッパーを使用することです。マッパーには、1 つのテーブルに関連する一連のメソッドとプロパティが含まれますが、そのテーブルだけに閉じられることも、特定の SQL スキーマに関連することもありません。

問題は、これらすべてを抽象化し始めると、SQL 構文にアクセスできなくなることです。データベース管理者に作業してもらう必要がある場合はどうすればよいでしょうか? さらに複雑なクエリでは、マッパーを使用すると、非常に厄介な抽象化「もの」につながる可能性があります。

これは正しいです ?もしそうなら、ここで中間項を見つけるためにどのような経路があるのだろうか.

4

1 に答える 1

1

複数レベルの抽象化であっても、機能を抽象化するときに手動で SQL を記述するオプションを失う必要はありません。

たとえば、Hibernate にインスパイアされた PHP 用の ORM である Doctrine を見てください。SQL に変換してエンティティを自動的にマップする DQL (Doctrine Query Language) でクエリを作成できますが、ネイティブ SQLを作成することもできます(ほとんどの場合、パフォーマンスの最適化のため)。ただし、結果のマッピングを自分で定義する必要があります。

于 2011-05-06T13:34:54.843 に答える