Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.2

前スレ　「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]
　　ttp://www.martinfowler.com/eaaCatalog/

詳細は、>>2以降に。

●O/R-Mapping Framework各種
　[HYBERNATE]
　　ttp://www.hibernate.org/

　[Cayenne]
　　ttp://objectstyle.org/cayenne/

　[Torque]
　　ttp://db.apache.org/torque/

　[CasterJDO]
　　ttp://www.castor.org/jdo.html

　[ObJectRelationalBridge (OJB)]
　　ttp://www.terra-intl.com/jakarta/ojb/
　
　[iBATIS - SQL Maps]
　　ttp://www.ibatis.com/common/sqlmaps2.html
　
　[Java Ultra-Lite Persistence (JULP)]
　　ttp://julp.sourceforge.net/index.html
　
　[Jakarta Commons DbUtils]（O/R-Mappingというよりは、O/R-Bridge）
　　ttp://jakarta.apache.org/commons/dbutils/

●コネクション・プーリング・フレームワーク
　[Jakarta Commons DBCP]
　　ttp://jakarta.apache.org/commons/dbcp/

　[c3p0 : JDBC DataSources/Resource Pools]
　　ttp://sourceforge.net/projects/c3p0

　[XAPool : Pool object for JDBC connections and XA connections]
　　ttp://xapool.experlog.com/



●JDBCに関する情報源
　[JDBCの基礎]
　　ttp://www5b.biglobe.ne.jp/~hrk117/personal/pc/jdbc/

　[JDBC API解説]
　　ttp://akimoto-jp.com/java/Database/Jdbc-api/index.html

●参考サイトや情報源
--- 比較資料など ----
　[JDBC, Hibernate, Torque, DbUtilのベンチマーク比較]
　　ttp://d.hatena.ne.jp/masanobuimai/20031216#p2

---- Hibernate関連情報 ----
　[HIBERNATE - Relational Persistence for Idiomatic Java 【日本語訳版]
　　ttp://www.ozacc.com/library/java/hibernate/doc/html/index.html
　
　[Hibernate User FAQ 日本語訳版]
　　ttp://nekop.programmers.jp/wiki/Hibernate/?HibernateUsersFAQ
　
　[@IT - Hibernateで理解するO/Rマッピング1,2]
　　ttp://www.atmarkit.co.jp/fjava/rensai3/ormap01/ormap01.html
　　ttp://www.atmarkit.co.jp/fjava/rensai3/ormap02/ormap02.html

　[JAVA開発メモ - Hibernate]
　　ttp://www.moriwaki.net/wiki/index.php?%5B%5BHibernate%5D%5D
　
　[はてなダイアリー - R2D2氏の日記]
　　ttp://d.hatena.ne.jp/R2D2/searchdiary?word=%2a%5bHibernate%5d
　
　[はてなダイアリー - koichik氏のひとりごと - Hibernate入門記]
　　ttp://d.hatena.ne.jp/koichik/searchdiary?word=%2a%5bHibernate%5d
　
　[Hibernateメモ]
　　ttp://muimi.com/j/hibernate/
　
　[Hibernateを試してみる]
　　ttp://docs.positrail.org/pukiwiki.php?Document%2FHibernate

続き：

　[Hibernateのマッピング情報を生成するのに便利なツール]
　　- XDoclet
　　　　Java Beanからマッピングファイルを生成
　　　　ttp://xdoclet.sourceforge.net/xdoclet/index.html

　　- Hibernate Synchronizer
　　　　Eclipse用プラグイン。DBのテーブル構造からマッピングファイルを生成
　　　　ttp://www.binamics.com/hibernatesync/
　　
　　- JFaceDbc
　　　　Eclipse用プラグイン。DBのテーブル構造からマッピングファイルを生成。
　　　　ttp://www.pratocity.com/index.jsp?mod=/jface/jfacedbc.jsp
　　　　(新バージョンから有償になった？)
　　
　　- Exadel ORM Studio Hibernate Edition
　　　　Hibernateにも使える、統合ORM操作環境(有償)
　　　　ttp://www.exadel.com/products_ORMstudio.htm
　　
　　- Hibernateと親和性のある、国産IoCコンテナ"Seasar"
　　　　ttp://www.seasar.org/
　　　　ttp://seasarproject.g.hatena.ne.jp/
　　　　ttp://itpro.nikkeibp.co.jp/free/JAV/J2EE/20040412/1/
　　　　


---- Cayenne関連情報 ----
　[Cayenneの紹介と、基本的な使い方(英語)]
　　ttp://www.theserverside.com/articles/article.tss?l=Cayenne

続き：

---- Torque関連情報 ----
　[Torqueを動かしてみる]
　　ttp://homepage1.nifty.com/kingyoshi/computer/jakarta/torque.htm
　
　[Torqueチュートリアル]
　　ttp://www.jajakarta.org/turbine/jp/turbine/torque/tutorial.html

---- JDO関連情報 ----
　[Castorを使用したオブジェクト・リレーショナル・データ・バインディングの基本を学ぶ]
　　ttp://www-6.ibm.com/jp/developerworks/java/021025/j_j-castor.html
　
　[CastorでオブジェクトをRDBにマッピング]
　　ttp://www.atmarkit.co.jp/fxml/rensai2/xmltool06/01.html

---- DbUtils関連情報 ----
　[DbUtilsメモ]
　　ttp://www02.so-net.ne.jp/~kikuta/dbu/index.html

---- コネクションプーリング関連情報 ----
　[Jakarta Commons DBCPを使ってみよう]
　　ttp://taka-2.com/jclass/DBCP/

　[DBCP利用法 from "『カモン!Commons!』 Jakarta Commonsを使ってスキルアップ" (2002/09)]
　　ttp://www.mobster.jp/wiki/index.jsp?pid=Commons#i10

てなわけで、立てますた。
あとは補足ヨロ

ﾉｼ

こんだけあると、スレで話すことはないな。

俺用hibernateメモ。

- Criteriaクラスを使うよりも、HQL使ったほうが高速。
　(Criteriaは、内部解析の後に、SQLへ変換される)

- hibernate.propertiesは、Hibernateが初期化される最初の1回のみに読み込まれ、
　hibernate.cfg.xmlは、SessionFactoryがビルドされる毎に読み込まれる。
　DBへの接続情報を、hibernate.cfg.xmlに書くexampleが多いが、
　経験上、DBとの接続情報などはhibernate.propertiesに全部移し、
　hibernate.cfg.xmlにはマッピング情報のみを記述したほうがいいかも。
　MySQLでは問題ないのだが、DB2に接続する際に、外部キー制約の処理中みたいな
　ログを吐いたところでしばらくwaitしたりする(Hibernate2.1.3と、DB2v8.1 on AIXで確認)。

てんぷれでお腹いっぱいなりました。ご馳走様。

Cayenne公式サイトの User Guide と Modeler Guide

http://www.objectstyle.org/cayenne/userguide/index.html
http://www.objectstyle.org/cayenne/modelerguide/index.html

Hibernate in Actionが10日に発売予定みたいだね。
英語がわからない俺には手を出せないが、挑戦してみるのもいいかなぁ。

O/Rマッパー使ってると、JDBCドライバとRDB間で、どのようなやりとりが
されてるのか知りたいときがある。そのためのツール。

[jdbcdebugger]
ttp://jdbcdebugger.sourceforge.jp/

[P6Spy]
ttp://www.p6spy.com/

HibernateとSpringを使ってトランザクショナル・パーシスタンス・レイヤーを開発する

ttp://www-6.ibm.com/jp/developerworks/java/040604/j_j-hibern.html

Hibenate + XDoclet + DbUnitの組み合わせをテスト
したいのですが、ディレクトリの構成で悩んでおります。
取りあえず以下の様にしたのですが、これがベストなのか
どうかご指摘等お願いします。

ちなみに出来るだけ単純にしたいのでコンソールアプリで
作成しています。

root
│  build.xml
│
├─config ←コンフィグファイル群 java/classesへコピーされる
│  ├─conf ←手動で作成
│  │      hibernate.cfg.xml
│  │
│  └─xdoclet ←XDocletで生成
│          model.hbm.xml
├─java
│  ├─classes ←*.class
│  ├─doc ←javadoc
│  ├─jar ←*.jar java/classesから生成
│  └─src ←*.java
├─resource
│  └─lib ←必要なjarファイル群(Hibenate等)
└─test
    ├─classes ←テスト用の*.class
    ├─data ←テスト用のデータ
    ├─report ←JUnitの結果レポート
    ├─src ←テスト用の*.java
    └─xmlout ←JUnitの結果

>>15
参考になるかどうかわからんが、
ココにHibernate+XDocletの解説とサンプルコードがあった。
ttp://www.commentout.com/people/takai/memos/hibernate_xdoclet/

>>16
そこのサンプルはMavenを使ってるようですね。

実は15の構成だとbuild.xmlがかなり複雑になってしまってて……。
mavenのゴールを調べてみると「xdoclet:hibernatedoclet」
「hibernate:init」「hibernate:schema-export」
などがありますね。
これからmavenを少し勉強してみます。

ありがとうございました。

「XAPoolは負荷をかけると死にます」
ttp://nekop.programmers.jp/diary/?date=20040606#p01

DBCPとHSQLDBのテストデータ使って、小さなテストコード書いてみたけど、
プーリング未使用時よりも30〜40%くらい速くなるのかな。

Hibernate MulitpleTableGenerator
http://www.nighttale.net/OpenSource/HibernateMulitpleTableGen.html

Jakarta Commons DBCP 1.2 ﾘﾘｰｽage

いいスレなのに盛り上がらないね。

>>21
大概語られてるからね

Hibernateのボトムアップ型開発の資料がないのですが。。。(；´Д`)

Middlegenとか見つけたんですがこれもまた資料が。。。（逝

だれか詳細わかるかた教えてください。。。

Sun JDOは無視ですか、そうですか。

まあね。

今だとHibernate一本だよね。

>>23
Hibernate + Middlegen + Antを使用したbuild.xmlの例
ttp://www.boundless-ocean.ne.jp/archives/000102.php

MiddlegenのAntタスクの仕様(英語)
ttp://boss.bekk.no/boss/middlegen/ant/index.html

英語の資料って読むのに時間がかかるので正直ツライ。

>>27
(-人-)アリガタヤアリガタヤ
後者の方は前に見つけて英語がんばってみたが10分で挫折_|￣|○

逝ってきまつ　λ．．．．

>>27のサイトを参考にmiddlegenを使ってみた。取りあえずmysqlでうまくhbmとjavaを生成できたけど……。
jarファイルの依存関係が大変なので、おそらくmiddlegenタスクに辿り着くまでに挫折する人が出てきそうだね。
ttp://boss.bekk.no/boss/middlegen/dependencies.html
んで、せっかくなので、成功したときのtaskdefを晒してみる。

<taskdef name="middlegen" classname="middlegen.MiddlegenTask">
  <classpath>
    <fileset dir="E:/java/middlegen-2.0-vo">
      <include name="middlegen-2.0-vo.jar" />
      <include name="middlegen-hibernate-plugin-2.0-vo.jar" />
      <include name="samples/lib/commons-collections-2.0.jar" />
      <include name="samples/lib/log4j.jar" />
      <include name="samples/lib/velocity-1.3.jar" />
    </fileset>
    <pathelement location="E:/java/mysql-connector-java-3.0.14/mysql-connector-java-3.0.14-production-bin.jar" />
  </classpath>
</taskdef>
<path id="hibernate.jars">
  <fileset  dir="E:/java/hibernate-2.1.4">
    <include name="hibernate2.jar" /><include name="lib/*.jar" />
  </fileset>
</path>
<taskdef name="hbm2java" classname="net.sf.hibernate.tool.hbm2java.Hbm2JavaTask">
  <classpath>
    <path refid="hibernate.jars" />
    <fileset dir="E:/java/hibernate-extensions-2.1.2/tools">
      <include name="hibernate-tools.jar" /><include name="lib/*.jar" />
    </fileset>
  </classpath>
</taskdef>

PriDE 2.1.2リリースage
ttp://pride.sourceforge.net/

struts + hibernate + etcツールをeclipseプラグインで提供。生産性5倍超w
ttp://www.exglue.jp/


上記のサイトで紹介されているHibernateのチュートリアル。
*.xmlのタグが＆lt＆gtになってるんでIE以外では見るのは厳しい。
ttp://www.ndci.co.jp/tips/hibernate/hibernate.html


・・・・・・なんか、妙な気分になるのは気のせいでしょうか？

妙な気分だけど、ExadelとかもStruts用のツールを有償販売してたりするから、
まぁ別にいいんでないかと。
フリーでこういうの出ないかねぇ。

一番妙だと思うのは、「５倍」の根拠ですかなｗ

>>32
自分でstruts-config書いたら、自動生成の場合より5倍かかる、と。

確かに生産性5倍というのは眉唾ものだと思うが、

Hibernateを使用した製品を販売している、という国内のHibernateの導入実績に貢献してくれた
ことについては、素直に評価したい。(購入する気はさらさらないが)


「実績がない」という一言で、便利なツール類が導入出来なかった事が多々あるのもので。

>>32
Exadelはフリー版で充分だよ

まぁ、使う人次第だ

Struts自体が生産性低くしてるもんだから、
こういうプロダクトが出てくるんだろうね。

漏れはよいことだと思うよ。



しかし、漏れの真のおすすめは、普通にServlet/JSPで作る
これで何が不満なのか

Hibernateって、いわれてもなぁ・・・

覚えるほどの価値あるのかしら、成果あるのかしら


イテレータとハッシュマップじゃだめなの？

誰かHibernate in Action買った？

>>37
と思うならそれでいいと思われ。

>>39
だよな。
別にわざわざ説明する義理もないし。

そんなあなたに Tapestry + Cayenne ですよ。

きゃいーん？
かいーの？かんぺい？

>>42にマジレスしていい？

キャシャーンだろ！

シャキーンだと思うよ。（｀・ω・´）

ショボーンかも（´・ω・｀）

Hibernate について、わりとまとめてみた罠。入門用（自分の）。

→ http://hirohiro.homeip.net/essay/2004/06/20040623.htm

Hibernate これからという人にはオススメかも。

素晴らしいです。

期待せずに見たけど、けっこうよかった。

30 June 2004 - Apache OJB (Object/Relational Bridge) 1.0 Released

使っている人いない？

>>47
ネ申
こういう資料を求めていた。･゜(ﾉ∀`)゜･。

＞４７
おおおおお！まさに神！さっそく印刷して使わせてもらってます。

>>47

Hibernateは何なのかとしっかりかいてあってよい

おかげで、漏れは絶対このアプローチのフレームワーク、ライブラリを使うまいと決心することができた

単にデータ構造表すだけなのにソースコード自動生成って、やっぱりくだらないと思うよ。
十年以上も昔にもっとスマートなアプローチ、連想配列や配列の配列ってのがあるしさ。

commonsでいいじゃｎ

>>53-55
と思うのなら、ORマッピングが必要なものを作ってないだけなので、使わなければいい。

ORマッピングが必要なものなんてあるのだろうか。
必要とまで言わなくとも、開発効率が上がるならよいと思うが
問題なのは自動生成したコードのメンテナンスが結局めんどくさいってこと。

Hibernateの作者がこのことに気づいちゃったらやる気なくなるだろうし、
もうHibernateは誰も面倒見ないし、このソフトを土台にしたソフトウェア自体危うくなる。

>>57
変更箇所の集中には価値がある。

>>57

ソースコードの自動生成なんてやってる限り、集中してないだろ。

それに過度の集中ならそれは機能間の依存性の高さに繋がって
変更にかかるコストが高くなる。

自動生成されたコードって人間の感性が反映されてなくて激しく読みづらい

>>59
> ソースコードの自動生成なんてやってる限り、集中してないだろ。

意味がわからん。
自動生成したコードに集中してるんじゃないの？

> それに過度の集中ならそれは機能間の依存性の高さに繋がって

相関がわからん。
たとえば、JDBCでは、DBシステムのバージョンアップで変更があったときでも、JDBCドライバだけに変更が集中する
つまり、この場合は過度に集中しても機能間の依存性の高さにつながってない。
どういう条件で、過度の集中が機能間の依存性の高さにつながるのか、説明きぼん

> 変更にかかるコストが高くなる。

変更作業の総量が少なくても、変更にかかわる人が増えると、変更のコストが高くなることもある。

>>61
> 自動生成したコードに集中してるんじゃないの？
そうだが、自動生成よりもっといい手があるならそれをしたほうがいい

> 相関がわからん。
相姦は特に無い
集中はいいといって本当になんでもかんでも集中させちゃう人が、実際にはいるので書いてみただけ

>>62
いい手があるならね。
自動生成したコードを機械的に変更するのがめんどくさくて、手近に女の子プログラマがいるなら、彼女にまかせればいい。
実によくやってくれる。

というか、>>62が普段どんな文章をかいているのかに興味がある。

↓

相姦

なかなか誤変換できるもんじゃないな。

>>63
最初から自動生成せずハッシュマップでよかろうと

>>66
だから、DBUtilsでいいなら、そうすればいい。
ORマッピングで、OR変換を集中管理したいならORマッピングにすればいい。
別問題。

単純な参照だけなら、ORマッピングは必要ないな。

>>68
「複雑な」参照でもORマッピングは要らないんじゃないの？
すんごい長いSELECT文発行するようなやつ

単純にSQLの結果を出力するだけなら、ORマッピングは必要ないな

>>69は勘違いしていると思われ

ORマッピングが使えるか使えないかはこの際置いておいて、ひとつの事実を。

それなりの規模の仕事をしてて、それなりに技術力のある人は、ORマッピングがイイって言ってる。

ストアドじゃ駄目なんかな？

まあ、ORマッピングがいらないって人は別に使う必要もないよ。
オブジェクト指向の時も、「オブジェクト指向はいらね」と言う人はたくさんいたわけだし。
それで今でも食っていけてるわけだし。

SQL文のメンテにくらべたら
自動生成されるソースのメンテのほうが楽ってこと？

Hibernate in Action を邦訳してだしてくれよ
>クイープ

クイープはやめて〜
Struts in Actionの訳ひどかった・・・・・・・・・・・・

>>74

ORマッピングとオブジェクト指向と同列にすんなよ。
漏れはオブジェクト指向マンセーだが、ORマッピングには超ネガティブ。

ORマッピングって、何の振る舞いも持たないクラスを自動生成するってことでしょ。
これは本当に意味無い。それどころかメンテしづらくなって有害。

>>73
結局やりたいことはJavaストアドなんだよね。

>>78
だから、意味がないと思ったりメンテしづらくなる場合には使わなければいいだけの話。

>>68

そりゃ、何か振る舞いを持つオブジェクトをデータベースを参照して生成するってのは、
それが有効な場面は多いが、しかし、ソースコード自動生成ってことは、ロクな振る舞い
クラスがどんどん生成されるってことだろ。

これは勘違い野郎のウォナニー。

>>78
そうかな。
俺、自作するのめんどいから、つかえるもんならぜひ使いたいけど。
DBレイアウトそのままにマッピングできるclass群の自動生成とか、
それだけでも有効利用する方法が結構思いつく。

おぼえるのがめんどいから、やらないけど。

来週も鬼のような集計用SQLを書いて、それを逐一classに転送する処理作成の続き。
ER図からclassのレイアウトを起こす
↓
classを作成する
↓
集計用SQLを書く（テーブル結合、サマリなどの集計あり）
↓
ResultSetから、値を取り出し、classに配置し、レコード数だけのListにする。
という処理。
なーんか自動化できるような出来ないような・・・。

>>75
SQL文は、分散する傾向がある。
それから、SQL文書いたときは、そのデータ型に従ったResultSet#get・・・メソッドを使って処理をする必要がある。
たとえば、開発中の場合、データベースのフィールド名やデータ型が変わることがゼロではない。
そのときに、SQL書いてResultSet#get・・・書いてる場所はすべて変更する必要がある。
ORマッピングで変換場所をまとめておけば、その部分だけを変更すればいい。
マッピングがXMLに記述されていれば、そのXMLを変更すればいい。
もちろん、完全にそれだけというわけにはいかないけど、ある程度変更場所を集中させることができる。

>>82
もしかして、大量のフィールドとアクセサメソッドしかないクラスを定義していたりするのかしら。

そんなコードもう見たくもない！
普通にMap使ってくれ。

>>83
フレームワークに頼らなくても（むしろ頼らないほうが）シンプルな設計にすることはできるよ。

>>84
だってMapだと型が・・・。

>>85
言うだけならただだよ。
どうシンプルにするんだよ。

>>87
普通にデータ取得する部分をリファクタリングして同じメソッドでやるようにすれば？

>>88
で、それを全部手作業でやる、と。

全部ってどういうことだ。データ取るメソッドが一箇所にまとまっていればそこを直すだけでよい。

>>83
1) DBの型変更→自動生成クラスの型変更
2) →自動生成クラスのユーザ修正

1)は自動化できても2)は必要でしょ
自動生成クラスの型が変わっちゃうんなら

HashMapマンセーの人は多分全部文字列にしてやってるんでしょう
事実それで問題ないことも多いし
型安全性が全く無い分、実はDBの修正に対して柔軟である
(コードの修正が必要ない)ことも多い気がするよ
HashMapを透過で扱ってる部分は全部パススルーになるし
カラムとかは設定ファイルで定義すればいいからね

>>91
だから、RDBの型が変わってもJava側の型が変わらない場合。

HashMapでどうの、って言ってるときは、結局そのデータ表示するだけって場合でしょ。
いろいろ処理する場合、型が必要になるわけで。

もし
自動生成のPOJOの類を透過で扱うためにBeanUtilとか使ってるんなら
まさにHashMapとかわらん気がするよ。
無駄にコードを太らせてるだけ。

> HashMapマンセーの人は多分全部文字列

なわけないだろ
キャストすれ

>>92
> いろいろ処理する場合、型が必要になるわけで

いやいらん場合も多いと思うよ
テキストタイプのSQLクライアントを想定してもらえば分かるように
SQLは基本的に全部テキストだ
Webのクエリに出てくるような情報も、意味論的には整数だったりするかも
知れないが、全部テキストだ
型情報が欲しければ、それさえも設定ファイルに含めてしまえばよい

パススルーではなく実際にロジック的な処理を行う項目・属性は
勿論それではすまないだろう。それはコードに現れざるを得ない。
だが、例えばWeb + DBで構築するような単純なアプリでは、
実際には透過で右から左に渡すだけのデータが意外に多い気がするよ。

>>94
キャストは透過にならないから嫌だなあ
カラム毎にくだらんキャストコード書くぐらいなら
まだラッパーPOJOがあるほうがマシじゃん

分かった
データベースを扱うプログラミングするときは明示的に型宣言しなくていい言語でやる

>>96
くだらなくない　それがJavaプログラミングの味だろ

>>95
>> いろいろ処理する場合、型が必要になるわけで
>いやいらん場合も多いと思うよ

で、いろいろ処理しない場合は必要ないっていってて、いろいろ処理する場合は必要って言ってるように見えるのだけど。

>>99
別にHashMapでも「色々処理すること」は可能だけど透過じゃなくなるだけ
ですよ
画面の入力項目が増えてDBのカラムも増えました
その入力項目は、しかるべきvalidationをおこなって
DBにそのまま突っこむだけです

といった場合、HashMapならコード一行もいじる必要ないよ

あ、勿論「画面」はかわるけどね

>>100
いや、せめて、選択カラムを増やすコードは直さなきゃいかんと思うが。
（リクエストの内容をそのままSQLに流すコードは書くこともできるだろうが、超危険）

>>102
選択カラムのセットなんて、設定ファイル化できるでしょ？

>>103
まぁ、いいんだけど。
個人的には設定ファイルなんてめんどくさいだけだから要らない。
ファイルなんかじゃなく、もっと適切な場所があるだろうし。

>>104
ソースコードの中、とか？(w

DBのカラムにつけられるコメント欄に怪しいコードを書き込んで
それを悪用してた先輩がいたっけ

>>100
なんで、「色々処理すること」は可能っていっておきながら、例として

> その入力項目は、しかるべきvalidationをおこなって
> DBにそのまま突っこむだけです
> といった場合

みたいな、色々処理してない例が出るんだろう・・・

個人的にはHashMapはだめだな。
ルーズすぎる。
新しいフィールドを追加するのも、フィールドけすのも自由なら、
違う型のデータを同じキーで打ち込むのも自由、どんな風にキャストするのかも自由なら、
変数ごとの制度の設定も自由。

だめに決まってるだろ。

ついでに言うと、わたってきたもののインスタンスがなんなのかなんの保障もないし、
どんなフィールドがあるのか、コードから類推できない。

悪いことだらけ。

まあ設定ファイル面倒くさいのは同意ですが
普通そういうのはExcelのマクロとかで吐かせるでしょ
糞みたいなxml手で書いてられるかっちゅーの

つまり、Hibernate + XDoclet 最強、と。

>>106
もしかしてHashMapで「色々処理する」やり方がわかんないの？

おれは、そういう自明な話じゃなくて、「色々処理しなくて済む
場合」には完全に透過になるからDBのカラム定義が変わろうが
コードなんかいじる必要ないよ、というメリットを話してるだけです。

「色々処理する場合」は、要するにキャストが必要になるだけ、でしょ
HashMapの主要なデメリットは。

>>107
> コードから類推できない

メソッド名が適切なら分かると思うよ。

>>107
> どんなフィールドがあるのか、コードから類推できない。

これは結構でかいよね。分かりやすさっつーかreadability。
Perlのようなwrite onlyとか言われる言語でコーディングするのに似てる。
でも、「汎用」だからあたりまえだよね。
コンパイラを眺めたって、それでコンパイルするソースコードが
どんなものかは、分からないのと同じ。

HashMapがいやなあなたは、勿論DOMなんて使わずに
SAXベースで専用のobject木を構築するんですよね、毎回。

>>112
そろそろやめてくれない？
もうそれでいいから。

ここはここで、使いづらくて有用でないORマッパーの評価を続けていくから。
これでいいだろ？

>>108
マクロで吐かせるレベルのものって、なんだ。

その処理に必要なカラムを選択したいからプログラムを書くわけで、
それを設定ファイルっていうのは、やはり面倒だ。メンテナンスしづらい。

>>110
だから、いろいろ処理しない場合は、ORマッピングの意味はあまりない、という話をしてるんだけど。
いろいろ処理するとき、PreparedStatement用意してどうのこうのして、キャストしてどうのこうの、というときの面倒を局所化できる、ということじゃないの？

なんか出だしはよかったのに、今日だけで無駄にスレが間延びしたな・・・。

>>114
validationのコードとか。
木構造じゃなくて表的な構造になってるやつはExcelマクロが
最適じゃん。

>>112
> HashMapがいやなあなたは、勿論DOMなんて使わずに
> SAXベースで専用のobject木を構築するんですよね、毎回。

そんなんDigesterにきまってる。

>>115
ばいばい。

>>117
Validaterで。

>>115
PreparedStatementだのResultSetだのは局所化するでしょ
HashMap使ってるんなら

HashMapってのはDAO層の上にあるobjectなわけだからさあ

>>100=112
107じゃないが
>HashMapがいやなあなたは、勿論DOMなんて使わずに
>SAXベースで専用のobject木を構築するんですよね、毎回。

単にパースする程度でいいならDOMで済ますけど
いろいろ操作したい場合は当然専用のobject木を構築します。毎回。
SAXベースのこともDOMからのこともありますが。

ORマッピングとHashMapも要は適材適所。
全部が全部どっちでないといかんという代物でない。
HashMap信奉者なのか知らんが何でもかんでもHashMapってのは頭が悪い。

>>118
Digesterっつーことはちょっと便利なSAX + 自前obejct treeですね
やはりDOMは
・型安全性がない
・性能がいやん
・マルチスレッド環境が怖い
という感じですか？

>>112
> 勿論DOMなんて使わずに
> SAXベースで専用のobject木を構築するんですよね

そこでRelaxerですよ。
あれもまたトンでもなく冗長なJavaコード吐き出すシロモノで、あれはよくないと思った。

それより、普通にDomプログラミングをしたほうが効率よい。

>>121
> PreparedStatementだのResultSetだのは局所化するでしょ
> HashMap使ってるんなら

相関がない。
HashMap使って、局所化するコード書いてるんなら局所かするだろうけど、そこまでするならORマッピング使った方が楽そう。

>>122

アクセサしかないクラスの自動生成だけは止めてほしいっていう、それだけなんですが。

>>123
っていうか、DOMより楽、ってことで。

>>126
アクセサしかないクラスは、自動生成したい。

>>128
それはHashMapで

>>129
キャストがいや。
たまにある、処理があるセッターゲッターが無視できない

>>125
局所化するのは当然の前提ですよ。
HashMapとDBのI/Oを取り持つDAO層のコーディングなんてタカが知れてるけど
いやならDB-Utilつかえばいいじゃん。
HashMapの場合は、UPDATE文やINSERT文は動的に生成することになるけど
affectするカラムは必要な物に完全に限定できますよ。
変更する対象だけHashMapに突っこめばいい訳だからね。

>>131
> HashMapとDBのI/Oを取り持つDAO層のコーディングなんてタカが知れてるけど

だから、タカが知れてるときは、HashMapでどうぞ、と。

>>127
そうかなあ。そうかもな。
.NETとかだとDOMがXPATH拡張されてるからラクチンだけど
今どきJavaでもXPATHだよね
まあいったん専用のobject木をつくっちまえば、後はそっちのが楽では
あるんだけれど

>>132
ごめんなさい。上で述べたような話は別に案件の性質に依存しないと
思うんですが
どういうときが「タカが知れてない」時なんでしょうか？

>たまにある、処理があるセッターゲッターが無視できない

そうするのが適切なデータベースを扱うソフトって見たことないんだけど、
どういうときに何をやるのか

>>133
オブジェクトにしとけば、イテレータでいけるし。
イテレータだと拡張forで楽ができる予感。

>>134
量が多い

>>137
何の？
HashMapベースのDAO層を作るとして、
テーブル数やレコード件数が増えようが
コードの量は別にかわらんでしょ。関係ないもの。
ま、テーブル数が増えれば設定ファイルは増えるだろうけど
それってフレームワークを使う場合と同じだよね。

結局、俺用マッピングフレームワークがあるからORマッピングが必要ないっていってるだけに見えてきた。

>>139
ええと、自分でコーディングしたことないんですか？
マッピングフレームワークとかがモテ系になる前に。
「で、楽になりましたか？」
と、そういうことを聞きたいだけなんですが。

>>139

俺用というのが、アプリケーション毎に必要な分だけ書かれたコード、という意味なら、
そういうこと。

それが正しいと思うよ。

>>140
フレームワークの一般論なので、とくに説明する必要ないと思われ。
自分のフレームワークで満足してるなら、それでいいよ。

つまり、「みんな俺様フレームワーク持ってるだろうから、ORマッピングなんかいらないだろ」ということ？

ぐげー伸び具合だ…

ということで、俺様フレームワーク持ってなかったり、持っててもメンテナンスがいやだったり、ちょっとでも自動化したいといったことにあてはまる人以外はORマッピング不要ということで。

HashMapで滅茶苦茶押してる奴はなんなんだ、いったい？

型付けがしっかりしてないと多人数が関わる大規模プロジェクトで
破綻すること請け合いですよ。

PHPとかのスクリプト言語じゃあるまいし。。。

ちなみに、HibernateでJDBCを柔軟に使いこなすってのは駄目なの？
単純なマスタ管理部分や更新系はHibernate使っちゃうと楽なんだけど。

BOは自動生成でいけちゃうし、わざわざDTO作る必要ないよね。

>>146
全部Stringでいい、ってプロジェクトなんだと思われ。

>>146
１人か少人数でやってるんじゃない？

今やHibernateは大規模プロジェクトでも使われてるんですか
数億ぐらいとか？
俺は怖いですねちょっと

大規模プロジェクトだとEJBなのかなと思ってました

HashMapで数人程度の奴なら回せますよ
実際にはロジックをいじるプログラマは開発要員の一部になる
訳ですから、困らないことが多い訳です。
昔のCOBOLのコーダーをガリガリ入れてたような大規模な奴なら
考え込むでしょうが、そういうやつでJavaというのは
やったことありませんね

>>148
Stringにマップする訳にはいかないやつって、どんなです？
BLOBとかですか？

数人規模のプロジェクトの上は、数億規模のプロジェクトなのか・・・
なんか支離滅裂やな。

148じゃないけど、いろいろな処理をする場合は、Stringにマップするわけにはいかんと思うんだが。

HashMapで数人程度の奴なら回せる
大規模プロジェクトだとEJB

なんか、HashMapだと足りなくてEJBだと大げさすぎるものはHibernateがいいかも、っていうのをわかってて書いてないようにしか思えないのだが。

>>152
ですから、必要な場合は型変換すればいいでしょう
Stringにしておくと、Validationも透過で扱えるから便利ですよ
正規表現が使えますから

で、あなたが関わっている「大規模プロジェクト」ってのは、
どの程度なんですか？

>>153
所詮その程度のものなんですか？

私は今やトレンドのようになっているOR mappingというのを
トレンドだからと言って盲信するのでなしに、
「本当に便利なのか？」というのを知りたがっている、
そういう「普通の」技術者の疑問に答えて欲しいと思っている
だけです。煽れば色々出てくるでしょうし(w

なぜに>>100さんがそれほど強気なのかわからんのだが・・
Mapでキーにする文字列は定数化とかしてるのかな？ある意味マジック
ナンバーになりかねないと思うけど。

とりあえず、型の考え方についてはEffectiveJavaの7章をしっかり
読んどいた方が良いよ。
http://www.amazon.co.jp/exec/obidos/ASIN/4894714361/qid=1088901593/ref=sr_8_xs_ap_i1_xgl14/250-7076236-2214640

***

あと、話題に出たEJBですがHibernateやっておくと3.0へすんなり
移行できそうです。

http://www.theserverside.com/news/thread.tss?thread_id=27005

>>154
> Stringにしておくと、Validationも透過で扱えるから便利ですよ
> 正規表現が使えますから

Validationがなにを指してるかわからんが、大文字で始まってるからにはなにかのクラスなんだろうか・・・
別にStruts使えば、Stringじゃなくてもバリデータ使えるし、正規表現使えるし。
ってか、そもそも正規表現でチェックしたいデータは文字列だし。

>>155
> 所詮その程度のものなんですか？

何期待してるの？
HibernateがEJBを置き換えると思ってたの？
両者特性が違うから、使い分けるものだと思うんだけど。

> 「本当に便利なのか？」というのを知りたがっている

その「本当に便利」というのは、どんな場合でも便利、ということなんかな。
「所詮その程度」という言葉が出てくるってことは。

>>146
だから、全部Stringなんてありえないって。
nIntegerやLongやBooleanとかいろいろあるだろ。

むしろ、アクセサしかないクラスはスッパリとなくしてしまったほうが
メンテナンスしやすくなって、大規模開発に向いていると漏れは思う。

StrutsでStringじゃなくてもバリデータつかえるっていうのはちょっと違った・・・

>>160
なんでメンテナンスしやすくなる？

>>162
コードは短いほうがよい

なぬ？

Javaに限らないんだが、
ソフトウェアの命はソースコードなんだから、
一行たりともムダなコードは書かないっていう意気込みを持った、
リファクタリングの文化が浸透している組織がもっとあっていいと思う。

ムダなコードがりがり書いて、質の悪いコードが自動生成されたとしても平気なのが、
図太いのかどうなのか。とにかくコードが無意味に沢山あるのが許せん。

>>163
コードが短いほどメンテナンス性が高くなるとは限らない。
処理上ひとつのメソッドで実装できるけど、ユニットテストのためにメソッド分割してコードが長くなるのがわかりやすい例。

アクセサしかないクラスのプロパティは、ツールで生成するし。

画面入力データ(ActionForm等)をHashMapに詰め込むところは
ゴリゴリ書くんですか？

>>165
ムダなコードはムダだけど、冗長なコードがムダとはかぎらない。
まぁ、アクセッサメソッドはC#のプロパティみたいな仕組みがあれば省略して書けるとは思うが。
「省略して書ける」だけだよ。

>>167
BeanUtils

>>168

Javaがあえて省略して書けないようにしてるっていうのは、

「アクセサ多くなりがちなときはキーを渡して値を返すメソッドを作ってくれ」

というJavaの言語仕様設計者のというメッセージなのだと思う。

漏れはこれが気に入っているが。

Mappingの方法で質問なんですが
実際に存在するテーブル一つに対してSELECTとかはできるんですが
JOINとかで結合する場合ってどうやって書けばいいのかわかりません
仮想的なそういうテーブル定義するんですか？
それともViewをDB側であらかじめ作っておきそれに対して
Mapping書くとか？

>>165
> ソフトウェアの命はソースコード

自分が書く部分は命と呼んでいいけど、自動生成されたものは正直どうでもいい。
NetBeansが吐き出すGUI構築部分とか

>>171
せめて、何使ってマッピングしてるのか書け。

>>170
> 「アクセサ多くなりがちなときはキーを渡して値を返すメソッドを作ってくれ」
> というJavaの言語仕様設計者のというメッセージなのだと思う。

「目があったからあの娘はオレのことが好き」理論だな。

>160

――--､..,
:::::::,-‐､,‐､ヽ.
:::::_|　 　|　　|-i､　　　　　
／. ` ' ● '　ﾆ ､
ニ　＿_ｌ＿_＿ノ　　
/￣　　　| i　　 　
|　　　 ＿＼＼
|(￣`'　　）/ /　
`ー---―' / 　
====（ i）=:

>>173
流れから察してやれよ

>>174
こういうのを全否定しているんだとしたら、
何の仮説も言えんじゃないか。

凄いレベルが低い話が続いてると思うのは俺だけ？

>>173
いえ、どのFrameworkっていうわけではないんですが
結合したテーブルをエンティティーオブジェクトとして扱うには
どうやって実現すればいいのかな？と思って
たとえばターキだとどうするのでしょう
一つのテーブルに対しての操作方法はわかるんですが
通常、一つのテーブルからデータ持ってくるだけでは済まないですよね
ある情報をSELECTしてきて、さらにIDと日本語名のマスタから
日本語名を取り出して表示させる場合とか
SQLだとJOINすれば済みますが

>>171
http://www.hibernate.org/hib_docs/reference/en/html/mapping.html#mapping-declaration-manytoone

>>177
少なくとも>>170は、仮説というか、根拠の無い思い込みだ。
仮説だというなら、その根拠になるものをなにかあげてくれ。

おれはアクセッサメソッドだけのクラスは「ツールで生成して振り返るな」というものだと思ってる。
別にJavaの仕様の何かが、暗に導いてるというわけじゃなく、勝手に思ってる。

>>179
外部キーが関連オブジェクトになるイメージ。
ローディングで負荷がかかりそうな箇所は、キャッシュを利用する事で回避。

>>178

こんな型がどうこうなんて、非本質的なのは確かだが、

Mapを使うかいいか、長いクラス定義するのがいいかっていうのは、
美意識の問題なもんだから、これはこれで面白い。

>>179
Turkey・・・ボーリングでストライクを３回続けて出すこと
Torque・・・トルク、偶力

Mapはﾏｼﾞでﾅﾝｾﾝｽ。
キーをスペルミスする馬鹿が頻出して困る。

>>185
ユニットテスト

>>186
実行時にならないと、そういったミスが判断できないような
アプリケーションはどうかと思う。

>>178
チームで開発するときは、チームの方針に合わせてやっちゃうからね。
言いたいこといろいろいあるんじゃないかと。

>>183
サーブレットからJSPにデータを渡すときみたいな一時的なものや、文字列にして表示するだけならMap
あっちゃこっちゃで使ったり、型が必要ならアクセッサメソッド。

長くなるかならないかは判断基準にならないし、するべきではない。

>>187
実行時にならないと判断できないミスって、他にもいろいろあるんだし。
そんなささいなミスを無くすために、ここでわざわざ長いコード生成するほどのことかと。
フレームワークがメンテナンスされなくなったときのリスクもあるんだし。

>>185
JSPに渡すだけなら、結局ELのところで実行するまでわからないことになるから、Mapでいい。

>>190
他にもいろいろあるからこそ、コンパイラで静的に保証できる部分は保証できるようにしておく。

皆ありがとう
リンク先読んでもJOINをどのようにすればいいのかわからんので
とりあえずもうすこし勉強します
外部キーですかなんとなく理解できそう

>>184
ですよね
こないだ、新プロジェクトで初顔合わせのリーダが
「ターキかハイバーネットを使用したいと思っている」
とか言っていたので「あ、あれってターキーて読むんだ」
と思いました
自分は今までトルクだと思っていましたので
「あぶねー恥かくところだった」と思いました

>>190
>>189が言ってるように長くなるかならないかは判断基準にはならない。
値の受け渡し箇所なんて、特にケアレスミスの発生しうる所だから
なるべくコーディング時にミスかどうかを判断させるべき。

>>192
そんな保証しなくていい。
コード追いかける身になってくれよ。

>>193
字で書くときはアルファベットのまま書くがよろしい。
nateをネットと読むこともないし。
最近の流れを見てるとTorqueよりはHibernateの方がいいらしいぞ。

>>195
ｵｲｵｲ…ちゃんと良書読んでるか？

Torqueであまり考えずに作るとOutOfMemoryに悩まされますよ。

>>191
それ、selectした結果をそのまま出すだけならそうかも知れないけど
selectした結果を使って何か処理したりする場合は…

>>195
Map使ってキーの名前間違ってて変な挙動した時のほうが、コード追うの大変。
単なるセッターゲッターだとわかれば、次からみなければいいし。

>>194
そんなこと続けてたんじゃ、
アクセサだけのクラスが多すぎて、本質的なコードが埋もれてしまう。
地獄だ。

>>199
だからJSPに渡すだけなら、と限定してる。

>>201
パッケージわければいい。

なんかMapをひたすら推してる奴等は、全然OOを理解していないんじゃ
ないだろうか。開発効率を優先とか言い張る気なのかな？

Map使いまくってるPJのヘルプに入った時、構造が全然つかめなくて
なんのためにJava使ってるのか意味不明だった思い出がある。

>>最近の流れを見てるとTorqueよりはHibernateの方がいいらしいぞ。
じつは僕、前すれ（だったかな）でHibernateの情報が英語しかなかったときに
一度、動作確認してその流れを書いた者です
あれから全然触っていなかったしこのスレもあんま見ていなかったので今から再度勉強してみます

>>201
おいおい、リファクタリングで局所化すればいいだけだろ？

>>204

OOの本質はポリモーフィズムだろ

振る舞いを持たないクラスを大量生成してオブジェクト指向って、ばかすぎる。

>>205
というかHibernateのGavinがEJB3.0に関わってるから、Hibernateが
主流になっていくのは間違いない。
あのソースを理解するのはかなり厳しいが・・・

>>206
リファクタリングはソースコードの品質を高めること。
コードを自動生成してたんじゃリファクタリングなんてできんだろ。
そのコード削れないんだから。

>>207
ええぇ・・・

>>204
OOは関係ない気が。
コードのメンテナンス性を理解してないだけだと思われ。

>>209
パッケージわけるとか、処理を埋め込むならGenerationGap使うとか普通の話でしょ。

なぜいきなりレスが増えたのだ

俺は今目が覚めたところﾃﾞｽ

>>208
そうなんすか
じゃHibernateの理解は重要ですね

>>207
ポリモーフィズムはOOの手段の一つで、本質は責任の分離。

関係ないけどHibernateInAction全然届かないな。

>>211
CVSリポシトジに自動生成したコードが大量に入ってるなんて、
想像しただけで嫌になる。

コードは少量・シンプルなのがいい。
データはMapと決めたほうが分かりやすい。クラスだと何か振る舞いを持っているのか
いちいちチェックしないといけない。

>>213
雨が降ってきたから。

>>216
そう。責任の分離。
ならば、やはりデータの受け渡しは潔くMapに任せるほうがよい。

MapをDynaBeanとかにすれば済むって話？
ここ数レス見てるとそう取れるレベルの話になってるぞ…

何万件のレコードを扱う場合ってどうするんですか？
メモリ内でやってもいいですが、メモリ喰いますよね
一度、テキストファイルとかに落とした方がいいんでしょうか？

それからいつも思うんですが
DBから取り出すデータを全部出すんじゃなくって
上から何行目までとかいう取り出し方ってないですかね？フレームワークで

データに通番つけて100番までとかいう条件つけるぐらいしか思い浮かばない

>>218
設定ファイルから自動生成するだけのコードなら、そのコードはCVSに入れず、設定ファイルのみCVS管理する。

> クラスだと何か振る舞いを持っているのか
> いちいちチェックしないといけない。

ツリーで、セッターゲッター以外があるか確認するだけでいい。

バグの可能性は少ないほうがいい。

>>218
だからパッケージで分けろって。
クラスだからとかそういうレベルじゃなくて、VOとかServiceとかDAOとか
役割でパッケージングして振る舞いを決めておけば苦労しないだろ。

そもそも、Service層とWeb層のやり取りをMapでやるなんてゾッとする。

>>222
> 何万件のレコードを扱う場合ってどうするんですか？
> メモリ内でやってもいいですが、メモリ喰いますよね

データベースにまかせる。

> DBから取り出すデータを全部出すんじゃなくって
> 上から何行目までとかいう取り出し方ってないですかね？

limit/offset使う

どもです

>>222
普通に提供されている。あとLazyLoding利用するとか。

まずリファレンスくらい読んで機能把握しろ。

>>224
> Service層とWeb層のやり取り

Servlet→JSPの連携を言ってるのか、アプリケーションロジック→Servletの話か、説明きぼん。

> 設定ファイルから自動生成するだけのコードなら、
> そのコードはCVSに入れず、設定ファイルのみCVS管理する。

Map使えばそんな技巧は要らないのに・・・。

フレームワークが、それがいろんな手続きを省略できて、人間からみて
読みやすくしているものならいいのだが、ORマッピングのフレームワークは
むしろ面倒にしているだけとしか思えない。

ORマッピングのスレだったΣΣ(ﾟдﾟｌｌｌ)

>>224
だから。DynaBeanならいいわけ？？

>>228
Action→Service（ビジネスオブジェクト）間のやり取りのこと。
DAOはServiceで利用される。

DIConにはSpringを使ってたりしてる。

>>230
そ、そうですよ
だから、Frameworkでどうするのかと・・・

>>229
技巧っていうか？

ま、HibernateにしろStrutsのActionFormにしろ、XDocletのタグが入るから、CVS管理するんだけども。

>>229
コーディング自体は面倒になるとしても、管理が一元化できて楽とかになって
それがいいと思えば使えばいいし
そんなのいらんと思えば使わなければいい。
ぶっちゃけ、JavaじゃなくてPHPでいいやと思えば、PHPでも似たようなアプリは作れるといった
レベルの話をしているだけだぞそれ。

>>235
ちょっとその人はEnterpriseDevの視点が薄いように思える。

>>236
目先の楽さにとらわれてるだけのような。

>>236
そもそもそこまでの話は出ているのか？
みんなMapうんちゃらCVSうんちゃらでものすごくミクロな視点でしか語ってないぞ。

>>238

単にコードの自動生成は止したいいという、ただそれだけ。
これは、エンタープライズ開発でも小規模開発でも、同じだと思う。

>>238
メンテナンス性がどうのとか、静的型保証の意義とか、そういう話。

性的型保証は必要ですぞ！

>>239
自動生成できるもんは自動生成する。
エンタープライズの場合、極端な話、Javaのコードはすべて自動生成したい。

自動生成する事によって、本当に必要なコードしか書く必要がなくなったよ。

>>242
コーディングレスなアプローチを設計するときは、
コード生成せず、設定ファイルとライブラリだけで動くようにしてください。

なんでソースを自動生成することにこだわるのか。

スクリプトあがりの技術者が多いんだろうなあ。
俺も昔はMap大好きっ子だったしw

>>239
自動生成がいやなら、問答無用で「いらん」って一言言って終わりじゃねーか。
話し合いにも議論にもなりゃしないだろ。

>>218
rubyとかいう糞言語に汚染されてる悪寒。。

だから、MapじゃなくてDynaBeanならいいのかよ？

>>244
最低限必要なクラスは存在するものです。
それともVOとかも設定ファイルを作っちゃうの？

それこそ俺様フレームワークですよ。

セッターゲッターしか持たないBeanを自動生成して、どこが悪いのか？

>>248
静的型保証が出来ない時点で論点が一緒。

>>244
> コード生成せず、設定ファイルとライブラリだけで動くようにしてください。
完全なコーディングレスができるならね。
っていうか、その場合はコードじゃなくてクラスファイル作るわけだが。
現実的には完全なコーディングレスはできないから、ソースファイルを生成して必要なところだけカスタマイズする。

> なんでソースを自動生成することにこだわるのか。
ソースを書くことは、ある一定の確率でバグを作りこむことだから。

>>248
DynaBeanはいいよ。

しかし、OR-MappingのスレでMap論を連呼されてもね。
もうちょっと勉強してから参加して欲しいと思うよ。
有意義な話にまったくならん。

>>252
雛形としての自動生成ってことなら、いいと思うんだが。

ちょっとデータ受け渡しの仕様変えるだけで、Javaコード吐き出し
ツールを動かしてJavaコード自動生成、っていうことなら、それは
よくない。

自動生成を否定しているのは、まともに自動生成を利用している
プロジェクトを知らないだけとかそんなオチ？

Map派→余分なBeanなんかいらない
O/Rマッピング派→静的型保証のできるBeanは必須

こんなのでは10年話したって決着つかないよ。
そもそもMap派はなぜこのスレにいるのか。いらないと思ったらこんなスレに来るなよ。

ちょっと前にやたらMapにしよう！という外注さんがいたなぁ。。。
あまりに自分勝手な人だったんで２週間でお取引願ったがｗ

>>255
ちょっとデータ受け渡しの仕様が変わる部分を手作業で
変えていく方がよくない。担当者によってはデグレートが発生しますよ。

>>228
普通に考えて後者だろ。
「型安全」をわかってないやつ大杉。

スクリプト書いてる人らは型に対する意識が低いように思える。
型に対する意識が低い人は、無意識にバグを埋め込む頻度が高い気がする。

>>259
はっきりいってERDが固まっていない時点でコーディングをすること自体よくない。

自動生成で作って、細かく手を入れたいところでは
ジェネレーションギャップパターン使えばいいじゃん。

Map推進派はそもそもの考え方がJavaのような型定義がしっかりしている言語に
向いてないよ。VBとかやれば？

最近アーキテクトやらせてもらう事が多いから気にならなかったけど、
いまだにMap信者っているんですね。

すげぇ。日本のOR技術者がゴミのように集まってきたよ

>>264
どうせVBでVariantとか使いまくってた人たちでしょ。

こんなもん。規模によって使い分ければいいだろう。

>>262
データベースのスキーマがほんとに固まるまで待ってたら、いつまでたってもコーディングできん。
コーディングの段階で変更の必要に気付くこともあるし。

>>266
これ、ORの話じゃ全然無いよ。

ここ2〜3日で一気に糞スレになりはてた ヽ(`Д´)ノ

>>269
あきらめたらそこで試合終了だよ

>>268
なんだけど、Mapの人は、小規模から大規模まで、Mapでやれとおっしゃる。

>>272
理想求めても、試合終了なんだけど。

>>265
型が保証されているっていうのは、そんなに重要ではないでしょ？
ただClassCastExceptionを避けるためでしかない。

それをやるためだけに、アクセサだけのクラスを（自動生成とかして）作ったりするのは
合理的ではない。非本質的なコードが多くなってメンテナンスしづらなくなる。

2〜3人ならMap使っても良いよ。俺は使わないけど。

>>275
ｵｲ、潜在的なバグをどれだけ減らせると思ってるんだ？

>>274
自動生成ツールくらい使いこなせよ。Antで自動化してれば面倒臭くないべ。
コーディングミスのような人為的ミスを許す方が、よっぽど理想から遠くなる。

>>275
> 型が保証されているっていうのは、そんなに重要ではないでしょ？
> ただClassCastExceptionを避けるためでしかない。

ClassCastExceptionだろうがなんだろうが、実行時に予期しない例外がでることは大問題。
その可能性が減らせることは重要。

>>278
流れ嫁。
データベースのスキーマは自動生成できんよ。

正論はどちらか明らかだが、あまりにも馬鹿馬鹿しいので参加しない。

>>280
ERWin

ツッコミどころがあるな。
データモデルは自動生成できん、だな。
オブジェクトが先かリレーショナルが先かと、順番を変えて、あとの方は自動生成できるが。

>>275
Javaやってるとは思えない発言だな。

>>284
たぶんPHPあたりが本職です。

>>283
そこら辺はBottom-UpやTop-Down、Middle（なんとか）の考え方が
Hibernateで説明されてたよ。

コンパイルが通るのも、それほど重要ではない、とでもいいそうな勢いだな。
動かせるところは動かせばいい、と。
動かしながら文法エラーがみつかったら「Parse error」とか出せばいい、ってね。

>>279
ユニットテスト

実行時エラーの可能性といったって、大して変わらないと思うけどね。
それを回避するためだけにフレームワークの使い方覚えて、大量に見づらいコード生成するって、これはやりすぎだ。
フレームワーク自体がメンテされない状況になったときのリスク犯してまでやることじゃない。

>>288
それをユニットテストの責務に入れるなよ・・・

>>288
アクセッサ書くのはいやで、ユニットテスト書くのはいいの？
アクセッサ使ってれば型保証に関してはテスト書く必要ないと思うんだけど。

>>289
入れてないと、落とし穴にハマると思うよ。

フレームワーク自体のバージョンが変わったときに、
フレームワークを信用して作ったソフトが動かなくなったっていうのは、よくある話。

逆に、ORマッピングフレームワークやるからにはしっかりとテスト作らないといけない。

>>291
それは、R→Oの段階だよね。
Mapの場合、O→Oの段階でもテストが必要になる。

>>291
>>290と一緒の見解。
あと、OR使った時は少なくとも自動生成したDAOに関しては
UnitTest書く必要はないと思うけど。

>>292
DynaBeanならR→Oは不要になるな。

＞ ただClassCastExceptionを避けるためでしかない。
爆笑。ClassCastExceptionが何のためにあるのかわかってない。Javaやめた方がいいよ。
VBかPHPかJavaScriptを奨める。

>>294
書いたSQLのテストは？

凄いレベルの低い技術者が一人で強情はってるだけの気がするね。
同じプロジェクトにいたら面倒臭そう。

あくせく働くのではなく賢く働こう: Kent Beck氏へのインタビュー
http://www-6.ibm.com/jp/developerworks/java/030926/j_j-beck.html

> Javaは非常に悲観的だと思います。Javaのコンパイラに「このプログラムは実行
> できるか分かりません。だから実行しません」と言われたことがあるでしょう。私は、
> 悲観的な言語の安全性とは幻想である、ということに気づいています。

Beckを出すのは良いけど、今回の件とリンクする次元の事なの？

>>298
Integer a = 3;
Object o = a;
String str = (String)o;

これがClassCastExceptionになる以上は、ここでそんな話持ち出しても意味がない。

>>300

まさいこういうことじゃないの？

それに、XP的にいうと、
つまらないミスを回避するためだけに仰々しいフレームワークを導入するのは
You arn't gonna need it の原則に反するし。

>>301
XPの人数スコープ知ってる？

>>301
BeckはここでClassCastExceptionになるのが問題といってるので、ClassCastExceptionになってしまうのだから、そうならないようにする。
で、>>288のいうようにユニットテスト書くのであれば、ソース自体で保証して、テストが必要ないようにすればいい、という話。

> つまらないミスを回避するためだけに仰々しいフレームワークを導入するのは
> You arn't gonna need it の原則に反するし。

つまらないミスを回避するという目的があって、そのフレームワークがその目的を達成するなら、その原則には反しない。

お前ら釣られすぎ、更新したら件数にバビッタヨ。

Mapだと、put("torque","a");としたところをget("turkey")にしたら実行時エラーがでるわけだろ。
で、そこでひっかからないためのユニットテストが必要になるわけだ。
class Hoge{
　String torque;
　String getTorque(){ return torque; }
　void setTorque(String torque){ this.torque = torque; }
}
としておけば、getTurkeyはコンパイルエラーだ。
で、この例みて、そんなコード書くのがめんどくさい、というかもしれんが、このコードはツールで自動生成できる。
ユニットテストは自動生成できない。

>>305
nullが帰っては来るが実行時エラーになるかどうかはその後のコード次第。

>>306
例外がでなくても、意図した動きと違うだろ。

> BeckはここでClassCastExceptionになるのが問題といってるので、
> ClassCastExceptionになってしまうのだから、そうならないようにする。

ORマッピングフレームワーク利用推進派は型安全マンセーなわけだよね。
ClassCastException起こるべきところで起きなかったら型安全マンセーな人は怒ると思うんだけど。


> ソース自体で保証して、テストが必要ないようにすればいい、という話

ソース自体の保証って、どっちにしろテストは書くのだから、ClassCastExceptionだけ回避できても
大した意味ないと思う。

今頃>>47が草葉の陰で泣いてるぞ。

>>308
っていうか、ORマッピング使う意味って、型保証だけだと思ってるの？

>>308
> ClassCastException起こるべきところで起きなかったら

だから、型保証することで、ClassCastExceptionが起きないようにするってことだよ。

>>308
> ソース自体の保証って、どっちにしろテストは書くのだから、ClassCastExceptionだけ回避できても
> 大した意味ないと思う。

コンパイル時に型が保証できれば書かなくていいテストもある。

ところで、検索の結果表に対してクラス自動生成する
O-R mapperって存在する？

テストが完全に書かれる保証はない。

>>311
型保証したところで、大した意味無い（幻想）っていってるんじゃ。

>>313
Hibernateのhbm2java？

>>315
型保証より、名前保証の方が大切な気がしてきた。

Hibernateで表結合を行うクエリ発行して戻り値を受け取る場合…

Iterator it = lst.iterator();

if( it != null ){
　while( it.hasNext() ){

　　Object[] aryObj = (Object[])it.next();

　　String strCcode = (String)aryObj[0];
　　String strCname = (String)aryObj[1];
　　String strBcode = (String)aryObj[2];
　　Date dtSdate = (Date)aryObj[3];
　　String strMname = (String)aryObj[4];
　　int intMprice = (int)aryObj[5];

　　・
　　・ 各インスタンスを使用した処理
　　・

　}
}

型保証もヘッタクレもない。
これじゃRowSetDynaClassと変わらんじゃないか！
ていうか、いくら1テーブルに対して1Beanを作ってくれるとしても
表結合なんか日常茶飯事なんだから、これじゃ全然意味無いんだよ。

>>318
そうですよね
僕はそのことを疑問に思って先ほど質問したんです（>>179）
そんな事やるぐらいなら
素直にJOIN使ったSQL書いたほうがマシなのではないかと・・・

関係ないが、改めて、版画リアン記法ってかっこ悪いと思うな。

>>318
確かに、それはいやだ。

>>320
まったくだ。

>>47のサンプルなんだけどね。
intMpriceって型がlongになったら、変数名全部変えるんだろうか、とか。

>>318
むしろ、配列のインデックスがselectで指定した順、っていうのが気になるけど。
select a, b, c ... ってクエリだとすると
Object[0] → a
Object[1] → b
Object[2] → c
になるらしいけど、こっちの方が可読性も低くなるし、危険じゃね？

それならまだMapの方がいいね。

まだMap厨がいるのか。
Mapスレ立ててそちらでやってくれ。
お前はMapを使い、俺たちはHibernate他を使う。

>俺たちはHibernate他を使う
その「他」にMapが入ってるくせに

>>326
煽りではなくてマジ質問なんだけど、表結合の時はどうしてるわけ？
>>318見る限り、今まで書かれてきたHibernateのメリットがあまり見えないんだけど…
別の書き方とかあるの？

>>328
同意

表結合はどうすんの？
まさか、SELECTしてきたレコードに対してさらにSELECTするなんてオチじゃないだろうな？
それだったら、ただ単にORマッピングって言うのは
DBアクセスだけをラッピングしたものってことになる

結合などのSQL文を抽象化してくれないと意味ないんだよな〜
テーブルに対して一個のJavaBeanつくったって意味ないじゃ〜ん

>>329
実際のところそうなのかもよ。
OODBなんかそうだよね。あれはリンク辿るけど。

>>331
え？まじすか？
もしそうだとしたら
ORマッピングって
オブジェクト志向的にDBのテーブルを操作するだけのものってこと？
そんなんならあんま意味ないよね
カスケードとかはできるみたいだけど
表結合って頻繁に使うよねマジで
SQL一本書いたほうが逆に楽なんじゃない？と思うわけよ

俺はてっきり
表結合された感じのJavaBeanを自分で作って（もちろん定義ファイルも自分で書く）
それをマッピングツールが勝手にJOINしてくれて
レコードが返ってくる機能は当然あるんだろうなと思っていたわけです

>>332
＞表結合された感じのJavaBeanを自分で作って（もちろん定義ファイルも自分で書く）
＞それをマッピングツールが勝手にJOINしてくれて
＞レコードが返ってくる機能は当然あるんだろうなと思っていたわけです
今までの書き込み見たら、誰だってそう思うよね…
俺もそう思ってたよ。

Mapは型が、、という問題はJava 1.5になれば解決する話ですか？

Templateじゃなくって、なんていうんだっけ

>>334
しません。せいぜいMap<String, Object>でキーがStringであることが指定できるだけです。

>>329
> ORマッピングって言うのは
> DBアクセスだけをラッピングしたものってことになる

基本的には、そう。

>>335
Generics

>>332
> オブジェクト志向的にDBのテーブルを操作するだけのものってこと？
> そんなんならあんま意味ないよね

そうでもない。

なんか、OR派の意見が返ってこないところを見ると
マジで結合できないんかな〜
外部キーとか定義ファイルに書いてるみたいだけど意味なさそう・・・

DBアクセスとかのコードは普通にそういうクラス書いてラッピングしようと思えばできます
あとは個々のSQLごとにJOINするSQLのString入れればそれを表すBeanが帰ってくるように
するクラスを一つ一つ書いた方が楽なんじゃね？
DBの変更を考えるとこの方法って辛いけど

>>340
あんだけ活発なスレだったのに、>>318が出たとたんにOR派の書き込みが減ったことからして
かなりアヤシイよな・・・

>>333
> 今までの書き込み見たら、誰だってそう思うよね…

今までの書き込みは、アクセッサのみのクラスとMapの比較だからね。
ORマッピングとかHibernateとかとは、別問題。
今までの書き込みがあって、HibernateのJOINが使えないね、という話になる。

ORマッピングツール
「一発でいろんなもの生成してくれる」
それだけのものなの？
DB変更には強いけど
書いてるソースが結局JDBCと同じならあんま使っても・・・

オブジェクト志向的に物を考えるのは、こういう場合には適さないのかもしれない
>>340のやり方は極端だが
オブジェクト志向的に考えることによって逆に難しくしているんじゃないかと思う

>>342
いや、Map派はもともと>>318のようなことを頭に入れて話してたはずだ。
そこですでに論点がずれていたんだ。

>>341
みんな今必死にしらべてます。(ﾌﾟ

なんか、萎えちゃったな。
Mapとhibernateの間を取って、DBUtilsあたりにしとくか。
間取ってねーな。

>>346
今、100人規模のプロジェクトで、DBUtils使ってるよ。

たぶんJOINするたびにそれ用のクラスをどんどん生成してくれる方法あるんじゃないか。

表結合するときは、出力のときが多いから、そのときはMapでいい。

>>348
ていうか、それ無しではO/Rマッピングツールの意義を問われかねない
今後のO/R派の書き込みに期待だ。
それまではcommonsで我慢だ。どっちにしろMapは嫌だから。

>>346
めんどい更新処理はHibernate使って、複雑なSQLの出力はDBUtils。
どっちかにする必要もないわけで。
Hibernateでまかなえれば、それに越したことはないんだけど。

おい、OR派出て来てくれよ！

マジでJOINはどうしてんのさ　煽りじゃないよ

おしえてくれ

出来ないのならマジで意味ないんですけど・・・

JOINって使いますよね？みなさん

318のやり方でやるの？

いみないっすよ

>>351
んなことするならPreparedStatementでいいと思うが…
ソース内での手間はかわらんし。サニタイスもしてくれるし

結局DBにはSQLが一番マッチしているのだろうか？
ORマッピングツールの記事を
「SQLなんてもう書きたくない」
っていう見出しと一緒になっている
てっきりJOINとかは当たり前に出きるんだろうなと思ったわけよ
あるいは自分であらかじめViewとかつくっとけってことなのかな？
それならそれでOKなんだが
Viewも扱えないようじゃORマッピングにして逆に複雑にしているだけだと思う

>>354

データベースを扱うプログラミングにマッチしているのは、
型宣言しなくていい言語だと漏れは思う。

今はできないにしても、HQLみたいなのができるんなら、あらかじめ
HQLで書いたクエリから結果表クラス自動生成なんて難しくは
なさそうなんだけどな。

「JOINとかを汎用的（OOP的に）にするにはどういう風にすればいいのか？」
と考えたが、かなりムズイよね
仮想的なViewテーブルを最初からDBのほうに登録しておいて
それに対してJavaBeanつくったりとかできるんかいな？

>>353の言うようにふつうにJDBC使った方がわかりやすい

>>355
じゃあJavaはそもそもWebアプリに向いてないんですね・・。

>>356
そうだよね
ただ、反論がないところをみると現状ではそういうのって出来なさそう

>>357

OOPと、
DBUtilsの生成するMapを使ってデータベースにアクセスすることは矛盾しない。

なんでORMapを叩く方向にきてるんだ？
俺が前にhbmでmany-to-oneやるサンプル見せただろ。

それとJoinで細かく取得するやり方も否定しないから、そもそもHibernateでJDBCを
直に取り扱う事もできるし。柔軟にやりたかったらそちらを利用する。
ただ、俺だったらSpringと組み合わせてJdbcTemplateを利用する事を推奨する。

SQLExceptionが実行時例外に変換されるから、見通しが綺麗だし。
そもそもDbUtilsより色々出来る。

Hibernateでやりやすい箇所は>>147で書いたよ。

>>361
叩くというかJOINはどうやるんだ？といったまでです
で、>>318のようになるんだったら意味ないじゃんということです
多対1とJOINは関係あるの？
ちなみに煽っていないです

ごめん>>363は俺
ちなみに関連クラスを Lazy Loding する事によって起こるオーバーヘッドは
普通にHibernateのキャッシュを有効に使えば回避可能。
とりあえず、俺は2次キャッシュまで利用してるけど、かなり良い感じ。

>>364
だから、どういったJoinが必要になるかによる。
Joinで取得したい別テーブルのカラムがあるのであれば、hbmで
マップしておいて、オブジェクト単位で外部キーから取得する。

そうではなく、複数テーブルがかなり入りくんだJoinが必須で
あれば、Jdbcで取得後BOを拡張してsetしていくやり方が必要。

ただ、入り組んだJoinを行うかどうかは設計レベルの問題も入ってくるね。

>>360
DBUtilsの生成するMapを使ってデータベースにアクセスすることは、DBUtilの範囲ではできん気がする。
データベースにアクセスした結果がDBUtilsによってMapのListが生成されるから。

>>355
そりゃ、RDBだったらストアドが一番マッチしてるにきまってる。
型宣言があってもいい。DB自体には型宣言があるわけだから。

入り組んだJOINって、出力用であることが多いから、そんときゃDBUtilsで。

ごめん>>366も俺、名前入れ忘れる・・・
てことで、そもそも>>318のような書き方は普通しないと思うけど。

まあ、>>147でも書いたけど更新系や単純な更新系、BO自動生成、
キャッシングという観点からみると、かなり効果的な選択肢だと思うよ。

>>370
訂正：更新系や単純な検索系ね。

>>366
>通常、一つのテーブルからデータ持ってくるだけでは済まないですよね
>ある情報をSELECTしてきて、さらにIDと日本語名のマスタから
>日本語名を取り出して表示させる場合とか
>SQLだとJOINすれば済みますが

↑こんな場合です

リレーショナルではない条件を指定する抽出にも向いてると聞いたが。

>>370
番号コテである必要がないんだから、スレごとに完結させること。

>>370
できるのはわかったから、じゃ、どうやるの、っていうのを示してくれ。

>>372
それって良く使われるマスタ関連を2次キャッシュしておいて
表示時にキャッシュから取得して表示させるとか駄目なの？

SQL的には一回で済むよ。
データ量が半端なく多かったら、キャッシングの粒度は
変えないと駄目だけど。

>>375
たしか、前に例を挙げたと彼は言ってるけど
検索しても見つかりません
番号とか教えてください

>>376
うん、言ってることがなんとなくわかった

とりあえずHibernateのJoin関連はここ見ると分かりやすいかも

http://www.hibernate.org/hib_docs/reference/en/html/collections.html

て、全然説明になっていませんか？

>>379
＞outer-join="true|false|auto"
おお！JOINあるじゃん　やってみます

>>379
それって日本語訳のページってあったよね

>>382
あれ古すぎです。

日本語版はこれ？
章番号違うけど

ttp://www.ozacc.com/library/java/hibernate/doc/html/collections.html

最近だったら、はてなでやってるHibernate入門記が分かりやすくて
オススメです。

スレの勢いが落ちたわけだが

>>386
必死に勉強中(ﾌﾟ

何があったんだ？今日の流れを簡単に説明してくれ。

>>388

Q,HibernateでJOINできるのか？
A,できる

じゃ勉強します

iBATISでいいじゃん

>>388
Map万能、アクセッサのみのクラス嫌いの、自動生成くそくらえな人が現れました。
それに対して、静的保証の重要性を説きました。
例としてHibernateがよくでました。
>>47で、JOINの場合静的保証どころか名前もつけれてないということが例示されてました。
Hibernate使えねぇという空気が流れます。
そこに現れたのが>>361でした。
そして今は、みんな勉強中。

なるほどよくわかる経緯説明だ
乙！

>>47が勉強してサイト書き換えたところで今回の流れは完結です。
がんばってね。

>>391
乙、なんかTorqueの時も似たような事あったな。

まだまだ発展途上だからな。
法則どおり、バージョン3になったら非常に便利に使えるはず。

はっはっはっは〜
何でも聞けおれに

>>396
辻ちゃんと加護ちゃんどっちが好きですか？

>>396
Hibernateで画像を回転させるには、どのようにアプレットを作ればよいですか？

辻！
最初から辻！

>>399
加護ちゃんがやせててもですか？

プロパティーファイルに
JAVA_3D_HOMEを設定する

燃料が切れたか

そうだ>>400

というか、HibernateでJOINができるらしいということで、一安心。

結局「joinときはこうやれ！」みたいのはまだないわけね？

>>403
ののが太ったら、HibernateとTorqueのどっちを使いますか？

ていうかここ2スレ目だろ
おまえら今まで何やってたんよ

>>405
どうも、悲しいかな・・・勉強してくださいってことらしい・・・
もうさ、「え〜？」って感じ
だれか解説してくれたら
乳首くらいみせてもいいんだけどぉ

>>406
迷うなぁ　ちくしょう　時間くれ

>>408
乳輪に毛は生えてますか？
その場合、英語のサイトを読むのがつらくありませんか？

生えてませんし
今後も生えません

英語のサイトはエロなら読み倒す

ジンガイのパイ毛は半端ではないからな

>>408
そうでしたら、手鏡には気をつけるとして、このサイトのCreating Hibernate Persistence Objectsのところがbeanの参考になりそうです。
ttp://www.meagle.com:8080/hibernate.jsp

急に落ち着いたね

ん？じゃあ、今までHibernateﾏﾝｾｰだったﾔｼらは、
どんなソースを書いていたんだ？

>>415
幸いJOINした結果をごちゃごちゃすることがなかった。
なっちが卒業しても泣かずにすんだ。
サーブレットからJSPに渡すときはDBUtilsを使っていたのでそのまんま。

つまり、ちょっと使ってみたら楽しかった。
まさか警察に通報するとは思わなかった。

>>416
JOINするときは>>47みたいにしてたってこと？
それでよく今まで型保証がどうのと言ってたもんだ…
てか>>361がいなかったら終了だったからな

>>418
型保証のときは、基本的にHibernateとは独立した話

JOIN程度で大騒ぎになるんじゃ、「大規模プロジェクト」が聞いてあきれるよね
みんなオモチャとしてつかってただけなんじゃん

なんかHibernateだとよくわからんのだが、テーブルのJOINって

Book
+--authorID
+--title

Author
+--authorID
+--name

とかいうテーブル構造で、BookのインスタンスからAuthorの
nameを取り出す場合ってことだよな。

　すくなくともWebObjectsのEnterprise Objectsフレームワークだと各テーブル間の
リレーションをちゃんとセッティングしておけば、

　String name = (String)book.valueForKeyPath( "author.name");

　で一発で取ってこれるぞ。ほかのも似たようなもんじゃないのか。
　そういうことじゃないのか？

Hibernateだと

String name = book.getAuthor.getName();

>>421
そうなんじゃないかな〜って言う理解で俺は判断した
多分そういうことだろ？Hibernateって

すまん

String name = book.getAuthor().getName();

>>422
納得
で、そのリレーションが
キャッシュとかあるいは遅延とかできるってことなんではないかと思う

だね。

DB側でちゃんとFK使ってる場合はそうかも。
でもそうでない場合も多い。

え？DBがわで外部キー設定しないとダメなの？
設定ファイルだけじゃダメなんですか？
マンドクサイなぁ〜

ていうか、FK設定すべきものは設定すべきだと思うけど
（これ、型安全性の議論にも通じるね）

INNER/OUTER/LEFT/RIGHT JOINの類の結合条件は別にFKだけとは
限らない
もっとはるかに一般的な、「N個の表から新しい結果表を作る」
機能なんだから。

Hibernateのは、FKをベースに、DB表の親子関係をObject木に見えるように
構築してくれてるだけでしょ。これはJOINと同じものではないよ。

結合、積、差、射影、選択なんてRDB理論の基本なんだから
それがどうマップされるか分からないんじゃ
怖くて使えないよね。

>>429=>>430
ちなみに俺は>>100だけど、意図的に煽りをやっていた自分意外にも
「Map信者」が多くて驚いたYo (w

しつれい
リンクのはりかたがヘンだったな
>>429〜>>431は = >>100です

以外と意外の区別もつかないやつが多くて驚いたＹＯ(ﾌﾟｹﾞﾗｯﾁｮ

2chでスペルミスの指摘して喜んでるやつってまだ居るんですね
珍獣認定させていただきます。

で、「大規模システム」的に、性能はどうなんでしょうか？
適切な選択や射影が行えないために参照性能が低下してるなんてことは
ありませんか？
JOIN一発で済むことに、何度もSELECTが発行されている、なんてことは？

システム屋がDBを扱う以上はSQLのチューニングという問題は
出てこざるを得ません
「大規模システム」なら当然ですね
NOT EXISTSでやればいいのにNOT INを使ってる、みたいな
初歩的な問題も結構見られますしね

ちなみに型安全性の問題ですが、Mapベースで構築した場合は
「柔軟であるがゆえに仕様変更に強い」という特徴があります。
つまり、コード変更をせずにシステム変更に対応できる可能性が
高いんですよ。
この場合、「Unitテストが必要」どころか、コードに対するテストなんて
要らない訳です。
頻繁に仕様変更やカスタマイズが発生する業務系においては
これはクリティカルな問題だと思いますがね。

>>435
だからキャッシュを効果的に利用するって言ってるじゃん。

大規模システムを何故出してるかわからんが、EJB3.0でHibernateに近い
イメージが想定されてる事からも、EJBの策定チームは問題無いと判断
してるんじゃないの？

あとFKの話が出てるけど、DBでFKが設定されてようがいまいが
Hibernateはhbmファイルで判断するから関係無い。
うまくhbmファイルを書けてるかどうかだけが問題。

>>435
>>1-4あたりにパフォーマンス比較のリンクなかった？

>>438
あ、大規模システムってのは、「Mapなんか使ってらんねー理由」
としてそれが挙げられていたからですね。
ただの信条上の問題ではなく、ビジネス的に切実な問題になる
可能性があるケースが、それであると。

>>436
だからEJBでBMPとCMPが併用されていたように状況に応じて使い分ければ良い。
クリティカルな部分は普通にJDBC直で取り扱えば良いだけなんだから。

ただ、すべてが大変なSQLとは限らないでしょ。要はそういうこと。

>>437
> つまり、コード変更をせずにシステム変更に対応できる可能性が
> 高いんですよ。

Map使った場合にコード変更が必要なところが、ORマッピングだと変更しなくて済む可能性がある。
ex フィールド名変更
責任範囲が変わるだけ。

>>439
なんせはてなの日記に過ぎませんし、本人が

> この数字，信用するかは自己責任でお願いします．観測者であるアタシ以外に，
> この値が役立つ人がいるとは思わんが．なにせ測定環境とか明記してないし．
> ＃検証コードは恥ずかしくて，とても公開する気にはならんが．:-D

なんてことを書いてる訳ですから、まともなシステム屋ならこれを信用
できるとは思えませんが？

だからが多くなっちゃった。

とりあえず、もうMap云々の話はやめようよ。くだらない。

みんな一般論になると強いな。(・∀・)

>>438
＞あとFKの話が出てるけど、DBでFKが設定されてようがいまいが
Hibernateはhbmファイルで判断するから関係無い。
うまくhbmファイルを書けてるかどうかだけが問題。


よかったそれが知りたかった

>>443
私にはあなたが頭ごなしに否定したくてしょうがないように見える。

>>442
> フィールド名変更
これは、Mapならコード変更は要らないでしょう。
無論、そのフィールドに対して実際に意味のある仕事が必要なら、
コード変更は必要でしょうが、jspとの間をスルーする程度なら、不要ですね。

逆に、型安全性の世界では、そういう場合にこそコード変更は
必須じゃないんですか？

>>438は>>361だな。

ちょっとしずかにしてもらえませんか。
さぁ盛り上がってまいりました

>>361を悪く言う奴は俺が許さん！

というか>>361とMap信者の話の次元が違いすぎる。

>>435
>>436
についての回答は、いかがでしょうか？

>>435>>436は単なる馬鹿DBAだろ？

いえ、私は「Map信者」だそうですが？
バカの根拠をお教えください。
あなたはSQLのチューニングを行わないのですか？
いかに最近のDBMSの最適化されたクエリアナライザでも、そうそう
賢いものではありませんよ。

俺は454じゃないが、>>441が答えになってないの？

>>448
そのフィールドを参照するすべてのJSPでコード変更が必要だろ。
ORならマッピング先のフィールド名が変わるだけ。
Hibernateなら、XDocletのタグが変わるだけ

うーん。適材適所論は中庸で賢そうですが
あまり美しくない気もするんですが。
メンテする人の立場になると、実装形態やクラスが分散されるのは嫌でしょう。

キケー！

>>458
っていうか、適材ではないものを無理やり使ってるほうが、メンテ大変。

>>457
なるほど、DBのカラム名だけが変わった場合に、もとと同じ名前にマップ
する訳ですね。確かにMapならjspは変更が必要でしょう。が、そういう
ケースはレアなのではありませんか？

カラムが追加された場合はどうですか？

>>460
Mapを使う方法はレガシーであるというだけで、別に適材じゃないとは
思いませんが。

反対してる人達は、そもそも触ったり本家のドキュメント読んだ事あるのかな？

つうか「レガシー」ってよく聞くけど
単語の意味も使い方もわkらん　誰か解説してくれ

>>464
直訳だと「遺産」ですね
なんか古くてボロっちいの
ラッパーが必要な奴
そういう意味で使われることが多いですが

ベンダが「新しい製品を買ってくれ」という意味で使ってるだけのことも
多いです

どもです

>>461
カラムが追加される、ということは、エンティティの性質自体が変わるわけだから、ロジック自体に影響がある。
それに伴ってコード変わるだろ。

それとも、セッターゲッター新たに書く必要があってコードが変わるだろ、Mapならそこに関しては関係ないみたいな、くだらんレベルの話？

ちなみにMap信者の私は「何でもテキスト」「ファイルはただのバイト列」
のUnix文化マンセーですね。テキストは便利ですよ。同じ方法で
透過で扱えますからね。

メインフレームはほんのちょっとしか触ったことがありませんが
データセットにレコード長その他の様々な属性があり、これがもう
RDBの物理設計をやるのと同じなワケです。ただのファイルなのに。

>>464
古くから普及していて、今でも使われている、という感じ。

>>467
そういう「くだらんレベル」は重要でしょ？仕事でやってんなら。

コーディングが発生するかどうか、テストが発生するかどうか、
カスタマイズや仕様変更に対する柔軟性はどうか

で、カラムが追加されても、たんに右から左に流すだけでロジックの性質には
変化が無い、といったケースは意外と(というかかなり)多いはずですよ。

>>470
うん、じゃあ、カラムが追加された場合は、Bean変更する必要があってめんどくさいね。
ORマッピングのよさは、DBの変更がマッピング部分に集中できる、ってことで、変更点が減るわけじゃないからね。
フィールド名が変わった場合もマッピング部分は変える必要があるわけだし。

10人以上のプロジェクト回した事無いんでしょどうせ。
それか異常に時間をもらえてるとか。

Mapを使った時のアンチパターンとか読んだ事ないんだろうなぁ・・・と思う。

10人ぐらいだと、SE、運用、保守、画面屋、etc...でロジック書く奴なんて
数人だから余裕ですね

で、あなたはどれぐらいの大規模システムにHibernateを導入してる
んですか？

>>473
ええ読んだことありませんね。
型安全性が無い点も理解してますし、その問題も分かってるつもりですが
一方その便利さも理解してます。
で、EJBでは大げさすぎるがMapの型安全性の無さが問題になってくる
領域の幅ってのは、どれぐらいなんでしょうかね。

>>474
ごめん実装者が10人以上ってことね。

>>476
画面数1桁以内程度かな？

>>427
ロジック書く奴が10人以上ということは、億単位でしょうか？
そういうのにこういう怪しげな奴を突っこむ度胸は私には無いですね
あなたは、そういう案件に実際に適用してるんですか？

>>478
その程度ならMapで余裕でしょ
つか一人で作れるでしょ

まあ画面の中で何か膨大な仕事をやってるんなら別ですが

Hibernateって怪しげなの？

>>481
ソースに目を通して自分でどうにかする根性があれば、怪しくないでしょうね

でも億単位の案件なら、ベンダの製品サポートが存在する（責任をなすり
つけられる）ことは、非常に重要でしょ。

ベンダーのフレームワークって当たり前にOR/Mapper提供してると
思ってたんだけど、間違えてるかな。
そこら辺のフレームワーク使ったプロジェクトで結構億単位のものは
多かったような。
別にHibernateだけの話じゃないよね、ここって。

Hibernateは全然怪しくないし、サポートは頼めばJBossでやってくれる
んじゃないの？

まあ、ここは新しもの好きが集まるところだからね。

>>482
はい
http://www.hibernate.org/148.html

>>486
ええと、これ実際に利用してる方、いますか？
適用例とかがあれば是非伺いたいものですが。

いや、わからんけど、不安だったらこれを使えば良いのではって話じゃないの？
日本での知名度は分かりきってる話だし、ここではそれを前提において話を
しているわけでしょ。

あなたが本当にプロジェクトを自分のスキル範囲で確実に成功させたいので
あれば、今までのやり方でやるべきだと思うよ。

今やる理由はHibernateが本格的に流行りだした時点で、自分達が熟練した
利用者になっているか、なっていないかの違いだと思う。

文章変だ。
熟練した利用者になるため。に読み変えといて。

>>476
怖いのは、分かってるつもりと理解してるはず。

>>483
EJBじゃない？

ORマッピングフレームワークっていったときには、EJBやMapはとりあえず含まれないと思う。

米国のもっと有名どころの良く知られた製品だって、日本国内に
代理店とサポート拠点がなきゃあ、使うのに躊躇するぞ。

>>479
Mapでやるのもいやだけどな。
それなりに評価して適用すればいいんじゃないの？
「怪しげ」だからと評価もせずに便利そうなツール使わないのはもったいないし。

おれがおれがのお山の大将ばっかやな

>>492
EJBはSLSBで、DAOはフレームワークで提供ってベンダーもあるよね。

まあ、今更JDBCでしこしこupdate文書きたくないよって事で。

ていうかこの人おもしろいよね。
実装に関することでかなわなければ、「億単位のプロジェクトでつかえるのか」って。
そんなん要件によって評価するだけだから、場合によって変わるのに。

>>498
>>454

とりあえず、新しいものに関しては「実績は」っていっとけば、答えに窮するしね。

>>47修正ﾏﾀﾞｰ

>>498
ちょっと違いますね。
ちょっと突っこむと
「RO-Mappingが有効かどうかは要件による」
という話が出てきますので、その有効な要件は具体的にどんなだ
と聞いてるだけですよ。

立って１ヶ月で100行くのか危ぶまれるくらいだったスレが、一気に500。
燃料が入るとよく燃える

>>502
でその答えがでてきたら、Mapで十分と返せばいいってわけですね。
大した燃料です。

で、ここまでの流れはどうなってるの？

>>504
答えって、>>478とかですか？
いえ、あの程度なら一人でやれるプロジェクトですから、
「型安全性は保証しとかないと多人数のプロジェクトはやってけんぞー」
という他の声とは矛盾している訳です。

>>497
そんなものは普通一回書いたら終わりですね
Mapを使うにしても

>>507
現実はスキーマがちょくちょく変わるって話と矛盾する。

>>508
いえ、UPDATE文はMapを使う場合は動的に作るでしょう。
ですので、「一回書いたら終わり」は、executeUpdate()を実行する
コードですね。

>>506
100以降、何度も、こういう場合はHibernateが楽でいい、とかいろいろ出てるよね。

？、キーがそのままカラム名になっちゃうの？

>>510
で、あなたの見解はどうなんですか？

>>509
用意したデータだけ更新するような場合に限るんじゃないの？
それならHibernateならそもそも用意されてるからなにも書かなくても終わり、ってことになるよ。
データ取得しながらその結果を元に更新する場合とかはめんどくさいと思うんだけどなぁ。

>>511
普通そうするでしょう。
キーとカラム名のマッピングを設定ファイルに落として変換するのも
別にどうということもありませんね。

>>511
それで十分らしい

>>513
HibernateはSELECT FOR UPDATEによる行ロックをサポートしているのですか?

>>511
あ、この人は、自分のまわりに起こってることは他の人のまわりにも同じように起こってると思ってるらしい。

キーの変換も機械的にできるし更新対象カラムを絞るのも簡単ですよね
Mapの名前ベースのスキームは設定ファイルとの相性が極めていいのが
強みです。
特殊化されたコードは一行も書く必要がありませんね。

キーにカラム名を使うなんて、まるっきりScriptだな。

>>518
あんた、笑われてるよ。

>>516
普通してる。

>>519
で、それの何が具体的に悪いのですか?
>>520
どうぞ。

>>521
それは、transactionのisolation levelの設定によって、ですか？
ちょっと興味があります。

>>516
ttp://www.hibernate.org/hib_docs/reference/en/html/transactions.html

> LockMode.UPGRADE may be acquired upon explicit user request
> using SELECT ... FOR UPDATE on databases which support that syntax.

>>522
あんたのは型付けのしっかりしているJava言語仕様を自分なりに
歪曲して理解しているだけ。
あんたの中で整合性が取れていても、他の人には俺様以外の何者でもない。

この解釈は間違えてる？

つうか、Hibernateのリファレンスぐらい嫁。読みやすいぞ。

>>525
そんなこというと、ベックが引用されるぞ。

>>525
えーと、Mapを使うかDynaBeanを使うかPOJOを使うかというのは、
Java言語仕様とは全く関係のない、プログラミングスタイルの
問題ですね。
どれもこれも「Java言語仕様」の範囲にあるクラスでありオブジェクト
なのですから。

あ、別に私はSmalltalk信者じゃないですよ(w
型安全性とオブジェクト指向を同列に論じている人を見ると
奇特な方だなあとは思いますが。

>>528
お前はお前で自身を持ち過ぎ。もうちょっと時代の流れを読め。

>>529
スレ違いに気づいていますか？

>>524
なるほど、クエリとしてSELECT FOR UPDATEを明示的に指定すれば
行ロックモードが獲得されるということですか。
Hibernateにおいて実際に使う場合、テーブル・オブジェクトに対して
常に二種類のSELECT文を定義する必要があるということですか？

>>531
どこらへんが？

>>533
Java⇔RDBのMapping-Frameworkを語るｽﾚ

別にくだらないMap主義について語るスレではない。

>>534
本当に私の発言が「無関係」だとでも思ってるの?
ま、「退屈だ」と思うのはしょうがないよ。でも、それはスレ違いとは
また別の話だよね。
実際には関係があるからこれだけスレが伸びている訳です。

>>535
お前意図的に釣ってるだろｗ、むしろ関係なさ杉

>>535
伸びたスレの内容がどうしようもない訳です。

>>537
まあそれは私一人の責任ではありませんので、あしからず。

>まあそれは私一人の責任ではありませんので、あしからず。

だそうです、終了。

やはり RDB は滅ぶべき技術だな。

そう。ファイルで十分。
っていうか、電源いれっぱなにしとけば、それすら必要ないじゃん。

30GBくらいメモリつんで、電源確保。
信頼性や容量確保したければ、台数用意して、P2P分散データベース。
なんだ。
ファイルもXMLもRDBも必要ないね。

コテつけてよぉ
ｱﾎﾞｿできないじゃん

>>542
みな枠からはみ出れないもんですよ

オブジェクトデータベースとかを
下手に新し物好きが採用すると
大体泣きを見ますからね

データの配置がメモリかストレージかという話と、RDB使うかどうかは
全然別の話じゃないのかね。
このままいったら、配列があれば良いって話になっちゃうぞオイ。

>>543
Map信者は私一人ではないようですよ(w

>>542
Google 的だね。

>>542
それ、ソフトのアップデートとかで泣きを見ませんか？

>>549
ﾏｼﾞﾚｽは厳禁です。

>>549
しかたないから、レジューム時だけディスクに書き込む。

っていうか、548のいうとおりGoogleなわけさ。
なので、Googleに聞いてくれ。

>>547
盲目的にMapがいい、って言ってるのはひとりだけな気が。
あと、Hibernateどうよ、っていう意見がすなわちMap信者というわけでもない。

値同士にややこしい関係が必要ないなら、永続化可能な単純な
マップというのは、必要十分なソリューションである気がするが。

＞値同士にややこしい関係
曖昧すぎ

テーブルの結合の仕方によっちゃ似たような名前のクラスいっぱいできるだろうし、
そうなるとクラスローディングのコストもバカにならないんちゃうかな。

>>555
そんなもん、データ自体のオブジェクトに比べれば盗るにタリン

>>555
ってか、もしかしてJOINの組み合わせごとにマッピングクラス作るつもり？

Hibernate良さそう→でもよく分からん→こいつら俺の分からんこと話やがって→Map厨誕生

前スレ、当スレの１です。
すげー伸びに驚愕してまつが。。。

メリットとデメリットの両方があるので、適用したいプロジェクトに
うまくハマるかどうかの見極めが重要だと思います。
漏れ、直近のプロジェクトでHibernate2.1.3を使ったんですけど、
途中で、微妙にテーブル構成が変化することが多い、最初の設計が
ややゆるめ（悪い言い方をすれば、仕様が曖昧）なものだったんですが、
マッピングされたbeanを使うアプリ側の変更がほとんどしなくて済んだので、
こういう場合には有効かなと思ってます。

あと、jFaceDbcとかHibernate SyncronizerなんかのEclipseプラグインを
使ってマッピングクラスを自動生成すると、かなり楽でした。
んで、マッピングクラスのgetter系メソッドを結構修正することが多かったんですが、
extendして使うと更に使いやすい。
これは、Cayenneでは標準的な使い方ですよね。

>>559
> これは、Cayenneでは標準的な使い方ですよね。
Generation Gap パターンすね。モデリングツールからクラス自動生成するときに
勝手にやってくれるんで、えらい便利です。
エンティティに自分でコード書いて「振る舞い」持たせても、後からの
クラス自動生成に一切躊躇しなくていいんで。

Cayenne1.1 ではさらにエンティティに継承関係を持ち込むことも出来るらしく、
「リレーショナルな世界の親子関係って気持ち悪いなあ...」と思ってた自分には
かなり朗報で、これから試してみようと思ってます。
http://www.objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html

Mapを使うとそもそもツールを使う必要すらない、とか、途中でテーブル構成が変わるなど問題外、とか、そういう意見でないかなぁ・・・

日本語資料が揃ってきたらカイエンがメジャーになりそうな気がするんだけど、Hibernateと比べるとどうなんでしょ。
Torqueはなんだか落ちぶれてきて、OJBは出遅れてて、JDOは鳴かず飛ばず、という印象があるんだけど。

>>562
Cayenne のサイトからリンク貼られてたこんな blog が。
http://www.theserverside.com/blogs/showblog.tss?id=CayenneAndHibernate

Cayenne のサイトからリンク貼られるくらいだから、どちらかというと
Cayenne よりの内容なんですが、一読の価値はあるかも。
結局みんな EOF に憧れてるわけなんだなーとか(笑)

# WebObjects 買ってもらったものの、まだまだ
# Cayenne が楽しくて WO 触ってない人

>>561
なぜMapじゃない手法が求められてるかをしっかり勉強しなさい。
自分の知識だけで判断してたらスタート地点にすら立てない。

>>564
お前は文章を読む力を付けような。

急にスレの勢いが止まったようだが

みんな、HibernateでのJOINとCayenneの勉強してます。

Mapﾏﾝ敗北

Cayenne
ロゴがApacheっぽいのでパクリかと思った

Cayenneたのしそう

今更だが、Hibernateだったらdynamic-componentでMapにも対応してるよ。

>>570
楽しいっすよ。楽しいし、何と言ってもラクチン。
もはや生の JDBC とかまったく触る気しないです。
最近ではちょっとしたツールで２〜３テーブルしか触んないようなのまで
Cayenne 使っちゃったりして。
そうなるともはや RDBMS を「単なる便利な永続化層」としてしか
使ってないですが、それはそれでいいんじゃないかと思ったりしてます。
RDBMS ありきでなく、オブジェクトをいかに効率よく永続化するか。
ODBMS 使えつー話のような気もしますが、使ったこと無くて分からんです...

というかMapって、初めて概念を知ると何でもそれでやりたくなるよね。
で、
MapのKeyをそのときそのときで手打ちはよくないから定数化しよう
→Mapのための定数をまとめてクラス化しよう
→せっかくだから定数クラスにMapを継承させて
振る舞いも含めてクラス内に閉じるようにしよう
→クラス内に閉じてるんだからアクセサを定義してget(Clazz.FOO)から
Object getFoo()みたいな形でアクセスできるようにしよう
→アクセサだってメソッドなんだから内部で型チェックとキャストを
行うようにして Foo getFoo()みたいな形でアクセスできるようにしよう
→…アレ?
ってな感じで夢から覚めると。

keyをまともに管理しないと立ち行かなくなった辺りで得失が逆転して、
そこから先はBeanにしたほうがトータルで楽になると思われ。

この前の、JOINの話だけど、 many-to-one と HQLの inner join
使えば綺麗にSQL一回でいけない？

>>568
まあさすがに煽りも飽きたというか、ネタがね……
>>572
ODBMSは遊びならいいけど仕事なら勧めない
>>573
さすがに
んなことやってる奴はいないと思うけどね、君以外は。

機能や振る舞いが多いかどうかでクラスを作るかどうかを
判断するのは当たり前でしょ
「便利なツールが使えるから」じゃなくて、あくまでそこにクラスやオブジェクトが
設計として抽出されるか、が本道な。
ロジックがただのフィルタやパイプラインに毛が生えたようなもので、
DBのデータを「ただのデータ」として透過で扱いたいような場合は、
Mapがしばしば便利であるというだけで。

Map使う場合は汎用的なプロセッサのようなモデルで作るから、
> MapのKeyをそのときそのときで手打ちはよくないから定数化しよう
んなバカなことはしません。

>>575
設計をリレーショナルにしてれば、すでにそれに対応するオブジェクトがあるわけで、それを今までは手間を考えてクラスにしてないだけ。
「便利なツールが使えるから」クラスを作る。

ROマッピングの話で、そんなこというのはナンセンスだな。

ただのデータというが、意味があるデータなら、クラスになりえないデータはない。
プログラムで扱うデータであれば、それはエンティティだからな。

> Mapがしばしば便利であるというだけで。

というのこそ

>「便利なツールが使えるから」

やってるわけだね。

ごめん、読み誤ってたみたいだ。

> 機能や振る舞いが多いかどうかでクラスを作るかどうかを
> 判断するのは当たり前でしょ

ここがそもそも間違ってるんだね。
機能や振る舞いの数は関係ない。

>>577
> ただのデータというが、意味があるデータなら、クラスになりえないデータはない

そもそも「意味がある」かどうかが、まず問題。
無論「業務上は」意味のないデータというのはあり得ないが、
「ロジックにとっては」意味の無いエンティティというのが実は結構
あるだろう。
そういうデータはロジックにとって透明であって欲しい訳で、
型やメンバといったものは一切気にしたくないし、
同じ方法で扱いたい。

要はクラス分けしてる状態よりは、もっと汎化された状態で扱いたいと。
機械的にフィールド毎に単純なバリデーションを適用したり、
データをフィルタリングしたり
(例えばクロスサイトスクリプティングのチェックやUCS文字セットの
中で一部の文字をマッピングするとか）といった仕事をするだけなら
Mapが条件に適合するってこと。一切特殊化されたコーディングは
不要だからな。ただし、valueの
型が不定では実際には不便でしようがないので、こういう用途で
用いる場合、俺は全部Stringにして使う。

Mapping frameworkでも、実際に「ロジックにとって」意味のある仕事
をする場合には、自動生成クラスを継承するか、それをUseする
ロジックを実装するだろう。Mapを使う場合も無論それは同じで、
透明でない部分はクラスを作ることになる。その部分がどれぐらい
多いのか？といったバランスの問題で、Mapが実際的かどうかが決まってくると
思うんだが。

>>579
だめだめやな。

> そういうデータはロジックにとって透明であって欲しい訳で、
> 型やメンバといったものは一切気にしたくないし、
> 同じ方法で扱いたい。

だからBeanに型もたせて、扱う場所では型を気にせずにすむようにするんでしょが。
Mapが便利な処理をする場合はBeanUtils#describe使えばいいだけで、マッピング用のBeanが自動生成できるならBean作った方がいいし。

>>575
Mapを使うとしたらキーは普通自動生成で定数化しますよ。
あなたは、キーをいちいち文字列で書かせてるの？

さぞかし、スペルミスがまったくない素晴らしい人たちばっかりなんですね。

またMap厨か。

だいたいこのスレで「普通こうする」って言ってるやつは、自分がやっている方法を他の人もやっていると思ってる。
または、他の人も同じ組織のレベル、同じアプリケーションの種類、同じ規模のものを作ってると思ってる。

「普通」なんか、組織やら作るものの種類・規模によって違う。

Map絡みは馬鹿が一人いるからループする。放置の方向でお願い。

カイエンに関して、日本語で解説されたサイトとか資料とかないっすか？

O/Rマッピング好きがコンパイルエラー頼りの人多いのは意外
マッピングするためのxml設定ファイルはキーワードエラーすら出ないのに

>>586
ん、マッピング設定の xml はツール使って DB スキーマから
リバース生成とかするんでないの？

>>580
valueの型が不定のMapなんぞ渡されても使い物にならんよ

>>581
ええと
> Mapを使うとしたら普通
ってのは、どっから出てくるんだ
脳内か？

>>588
使う腕がないから？
それなら、Mapにデータを持つ場合も同じ。
MapのデータをすべてStringにする、というなら、そのときに使うコンバータをBean→Mapのときに使えばいい。

>>590
いや、もとからMapで作る気なら最初からStringで設計するな。
だから、同じじゃないよ。

>>589
変数をID管理してたCOBOLerじゃないの？

Mapが使えるのはキャッシュくらい。

>>５７５
ＯＤＢＭＳはプログラミングはラク。
しかし今ＤＢにどんなデータが入ってるかを把握するのが辛い。。
ＳＱＬの偉大さを知ったよ。。

ODBMSはパフォーマンスを出しにくかったり、言語に密接になってしまったりと使いづらいという印象がある。

>>591
Stringで設計しない、なら、valueにどんな型が入ってるかわからないわけだよね。
>>588のいう「valueの型が不定のMap」じゃないの？

みなさんお待ちかねのMap屋ですよ。

>>594
Object storeあたりかしら？
俺的には別にプログラミングが楽とも思えませんが……。
システム屋が普通にサポートするレベルの性能・保守・運用面を考えたら
地獄を見るだけ、でしょう。
壊れてもいい程度のデータの永続化に使うならいいかもしれませんね。
UnixのDBMの延長線みたいな感じで。ただ、それなら素直に
Berkeley DBでいいような気もしますが。pure java版のライブラリも
最近は利用できることですし、実は最近のはトランザクションや
チェックポイント、リカバリなんて機能もあるようですから驚きです。
どうせならperlのtie()風に透明に扱えるともっと便利なんですけど。

>>593
ハハハ、自分の無知をひけらかしているだけのレスですね。
コンパイラのシンボルテーブルのようなものを実装するのに
あなたはMapを使わないのでしょうか。あ、もしかしてC++の
std::mapなら型安全だから使うの？
くだらないね。

>>585
つくりました。

CayenneでORマッピング
ttp://www.fk.urban.ne.jp/home/kishida/kouza/cayenne.html

「日本語で書いてある」以上の意義はありません。
とりあえず使うだけ。

>>598
Map屋ですが、素晴らしいですな
ただ、以前Cayenneを一瞬だけ斜め読みしたときは、主キー生成部分がまだまだ
アマいのと、対応DBが不十分だったんで、その辺を書いてくれると
嬉しいのかなと。最近のはマシになってるようですからね。

ちなみにそこで挙げられてる
サンプルソースのような、Criteriaみたいなクラスを使った検索って
何がうれしいのか俺は分からないんですがね。マジで。

・どんなSQLが走るかトレースしてみないと分からない
・コードも別に全然短くない
・クエリを設定ファイルなどに切り出しにくく、明示的な
　コーディングが必要
・オンメモリにリストを作っちゃうので大量検索に向かない
・誰もが知ってるSQL構文ではなくライブラリ独自の方法の学習が必要。
　SELECT構文って本気で使うと複雑ですからね……

最悪ですね。

>>599
> その辺を書いてくれると嬉しいのかなと。
ま、使ってみましょうかね、という企画なので。
とりあえず使ってみれば、英語のドキュメント読む気にもなるかな、と。

> 何がうれしいのか俺は分からないんですがね。マジで。

分からないなら必要ないので使わなければいいだけの話で、使ってうれしい状況になれば何がうれしいのか分かると思うんですがね。

ひが氏の今回の更新がORMappingだったので
過去記事含めて貼ってみるテスト。

ダイコン時代のORM - 結果セット中心
ttp://d.hatena.ne.jp/higayasuo/20040708#1089245059
過去記事
ttp://d.hatena.ne.jp/higayasuo/20040609#1086738237

で、結果セットってのはどうよ?
俺はこういう場合はDAOでJDBC直書きでデータ抜くなりO/RMaｐされたBeanから値抜くなりして
Beanに詰めさせるもんで、O/RMapより一階層上のレイヤの話だと思ってたんだけども。

>>599
・ほとんどのSQLは、パフォーマンスで問題になることはない。
・ほとんどの問い合わせは、どんなSQLになるか興味ない。
・めんどくさいJOINを書かなくて済む
・明示的なコーディングをどっかでメソッドにして使いまわせばいい。
・烏合の衆にめんどくさいJOINを教えなくて済む
・烏合の衆が書いたSQLのtypeによる例外が減る
・オンメモリにリストを作っちゃうとは限らない。
・コード補完のおかげでフィールド名を覚えておかなくていい。
・なんにしろローカルなコーディングルールやフレームワークを作るだろうけど、そのドキュメントのメンテナンスはめんどくさい。
　有名マッピングツールなら、ドキュメントが整備されてる。Cayenneもそのうち増えるだろう。
・なんにしろローカルなコーディングルールやフレームワークを作るだろうけど、それに比べればコードは少なくなる

>>601
DAOとEntityを分けて考えるというスタンスだからこれはこれでアリと思われ

>>599
> ・どんなSQLが走るかトレースしてみないと分からない

query.setLoggingLevel(Level.WARN);
とすれば、とりあえずどんなSQLが走るかログがでます。

> ・オンメモリにリストを作っちゃうので大量検索に向かない

performIteratedQueryを使ってResultIteratorを取得すればいいらしい。
でも、チュートリアルみると、あまり嬉しくないコードを書く必要がある気配。

なんか、全体的にキャストが必要なことが多い気がする。

> ・誰もが知ってるSQL構文ではなくライブラリ独自の方法の学習が必要。
> 　SELECT構文って本気で使うと複雑ですからね……

「本気で使うと複雑なSELECT」を書かなくて済むのはいいかも。
JOINがからむ場合とか。
楽ができる部分と、めんどくさくなる部分がある。

>>599
お前は確実に嫌われるタイプの人間だな。
自分の意見を押し付けすぎだし、書いている内容が批判中心で実が無い。

とりあえず、お前が望むレベルのOR/Mapper作ってみてくれ。

Map絡みはかなりスレの流れを阻害している気がする、ほんと勘弁。

SQLに凝るやり方は、技術者によって差が出すぎるからオススメしない。
なるべく設計レベルでうまくまとめるべき。で、PGとかではシンプルに書くと。

>>602
>>599は烏合の衆にSQLのテクニックを教えるのが好きなんだよ

>>606
ﾉｼ 同意

>>602
> 烏合の衆が書いたSQLのtypeによる例外が減る
要するに、DBアクセスコードを書いておきながらテストせずに
納入しますよと言ってるのか。大笑い。
こんなこと言ってるようじゃ、
> ほとんどの問い合わせは、どんなSQLになるか興味ない。
興味がある場合をつきつめているとは思い難いね。

> なんにしろローカルなコーディングルールやフレームワークを作るだろうけど、
SQLは作るまでもなく誰でも知ってるんですが。

>>604
> 「本気で使うと複雑なSELECT」を書かなくて済むのはいいかも。
> JOINがからむ場合とか。

JOIN一つ程度じゃ別に複雑じゃないでしょ。
UNION(ALL), MINUS, JOIN(OUTER, LEFT, INNER, RIGHT),
副問い合わせ,...
等々が複雑に絡み合う可能性があるのがSELECT文。
こういうのを一々メソッドならべて書く気？

テキスト形式のSQLなら、sqlplus, osqlといったコンソールのSQLクライアント
で実行可能なSQL文をそのまま書きゃいいだけ。慣れてる奴なら見れば
やってることはすぐに分かる。

>>598
おつかれさまです。
GUIツールがついてるのが新鮮ですね。なんか、面白そうかも。

>>610
スキル依存ｲｸﾅｲ

ついでに言うと、「烏合の衆」に書かせたSQLをチェックする場合は、
まず一番気になるのはパフォーマンスが出るSQLになってるか
ということだろ。
型の例外なんぞUnit Testでチェックすりゃいい。
SQLがコードまたは設定ファイルにテキストで書かれているならば、
grepしてDBAがチェックするのは簡単なことだ。

君ら、本気で業務で使ってるとは思えない発言が多いね、ほんとに。

>>611
>SQLは作るまでもなく誰でも知ってるんですが。
誰でも知ってるってソースは？

>>613
暴走しすぎ。お前は何年前の業務開発を基準に話をしてるんだ？

>>614
アフォか。
CayenneだのHibernateだのの新参のクラスインタフェースを知ってる人間と
SQLという歴史のある問い合わせ言語を知ってる人間を比べる気か？

前者にくらべりゃ、後者はほぼ「誰でも」だね。
まともな会社なら新人教育で教育することだ。
ま、あんたの会社は違うかもしれないがね。

> 型の例外なんぞUnit Testでチェックすりゃいい。

http://d.hatena.ne.jp/higayasuo/20040708#1089245059

Typesafeでない代償は、細かいところで積み上げられ結局大きく
なってしまう。

>>615
今はSQLはパフォーマンスを気にする必要が無いといいたいの？
OracleでNOT EXISTをNOT INに書き換えたり、
WHERE句のカラムの順番を適切でないものに並び換えて実行して見ろっての。

どうせ、explain planやtraceなんてとったこともないんだろ？

個人的に SQL 直書きだと使う DBMS を変えようと思ったときにつらい。
Mapping-Framework だとだいぶそのへんを吸収してくれてうれしい。

>>616
なんか書き込みが一昔のCOBOL厨みたいだな。
あんたが言いたい事もわかるけど、ここはそういう要素も解消できるように
考えていこうって所じゃないの？

まっさらなSQLだけで攻めるのも未来が無いよ。

結局、ストアド使うに越したことはないよ。

>>618
普通にあるけど・・・
すべてのSQLでパフォーマンスを気にするかどうかとは別の問題では？
うちではクリティカルな所は熟練者に任せてるけど、流石にすべての
SQLを確認は厳しいよ。

>>621
SPまたは、Viewな。
それは基本だけど、DBMS依存にはなるよねどうしても。

トリガとかチェック制約ぐらいになると、入れたがらないDBAも多いね。
この辺は人によって見解や好みが違う。

>>620
＞ なんか書き込みが一昔のCOBOL厨みたいだな。
ﾜﾛﾀ。でも禿道。言い得てる。

熟練者が担当していない部分で、SQL記述の統一を図りたいからORマッピングツールを
考えてるんだけど駄目なのかなぁ。
ちょっと試した感じだと十分いけそうな気がするんだけど。

>>622
まあ、正直システムテストの一環でパフォーマンステストやって、
問題無さげなら通しちゃうこと、多いけどな。
ただ、生のSQLだと問題の抽出や修正は早いよ。grepでひっぱって
そのまま実行できる訳だからね。まあパラメタライズされてる
部分はいじる必要があるが。

PL/SQLでゴリゴリストアドパッケージ書く
Javaは表示に徹する

これ

というか、OracleでJavaを書く。

これ

>>627
OracleのSPは今どきJavaでもかけるけど、数年前に試したら
使い物にならなかったんで、避けてる。Oracleサーバプロセス内部で
実行されるAurora JVMのデキがウンコでね。
今でも避けたいDBAは多いだろう。

>>625
いいんじゃない？試してみる価値はありそう

>>628
誰が書くか

何故にDB依存の方に話が行く？
小規模でも構わないからどのDB依存にならない方法を見つけたいね。

今日もORツールの話はないの？

システム作る時はどのDBで動かすかを決めてから作るから、
別にDB依存でもいいや。むしろ関数使いまくり。

凄い汎用的に作ったつもりでいて、日付の取得に関数を使っていたのに気づいたとき…
それ以来、割り切ってDB依存するようになったね。

>>621
ま、SPやViewにできる部分はいいけど、複合的な検索条件を
動的に生成しなきゃいかん画面とかは、どうしてもある罠。

カーソルの受け渡しが出来るかどうかとか、SPの能力も
どうしてもDBMS依存になるしな。

>>635
WHERE句の条件に関数含めなきゃいけないケースとかは、わりと
どうしようも無いよね。
DECODEだのNVLだのの類だとか。
NULLの扱いなんて基本的なところからして、DBMSによって違うし
（というか、Oracleが標準に準拠してないだけなんだが）

>>618様はwhere句に関数を使うなとご立腹です

>>638
そうだよインデクスが効かなくなるからな、プンプン
つか、まあ俺は原理主義者じゃないから必要なときは使います
ごめん

>>639
関数インデックス・・・

Cayenne、キーの操作がめんどくさいのだが・・・

とりあえずO/Rマッピングに反対の人とか好きになれない人にとっては、
このスレは意味が無いと思われ。
他スレでやってくれないかな。

何も産まないフレーミング合戦やるより、このスレではO/Rマッピングという考え方が、
生産性向上とか効率につながるのかとか、意味のあるカキコしませんか。
その上で、

「O/Rマッピングに一瞬光を見たけど、やっぱSQL直書きのほうが効率的だわ」とか、
「やっぱしこれからはO/Rマッピングだよなー」とか、
いろいろな判断ができると思うんですよ。
ここんとこ、日本語で情報源を作ってくれる人とか増えてきたから、
どんどん有効な情報を共有して、使えるモノなら導入して、
定時で帰ろうぜ！(笑)

あぁ、でも、マンセー派ばっかりだとデメリットとかが見えなくなって、
盲目的にO/Rマッピングに隷属する信者ばかりになりそうですね。
客観的かつ論理的なO/Rマッピング否定論ってのも、オモシロそうですな。

>>642
ORマッピングは、いろいろな方針があるので単純にいい悪いを言うべきではないと思う。
つまり、ORマッピングという技術に対しての評価っていうのは、あまり意味がない。
なぜなら、SQLを意識せずSQLの場合より単純なコードでパフォーマンスも最適化されるような「理想的なORマッピングの実装」があれば、ORマッピングを使わない理由はないから。
実際には、トレードオフの部分があるから、それぞれの実装に対しての長所・短所をあぁだこぅだやるのがいいと思う。
HibernateだけをみてORマッピング使えねぇとか、CayenneだけをみてORマッピング使えねぇとかいうのは具の骨頂で。

Hibernateはマッピング先のオブジェクトがPOJOだから小回りがきくね。
HQLで、ほぼSQLでの操作ができるし。
パフォーマンスもチューニングしやすそう。

Cayenneはラップが厚いので、SQLを意識しないコードが書きやすい。
テーブルの関連をたどる処理が非常に書きやすい。
逆にSQLを意識したときは書きにくい
とくにキーの操作がやりにくい。
キーはすべて自動採番で、マッピングオブジェクトをそのプロセスだけで使う、というように条件をうまく選べばかなり楽ができる。

ちょっと、いろいろ試した結果を追加しておきました。
あまりチュートリアルに書いてないことを書いてます。
結局主キーでの並べ替えがわかりませんでした。
チュートリアルには主キーを使う操作があまり書いてないので、主キーの値を使うな、という方針なのだと思う。

どんな場合でも使いやすい、というわけではないツールです。集計はできない気配。
だけど、はまったときは楽々。

>>642
> 定時で帰ろうぜ！(笑)

つまり、電車があるうちに帰ろう、と。

>>646
おまいさんの勤務先では、就業規則に
「定時とは終電に乗れるまでの時間とする」
なんて定義されてるのかい？（ｗ

ってﾏｼﾞﾚｽはおいといて、
早めにあがりたいよな（ｗ

こんなところに書き込んでるから
どんどん帰りが遅くなるんだよ

ΣΣ(ﾟдﾟｌｌｌ)

うーん。。。
Cayenneで主キーでの検索やら並べ替えってどうするんだろう・・・
単純な検索だけはできるんだけど。

limitはわかったけど、offsetはどうやるんだろう・・・

>>645
モデラーで DB からリバース生成した ObjEntity には DbEntity の
主キー項目がついてませんが、モデラー上で自分で追加してやれば
主キー項目も ObjEntity 上に持たせられます。
1.1 のモデラーなら、ObjEntity を選んだ状態で、アイコンの右から３番目の
"Create Attribute" を実行すると新しく空のアトリビュートが追加されるんで、
DbAttribute に DbEntity の PK 列、JavaType に対応する型を選んで、
ObjAttribute に適当な名前をつければ OK です。

で、マッピングされたクラスに PK 列が入ってればあとは単純で、
並べ替えは

SelectQuery query = new SelectQuery(Foo.class);
query.addOrdering("primaryKeyColumn", true);
List foo = ctxt.performQuery(query);

とか。

モデラーが自動で生成してくんないってことは、Cayenne の流儀に
反してるのかも知れませんが、自分はこーやってていままで特に
問題は出てないです、とりあえず。
いちいちモデラで作業しなきゃいけないからちとめんどいんですけどね。
(リバース生成じゃなくて、最初からスキーマもモデラで作ればいいのか..)

>>645
あと、集計というのが AVG とか COUNT とか MIN とかそういう集約関数
のことを指してるんでしたら、めんどくさいながらも一応使えるようです。

http://objectstyle.org/cayenne/examples/index.html

の SQL Aggregate Functions にやり方載ってました。
サンプルソース落としてこないと見れないんですが、コード上で
Expression 作ってという方法じゃなく、モデラー上で DerivedDbEntiry と
いうのを作って (赤、白、赤の三段重ねのアイコン)、そいつの spec に
max(%@) だのと書くようです。(そしてその ObjEntity を使う)

モデラーのドキュメントがまだあまり整備されていないので、spec を
どう書けばいいのか、詳しい使いかたは分からないんですが...orz

>>652
自分もそう思って、追加してみると、ObjectIdを設定して新規データを作成するときに「主キーがnull」というエラーが出るようになりました。
主キーが自動採番型になってるなら問題ないのだとは思いますが。
1.0です。
1.1ではなおってるのかな。

うひゃー、雷がすごいよ。

ObjectIdを設定せずに、プロパティのセッターで主キーを設定したらうまくいきました。
けど、気持ち悪い・・・
現実的には主キーはすべて自動採番にするだろうからいいとは思うけど。

1.1試してみたら、TempObjectIdを使って登録するやり方ではうまくいかなかった。
commitChangesで例外が出る。
データベースにcommitしたあとで、オブジェクト取得しなおすみたいなんだけど、そこで失敗するみたい。
ということで、必ず主キーのマッピングを追加したほうがいいみたいだ。でsetHogeId(...)で設定する。

実際のデータが登録されたあとで例外がでるので、タチが悪い。
こんな挙動されたんじゃ、怖くて使えないねぇ。
まだマイルストーンだから、リリースされたときには修正されるだろうけど、開発中でもこんな挙動するのは、そもそもの設計方針が悪そう。

Cayenne情報が増えてきたね。(･∀･)ｲｲ！
Hibernateと双璧を成していく予感もあるから、
オレも勉強してみよう。

経験でいうと、やはりコード自動生成で済みそうなシーンは大抵Mapを使っても間に合う。
コードの自動生成するとプロジェクトのリポジトリが膨らんで嫌だし、
必要なものだけクラスを定義してやるのが結局一番シンプルだと思うよ。
そうやって定義されたクラスは重要なものって認識するし、自動生成されたコードだと
何が重要なクラスか分からなくなる。

>>658
必要なものだけ自動生成すればいいんじゃないの？

１からスクラッチでゴリゴリ書いて間に合うスケジュールになってる
プロジェクトだったら、自動生成など無くてもいいよな。

>>658
つたない経験だな。

Cayenneのリレーション処理なんか見てると、全然Mapと比較にならんわけだが。
主キーの処理をどうにかして欲しいとは思うが。

Mapを推してる奴はJava初心者

Java初心者ではなくて、効率の良い開発についてわかってない人だと思われ。

商業でもオプソでもこの手の（OR Mappingは型安全がウリとのことで）
プログラマを信用しない、プログラマを束縛することを基本姿勢にしているツールって
よくみかけるんだけど、

これって結局プログラマ（そのマネージャ）のコミュニケーション力を信用しない、
いいコードを保つための工夫、アイデアを考えることをやらせないということにも
なってるんじゃないのか。

それをやる能力を出させないで、こうしたツールで縛るっていうのはリスクがあると思うよ。
ツール自体のメンテナンスされなくなったときはどうする？　ツールの使用が変わって
今まで作ったアプリが動かないときは？

ツール作者が想定している以上のことが起こるのが、大抵のソフトウェア開発の現場。
柔軟性が無いツールなら、逆にコスト高になる。

大体、こういうツール好きな香具師はツール学ぶコストを無視しすぎ。

あきらめたらそこで試合終了だよ

つまり、俺様の知らないツールを使うな、と。

根本的な考えが間違ってるから、いちいち突っ込むのも面倒。
各論は反論する余地があるだろうが。

>>665
> これって結局プログラマ（そのマネージャ）のコミュニケーション力を信用しない、
> いいコードを保つための工夫、アイデアを考えることをやらせないということにも
> なってるんじゃないのか。

自動化できる、本質的でない部分で、アイデアを考えるひまがあれば、本質的な部分で頭使った方がいい。

> それをやる能力を出させないで、こうしたツールで縛るっていうのはリスクがあると思うよ。

あたらしい、使えそうなツールを試さないリスクの方がでかい。

> ツール自体のメンテナンスされなくなったときはどうする？　ツールの使用が変わって

メジャーなツールなら、致命的なバグを残したままメンテナンスされる可能性は少ない。
自分らで作ったフレームワーク・ツールの方がメンテナンスされなくなる可能性が高い。
もし致命的なバグが残ったままメンテナンスされなくなったら、自分でソースみてがんばる。
そういう致命的なバグは、自分が作ったソースで発生する場合の方がタチが悪い。

> 今まで作ったアプリが動かないときは？

アプリの寿命が短いから大丈夫。

> 大体、こういうツール好きな香具師はツール学ぶコストを無視しすぎ。

中心となる人物が学習すれば、あとの烏合の衆は通常のコーディングルール程度として使い方をとらえればいい。

>>669

>自動化できる、本質的でない部分

適材適所ではありますが
このOR/Mappingは自動化するまでもないことで自動化ようとしている場合が多いと思う。
だって、アクセサしかないクラスを自動的に作るんでしょ？
何の意味があるんだ。

> 自分らで作ったフレームワーク・ツールの方がメンテナンスされなくなる可能性が高い

そこは、リファクタリングでカバーするのが正しいと思うよ。
シンプルに作ればメンテナンスは簡単。

>> 今まで作ったアプリが動かないときは？
> アプリの寿命が短いから大丈夫。

いい状態のソフトなら、新しく作り直す意味はないはず。

>> 大体、こういうツール好きな香具師はツール学ぶコストを無視しすぎ。
>中心となる人物が学習すれば、あとの烏合の衆は通常のコーディングルール程度として使い方をとらえればいい。

それはそうだが、しかし、このOR/Mappingに関しては、
その労力を正しい設計、コーディングのためのコミュニケーションに費やすほうがいいと思う。
ツールっていうのはしばしば自由度が低くて、
ある要求がきた時点で、行き止まりになるか、突然険しい道になる。

>>671
> いい状態のソフトなら、新しく作り直す意味はないはず。

業務モデル自体が変わる。
上記の質問が出る時点で、業務アプリの経験がないことがわかったので、口出しは控えたほうがよいと思われる。

> だって、アクセサしかないクラスを自動的に作るんでしょ？
> 何の意味があるんだ。

手で作るより楽。確実。
Cayenneの場合、DataObject継承してるから、アクセサしかないクラスではないし。

>>672
>> いい状態のソフトなら、新しく作り直す意味はないはず。
>業務モデル自体が変わる。

それにしたって、最初からフレームワークの選択まで含めた作り直しはありえない

>> だって、アクセサしかないクラスを自動的に作るんでしょ？
>> 何の意味があるんだ。
>手で作るより楽。確実。

それはもう主観でしかないのだが、

漏れが思うにこれは型安全で解決する問題じゃない。
カラムに確実に正しい値が入る保証は常にあるシーンがあるとは思えない。
自動化されたテストで保証すべき。

>>673
>>> だって、アクセサしかないクラスを自動的に作るんでしょ？
>>> 何の意味があるんだ。
>>手で作るより楽。確実。
>それはもう主観でしかないのだが

いやぁ、実測しても手書きで作るよりは自動生成の時間も短いだろうし、間違いも少ないとおもうぞ。

>>673
> カラムに確実に正しい値が入る保証は常にあるシーンがあるとは思えない。

おまえはまず、考えを日本語にマッピングするフレームワークを使った方がいい。

>実測しても手書きで作るよりは自動生成の時間も短いだろう

なので、もう最初から単純なデータのやりとりのためにクラスを定義するのは止しましょう。
クラスを定義するのは（型安全にする以上に、たとえばそれがアプリケーションにおいてよく使いまわされる
核となるオブジェクトを定義するときのために）意味があるときだけにしましょう。

>>676
他に良い手段があるならね。

> それにしたって、最初からフレームワークの選択まで含めた作り直しはありえない

ありえるし。
むしろ、こんな局所的なフレームワーク、臨機応変だし。

>>677
>ありえるし。
>むしろ、こんな局所的なフレームワーク、臨機応変

マジですか。
確かにデータやり取りする部分が局所化できていれば、書き直しにはそんなに苦労しないしが。

だからこそ、クラス生成する技巧やるほどのことかどうかは謎になってくる。

＞ これって結局プログラマ（そのマネージャ）のコミュニケーション力を信用しない、
＞ いいコードを保つための工夫、アイデアを考えることをやらせないということにも
＞ なってるんじゃないのか。
それを言ったらインタフェースや抽象クラスのabstractメソッドもいらない、
カプセル化もいらないってことにならないか？全部publicで作ればOK、みたいな。

ルール決めやその徹底、チェック等の工数も削減できるんだよ。
大規模開発経験無いな？

>>678
.NETからJ2EEとかJ2EEから.NETとか、VB6からVB.NETに比べれば、ぜんぜん楽。
新しく作るサブシステムから徐々に移行することもできるわけだし。

>>678
> クラス生成する技巧

これを技巧っていうくらいだから、そうとうレベルが低いんだろ。

>>678
> マジですか。

ねんのため、いうておくが、ビジネスモデルの変更にともなうシステム更新での話だぞ。

>それを言ったらインタフェースや抽象クラスのabstractメソッドもいらない、
>カプセル化もいらないってことにならないか？

プログラマに単に自由を与えるのではなくて、
コードに表現力を持たせることが重要だと思うのだけど、
表現する自由が無くすのはよくないなと。

いいフレームワークなら表現力は上がると思うんだけど、
単にオブジェクトとデータベースのデータをマッピングするためのクラスを生成って、
これは表現力を薄くすると思う。

>>683
> 表現する自由が無くすのはよくないなと。

いらん。確実に動く方が大切。

>いらん。確実に動く方が大切。

いや、確実に動かすために表現力が要るといいたいのですが

>>685
Perlでも使ってろ。

同じコードを書くのに複数の書き方があるよりは、ひとつの書き方しかない方が、表現力は下がるが確実に動く。

ここでいう表現力っていうのは、「これしかない、この方法を使え」　と明確に
プログラマに伝えることだから、フレームワークは表現といえる。

（とはいうものの、ORマッピングは何も表現しない、それどころか余計なクラスが
大量に作られるため、薄くしている。）

>>687
えっと、自覚のないアホは逝ってください。

>>687
> ORマッピングは何も表現しない

意味がわからんが。
接続のタイミングやトランザクションの使い方、JOINのやりかただとか、データの取得・更新の記述を限定させる役割はある。

けんかを〜やめ〜て

>>690
片方があまりにもわけわかってないから、けんかになってない。

「労力」を強調する所を見ると、「ORマッピングを覚えるのがﾏﾝﾄﾞｸｾ」と言いたいだけか

つまり、新しいツールが覚えられなくなった、頭の固い高齢者。

やあ、Map厨ですよ。

>>686
> 同じコードを書くのに複数の書き方があるよりは、ひとつの書き方しかない方が、
> 表現力は下がるが確実に動く。

コボラーの方ですか？
コーディング規約とか、好きでしょ。
C++とアセンブラについては、どう思いますか？

>>692
アフォですね。ていうか、プロジェクト切り回したこと、ないでしょ。
全部が自分で完結してる世界なら、これ以上楽な物はないわけですが。

>>694
コードをいかようにも書ける場合こそがコーディング規約の出番なわけだが。
コードの書き方が限定されていたら規約類もガチガチにしなくて済むんだよ。

>>693
新しいツールは自分が学習すればよろしい。
ですが、プロジェクトに導入するかどうかは別の次元の話ですね。
学習（させる）コストと対価を考慮に入れないとね。

RO-Mapping信者の主張するところの、フレームワークのメリットは
Fool Proofであること、バカにバカなSQLを書かせることを防げること、
といった、大規模三流業務開発向けのメリットな訳ですが、
実はそれは新し物好きの脳内理想論に過ぎなくて、現実を無視している
ようにしか見えないというのはそこのところです。

現実のRDBシステムには差異があり、システムには要求性能があり、
開発者の一人一人（特にバカ）にいちいち新しいフレームワークを
学習させる時間はないというのは現実なんですがね。

>>696
で、C++はどうですか？
・テンプレートは使わない（移植性がないから。つかメタプログラミングヲタの
コードはバカに読ませられないから）
・例外は使わない（移植性がないから）
・RTTIは使わない（移植性がないから）
・staticコンストラクタは使わない
　　　:
　　　:
とかやってる訳ですか。
C++のソースは移植するのが大変なことで有名ですが、それ以上に
プログラマ間の移植性が無いとも言われますね。
だいたい、自分の好きな周辺のみをいじくっているという。

>>697
グダグダなメンテ不能なコードが大量生産される理由はここにあり！
って感じでつね

>>699
いや、だからそれが現実なんですよ。
で、フレームワークを導入すれば未来がバラ色になると考えている
あなたこそ、脳味噌が腐っているとしか思えませんね。
所詮、使役される側の発想でしかない訳です。

＞フレームワークを導入すれば未来がバラ色になると考えている
はぁ？脳みそ腐ってませんか？
どこを縦に読むとそうなるんでつか？

明らかに経験少なそうなのに、ここまで強気だとたくさん釣れるんだな。

どうせ*00マン程度のシステムしか作ったことないんだろ。
あまりにもプロジェクト運用の進め方がわかってないよ、この人。

SQLを直書きすることに対しては
> スキル依存ｲｸﾅｲ
> 烏合の衆に
うんぬんとのたまう方々が、一方ではフレームワークぐらい
学習しろよと平気でのたまう訳です。

俺なら、SQLを覚えさせますね。そっちのが確実に役に立つから。

フレームワーク導入したところで意味は無いってのはその通りだと思う

メリットはクラス自動生成されることによる型安全、コンパイルエラーが出るだけ。
そんなの何の意味も無い。

>>702
で、何が分かってないのか、説明してごらん？
あんたはこのRO-Mappingとやらで一体どれぐらいの規模のやつを
作ったってのよ。

そもそもXDocletやVelocityを考えたのは、XPを発明した欧米の方達ですよ。
MDAの考え方とかご存知ですか？

>>705
俺は自動生成の話をしただけ、strutsのvalidation.xmlとか1000万超える
レベルになると自動生成使わないと信じられないことにならない？

>>698
自分の世界に入ってしまう人だねぇ。
関係ない話題持ち出してきて、それに固執する。
そりゃ、みんなでコーディングは向いてないよ。

>>706
あ、ようするに海外のえらい人が言ってることは鵜呑みにしちゃうひと
なわけね……

というのはさておいて、
XDocletやVelocityは、別にRO-Mappingとは直接関連がないでしょ。
有効と認めたら使う、認めなかったら使わない。
私は自分で判断しますね。そんだけです。
XPでさえ、プロジェクトによって有効かどうかは差異がある。
「銀の弾はない」ととっくの昔にバレてるのがソフトウェア・システム
開発の現状なんですから。

>>703
SQLよりはよっぽど個人差がつかない。
ちなみに、フレームワークといっても開発者に使わせるのは、その一部分だけ。
メインのアーキテクトが局所化して振るから、それほど学習コストはかからない。

>>709
OR-Mappingの自動生成で主に利用されてます。

別にXPが銀の弾丸とも言っていない。
ただ、縛りつけが嫌いなはずの欧米人が開発してるって事。
みんな、面倒くさいルーチンは嫌いなんだよ。

>>710
実際には、アーキテクトがいて三流開発者に振るようなケースでは、
そもそもSQLにタッチする部分は、書かせない、でしょ。
だから、差異はないとも言えるわけです。
あなたは「それほど学習コストはかからない」と言うが、
POJOを使うだけならゼロですね。ですがこれはMapも同じだ。

>>709
お前はえらい人関係なく、自分の意見しか信じないタイプだろ。

>>713
いや、そんなことはないですよ。
BillJoyタン、ハァハァとか
RichardStevensタン、ハァハァ、なんで死んじゃったのよとか

まあどうでもいい話ですな

>>703
> うんぬんとのたまう方々が、一方ではフレームワークぐらい
> 学習しろよと平気でのたまう訳です。

フレームワーク使って、中心人物が学習すれば、烏合の衆にはコーディング規約の一環としてフレームワークの使い方教えれば済む、というわけなのだが。

> 俺なら、SQLを覚えさせますね。そっちのが確実に役に立つから。

いいねぇ、時間があって。
そこからさらにコーディング規約とか、データベーススキーマの説明するわけだね。
もちろん、細かい使いわけまで教えるんだよね。

>>712
いくら3流開発者でも、流石にORM無しだとSQLを書かせざるえないだろ。

Map厨はDAOを使っていまつか？

>>715
DBスキーマを理解してないやつにDBアクセスコードを書かせるなんて
そんな空恐ろしいこと、俺にはできませんが。

フレームワークを使えばそれが可能だとでも思ってるの？本気で。

のらりくらりと明言を避けるあたり、ある意味面倒なプロジェクトの経験豊富なのは認めてやろうｗ

>>717
さすがにDAOは、Access MDBのテーブルとかをマニアックにいじりたい
時ぐらいしか使う用途がないんじゃないでしょうか
プライマリスレッドからしかいじくれないというのは、今どき
かなり致命的でしょう。

>>718
ORM使えば問題ないだろ？3流開発者へ割り振る仕事なんだし。

>>718
SQL使ったJDBCのコード書かせるほうが、もっとこわい。

>>720
このレベルかよ・・・もう寝よ。

数百万レベルでも、数人で組むなら有効だとおもうぞ。
ひとりで組むんでも、有効だとおもうぞ。

>>723
どうせなら、バカにする理由ぐらいは教えて欲しいものですな
後学のためにも。

>>712
> あなたは「それほど学習コストはかからない」と言うが、
> POJOを使うだけならゼロですね。ですがこれはMapも同じだ。

Mapの場合、プロジェクト独自のルールで使うわけだから、ORマッピングと同等に使うなら、それなりに学習コストがあるとおもうぞ。

>>723
くまー

あれ、もしかして>>720はマジレスだったのか？

>>722
そうですか？
だいたい、「怖い」って、あなたテストもせずに納品するんですか？

生のSQLだと、実はコードや設定ファイルからSQLを抽出することは
簡単にできるので、問題を防げることが多いですよ。
という話は前にも書きましたがね。

>>725
ここ来るならDAOパターンくらい頭に入れた上で議論しろよ。

あ、DAOって聞いたときに、MSのDAOライブラリだとおもったのよ。
ごめんね。

って、もしかして今や誰もそんなの、知らない？

>>731
ﾌﾟ、必死ですね。

ORMの話の流れでDAOって出てきて、何故にMSが絡むんだよｗ

今必死にgoogleで調査中です。

>>735
マジっぽいな。反論がぴたりと止んだ。

えーと、私の過去の発言をさかのぼっていただければ、
ORMの文脈でのDAOについて私が発言していることは分かるでしょう。
たとえば>>121とか>>131とかですな。

今ちょっとDAOでMSライブラリの話が思い浮かんだのは
極めて個人的な理由なので、あまり触れたくありませんな。

>>729
> だいたい、「怖い」って、あなたテストもせずに納品するんですか？

あのぉー、問題のレベルが違うんですが。
テストしたところで、確実なテストはできないし、そもそもの品質が低ければ、修正コストもばかにならんし。
結果さえ表向きよければ、途中は何が起ころうと、時間がかかろうと、問題ないわけ？

えー、、DaoからMicrosoft Accessを連想するってありえな〜い。
高度に練りこんだネタだよな？ｗ

VB厨が一匹紛れ込んでる模様

>>737
同一人物なんて分からんよ。認識して欲しかったらキャップ付けろ。

>>738
> テストしたところで、確実なテストはできないし

ﾌﾟｹﾞﾗ
あのーお客さんのDBいじるのに、確実に動くかどうか分からない
その程度のやつを納品するのね、あなたは。
SQL直書きで、ちゃんとSQLが意図通りに動いてるかどうかの確認なんて、
簡単でしょ。
極めて繊細なレースコンディションのテストしてる訳じゃないんだからさ。

>>740
VBにはOR-Mapperが無いからな。

>>741
あ、俺は>>100ですよ。まあキャップつけてもいいんだけどさ、
別に認識してほしいってほどじゃない。

>>742
ﾌﾟｹﾞﾗ

発想が極端過ぎ。

>>742
OR/Mappingと比べて、SQL直書きの方が検証が大変だと思われるんですが
すべてのSQLに目を通してテストされてるんですか？

>>739
そうかな。
MSのDAOライブラリを使って便利なのって、今どきはAccessのMDB
いじるときぐらいだと思うけど。
普通はVB厨御用達なのは、今どきADOでしょ。ただしそれも6.0以前限定で、
.NETだとADO.NETね。

>>747
言いたい事はわかるが、ここでそんな話になる事自体おかしい。

> だいたい、「怖い」って、あなたテストもせずに納品するんですか？
どんな低スキルなプログラマに何を担当させてもテストするのなら怖くないの？

>>100はMS Access→Javaへのスキル転換中エンジニア・・・

>>746
検証って、何のことを言ってるのかな。
「何がどう大変」になるのか、説明してくれる？

「入力に対して想定した結果がDBに格納されていること」を
テストするなら、実装によって差異は生じませんね。
性能のチェックをするならば、同じくどちらも同じですが、
机上でSQLのチェックをするのであれば、直書きの方が圧倒的に
すぐれていますね。見りゃ、どういうSQLが送られるかすぐ分かるから。

ぼくー、Accessベースのシステムと一緒にしないでね？？

MapをDAO層に渡すのはきっついなぁ

>>751
良く分からんが、そもそもSQLのチェックなんて必要ないだろ。
あんたの言う、型チェックまで入った自動テストが通っているのであれば。

>>750, >>752
なんだ、君らその程度の煽りでプライドを保つぐらいしか
脳がないのね。
DAO層の概念ぐらい知ってるっつーの。って、>>737で説明したでしょ。

>>755
そこで煽るお前の方が脳が無い事に気づけ。

こういう中途半端なコボラーに粘られるとマジでまいるな。

>>754
信じ難い書き込みを見た。
あのさ、型チェックが通ればいいとでも思ってるの？
「コンパイルが通れば、いい」と同じレヴェルの発想だぜ、それって。

あなたの脳内にはシステムテストも運用テストも性能テストも
無いんでしょうな。

「どういうSQLか」は、ツールにやらせた方が品質が一定しない？
プログラマにやらせると人によって微妙に違ってくるからやっかい。

>>757
ごめん俺コボルは知らないんだ、新参だから。
CとかC++とかなら、わかるよ。

>>758
お前は馬鹿か？

自動テスト内で、参照や更新ロジックの整合性が証明されてるのは当然だろ？
なんで、さらにSQLを洗い出してテストする必要があるんだよ。

型チェックが入ってるって書いたのは「皮肉」だ。

>>759
それを分からず、全員にSQLを書かせようと意気込んでるようです。

>>759
えーと、OracleのSQLのオプティマイザの能力がどの程度か知ってる？
いや勿論素晴らしいんですが、オプティマイザだけじゃ限界があるから、
プランをコストベースにするかどうかとかを、ユーザサイドが設定するし、
SQL自体のチューニングもやっぱり必要という世界な訳です。

「品質が一定」って、何なの？要するに、コーダーに好き勝手に書かせて
放置してる訳じゃないんでしょ？
しいて言えば、ただのSQLの場合、Javaのコード程は品質に差が生じない
でしょう。「やれることが限られてる」から。

>>758
純粋に興味があるんだが、お前の単体テストってどうやってるの？
ツールは何使ってる？

>>761
いやだから、整合性テストだけじゃ性能や、トランザクションのインプリが
正しく行われてるかは、確認できないでしょ？

DBのトランザクション絡みは、突き詰めればレースコンディションの
話になるから、単体自動テストでどうにかするのは、限界あるよ。

>>763
ORMよりSQLの方が品質に差が出るに決まってるだろ？
そもそもDBはすべてOracleを使うのが前提なのか。

ヤバイ所はViewにして、後でオプティマイズ書ければいいだけの事。

というか、誤りを作りこまないことと、テストすることは関係ない。

>>766
違う。Oracleはもっとも有名でメジャーなRDBMSだから例に出してるだけ。
他も似たりよったりかよりひどいだけだよ。

> ヤバイ所はViewにして、
ようするに、Viewという形のstaticなSQLで済む場合しかあなたは頭に
ないわけね。
そんなの出来るところはそうするのは、常識以前の問題。

>>765
トランザクションの制御は宣言的にやるから、XMLチェックだけで良い。
性能テストはボトルネックになる箇所だけチェックすれば良い。

>>769
で、ボトルネックをテストする前から特定できるの？あなたは。
まあ、想定は出来る場合はあるだろうけど、やってみなきゃ確証は
とれないよそんなの。

ハァ、、頭がガチガチに固い、４０代の先輩と話してるみたいだ。。
物知らないのに、議論に加わりたがるんだよね。。

>>763
つまり、プログラマ依存またはDBMS依存なわけね。
使うDBMSによって貴方のシステムは品質が大きく左右されるわけだ。

>>768
お前煽りすぎ。そもそもお前が危惧してるようなSQL書いてみてよ。
実際はViewレベルで解決できるケースがほとんどだよ。

>>772
は？何当たり前のこと言ってんの。
ユーザがバカ高い金だしてOracle使うのは何のためだと思ってるんだか。

Oracle要らないんなら、Berkeley DBでも使って自分でDBMS実装すれば？

>>770
ボトルネックが性能テストで分かったところで、解決するってだけの話。
それでHQLで厳しいようならネイティブのSQLを書く。

>>773
うんまあちょっと煽りすぎだけど
そのほうが盛り上がるからね(w

>>774
どうやってユーザーにOracleを勧めているのかが目に浮かぶよ。

>>776
自分のバカをさらして盛り上げるとは、いい奴だ。

>>777
決まってるじゃないか。俺らは余分なサポートはしたくない。労力は
払いたくない。Oracleならゴールドやプラチナ保持者程度は
ゴロゴロしてる。
だから、金払えオラ。

頭の固いオヤジ確定だね！

>>778
うん感謝してよ。
バカをよってたかって叩きたがるバカが多いからね、このスレは。

DAO　
読み方 ： ディーエーオー
フルスペル ： Data Access Object
00.2.11更新

Microsoft Accessによって作成されたデータベースを操作するための
プログラミングインターフェース。
データベースの作成を含め、あらゆる操作をプログラムから利用することが可能。
同社のプログラミングツール「Visual Studio」シリーズに標準で添付されており、
Visual BasicやVisual C++などで利用することができる。

>>781
ただねぇ、あまりにもバカだから面白くないんだよねぇ。

こいつが話しているDBの話って、3,4年くらい前に必死に俺も訴えてた気がする。
今は自動に任せられる部分が増えて楽になったよな。

うちはPostgreSQLの案件もDB2の案件もあるからなー
Oracleでゴリ押しできるならいいんじゃない？

>>782
古いよねえ2000以降更新が止まってるんだもの。
でも、MDB使う分には今でも便利なときはありますよ。

今はSybaseですよ！

>>785
mysqlとかsybaseとかMSSQLとかはないんですか？

>>783
いやそのツマランはなしに必死になって食らいついてくるアフォが
多いからこんだけ伸びるのよスレが。

>>786
ADOで。
そしてスレ違い。

>>789
はやくお引取り願いたい。

>>788
俺今挙がってるすべてのDBで仕事した事ある。
一番好きなのはPostgreSQLかな。

Oracleは遅いし、メンテナンス費かかるから嫌い。

>>792
Oracleはチューニングしないと遅い。ちゃんとチューニングしなさい。

>>790
んなことは分かりきってるので>>747で既出ですがね。

>>789
>>764

答えてよ。

>>792
要するに、あなたにはOracleのありがたみが分からない
それだけのことです
まあ、Oracleの全てをマンセーする訳じゃありませんがね

そろそろ燃料投下をやめてくださ〜〜い！

Oracleに慣れると、客に優しいシステムは作りづらくなる。

知識のベクトルが異なっていて、会話が成立たない例だな。
大人しくDB板へいってくれ。頼むから。

>>800
中途半端にDBに対する自信があるから、Javaの知識が浅くても
意見を強引に押し付ける。

まあ、良く見られる光景です。

そういやうちのDBエンジニアでこんな香具師がいたな。

「DBに関してJavaエンジニアの意見を全く聞かない」

ちょっと気になるとこを指摘されると、顔真っ赤にして反論してたな〜

みんな食うために必死なんですよ

だからといって、ここでウサ原さんでくれ。

なんか知らんが、Map厨はまだ理解できてないのか。
J2EE設計を行う上でエンティティのMap実装なんか、ありえない。
そんなこと、ある程度の経験積んでる開発者なら常識とも言えないほど当たり前のことだろうが。
そもそもエンティティをMapで表現することに一体何の利点がある？
柔軟性？そんな見せ掛けだけの薄っぺらな柔軟性で一体どんなシステム作ってんだよ。
型安全も拡張性も多態性も、Javaの利点をことごとく捨て去ってまで目先のお手軽さを
優先するような奴が、システム設計なんかすんな。周りが迷惑するだけだ。
OO自体理解してないみたいだから、それこそ時間の無駄かもしれんが、
うちの新人がここ読んで変な気起こされても困るんで、一応言っとく。

ObjectモデルとRelationモデルのギャップを埋めることの意義をわかってないんだよね。
だから、POJOだの、Mapだの、そのレベルのどうしようもない話しかでてこない。

>>805
それでも納得していただけないのでMap厨なのです。

まあ、こうやって顔真っ赤にして反論してくれる人たちがいるから
飽きないんですけどね。

> J2EE設計を行う上でエンティティのMap実装なんか、ありえない
こういうのをstubbornという訳です。いやどうぞあなたの会社の
新人を教育する気は私にはありませんし、勝手になさってください。

コードの再利用性や疎結合を高めるために、OOというよりは
デザパタを駆使して作り上げた典型的なモンスターがJ2EEですが
EJBを選択せずにこっちを選ぶ人というのは、J2EEが場合によっては
無駄にデカ過ぎることには気づいている訳です。
なんであのJ2EEのPetShopデモはあんな下らないアプリなのに
あんなにデカいのか、と。

あのbjarne stroustrupのネタインタビューを思い出すところですね。
コボラの給料がアフォみたいに安くなったから、無駄に複雑な
言語C++を俺は作ったと。

J2EEにはサーブレット/JSPやJavaMailも含まれてますよ、と。

駄目だ。ほんと救いようがねー。
必要なはずの複雑さすら取っ払っちゃ元も子もないだろうが。
だいたいな、Mapでやるにしたって型安全ぐらい簡単に実装できるだろうに、
なんでそれすらやってない？
その程度の知識で、どっからその自信が沸いてくんだよ。

EJBに関してはこういう状況なわけだが。
ttp://itpro.nikkeibp.co.jp/free/JAV/NEWS/20040510/1/

あいかわらず話題それて自分の世界に入っていくし。

>>810
自信は自分の内側から沸いてくるものです。
ボウフラのように。

＞その程度の知識で、どっからその自信が沸いてくんだよ。

＞あのJ2EEのPetShopデモ
＞あのbjarne stroustrupのネタインタビュー
たった２回の「あの」ではあるが
たぶん知識量そのものに絶対の自信を持っているのだろうと推察される

いまさらストラウスとラップのニセインタビューが出てくるところなんかが、その知識のフルさを

>>814
ははは、あなたはコンテンポラリという表層を漂ってるだけの
ボウフラとして一生生きてください。
古きを温めることを知らない能無しの技術者はね。

まあ、DB屋はこんな感じでも食っていけると思うよ。ウザイけど。
こぼらーよりは全然寿命長いだろうね。

っていうか、あのインタビューは、C++を複雑なだけで使えないというコボラーを皮肉ったものだ。
ORマッピングが複雑なだけで使えないというアホへの例え話としては、最適かもしれない。

>>815
お前の主張している古きは別に温めるレベルのものではないよ。

>>816
いやまさか、リアルでこんな奴なら俺でも敬遠しますよ(w

ただ、実際のビジネスの現場では、なんだかよく分からないが
自信満々の奴が勝つ、というケースは意外と多いですね。
日本人は「断言してくれる人」を必要としてるのかも知れません。
まあ、そいつがちゃんとケツを持てるかどうかは
別問題だったりしますが。

みんなそろそろ気付き始めてる？

コボラーよりウザイ事に。

>>815
温めなくていい古きを温めて、新しきを知らないのは、害だけど。

>>817
なるほど、その程度に読んだのですね。
あれはC++へのエレガントな皮肉にもなってますよ。

いまどきわざわざEJB選択するなんてアフォがどこにいるんだ。
だからここで議論されてるようなORMapperやらDIコンテナが注目されてるんだろうが。
で、必要最低限の複雑さでどうにか切り盛りできないかって、
その辺を模索していく中で、EJB3.0ってのが見えてきたわけだろ。
お前の場合は何なんだよ。アクセサすらないMapで一体何をどうしたいんだ？
たとえリードオンリーのデータだろうが、それをMapで表現するってことに
どんな問題があるのか分からないようなら、もう一度入門書からやり直して来い。

というか、ここ最近のハードウェアスペックだとアホみたいなSQL
書かない限りは問題なく本番でもいける。
まあ、経験的に社内の基幹システムがほとんどだけどね。

>>822
C++は突貫で作った感が否めないし、EJB2.0は確かに重すぎるが。

>>823
> いまどきわざわざEJB選択するなんてアフォがどこにいるんだ。
そういう面白いことは、別の場所でケンカ売ってくるといいと
思いますが(w
私のようにたくさんのレスをもらえるかもしれませんよ。

>>823
ローン抱えちゃってるから、そんな余裕ないんだってば。

>>825
突貫でというか、Cとの互換性を維持しつつ仕様を追加していった
結果があのKichen sinkだと思いますね。

個別的な仕様には文句のつけようのない、筋の通った理由がある。
でも、総論的には……

>>805
言いたい事は非常にわかるし、その通りなんだが。

Map厨の頭には届かないと思うよ。とにかく自分ワールド炸裂だから。

>>826
間違ってない意見なので、「そうだよねぇ」となるだけ。

>>826
DIConのおかげで必要ないよ。
J2EE Development without EJB 読んだ？

自分の知識をひけらかそうと、小ざかしい英語使う奴は嫌いだ。

>>832
ちょっとﾜﾗﾀｗ

>>831
> J2EE Development without EJB 読んだ？
いいえ。
DIConって、例えばSeasarとかで提供されてる奴ですか。
ライトウェイトなコンテナということで、結構興味は持っていたのですが、
今どきどれぐらい使われてるんでしょう。

>>834
その程度の知識で>>826を言い切る所にお前の問題がある事に気付け。

とりあえず、Springを使ってるプロジェクトはいくつか知ってる。

>>835
ああ、SpringもDIConなのですね。なるほど。

でも、>>826って何か問題のあること、言ってるのかな？

そうだよね。
別のところでは言ってるけど。

>>837
EJBを利用する機会は昨今非常に減ってるよ。たまに使ってもMDBかSLSBくらい。

361氏がSpringの話してなかったっけ？

>>836
むしろSpringがDICon。なんでS2ではなくSeasarがでてくるか分からん。

俺が今携わってるプロジェクトでは、基本的に Spring + Hibernate、
Hibernateで吸収できない複雑な問い合わせ(帳票系とか)はDbUtilsの
カスタム実装とSpringのDaoSupport組み合わせて使ってる。
Hibernate使ったDAO実装はテスト書く必要ないから楽。ほぼ自動生成+α。
もちろんそれを使うService層でのテストは必要なんだが。

>>842
ここではそういう話が非常に参考になると思うが・・・
Map厨には伝わらないよ。特殊なケースとか言いそう。

>>841
あ、しつれい。S2のつもりでした。
>>842
「DbUtilsのカスタム実装」というのは、Handler層のカスタム実装を
行っているという意味ですか。

>>829
>>843
こういう人たちは、まじめに回答してくれている人たちの
行為を結局はバカにしているのと同じですな。

>>844
Handler層って何？

>>845
まあ、謙虚に学んでけよ。そのうち反応も和らいでくるぞ。

>>846
あ、ResultSetHandlerをカスタムでインプリしているのかという意味ですね。

>>847
いやまあ煽ってるからこんだけレスが返ってくるという
事情はあるんですがね(w

>>848
純粋にDbUtilsを拡張してるだけじゃないの、Handlerに改良の余地あるっけ？

>>849
実の無いレスでスレが消費されても意味が無いよ。
実際HibernateやCayenneとかの話に全然深く入っていかない。

>.>844
そういうことになるのかな。
DbUtils2.0のBeanProcessorをいじって独自のマッピングルールを追加した上で、
SpringのMappingSqlQueryの継承クラスに使わせてる。
開発者にSQLとModelBean用意させれば勝手に結果セットがそのModelBeanに
詰め込まれるってとこです。
Springの作者的にはあまりやって欲しくないらしいけど、マッピングルールが固まってるなら
別にいいんじゃないかと思ってる。

>>852
なるほど。
って、よくみると>>805さんはあれか。
私は同じMap厨なのですが、えらい口調の変わり方なので
最初わからなかったですよ(w

>>852
MappingSqlQuery知らんかった。こんなのもあるのね。

>>853
なんだか嫌らしい書き方する人ですね。

同じMap厨・・・勝手に仲間にされとる。

あ、そういう意味じゃないのか。

>>857
日本語が読みにくいからしょうがない。

Hibernateチームの人間が、EJB3.0の仕様策定チームに参加してるんだっけか。
んで、EJB3.0では、否が応でもHibernate的な設計になっていくわけだが。

>>859
>>208

何でもいいから、O/R Mapping 使う気ないならこんなとこまできて
わめき散らさんで。そんなヒマあったら Map でもいじくってて
下さいよ。こっちもアータの御高説聞く気もヒマもないから。
...あ、ひょっとしてスレタイ読めないのかな。

>>535でスレ違いでは無いとおっしゃられているようです。

ま、本質的な話題を振ることができないから、関係ない話題で場を乱してかまってもらって喜んでる、哀れなオヤジだから。

うーむ、随分と伸びてるから熱いスレなのかと思ったら、実は寒いスレだっだんだな・・・

まあ、老害をもろに見た感じだな。

明日は我が身だよ

あぁならないように、日々努力、ってことだな。

>>867
同意

MAP厨ってなに？

ストレージングの形式なんて、それこそ要件次第だとおもうんだけど、
なんでもめるの？決定くつがえす権限があることなんてﾅｲﾃﾞｼｮあんたら。

上のほうにエンティティのMap実装なんてありえないとか書いてあるけど、
なんか話が食い違ってない？

エンティティクラスの実装方法の話じゃなくて、永続化形式の話でしょこれ。
型制約を利用してプログラムを静的に安全にするか、Mapみたいななんでもアリ
にしてそのかわりあとでひどい目にあいそうな実装にしちゃうかなんて話も、
実は単なる選択でしかないと思うが、それは別の話じゃないのけ。

>>869
ORマッピングなんか必要ない。
アクセッサだけのクラスなんかムダ。
ムダなもん自動生成するORマッピングなんか、もっとムダ。
すべてMapで解決できるだろ。
品質の低いコードも、ちゃんとテストするから大丈夫。


という持論の人。

>>871
ウヒョ。
巨大なデータが入ったRDBのインスタンスがすでにあるときとか、
どうすんですか、それ。

>>870
> それは別の話じゃないのけ

その、別の話をするスレなんだが。
マッピングスレだし。

>>872
Mapで大丈夫。


らしい。

ああ、よくわかりました。

スレ読まなくてスマソ。

（　．３．）　ヌェー　871はオレだＹＯ

　あのな、おれO/R Mapping大好きだけど、でも型保証とO/R Mappingを結びつけて
O/R Mappingの利点とするのは違和感があるな。

　たとえばEnterprise Object Frameworkはデータ取得する時にObject型で返すのが
普通なんで、かならずキャストが入るし（型保証は弱いわな）、Enterprise Objectは
内部表現としてマップ使ってんだぜ。

　でもJava プログラムとDBとの関連づけがあっさりできるとか（マップを意識する必要ないし）、
キャッシングとかリレーション設定の簡便性とか、ＤＢに対する透過性とか、複数ＤＢを意識する
ことなく統合できたりとか、そういう利点があってこそのO/R Mappingだろ。しかもそれらの
利点を、簡単に利用できるところこそがウレシイわけだろ。

　マップで十分って方も、O/R Mappingは型安全性が、ってのも、なんか論点ずれてないか？
　まあここは２ちゃんではあるわけだが...

>>871
ゴメン間違えた。
>>877
>まあここは２ちゃんではあるわけだが...
そういう風に納得しました、ワタシ。

>>877
よく読んでもらうとわかるが、ORMappingは型安全性が・・・という議論じゃない。
型安全性なんか無意味だ、アクセッサだけのクラスなんか無意味だ、マップで十分だ、という意見に対する反論。
ORマピングに関しては>>317みたいな意見もすでに出てるわけで。

ORMappingは無意味だ、というのも入り混じって、変なことになってる。

>>879
そーそー。型安全性なんて、O/R Mapping の数ある利点のひとつって
だけなのにね。
Map に何でも突っ込んだら型安全性 *すら* (簡単には) 保証できねえじゃん!!
って話なのに、ネチネチ粘着しおってからに。

そういう部分にくだくだ神経使いたくないからこそ便利なツールとか
使うわけなのに、かの人は典型的な「何でも全部自分でやらないと気が
済まない」タイプの人なんでしょう、恐らく。
ならクラスライブラリも使わずに全部自作すりゃいいのにね!!
若しくは cat > Foo.class でダイレクトに中間コード書け。

もちろんJakarta-Commonsなんて、ライブラリのメンテナンス終了が怖いので、使えるわけアリマセン。

>>870
>>872
その通り。俺も型安全がORMの利点であるとは一言も言ってない。
エンティティのMap表現なんて、OO(というよりむしろJava)の利点を捨てる上に
必要なはずの複雑さ(なんかこういう言い方も違和感があるが)まで切り捨てて
やるようなことじゃないって言ってるだけ。

ありゃ。アンカー間違えた。
>>870と
>>877です。
ついでに
>>880もつけとくか。

まあ、普通は自分の意見が誰にも同意されてない事に気づくと思うんだが。
彼はそれでも負けないからね。強靭な意志を持ってるよ。

しかし、不毛有毛に限らず、すげー伸びだな。。。
前スレなど消費するのに１年以上かかったのに（ｗ

裾野が広がったのだろう。
ということにしておきたい。

職場でも話題です、このスレ。。

学校でも話題です、このスレ。。

お店でも話題です、このスレ。。

彼女とも話題です、このスレ。。

街中で、評判です、このスレ。。

全米でNo.1ヒットです、このスレ。。

祖父母とも話題です、このスレ。。

参院選の争点でした、このスレ。。