PoEAA 9.3章

mtoyoshi @mtoyoshij

#EAA9_3 やっと理解できた。DataSetはDB、DataTableがテーブル、DataRowが行をあらわしていて、そういう汎用的なものをより具体的に使いやすくするためにフロントにProductとかを入れて、メソッドをそこに配置していく、と。ディスカッションしてよかった。

ricymst @ricymst

#EAA9_3 メリットは、テーブルを軸にビジネスロジックが体系化されている 。リレーショナルデータベースのメリットを活かせる

ricymst @ricymst

#EAA9_3 データベースのテーブル1つにつき1つのクラスを持つドメインロジックを構築する。

ricymst @ricymst

#EAA9_2 テーブルモジュールは、テーブルやビューのレコードセットに関するビジネスロジックを扱う

huskyhead @huskyhead8080

#EAA9_3 ここまで読んだだけだと、ＴＳ＝手続き言語的、ドメイン＝オブジェクト指向的、テーブルモジュール＝社内ＦＷ的（.NET）となると、今後注力（慣れる）すべきは今手薄になってるドメイン？

huskyhead @huskyhead8080

#EAA9_3 使用するタイミングは、共通のテーブル指向のデータ構造をベースにしている場合とあり、.NETの例が書いてあるけれど、業務系ＳＩの経験からすると相当複雑なアプリじゃない限り、このパターンでいいのでは。。。と感じました

huskyhead @huskyhead8080

#EAA9_3 テーブルモジュールはインスタンスの場合もあれば、静的メソッドが集まったものの場合もある、とあるけど、静的メソッドの例は、コードマスタ参照とかでＤＢ操作にパターンが固定されてる時という理解

huskyhead @huskyhead8080

@chipstar_light #EAA9_3 ですよね？ホント、似ているなぁと思いました。だから理解しやすかったです

mtoyoshi @mtoyoshij

#EAA9_3 例：「本棚」と「本」という1対多関連のモデルがあるとする。通常誘導可能性は本棚→本だと思うけど、逆に本から本棚が取れても、まぁそういう時もあるわなと思える。これは許せるんですよ。この例はこれとはちがうよね？嗚呼、俺が感じてるキモさ共感してもらえるかなぁ。

mtoyoshi @mtoyoshij

#EAA9_3 細かいけど。table = ds.Tables[tableName];で取り出した個別のtableから、table.DataSetってやったらもとのdatasetが取り出せるんだ。。個人的には直感的ではないです。好きじゃない。

mtoyoshi @mtoyoshij

#EAA9_3 オンメモリなのでレスポンスは早そうだけど、メモリ使用量の観点からは厳しそうだ。ま、絶対使わない（というかアクセスさせるべきではない）別会社のデータとかは流石にのらないと思うけど。やっぱ必要なレコード分だけインスタンスがある方がしっくり。1レコード1インスタンス。

mtoyoshi @mtoyoshij

#EAA9_3 P138から始まる例のとこ。Contractコンストラクタの引数は、その後RevenueRecognition、Productの引数にも渡されていってるけど、このデータ量はいかほど？thisメソッドでid指定で取れるってことは全データ？

mtoyoshi @mtoyoshij

#EAA9_3 イマイチこのパターンがしっくりこないのは、.netの例の経験がないからだろう。つまり、”レコードセットがアプリケーション内のデータの主要なリポジトリとなっている”って状況のこと。

mtoyoshi @mtoyoshij

#EAA9_3 テーブルと１対１が基本。じゃ、joinとかしたくなったらどうするんだろう？と思ってたら、P136の上段に「実際、（中略）テーブル構造よりもビューやクエリーなども含めた（中略）仮想テーブルに依存したもの」とあった。

mtoyoshi @mtoyoshij

#EAA9_3 トランザクションスクリプトが「こと（処理）」、ドメインモデルが「もの」、テーブルモジュールが「テーブル」に着目。そのままやけど。

河野秀樹 @nangoku_skier

#EAA9_3データベースを強く意識するパターンなのである意味分かりやすい気もする。

kyoinn3 @XY_kyo

#EAA9_3 　このパターンではリポジトリの構成が凄く大事だなと思う。リポジトリの構成が良くないと、このパターンを採用する意味があまりない。

kyoinn3 @XY_kyo

#EAA9_3 テーブルモジュールはクラス単位で対応するテーブルを構築することを主張している

kyoinn3 @XY_kyo

#EAA9_3 「ドメインが抱える問題の一つに、ＲＤＢとのインターフェースがある」というのはクラスメンバーとRDBテーブルの項目の対応にポイントになっていない

Takuya Kitamura @chipstar_light

#EAA9_3 一方、うちのフレームワークによく似ているなと思っていたRoRは、ドメインモデル＋アクティブレコード「シンプルなドメインモデル」なので少し毛色が違うと。

Takuya Kitamura @chipstar_light

#EAA9_3 作っていて知らなかった。。。そうだったのか！

Takuya Kitamura @chipstar_light

#EAA9_3 これも、うちが作っているFWのコンセプトによく似ているし、わざとパクっています。 ということは、うちが作っているFWは.NETを強く意識していたんだけど、それは結局、このテーブルモジュールパターンに該当するアプリケーションを作りやすい仕組みにしていたということ。

Takuya Kitamura @chipstar_light

#EAA9_3 また、テーブルモジュールから取得されるレコードセットはUIへのバインディング（.NETでいうDataSetバインディング）に優れていて、プレゼンレイヤでも、ある程度RDBを意識した作りにしておくことで、ドメインレイヤとプレゼンレイヤの紐付けを簡単にしていると。

Takuya Kitamura @chipstar_light

#EAA9_3 この辺りは.NETのDataSetに通じる部分があると書いてあるし、自分たちが今作っているフレームワークにとても似ている まぁ、うちのフレームワークは意識して.NETのDataSetをパクっているわけですが。。。

Takuya Kitamura @chipstar_light

#EAA9_3 また、特徴としては、このテーブルモジュールを通してやり取りされる個々のデータは、Beanではなく、レコードやレコードセットといったRDBの永続化形式に依存させたオブジェクトにしていること。