いう位置づけだったりしました(プログラミング言語ではない)。なんつのは,開発者だからこそ使いこなせる言語じゃないと思ってたりする。使えます!とかいった話と同じ感じ。SQL」なる話も比べる水準が違うんでねいか,と思ったりします。クラスみたいなクラスで永続層(データストレージ層)を抽象化することは,よくしている気がしています。クラスを作るってなことなんですが。埋め込むってなことだとすると,あまりしない。あたしの周りの話だけれど。埋め込まれるわけですけれど,こういうクラス構成にするのには理由があります。埋め込んだ方が早い気がします。理由っつのはこゆモノ。データアクセスをクラスに抽象化することで,具体的なデータソースをビジネス層から隠蔽できる。データベースの物理構成(テーブル構成)に対して,ビジネス層が依存しないで済む。タイミングでデータベースにアクセスできる。意識しないで永続層にアクセスできる。なんかで作られるクラス/オブジェクトの目的は,最後の理由(4)が主たる目的なんだと思います。初心者向けの理由なんですけれど,普通のプログラマでも,オープンしたコネクションを閉じないままにしちゃうミスがたまにある。オープン/クローズを親クラスにまとめていて,デストラクタでクローズするようにしている)。アクセスをクラスにまとめる利点はある。作る目的は,もっと重要なところにあります。上流がグニャグニャなときに有効なんですが。具体的なデータソースを隠蔽することができるってのは,要するに,データソースが変わっても,インターフェイスさえ決まっていれば,ビジネス層がその変更を意識する必要がない,という意味です。変更します,とかいった場合でも,ビジネス層がその変更を意識する必要がなくなる。以外になる場合(ウェブサービスを使うとか)でも,ビジネス層はそれを意識しなくて済むということでもある。データソースのカプセル化は,作業を分担するときにも有効です。ライブラリも含めて10万ステップ程度のシステムでは,それほど意識しないだろうけれども,50万ステップとか100万ステップとかいった規模になると,ひとりふたりでは作業できなくなってきます。データベースを専門的に管理するチームも編成されたりする。このとき,データベースが決まらなかったら,ビジネス層の実装に入れないってなことになるのはあほらしいわけで,適当なスタブを作ることになります。受託案件なんかでは,客先の環境とまったく同じ開発環境を用意できないこともある。しておけば,ビジネスオブジェクトだけで作業できるし,単体テストもできるようになります。分担をきっちり分けることができるわけです。抽象化しておけば,その内部を修正するだけで足ります。ついて修正を加える必要が出てくる。バグを埋め込む機会も増えてしまいます。パターンを使うのは,こういう理由が一番大きいと思います。アクセスしてデータを取得する場合,更新はあまりしないけれどよく参照されるテーブルを利用することもあります。業務アプリで言うなら,社員テーブルなんつのはほとんど更新されない割によく参照される。こゆテーブルにアクセスするときに,本当にコネクションを開いてアクセスするのは無駄です。ほとんどの場合,さっきと同じデータが返ってくるからです。こゆ場合,プログラムのレベルで結果をキャッシュしておけば,パフォーマンスも上がるし,無駄なトラフィックを減らすこともできます。担当させるってな考え方がある。クラス変数に参照結果を取っておくわけです。データアクセスの要求をフックして,永続層にアクセスするタイミングを制御することができる,と言える。高機能だから,ある程度参照結果を賢く取っておいてくれるけれども,業務に特化したアクセス方法がある場合,アプリケーションのレベルで制御する方が適切なこともあります。ま,そんな便利機能も実装できますよ,と。自前でデータアクセスするように課題をこなしてもらっていたりします。使わない方法も検討してもらったんですけど,結局作ることにしたみたい。作る利点と欠点を実際に感じてもらいたいからだったりします。マッパを使うにしても,要件を自分で判断しなくちゃいけないときに,見るべきポイントが分かるんじゃないかと思ったりします。アクセスすることは,よくある話デスヨ。