DTOとDAO
DataSetかPONOか!? - sugimotokazuyaの日記
DataSet vs カスタムエンティティ - #87にっき
私はPONOか、DataSetかの選択は用途、つまりデータが使われる層に依るところが大きいと考えている。
PofEAA(Patterns of Enterprise Application Architecture)に当てはめると判りやすいので例えるが、プレゼンテーション層とビジネスロジック層、データ層等、層間をつなぐためのオブジェクト、つまりDTO(DataTransferObject)はPONOが適している。理由は
ちなみに、私が先月のエントリで言及してきたコントロールとオブジェクトの双方向バインディングに関しての話題は、主にDTOとしての用途をターゲットにしている。
DataBidingsAttributeによる双方向データバインディングの自動化
カスタム属性を用いたデータバインディングの省力化(BindingSource編)
カスタム属性を用いたデータバインディングの省力化(INotifyPropertyChanged実装編)
一方、真のデータとバインドとして永続化にも関わるデータ層のオブジェクト、特に.NETプラットホームでは、TableDataGatewayと呼ばれる、いわゆるDAO(Data Access object)はDataSet(とDataAdaptor)が適しているだろう。理由は
- QL(SQL)を簡単に扱えることが要求される(フィルタリング、ソーティング等)
- CRUD(DML)操作が必要である
- ビューと直接バインドすることは余りない
- データソースのメタデータと(スキーマ)一致することが多い
ただし、DataSetはメモリ上のデータベースともいえる機能を持っており、かなりヘビーなオブジェクトなので、大量のデータを載せたり、大量のインスタンスを生成、破棄する用途には使いにくいと思う。逆にスマートクライアント(リッチクライアント)がリモートでデータのスナップショットをあたかもデータベースのように使う用途にはぴったりではないだろうか。
追記:
重いDataSetを嫌う、データベースとの統合を重視するのであれば、それこそs2Dao.NETや、NHibernate、Castle.AcriveRecord、iBatis.Net等のPersistenceフレームワークがあるので、それらを選択すればよいだろう。
なお、DTO、DAOのリンクにはPofEAAのサマリサイトであるるPofEAA Wiki - パターンカタログの翻訳を使わせていただきました。先達に感謝いたします。
