DataSet vs カスタムエンティティその２

.NET

ちょっと遅くなりましたがid:sugimotokazuyaさんとid:Kazzzさんのトラックバックに対して返信を

まず前提として趣味や趣向の話では無いので視点を明確にしたいと思います。

チームを組んで開発作業を行うにあたってトータルで妥当な判断を下す必要があり(今風に言えばアーキテクトとしての視点という感じでしょうか)例として以下のような構成要素が存在するとします。

  • チームメンバのスキルはまちまちで経験の浅い者も戦力として使わなければならない
  • 運用フェーズ以降の保守開発は違うメンバーが行う事も検討しなければならない
  • 受託開発がメインで開発対象のシステム形態や業務ドメインが異なるケースが多い

メンバーの全てがハイスキルなドリームチームで構成されており、開発対象のシステム機能・性能・リリース間隔などが非常に重要になるのであればポールグラハムの言うhttp://www.shiro.dreamhost.com/scheme/trans/beating-the-averages-j.htmlで述べられている概念のように最も生産的であろう戦術を取れば良いと思いますが、普通以下の奴も含めて普通以上のアウトプットを求めるには如何すれば良いのかを考えています。
また、http://japanese.joelonsoftware.com/Articles/BigMacsvs.TheNakedChef.htmlに落ち込まないようにバランスを取るという点も考慮する必要があり簡単な問題ではありません。

個人的な好みを言えば、Hibernateタイプの疎粒度オブジェクトを組み合わせてリッチなドメインモデルを構築する設計の方が美しいと感じますが、では実際にHibernateを使うとしてチームメンバ全員に

  • 最適なコレクションの使い分けの知識
  • シリアル化、HashCode、Equals、ToStringの完璧な実装
  • マッピングルールの理解と自動生成されるSQLの対応づけ
  • 遅延フェッチとイーガーフェッチの正しい使い分け
  • HQL構文の理解
  • Hibernateセッションの状態管理と制御
  • 循環リレーションとなる場合の制約条件

などなどを強制するのは先に挙げた構成要素から難しく導入は困難ば場合が多いです。
DataSetやDataAdapter等は標準機能なので最低これぐらいは知っていない奴は戦力にならんと突っぱねる事も可能だし、調べるにあたって日本語リソースも豊富です。

以上を踏まえて

PONO？かDataSetの選択は「使われる層に依るところが大きい」と言う意見がありますがMSの見解としては

に示されるようにDataSetにはDTOとして利用するケースも想定されている事が示されています。(MSの主張を素直に受け取ったらの話です)

オーバーヘッドに関しては.NET2.0からバリナリシリアル化に対応したり、メモリ内クエリのインデックスエンジンが強化されたり改善が図られているようです。
また、Hibernateならサーバーサイドで保持しているHibernateSessionがレコードの状態保持を行っているのに大してDataSetはDataRowStateに情報を保持しておりショートトランザクションを超えた管理が可能です。データの安全性から見ればデメリットにもなりえる機能ですがWebサービスやリッチクライアントではメリットとなりMSがいう非接続データアクセスという表現が現れている部分かと思います。

上記を考えると「使われる層に依るところが大きい」と言うよりも想定しているカバー範囲が大きいと言った方が適切な気がしますし最初に私が言った完璧には遠いが大抵の利用ケースで70〜80点をとれる良く考えられている技術という表現が伝わり易いと思います。
PONOと比較すれば非常にオーバーヘッドが大きいのは確かなので要件に合わないケースでは使えない事もあるでしょうし、特定用途に最適化されている訳ではないので最もシンプルな構成とも異なるでしょう。

駄目だしの多かったデザイナに関してですが、使うのはあくまでもDataSetの話で画面へTableAdapterやデータソースコンポーネントを貼り付けてレイヤー構造を壊す事はありません。
Daoの内部でDataAdapterの機能を使いますが、独自Daoではs2dao.netのパーサのベースになったコードを用いて複雑なクエリは２WaySqlにて記述しているのでデータを入れる対象がPONOかDataSetかの違いでDataAdapter構成ウィザード等もまったく使ってませんので・・・

また、エンティティの構造とプレゼンテーション層がやり取りを行うオブジェクトの構造を詰め替えるGoyaで言うところのDxoですが、型指定したDataSetやコードで構成したDataSetのスキーマはデータソースと異なっていても良いですし.NET2.0からDataRowStateを外部から操作可能だったと記憶しているので詰め替えを行っても上手く機能するのではないかと予測しています。

以上を踏まえ要件やトレードオフから判断して使い分ければ良いのでは？って思うので判断基準としてメリット・デメリットを挙げました。

DLinqが出てくるとさらに選択肢が増えそうで大変ですけどorz