Record Set

An in-memory representation of tabular data.

(本書執筆時点で)20年来、データベースのデータ表現は表形式の関係データ
- 大小さまざまなRDBMSベンダによるサポート
- 標準化されたクエリ言語(SQL)
- 目に入るかぎりほぼすべての開発でRDBが使われるように
関係データ前提のUIツールの隆盛
ほぼプログラミングすることなくデータ表示・操作できる
- バカ簡単
- 簡単すぎて、ドメインロジックを書く場所が提供されていない
  - ストアドプロシージャとしてデータソース層に入ってしまう
  - UIと密結合してSmart UIになってしまう
Record Setの出番
- SQLの結果とまったく同じ見た目の、オンメモリなデータ構造
- システムの他のパーツ(Table Moduleとか)により生成・操作される

How It Works

普通自前では作らない
プラットフォームにより提供される
- ADO.NET
- JDBC 2.0
重要な要素
- Record SetはDBへのクエリ結果とまったく同じように見えるデータ構造である
  - 典型的な2層構造にそのまま適用できる
    - クエリでデータ取り出す
    - 表形式データ対応のUIに突っ込む
- 簡単に構築できる
  - mapのlistか何かから自分で
  - DBクエリ結果から
- ドメインロジックコードで簡単に操作できる
  - Table Moduleとか
自前で作ることもできる
- 表形式データ対応のUIも提供されておらず、自前で作らねばならないことがある
- mapのlistがよい例
  - 【補】Laravelの、stdClassのCollectionもこの類
Record Setとデータソースを切り離すことができることは有用である
- DBコネクションのことを気にせず、ネットワークを超えて伝送できる
  - 簡単に(デ)シリアライズできるなら、Data Transfer Objectにもなる
データソースと切り離す場合、UPDATEはどうするの
- Record SetにUnit of Workとしての性質も具有させるプラットフォームも増えている
  - 変更をまとめて、1つのトランザクションとしてcommitする
- 典型的にはOptimistic Offline Lockが用いられる
  - コンフリクトがなければ変更を書き込む

	implicit interface	explicit interface
メリット	汎用。あらゆる種類のレコードに対応	特定の種類のレコードに特化
デメリット	属性の取得方法がわからない・静的チェックの恩恵がない	専用のクラスを作る必要がある

Implicitはよくないよ
- 乗客を取得するキーが'passenger'なのか'guest'なのか、はたまた'flyer'なのかわからない
  - コードベースをさまよい歩くことになる
  - Explicitなら、定義を見れば一撃でわかる
静的型付き言語だとさらに良くない
- キャスト必要

((Person)aReservation["passenger"]).lastName

explicitなら型情報持てるので良い
implicit interfaceであるとして、ふつう有効なカラム名情報を持っているのが救い
- そうでないとしても、Record Setの構築時に問い合わせたSQLにカラム名が含まれるので、
  プロパティ名を得るのはそう難しいことではない
でもexplicit interface使ったほうが親切だよ
- ADO.NETでは強く型付けされたdata setsを提供する
  - 関連も表現できる
  - XSD data set definitoinからクラス自動生成
(執筆時点で)implicit interfaceのほうが一般的なので、本書の他の部分でRecord Setが登場するときはそれにならった
ADO.NETで製品コードを書くなら型付きの(=explicit interfaceな)データを使え
ADO.NET以外の環境でも、コード自動生成を使ってexplicit interfaceなRecord Set作れ