読書会(EJBデザインパターン)第2回議事録

[ 戻る ]

EJBデザインパターン読書会議事録 2004年2月28日

出席者:金井 根本 金 村上 吉村 坂本 松本 高橋(智) 布留川 百瀬 高橋(徹) 村山

■P46　Data Transfer Object Factoryより
　-DTOとはdataの１行をjava beanにしたものと思う。
  -Entity beanのコードの書き換えごとのDTO書き換えの問題を排除する。
　-図1.11はstateless session beanの例
　　この図にはなぜ getCarAndManufacturer(carPK) に戻りがないのか？
　　このシーケンス図に限らず、この本は全般的にシーケンス図での
　　戻りは書かないらしい。
　-"スライス"とはいったい何か? 原著もこう書かれている各DTOの合体物を言ってい
るようだ。
　-aggertation entityと似ているが aggregation entityは使わない方がいいらしい
(p225参照)
　-CRUD操作とは　CREATE READ UPDATE DELETEのＤＢ操作の４種類
　-sequence図は、厳密に書くとどうなるか、
　   CarAndManufacturer DTOの生存期間がぶつぎれでおかしい
　   servletの下の×はなんだ？　serverletが消滅するはずはない
　-.NETはXMLスキーマからクラス生成する　JavaならJAXB が近いかrelaxerが近いか
も
　 しれない、VSの標準である、 VisualStudio .NET開発環境ではエンティティーの
   生成は半自動になっていて便利そうである。

■Generia Attribute Access
　-CORBAならgetAttribute() でアクセスする。
　-本当に便利なのか、動作時動的検査に頼るかどうかとなる
　-getter/setterなくせる面は良い。
　-最近のfreesoftはautoPopulate機能がある。　例 http ?
　-Jakarta commonsのBeanUtilsが近い、beanを作りこむ作業が簡単にできる。
　-refletctionを使うので遅くなるのは確実。
　-jdk1.4移行なら性能upしているのでreflection使っても良い。
　-clientのhaspmapのcast操作が煩雑、コーディングは大変
　-I/Fの名前決め作業が煩雑
　-なんでもかんでもXML化して解決というのは遅くなる。
　-DOMは遅い、XPathも速いかどうかは不明
　-XMLはDTOの定義不要となっていいかもしれない。
　
■Business Interface
　-妥当性検査はそんなに煩雑なのか? これはいったいいつの世代の
　 話か？(単に右クリックでvalidationでは)
  -整合性検査が不明、
　-インクリメンタルコンパイラーは大変か、都度自動コンパイルでも
　かまわないはず。
　-開発工程の下流に押しやることにはたしかになるかもしれない。
　-XDocletなら型不一致問題解決可能
　-図1.15 interfaceはimplementsを多段化できるのでこの表記となる。
　-WebLogicはremoteといってもlocalと判断する機能がついている。
　-EJBの仕様にもう入っている、remote interfaceもlocalとして読んでくれる。
　-必要性が不明、XDocletが整合性をみてれてるに期待すべきでは？
　-このパターンは使わないかもしれない。
　-図1.16の右上のbusinesslocalだけ書けば後は自動生成にしてほしい
　- おまけ: C#はthrowsなし
　-JDC @remoteをinteface宣言にうめこめばOKとなるらしい
　-JSR175 はソースにコメントを入れて自動生成できる使用である
　-JSR220 EJB3.0ではmetadataに従ってremote/homeを自動生成
　  もうDeployment Descripterは各必要がない。
　-EOD= Ease of Development
　
■Data Transfer Object
　　コメントなし

■Doman Data Transfer Object
　-クライアント区分トランザクション　JTAか user transactionのことらしい
　-図2.2のEJBの活性期間が長すぎる
　-Entityに日付を与える
　-VSSではなく CVSの感覚
　-optimstic lock　dbはhttp requestはプールをまたがってはlockできない
　-timestampはoracleは1秒以下も表現できるが保証はされない
　-solarisは10ms単位、ただし表記と保証は別問題。
　-Javaの時間は一番信用できない
　-Value ObjectよりはDTOの方が単位として大きいらしい
　-C#の世界でValueObjectに相当するものStruct

■Domain Data Transfer Object
　-C#はDrag&DropでDTOをつくれる
　-属性にルールもつけられて validator的に使える
  -参照整合性は見ない
　-DTOがないどEntityBeanがつくれないという話はおかしい、
　-Entity Beanに対応したDTOという意味だろう
　-local i/FのsetattributeだけではDBの更新はされないはず
　-ejbstore ejbloadが全部の読み込みであれば書き込みは起きないはず。
　-「j2ee best practice」の "value object proxy" hasntableの中身の
　ようなもの、外はI/Fとなっているもの。
　
■Custom Data Transfer Object
　  コメントなし

■Data Transfer HashMap
　-大規模開発ならばHashMapが適切
　-また変更が多発する場合もこれが適切
　-繰り返し構造はどう表現する？　
　-CustomDTOでもlistを入れたほうがJSPからはcollectionとして呼びやすい
　
■Data Tranfer RowSet
　-RowSetの呼び出し　
　-最初は select count * とかで数を見るから全件取り出しかどうか決める。
　-全件取らない様に注意が要る。
　-現状の仕様ではjdbcのドライバーに依存してしまう。
　-Clientのjdkのバージョン合うのか、シリアライズ化に問題は起きないのか。
　-サンマイクロのcachedrowsetとは?
　  http://www.javaworld.com/javaworld/jw-02-2001/jw-0202-cachedrow.html
　  良い日本語記事見つからず。
　-Viewでまとめていることもある
　-「実践J2EE」では、結局DB固有になるのでDB入れ替えはできない
　-logicはjava側で持つべき
　-Container側で CMPのSQLを書くはず　EBJ Containerが決める
　   mappingがないと使えない

■Data Tranfer RowSet
　-XMLDBで代わりになるか？ select操作にXMLは適していないのではないか。
　-富士通OODBもうまくいかないようだ。
　-XMLDBの性能比較はJavaWORLDに載っていたかも
　-雑誌の性能評価記事はアテにならない

■■トランザクション　と永続性に関するパターン
■Version Number
　-tableのsequenceの方が楽　
　-JSPのtokenと同じ　何もしないで帰ってくるものと思えばよい。
　-http sessionにシンクロナイズかければいい、single thread modeなら安全
　-single thread modeのhttp sessionはありえない、パフォーマンスが出ないため
　
※　次回DTO　９３ページ上から
　
根本和郎　記

[ 戻る ]