PoEAA 10.1章

ricymst @ricymst

#EAA10_1 本ばたーん輪読、お休みさせてもらいます。すいません。別途、学習します。

huskyhead @huskyhead8080

#EAA10_1 テーブルやビュー毎にデータゲートウェイを作成していたら、コード量は半端なく増える気がする。 ゲートウェイ内の共通ロジックをクラスで切り出しても、ビューの数だけあるとしたら。。管理面でも想像するだけで大変そう

huskyhead @huskyhead8080

#EAA10_1 TDGWは全てのSQLを有している。各メソッドから構成されている。

huskyhead @huskyhead8080

#EAA10_1 TDGWとテーブルモジュールの違いが分からなかったから、見直してみた。テーブルモジュールはビジネスロジックを含む場合があるが、 TDGWはビジネスロジックは含めないという違いらしい。

huskyhead @huskyhead8080

#EAA10_1 今回のパターンに限った事じゃないけど、メンテの時でも相当設計を考えてソース変更しないと怖いんじゃ。。 例えばP158のメソッドに「削除キーが追加」という仕様変更があった場合、 （続く）

huskyhead @huskyhead8080

#EAA10_1 直接変更したいけど、 影響範囲が怖いから元のメソッドは残しておいて、別のロジックを追加するか、 そもそもクラスを分けるかするのかな？でもそれなら継ぎ接ぎ継ぎ接ぎで、結局旧来のメンテと変わらない気がする。

huskyhead @huskyhead8080

#EAA10_1 内の開発でこの本で紹介されてる手法を導入するなら、いろいろ足りないものがあると思うけど、 今の単体テストのやり方だと、TDGWとかクラスを多数作るパターンだと絶対漏れが発生するなぁ。

Takuya Kitamura @chipstar_light

#EAA10_1 テーブルデータゲートウェイ（以降TDG）の戻り値はマッピング（Map）は駄目ってさ！うちのフレームワークはMapに近いもの、正確には.NETの非型付DataRowを返してるからダメになってしまう。まぁ俺はいいと思ってるけど。いちいちDTO作るのもめんどくさいから

Takuya Kitamura @chipstar_light

#EAA10_1 この章にも記述されているけど、DTOは「他のどこかで使用されない限り、あまり意味がない」と思う。F/Wの利用案件では、DTO共通化が難しシステムが多いです。１EntityのCRUDを行うPGが１本というような構成のシステムが多いから。

Takuya Kitamura @chipstar_light

#EAA10_1 また、うちの開発体制だと、重複除去より、担当者間のモジュールの非依存性を強く求められるという側面もある。いいのか悪いのかは別として。

Takuya Kitamura @chipstar_light

#EAA10_1 ちなみにうちのF/Wのデータアクセスライブラリはこのテーブルデータゲートウェイパターンですな。ゆえにドメインロジックをテーブルモジュールで組むと相性がよい。というより、TDGはドメインロジックをどういう風に組もうが使い勝手がいいか。

Takuya Kitamura @chipstar_light

#EAA10_1 ターゲットがビューでも、ロジックをTDGで組んで、更新形の処理をストアドで組むってのは面白いなー。永続化の方法に依存するロジックはDB側に持たせてしまって、データソースレイヤのロジックをシンプルにできるのは魅力的。

Takuya Kitamura @chipstar_light

#EAA10_1 TDG ≒ DAO　ですな。

mtoyoshi @mtoyoshij

#EAA10_1 基本的には理解したと思っているけど、P154の真ん中より下あたり。”更新がテーブルデータゲートウェイを介して行われる場合、返されるデータは実際のテーブルではなくビューに基づいたものになるため”　なんで断定できる？？このビューはDBのビュー？なんか違うもの？

mtoyoshi @mtoyoshij

ただし、何がどう違うか具体的に述べよって言われてもうまくいえない。うまく説明出来そう？twitter上で厳しければ明日でもいいんだけど。 RT @chipstar_light: #EAA10_1 TDG ≒ DAO　ですな。

Takuya Kitamura @chipstar_light

TDGWはデータソースレイヤのパターンで、テーブルモジュールはドメインロジックレイヤのパターンやね。RT @izumin8080: #EAA10_1 TDGWとテーブルモジュールの違いが分からなかったから、見直してみた。

mtoyoshi @mtoyoshij

#EAA10_1 俺がよくやるのはServiceLayer → PersonFactory#getPerson(id) → PersonDAO#findPersonById(id) で、Personが返っていくというヤツ。

mtoyoshi @mtoyoshij

P135のシーケンス図でTDGとTMがそれぞれどういう仕事をしているかみればよりわかりやすいと思うよ。責務はしっかり分かれている。 RT @izumin8080: #EAA10_1 TDGWとテーブルモジュールの違いが分からなかったから、見直してみた。

Takuya Kitamura @chipstar_light

うちの場合自社F/W使ってるけど、そのF/WがTDGを実装することなく利用できるよね。専用ツールで設定を行うだけ。だからこれを作ってもテストは今と変わらないと思うよ。 RT @izumin8080: #EAA10_1 内の開発でこの本で紹介されてる手法を導入するなら...

mtoyoshi @mtoyoshij

F/Wとして汎用化させるならそう作ることになると思います。タイプセーフにもっていくならマッパーの仕組みを組み込むことになると思う。どこまでやる？っていうトレードオフ。 RT @chipstar_light: #EAA10_1 TDGの戻り値はマッピング（Map）は駄目ってさ！

Takuya Kitamura @chipstar_light

また突っ込んだ質問してくるねー。J2EEパターンは詳しく勉強したわけではないんやけど、ちょっとみてみます。RT @mtoyoshij: 何がどう違うか...うまくいえない。うまく説明出来そう？ RT @chipstar_light: #EAA10_1 TDG ≒ DAO　ですな。

Takuya Kitamura @chipstar_light

#EAA10_1 すぐに言える事は、DAOはRDBだけをターゲットにしてるわけじゃないけど、TDGは完全にRDBのテーブルをターゲットにしてると思う。

mtoyoshi @mtoyoshij

たかがテーブル数よね？むしろテーブル毎に分かれているので管理しやすいと思うけどな。 RT @izumin8080: #EAA10_1 テーブルやビュー毎にTDGWを作成していたら、コード量は半端なく増える気がする。

mtoyoshi @mtoyoshij

怖いならメソッド追加だろうね。それよりもっと怖いのは重複してて修正漏れが出ること。Personへの変更はPersonGWだけ見ればいいと言えるのが重要なんだと思う。 RT @izumin8080: #EAA10_1 影響範囲が怖いから元のメソッドは残しておいて、別のロジックを追加

kyoinn3 @XY_kyo

#EAA10_1 F/Wってなんの略ですか？FrameWorkですよね。