[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfriends-ml 11046] ２月議事録
遅れましたが、２月議事録ポストします。
根本
----------------------------------------------
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 ９３ページ上から
根本和郎 記