- 1 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 11:54:44 ]
- 前スレ：
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
ttp://pc8.2ch.net/test/read.cgi/tech/1090653286/
過去スレ：
「Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.2」（落ち）
ttp://pc5.2ch.net/test/read.cgi/tech/1086315004/
「Java⇔RDBのMapping-Frameworkを語るｽﾚ」（落ち）
ttp://pc5.2ch.net/test/read.cgi/tech/1049030272/
●まずは、基礎知識と技術選択指針など
[The Fundamentals of Mapping Objects to Relational Databases]
（RDBに対するオブジェクトマッピングの基礎(英語)）
ttp://www.agiledata.org/essays/mappingObjects.html
[O/R-Mappingツールの比較サイト(英語)]
ttp://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
[Catalog of Patterns of Enterprise Application Architecture (PoEAA)]
ttp://www.martinfowler.com/eaaCatalog/
あとは>>2以降
- 313 名前：デフォルトの名無しさん mailto:sage [2006/07/30(日) 04:53:44 ]
- sfはリリースしてから実際にDLできるまでにラグがあるらしい
- 314 名前：ストーカー [2006/08/03(木) 01:49:49 ]
- crudfactory.sourceforge.jp/tutorial.html
こんなんできてるYO!
- 315 名前：デフォルトの名無しさん mailto:sage [2006/08/03(木) 11:29:37 ]
- メモリに入りきらないぐらいの巨大なテーブルをSELECTして、一件ずつ処理したいと思っています。
Hibernateを使おうかと考えていますが、ネットの入門を見ている限りSELECTした結果を一気に取得しているようです。
全件一気にオブジェクト化するとメモリが足りなさそうなのですが、こういう用途はJDBC使って1件ずつ取り出した方が良いんでしょうか？
- 316 名前：デフォルトの名無しさん mailto:sage [2006/08/03(木) 11:56:03 ]
- 1件ごとにSELECTすると効率が悪いから
何十件かまとめてSELECTするよろし。
それにそもそも、巨大なテーブルを全部変更するなら
ストアドプロシージャのほうが圧倒的に効率がいい。
- 317 名前：315 mailto:sage [2006/08/03(木) 12:48:31 ]
- 書き方が悪かったですね、申し訳ないです。
SELECT * FROM TABLEして全件取得して、ResultSet.next()で1件ずつ処理したいって事なんです。
Hibernateの入門ページ見てると、検索結果がListで一気に戻ってきているようだったので。
つまり聞きたいのは、検索結果全件を一気にオブジェクト化するとメモリが足りないので、
検索結果全件の中から1件ずつオブジェクト化して処理できないかな？って事です。
ListのgetやIteratorのnext時にオブジェクト化されていたら問題なさそうなんですか。
って書いてたら聞くより本なり読んでちゃんと理解してから判断した方がいい気がしてきた・・・。
- 318 名前：デフォルトの名無しさん mailto:sage [2006/08/03(木) 13:24:03 ]
- >>713
素のJDBCだと 一方向に読み込み専用 で取得すると
一気には取ってこないみたいだね
- 319 名前：315 mailto:sage [2006/08/03(木) 16:36:42 ]
- >>318
それをO/RマッピングでやってみたいんですがやっぱJDBC使わないとダメなんでしょうかね。
ふむむ、できないとしたら分割してSELECTするなり工夫が必要かぁ・・・。
- 320 名前：デフォルトの名無しさん mailto:sage [2006/08/03(木) 16:52:08 ]
- >>315
Hibernate使ったこと無いけど、lazy initializationを有効にすると
取得したコレクションからオブジェクトを取得するときまで
インスタンス化を遅らせることができるそうだ。
ttp://www.hibernate.org/hib_docs/reference/ja/html/collections.html#collections-lazy
つうかドキュメント読め。
- 321 名前：315 mailto:sage [2006/08/03(木) 17:14:37 ]
- >>320
おお、良い感じですね。
問題はいらなくなった読み込み後のオブジェクトがちゃんとゴミ掃除されるかどうかだけど・・・とりあえずいろいろ読んでみます。
㌧クス!!
- 322 名前：デフォルトの名無しさん mailto:sage [2006/08/07(月) 18:33:15 ]
- Beanて、テーブル毎に一つ作るものでしょうか？
INSERT目的なら全カラム必要になるだろうけど、
SELECT目的なら一部のカラムのみで十分なケースってあると思うんです。
例：
BOOKというテーブルはID、名前、著者名、カテゴリ情報、概要等、
本に関する情報を多数持っているが、
検索結果に表示するのは名前だけで十分、という場合。
この時ID、名前以外の情報まで持ってくるのは非効率な気がするのですが、
このSELECT目的に別にBeanクラスを定義するというのはアリでしょうか。
class Book { 全カラム }
class BookForSearchResult { ID, 名前 }
それとも、この程度の効率はO/Rマッピングを使用する以上、
気にしない方がいいんでしょうか。
- 323 名前：デフォルトの名無しさん mailto:sage [2006/08/07(月) 19:15:38 ]
- >>322
どうしても気になるのなら、IDと名前だけのビューを作って、
そのビューとBeanをマッピングしたらどうでしょう？
- 324 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 01:42:02 ]
- hibernate使ってたけどいろいろ面倒くさくなってきたのでCommonsDbUtilsに戻してしまった。
なんかすがすがしい気分になった。
- 325 名前：322 mailto:sage [2006/08/08(火) 11:09:26 ]
- >>323
なるほど、ビューを対象にするなら違和感ないですね。
カラムを限定するようなケースが発生するのは大概検索画面なので、
わざわざビューを作る、というのもアリが気がします。
ありがとうございます。
- 326 名前：デフォルトの名無しさん mailto:sage [2006/08/08(火) 19:12:24 ]
- OJB 1.0.4を利用しようと思ってソースとバイナリを取ってきて
動かそうとしているのですが、junit test suiteがFailureを出します。
WinXP (SP1)
JDK 1.5.0_06
lib等は、
antは1.6.5を別途導入。junit.jarはojb1.0.4のをcopy
DBはデフォルトのhsqldb (入手したママ)
でるFailure (1件のみ)
testReportPathExpressionForExtent2
check size expected:<2> but was:<0>
(その他実行結果のファイルにはNOT_EXISTテーブルがないとかもでている)
OJBのドキュメント等やMLも読んだのですが、junit testについては
(hsqldb)についてはそのまま動くとのことで、どう修正すれば
動かせるのかどうかわからなくて困っています。
ここでいいのかどうかわからないのですが、よろしくお願いします。
- 327 名前：デフォルトの名無しさん mailto:sage [2006/08/09(水) 00:20:58 ]
- まだ見てるかわからんが、HibernateならScrollableResultsがある。
ResultSetと同じようなカーソル的な使い方ができるので、
適度にevict()しながら処理すればいいと思われ。
- 328 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:09:46 ]
- 正直O/Rまっぱーの利点がわからん。
簡単な表結合ならSQL書いちゃったほうが早いし
難しい表結合はO/Rまっぱーじゃ結局無理だし。
なにがいいのか俺にもわかるように説明してくれ。
DTO自動で作るだけならエクセルマクロで十分だし。
- 329 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:22:18 ]
- そのエクセルマクロ生成コードにむかついた人が張り切ってしまって
できたのがO/Rマッパー。
むかつかない人はそのままでいいよ。
- 330 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:29:30 ]
- ＞簡単な表結合ならSQL書いちゃったほうが早いし
ORMの利点は、「SQLを書かなくていい」ではない。
＞DTO自動で作るだけならエクセルマクロで十分だし。
それを「車輪の再発明」と言う。
ダメエンジニアが行う愚行の一つ。
- 331 名前：328 mailto:sage [2006/08/17(木) 18:32:31 ]
- >>330
で、結局利点はなんなのでしょうか（＾＾；
- 332 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:35:56 ]
- >>329
個人の趣味で使うものってことでしょうか？？
仕事で使うもんじゃないってことでFA?
- 333 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:42:12 ]
- >>331
オブジェクトとSQLのマッピング作業をフレームワークがやってくれる点。
- 334 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:43:03 ]
- >>329のレスから>>332のような結論が出る時点でDQNエンジニア確定だな。
- 335 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 18:46:33 ]
- ぶっちゃけ俺DQNエンジニアだとおもう。
まっぱーの利点とか理解できないし。
だから教えてくださいお願いします。
>>333
マッピングってDTOつくって、ResultSetから値を取り出してDTOに入れていくってことですか？
ただそれだけですか？
そこでそんなにバグが出たり工数がかかったりしてるんですか？
- 336 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:01:57 ]
- >>335
検索だけじゃなくて、挿入・更新のときのマッピングもね。
DQNかも知れないエンジニアを大量に使わざるを得ないプロジェクトで、
テーブル数が数十個ある場合で、カラムの追加変更などがある場合でも
フレームワークにやらせるよりも手作業の方が早くて確実なら使う必要はないだろう。
- 337 名前：328 mailto:sage [2006/08/17(木) 19:10:21 ]
- それだけしか利点がないならやっぱ内の会社にはいらないのかもしれない。。
ほんとにそこでみんな困ってるの？？？
そのあたりって仮にまちがえてもテスト段階でバグ発見しやすい部分だと思うし
そもそもDTOに入れたり出したりするのなんてそんなに大変な作業でも
ないとおもうんですが・・・。
うちのシステムもテーブル150ぐらいあるし、
カラムの追加変更もときどきあるけど
一度に追加変更されるのって2、3テーブルぐらいのものだし
それだけのためにxml書いたりといった面倒な作業が
工数的、費用的ににペイするのかしら？？
あたらしいもの好きな人たちが趣味でやってる領域なのでは？
実際に業務に使ってるひといるの？？？
- 338 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:25:27 ]
- XMLファイルを手書きしてたらメリットは感じないたろうね。
トータルの記述量はあまり減らないし、かえって面倒と感じるだろう。
そこは自動生成するところだよ。
- 339 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:32:14 ]
- ORM=XML設定ファイル必須というわけでもない。
S2DAOや、Hibernate Annotation、EJB3はXMLによるマッピング不要だ。
- 340 名前：328 mailto:sage [2006/08/17(木) 19:39:49 ]
- XMLをテーブル定義から自動作成する工数と
DTOなど自分でコーディングする工数
システム開発全体にかかる工数から比較したら
これらが締めるのは微々たるものでは？
- 341 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:51:09 ]
- ＞XMLをテーブル定義から自動作成する工数と
＞DTOなど自分でコーディングする工数
ちがう。
テーブル定義からXMLとDTOとを自動生成する工数と
DTOを自分でコーディングおよびSQLとDTOの値の受け渡し処理の
コードを書く工数とその部分をテストする工数の合計だ。
後者の方が早くて確実なら使う必要はない。
- 342 名前：328 mailto:sage [2006/08/17(木) 19:54:00 ]
- その2つだけをくらべたら後者のほうが遅くて不確実なんですが
OR mapperに潜んでいるバグのリスクや、
各OR mapperの使い方を覚える工数を考えたら
やっぱ使わないって判断かなあ。
そもそもわざわざ導入したところで削減できる工数が少なすぎるような気が。
あんだけ雑誌やネットで騒がれておきながら
メリットってこんだけなの？
なんかほかにメリットないのかしら・・。
- 343 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 19:54:11 ]
- そう感じてて、それで本当にいい！ ノープロブレム！
って思うなら、それでいいじゃねえか。
俺はDTOを自分で書くなんて冗談じゃねえが。
Hibernate Annotationでハッピーライフ。
- 344 名前：328 mailto:sage [2006/08/17(木) 19:57:38 ]
- いや、どう感じるかは問題ではなく
客観的な指標から判断して
どちらが生産性の向上につながるのかが知りたい。
なんでこれだけのものにみんな大騒ぎしてるんだろう？
なんかあるのでは？って思ってしまう。
- 345 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:02:51 ]
- 生産性にまともな測定方法なんてﾈｰﾖ
むかつくやり方を続けると、精神衛生に悪くて生産性が下がる。
それだけ。
- 346 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:35:55 ]
- ＞OR mapperに潜んでいるバグのリスク
おまいのところがGavin Kingより優秀な開発者を抱えてるならリスクとなり得るなｗ
- 347 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 20:47:21 ]
- >>345
それは真理だな。
>>344
なんにもないから安心しろ。
頑張って車輪を発明し続けてくれ。
- 348 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 21:04:21 ]
- >>346
マジレスすると、Kingよりも優秀な奴が一人いてもダメだと思う。
HibernateやS2DAOがどれだけの人に動作検証されているのかを考えると、
それ以上の動作検証ができて、はじめて
「OR mapperに潜んでいるバグのリスク」が自作コードより大きくなると言える。
- 349 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 21:37:15 ]
- >>348
自作コードの方が普通は仕様が小さいから、
同程度の品質を確保するのにそこまでの動作検証は要らないけどね。
- 350 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 22:30:32 ]
- ORマッパには、いままでの長い期間で発見されたパフォーマンス
改善手法がデフォルトで組み込まれている。
ORマッパの大部分は関連テーブルのレコードを自動的に取得
できる。
百人がよってたかってデバッグしたコードと、どっかの中小企業が
自分たちのしょぼいプロジェクト用に作って二人か三人でデバッグ
したコードでは、前者の方が信頼性が高い。
ただし１テーブルのデータちょっと取ってくるだけ、しかもテーブル間
リレーションもほとんどない、毎回SQLをコンパイルさせる程度の
負荷などまったく気にしない、とかなら別に使う必要はなし。
- 351 名前：デフォルトの名無しさん mailto:sage [2006/08/17(木) 22:36:31 ]
- 大量のデータをinsertするような、バッチ的処理には向いてないね。
あくまで、オンライントランザクション処理を簡易化するためのフレームワーク。
万能ではない。
- 352 名前：デフォルトの名無しさん [2006/08/17(木) 23:09:32 ]
- まずはテーブルの構造からO/Rマッパー的に作る必要がある。
それができないプロジェクトは、リプレースするか、捨てるか。どっちかしかない。
- 353 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 00:54:27 ]
- >>328
とりあえず何か動かしてみたりはしたの？
Hibernateなら、ツール使えばスキーマ読み込んで勝手にクラス作成までやってくれるから
一度適当に使って試してみたら？
結局ツール適用のメリット有無なんて、対象システムや開発環境との相性だからな
- 354 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 01:31:01 ]
- >>176
忘れた頃に禿同
オレもエンティティにビジネスロジックを書きたくなってしまう。
GRASPじゃないけど、OO的に考えるなら、データに近いところへ
メソッドを寄せ集めておきたいんだよな・・・
自動生成されたエンティティをサブクラスするのはちとキモイしねぇ
- 355 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 07:19:44 ]
- >>176,354
＞自動生成されたエンティティをサブクラスする
ちょっと意味不明だけど
任意のクラスを継承したエンティティを自動生成できるツールがほとんどだよ
- 356 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 07:48:13 ]
- >>355
クラス継承によるロジック共通化をフレームワーク単位で行うと、クラスの拡張性が著しく損なわれるので
最近は避けられる傾向にある
最近DIコンテナを使った開発で多用されているのが、委譲による疎結合。
その場合はステートレスなロジッククラスが利用される。
これとドメインモデルとの相性がイマイチなのがORマッピング利用時の問題
ORマッパー自体がDIをサポートして、ロジックを委譲するオブジェクトを注入してEntityを作成することが出来れば
ドメインモデルでも疎結合でロジックを構築できるのでは？・・・という話
- 357 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 08:00:02 ]
- >>356
>>354からそこまで読み取れたらネ申だな。
- 358 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 08:42:51 ]
- >>176を先に読めよｗ
- 359 名前：デフォルトの名無しさん mailto:sage [2006/08/18(金) 18:56:37 ]
- iBATIS2.2.0(β)
- 360 名前：デフォルトの名無しさん mailto:sage [2006/08/19(土) 00:12:40 ]
- あれ？
iBATIS2.2.0って、ストアドプロシージャと
Beanとのマッピング出来るようになったん？
- 361 名前：デフォルトの名無しさん [2006/09/05(火) 02:43:56 ]
- ついに1000体突破かよ
アイロボットみたいだな
株ロボもいつか夢を見るようになるのかなぁ
- 362 名前：デフォルトの名無しさん mailto:sage [2006/09/06(水) 11:11:38 ]
- 貼っとく
[ThinkIT] 第7回：それぞれのメリット／デメリット (1/3)
ttp://www.thinkit.co.jp/free/article/0606/13/7/
- 363 名前：デフォルトの名無しさん mailto:sage [2006/09/08(金) 15:08:40 ]
- 質問なんですが
Hibernateでsessionキャッシュ上の永続オブジェクトに対して
オブジェクト単位での変更チェックは出来ないんでしょうか？
bool Session#isDirty(Object o, ...)みたいなものがあればいいのですが...
- 364 名前：デフォルトの名無しさん mailto:age [2006/09/26(火) 00:45:24 ]
- キましたね。iBATIS。
ストアドプロシージャとBeanのマッピングOK。
サンプル書いて確認とれました。
sqlMap.queryForObject(query, map);
ArrayList list = (ArrayList)map.get("out");
for(int i=0; i<list.size(); i++){ Bean bean = (Bean)list.get(i); bean.getId();}
SpringFrameworkと連携するときは使えないかもしれないけどね。
とりあえず、Map（HashMap）->ArrayList->Beanの順に格納されているので、
１コ１コ取り出さないといけないのがメンドイ。
つーか instanceofで確認取らせんな！( ﾟДﾟ)ｺﾞﾙｧ!!
- 365 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 01:16:45 ]
- あいばてぃす？
あいべいてぃす？
- 366 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 01:26:28 ]
- いーばてぃす
- 367 名前：デフォルトの名無しさん [2006/09/26(火) 01:36:02 ]
- ibatis.apache.org/background.html
ここ読むと
>We pronounce it: eye-BAT-iss
ってあるから、あいばってぃす？
- 368 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 02:22:18 ]
- シンクイットって登録しないと読めないから資料価値ない。
グーグルキャッシュに入らないマイコムにも言えるが。
エクセルマクロ生成コードにむかついた人が張り切ってしまってできたのがO/Rマッパーなのはいいが、漏れはO/RマッパーのXMLファイル作成にムカつくのはどうすれば良い？
誰かエクセルマクロからXML生成するツール作ってない？
つーかxlsファイル自体を読み込んでO/Rマッピングしてくれってのが、.NETのノリ？
- 369 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 02:44:42 ]
- ＞誰かエクセルマクロからXML生成するツール作ってない？
当然みんなつくってんじゅねぇーの？
一々仕様書から写す手間を考えるとそりゃマクロで吐き出させるだろうし。
こういうのってオープンソースで一個作っちゃったほうがいいよーな気もするよな。
- 370 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 08:09:54 ]
- 作ったらOSSとして公開でいいんじゃない？w
- 371 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 13:10:33 ]
- ソースはどこにうpされてるの？
- 372 名前：デフォルトの名無しさん mailto:sage [2006/09/26(火) 20:32:49 ]
- 会社で作ってて、パッケージ名までcom.なんとかになってるから、
さすがに公開はできんわｗ
- 373 名前：364 mailto:sage [2006/09/26(火) 21:23:18 ]
- SpringFramework + iBATIS でのPL/SQL連携を確認。
つーかさ、DBの問い合わせから戻ってきた値が
<parameterMap>のclass要素のオブジェクトにマッピングされるのはいいんだが、
public List findList(String query, HashMap map)throws DataAccessException
{ return (List)getSqlMapClientTemplate().queryForList(query, map); }
↑のコードの意味無いじゃん。↑のメソッドを ArrayList list = (ArrayList)dao.findList(query, map);
で呼び出すんだけど、結局引数に渡したmapオブジェクト変数に格納し直されるっていう動作はどーなのよ。
いいの？これ。
どーいう意味かの解説は ttp://canetrash.seesaa.net/article/2656752.html にあるんだが、動作的にねぇ…？
結局引数に渡したmapからListを取り出して、さらにBeanを取り出して…。
メンドクサーですよ。O/R-Mapperってこんなんなん？いや、動作的にはO/R-Mappingなんだろうけどさ。
識者コメント＆ツッコミ・キボンヌ。
- 374 名前：373 mailto:sage [2006/09/26(火) 21:46:39 ]
- あー、でも ttp://www.h7.dion.ne.jp/~a.d.1976/naguri20050307.html
見ると
--------------
sqlMaps で SQL を実行する時のパラメータとして使えるクラスには次のものがあります。
・Bean
・Map
・プリミティブクラス（Integer など）
--------------
ってなってるから、だめだ。Map or Beanじゃないと。orz
- 375 名前：デフォルトの名無しさん [2006/09/27(水) 07:55:54 ]
- O/Rマッパーじゃないけど、RailsのMigrateみたいなDBのバージョン管理できるJavaプロダクトって何かありますか？
あーゆーの欲しい。
- 376 名前：デフォルトの名無しさん mailto:sage [2006/09/29(金) 01:08:11 ]
- >>368
blancoDb だろ。Excel O/R マッパー。
俺はそれを作ってる、いがぴょんっていう奴の顔がキモすぎて
試してもない。違うんかもしれんが。
- 377 名前：デフォルトの名無しさん [2006/10/07(土) 04:01:15 ]
- やっぱHibernate最高ですよね？
うちの会社に導入しようと思っています。
いまどきＪＤＢＣでＳＱＬ直書きなんて氏ねばいいと思います。
- 378 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 04:23:21 ]
- 導入前に氏んでいるわけだな。
- 379 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 08:56:57 ]
- >>377
Hibernateがいいときもあるし、JDBCでSQL書きがいいときもあるし、iBatisがいいときもある。
最高ではない。
- 380 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 09:48:02 ]
- まあいまどきJDBCのようなところはとりあえず入れたほうがいいな。
見聞を広げるちゅー意味でも。
- 381 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 11:13:58 ]
- 同意。
Hibernate最高とか言っちゃわない程度には触っておいたほうがいいな。
- 382 名前：デフォルトの名無しさん mailto:sage [2006/10/07(土) 11:46:24 ]
- 適材適所。「最高」なんてものは無い。
- 383 名前：377 [2006/10/08(日) 10:47:35 ]
- いや、Hibernateは上級レベルの達人たちが
ものすごい工数をかけて作成したフレームワークだ。
Hibernateありきだ。
最初に。
もちろんHibernateではダメだというケースも
あるとは思うが、まずはHibernate最高と思っておいて
問題ないのでは？
- 384 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 11:14:28 ]
- JDBC APIだって上級レベルの達人たちが
ものすごい工数をかけて作成した仕様なのだが・・・
- 385 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 11:25:44 ]
- 妄信してる信者の発言にしか聞こえない。
結局はどれが良いのか客観的に語ってよ。
- 386 名前：377 [2006/10/08(日) 11:26:36 ]
- いや、Hibernateも内部でJDBCを使っている。
どんなシステムでも大抵、JDBCを利用するための
フレームワークを作っているだろうが、
そういうフレームワークとしてHibernateに
勝てるわけがないということだ。
- 387 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 14:01:29 ]
- うちなんてHibernateどころかServletすら使えないよ
DBまわりはWrapperがあるけど
BroadVision6...
- 388 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 14:15:17 ]
- ＞そういうフレームワークとしてHibernateに
＞勝てるわけがないということだ。
すげぇ盲信っぷりにﾜﾛﾀ。
- 389 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 18:44:47 ]
- まあ言い方はあれだけどｗ、
日本の会社が自社で作っていたものとは次元が違う存在というのは言うまでもない。
すべてのケースに適しているとはいえないが、
使ったこともないじゃORマッパーを語れないな。
俺はjar（というか使ってるクラス）があまりにも多すぎるところがいやだな。
入れたら起動も死ぬほど重くなるし、OutOfMemoryにもなりやすい。
サーバーにいくつもHibernateを使ってるWebAppがあったら目も当てられない。
- 390 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 19:11:56 ]
- そんな貧相な鯖で Java を動かすこと自体が間違ってる。
- 391 名前：デフォルトの名無しさん mailto:sage [2006/10/08(日) 23:17:11 ]
- フレームワークは目的ではなく手段。
無駄な残業したくないなら要件にフィットするものを選ぼう。
冷静に、冷静に。
- 392 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 01:04:59 ]
- あれこれ選び分ける程の余裕もスキルもありません。
可能な限り「標準」で行きたいのだけど。
JPAはしばらく安定しないだろうなぁ・・・
- 393 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 03:36:02 ]
- >>386
Hibernate に詳しいようだから、使ってみた感想でいいから
他のいくつかの O/R マッパーと比較して何かいいか
教えてくれないか？
俺には何がいいかさっぱり分からんので。
- 394 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 04:56:36 ]
- まずいエサだがスレの内容には沿ってるな＞393
Hibernateのよさは、資料が多いことだな。
俺はCayenne > Hibernateだと思う。複雑なクエリを
HQLで書くのは俺には無理。
- 395 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 05:56:46 ]
- >>393
質問がO/Rマッパーの有用性は
- 396 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 06:29:22 ]
- ごめん、途中で送信した
O/Rマッパーの有用性はわかるけど、Hibernateの優位性がわからないのか
O/Rマッパーの有用性がわからないのか、どっちなんだ
前者ならJPA実装の中でも枯れてるしData Mapperパターンでは決定版に近いってレスになるし、
後者なら、そうですねってレスになる
- 397 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 11:29:44 ]
- O/R マッパー自体の有用性が分からない、つーのはスレ違いじゃね？
有用性があるのが前提で、優劣を議論するのがスレの趣旨じゃね？
- 398 名前：デフォルトの名無しさん mailto:sage [2006/10/09(月) 19:50:13 ]
- >>397
適用範囲を把握するという意味では、
有用性自体を問うのもありだと思ふなり
- 399 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 10:05:46 ]
- ド短期製造、お前らなら何使う？
製造期間 10 日、マスタメンテ 3 機能。
DB 設計済み（複合キー）、検索条件は可変多し。
製造担当はたぶん JDBC 直以外知らない。
学習工数、製造工数の少なさを最優先。
JDBC 直、Hibernate、iBatis、DBUtils、、、
- 400 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 10:20:46 ]
- ＞製造担当はたぶん JDBC 直以外知らない。
＞学習工数、製造工数の少なさを最優先。
10日間に学習工数も含めるのなら、断然JDBC直。
フレームワークは学習コストがそれなりにかかることを
認識しておかないと痛い目を見る。
それを認識できてない奴が「生産性が低い」と騒ぐんだ。
強いて何か覚えるなら、ORMよりもDbUnitでも覚えておいた方がいいんじゃね？
- 401 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 14:16:27 ]
- >>399
MS Access
- 402 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 14:50:21 ]
- 短期なのに学習コスト込み？てか１０日？
ギャグのつもりじゃなかったらやめたほうがいいだろう。
- 403 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 15:28:56 ]
- >>399
JDBC 直
- 404 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 16:47:16 ]
- JDBC直よりは、closeし忘れとかを防止する意味で、
DBUtilsの方がいいんじゃない？
まあ、10日であることを考えたらJDBC直でもいっか。
悩んでいる暇があったら、早くやれって感じだ。
- 405 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 17:31:45 ]
- JDBC直でResultSetMetaDataとDatabaseMetaDataをひっぱって
全テーブル同じクラスで処理する。
- 406 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 18:07:12 ]
- >>399
JAVA止めて、お前がLLで作る
- 407 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 23:48:22 ]
- 仮に実装担当者が「色々とORM知ってます」と言ってきても
ちょっとしたもんならJDBC直（or 学習コストがかからん DbUtils）で十分。
後々メンテ担当者がチェンジする時のリスクも小さかろう。
- 408 名前：デフォルトの名無しさん mailto:sage [2006/10/14(土) 23:57:44 ]
- >>400
DbUnit も知らんとか言ってたな。
一応、俺が Struts 上にアクセス制御、セッション管理、ログ、エラー制御あたりの
共通部を 2 日ぐらいで俺が作って後は任せようかと思ってる。
Click か Wicket も考えたけど 10 日じゃこわいんでやめとこうと思ってる。
>>402
俺はフリーで複数案件やってて60 万で案件とろうとしてるだけだ。
60 万ぽっちじゃ、10 日ぐらいでやらんと割りにあわんだろ。
部下の勉強がてらに良いと思ったんだけど意見を聞きたかった。
>>404
JDBC 直で close し忘れ防止は Session in View パターンで
ServletFilter でも作るわ。
>>405
結果は Map に格納すんの？ リフレクションで Bean？
昔作ったような気もするけど、それだったら何かあるやつ使うかなー。
- 409 名前：デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:08:49 ]
- >>408
勉強がてらなら、もっと納期が厳しくない案件でやらせた方がよくない？
確実に作らせたいのなら、担当のスキルと日程をふまえて指示する側が見極めないとな
あと、DbUtilsにするんなら、1.0は色々問題があるからdevelop版を使ったほうがいい。
- 410 名前：デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:33:13 ]
- 可変長の引数が可能ですが、引数取り出しの扱いがわかりません。
function! AllRead(...)
while args
r args
endwhile
endfunction
どうすればいいでしょうか？
- 411 名前：デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:50:59 ]
- >>409
thx。DbUtils か JDBC にするわ。
- 412 名前：デフォルトの名無しさん mailto:sage [2006/10/15(日) 00:52:05 ]
- >>410
何のハナシをしているのかわかりません
- 413 名前：デフォルトの名無しさん mailto:sage [2006/10/17(火) 13:36:28 ]
- Hibernate 3.2.0 GA
Hibernate Annotations も Hibernate EntityManager も同時に 3.2.0 GA
|
 |
