[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[jfriends-ml 11046] 2月議事録



遅れましたが、2月議事録ポストします。
根本
----------------------------------------------
EJBデザインパターン読書会議事録 2004年2月28日

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

■P46 Data Transfer Object Factoryより
 -DTOとはdataの1行をjava beanにしたものと思う。
  -Entity beanのコードの書き換えごとのDTO書き換えの問題を排除する。
 -図1.11はstateless session beanの例
  この図にはなぜ getCarAndManufacturer(carPK) に戻りがないのか?
  このシーケンス図に限らず、この本は全般的にシーケンス図での
  戻りは書かないらしい。
 -"スライス"とはいったい何か? 原著もこう書かれている各DTOの合体物を言ってい
るようだ。
 -aggertation entityと似ているが aggregation entityは使わない方がいいらしい
(p225参照)
 -CRUD操作とは CREATE READ UPDATE DELETEのDB操作の4種類
 -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 93ページ上から
 
根本和郎 記