1 :
デフォルトの名無しさん :
2006/06/22(木) 11:55:30 あんなもん、レスポンス悪くなるだけ。 SQL直書きがいいに決まってる。
まあ、同意だな。 複雑なSQLに対処できないし、 簡単なSQLならORマッピング使うまでも無い。 パフォーマンスを考慮したら、邪魔になること間違いない。 コードなかなくても、定義ファイルを作らなきゃいけないから 結局、何も楽にならないし。 データベースのフィールドの値を変数に代入する、 またはその逆の関数程度があれば十分。
ORマッピングを使うメリットってなんでしょう?
1. SQLを直書きしなくていい。直書きしないメリットは省略。
2. DBの存在を意識せず、オブジェクトのことだけ考えればいい。
けど現実には
>>2 が言ってるみたいなことになったりもする。
俺自身はORマッパの是非は要件と使い方によると思うので、いるともいらないとも断言できない。
必要になるシチュエーションってあんの?
UPDATEやINSERTもORマッピングって対応してんの?
UPDATEやINSERTには対応しているが、 ちょっと複雑なJOINには対応していないことが多い。 複雑なSQLかかないのなら、直で書いても手間じゃない。
Commons DbUtilあたりがちょうどいいなぁ。 中で何やってるか丸わかりで安心だし、 SQL直接指定できて、検索結果はBeanで返ってくる。 コンバータ書けばO-R任意のマッピングもできる。 ただ、リフレクション使うから遅い。 大規模やパフォーマンスにシビアなシステムでは使えない。
9 :
デフォルトの名無しさん :2006/06/23(金) 00:44:49
オブジェクトにマッピングするなら、 本格的にオブジェクトにしてくれよ。 たとえば継承やメソッドまで使えるようにする。
以前どこかのスレでMap最強厨が異常に叩かれていたが、俺は結構Mapもアリだと思う。 最近はDIと絡めて、色々自動生成したりリフレクションに頼ったりしてるが、 トランザクションの最初と最後を強制的に決めてしまう クロージャや内部クラスのような使い方さえ躾けとけばいいと思う。
ORMつーより、むしろドメインモデルが何の役に立つのか 分かって無いって感じだな。
マスメンみたいな簡単なのは マッパー使って 帳票とかはSQL書きたい。 てなことでS2Daoがしっくりきた。
14 :
デフォルトの名無しさん :2006/06/24(土) 14:29:20
はげどう。両方使えるのがいいよな。
すまん、あげてしまった。 というか、複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ? 8割9割は簡単なSQLですんで、1割くらいはちょっと複雑になることがある。 それを考えると、すべてをSQL直書きは面倒くさい。 ORマッパーで楽できるところは楽して、SQL手書きでがしがしやりたいところは手書きでやるのがいちばん。
簡単だが、手間のかかるところを ORマッピングするわけだが、 どういうこっちゃ? はぁ?
>>16 フィールドが200〜300あるのを毎回打ち込むのマンドクセ
フィールドが三桁もあるのはどっかおかしいのではないかと 思うのは俺だけか?
訂正: ×: フィールドが三桁も ○: フィールドの個数が三桁も
書いてから200は多いなと思った 2〜3って読んどいて
Hibernateしか使ったことないけど、HibernateはSessionから JDBCのコネクションオブジェクト取れるしね。 ってことは、Hibernate使うときは素のSQL書かせないようには 当然してないと。 Mapに詰めるのは、メンバーが合意してるんだったらいいんじゃね? って思う。漏れはHibernate使う人だから進んでは合意しない。 getter,setterがあると、eclipseでコード補完効くから、楽だしな。 あと、オブジェクト指向かDB指向かと言われたら、間違いなくDB指向だ。 まあHibernateのObjectの永続化の考えに反するかもしれないが、 RDBには、RDBなりの設計が重要だと考えてるから。 いつなんどき、変態DB屋が現れるかわからんしなw
ちょっと屁理屈かもしれんけど、
オブジェクトを使う以上は、フルSQLであろうとなんだろうと、
何らかのORマッピングをやってるわけで、
>>1 の言ってる話は、
なんらかのORマッピングフレームワークによる(半)自動化が、
必要かどうか、という話なんでないの?
まぁ世の中には流行っているって理由だけで、バッチ処理にORマッピング使う馬鹿がいるからな〜
? ∧∧ (,,゚Д゚) / | 〜OUUつ
25 :
デフォルトの名無しさん :2006/06/24(土) 16:58:17
seaserの作者がspringとベンチマーク比較を載せてるけど 結局どっちも遅いな
>>15 >複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ?
そっかなー、帳票にしろ、更新にしろ単純なSQLはあんまり無いけどなー。
特に更新系のSQLは WHERE を見れば仕様が分かるから
ORマッピング使ってダラダラ書かれると後からおっかけにくい。。
それは1回のSQL呼び出しですべてを完了させようとするから。 たしかにパフォーマンス考えるとそっちがいいに決まってるんだけど、 パフォーマンス的にシビアでない場合なら簡単なSQLを数回発行するほうが プログラムが簡単になる。
UPDATE 売上 SET 請求フラグ = 1 WHERE 売上日 = NOW みたいなのは if (obj.UriageDate == Now) { obj.SeikyuFlag = 1; } これを対象件数分繰り返すの?
売り上げアクセス dao = コンテナのDAOビルダ.create( 売り上げアクセス.class ); dao.set請求フラグofToday( 1 ); みたいな感じジャマイカ
更新対象が画面で選択されたものの場合とかどうすんの?
>>31 対応するインスタンスの状態が変わる→任意のタイミングでDBに反映
って感じかな?俺は元はDB屋なんだけど、ORマッピングに関しては、オブジェクト寄り。
上に出てる多量の行を一気に更新する、ってのはORマッピングに対する反論としてよく出るけど、
オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケースなわけ。
だからSQL直書きでもいいし、ストアドキックでもいいと思ってる。その間、インスタンスは使いづらく
なるけどね。
mysql+hibernateでトランザクションがロールバックできないってホント? 空気嫁って?
mysqlってトランザクションサポートしてるの一部のテーブルタイプだけだろ?
/つ_∧ /つ_,∧ 〈( ゚д゚) |( ゚д゚) ヽ ⊂ニ) エェ ── ッ !? ヽ__と/ ̄ ̄ ̄/ |  ̄\/___/ ̄ ̄
>>35 の反応が気になって調べてみた。やっぱInnoDB指定しないと駄目よね。
多分、InnoDB指定しないで「使えねぇ」って言ってるアホと思われ
>オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケース まじで??
まぁ、業務から設計すると帳票とかのデータ構造がまず先に来るから、 仕事では「オブジェクト(クラス・インスタンス)のほうから設計」するのが まず例外ケースだと思うけどね。
SQLの代替、進化版じゃなくて、オブジェクトの永続化にDB製品使ってるって話だからさ SQLとORマッピングの比較じゃなくて、プレーンなファイルを使った場合とDB使った場合での オブジェクトの永続化のやりやすさ、ってとこを考えないといけない
40 :
32 :2006/06/28(水) 19:38:46
>>37 たまたま見たのでレス。
マジだよ。ただ、前提条件があるんだが、そこには触れていなかった。
・多量データの更新というのは、データをひとかたまりに見ていれば当然でてくるだろうけど。
多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
する人は、無意識に「データベース」が頭にあるんだと思う。
・で、メンテナンス以外での一括更新ですが、これは単純にはあるクラスで集約するという
概念になります。データへの変更はなし、ただし特定クラスのインスタンスで集約されている
状態になる。
・集計などは夜間バッチで集計表に移したり、ストアドプロシージャを利用します。
得られた結果は元の表とは別のオブジェクトと考えればいい。
抽象的過ぎて、非現実的と思われるでしょうが、データベースにアクセスするんじゃなくて、
あくまでもインスタンスを永続的にストレージに保持する必要があって、たまたまデータベースを
利用するに過ぎないって観点です。そしてデータベースの中で済む処理はすべてお任せ。
上にも書いたけど、クラス・オブジェクト設計して、多量のインスタンスを変更するなんて、
お粗末な設計でしょ。一括ってことは、そこに関連性と法則性があるんだから。
って、いっぱい反論あるんだろうな…繰り返しになりますが、自分はSQL直書きでもストアドでもいいって
立場です。むしろそうやることでドメインモデルから距離を置いたほうがいいよねーって感じ。
まあ UPDATE 売上 SET 請求フラグ = 1 WHERE 売上日 = NOW みたいのは、「請求(乃至イベント)」クラスに1レコード当日日付持たす、でいいわ 日別状態クラスの当日ステータス更新ってかたちでもいい
42 :
デフォルトの名無しさん :2006/06/29(木) 10:46:33
データ更新用オブジェクトを作ればいいじゃないか
意味がわからんが、部分集合に対するupdate文を発行するオブジェクトって意味だとすると、 メモリ上の各レコードのインスタンスとの整合性保持するのが困難
データを大量にインスタンスとして持とうとすると、一挙にややこしくなるねえ。
>>38 帳票とかのデータ構造が先に来るってのは、
DB屋の設計手法としても間違ってると思うのだが。
Sヨお得意の画面/帳票まんまな糞DBじゃんw
帳票(現在)→DBエンティティ→帳票(改修)
>>29 >これを対象件数分繰り返すの?
ORマッピングだけをつかうなら、そういうことになる。
あとはdeleteのときも、件数分delete文を発行する。
もちろんこれは効率が悪いけど、それで速度的に問題ない場面ならORマッピングをそのまま使う。
問題ある場合だけSQLをがしがし書く。
だからORマッピングだけで完結させるのは難しいし、そんなことにはこだわらないほうがいい。
>>40 >多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
>てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
そんなばかな。業務システムではしょっちゅうあるけど。なぜこんなことを言い切れるのか不思議。
とりあえずHibernate+Springは俺には無理だったな セッションやらキャッシュやら自動トランザクションやら訳判らんし、データ更新してもTomcat再起動すると元に戻ってたりと、 ORマッパーが裏で何やっているか完全に把握している人間がいないとダメだわ まぁ俺が不勉強なだけだけど、 普通にJDBC直書きでトランザクション制御はTemplateMethodパターンの方が遥かにわかりやすかった
>まぁ俺が不勉強なだけだけど、 自分でわかってんじゃん。 新しい物を覚える能力に欠けていると自覚するなら この業界でやっていくのは難しいよ。 オブジェクト指向が理解できないCOBOLオヤジと一緒。 早く別の道を探した方が良さそうだね。
>>48 そんなあなたにS2DAOをお勧めする
設定ファイルもシンプルで簡単だし、サンプルもわかりやすくてマジ最高
51 :
デフォルトの名無しさん :2006/07/02(日) 11:33:46
結論:ORマッピングはいらないと言っている連中はオブジェクト指向が理解できないCOBOLオヤジと一緒。
select * from table でとってきた奴はO/Rマッピングオブジェクトに入れた方が その後ガシャガシャやるのに便利じゃないか。 ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して 全カラムupdateするのは嫌だな。 うっかり変更する必要がないプロパティ変更しちゃってたら大変だ。 なのでupdateは、必要なカラムだけupdateするSQL呼び出しをDAOを作る。
>>52 >ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
>全カラムupdateするのは嫌だな。
無知。使いこなせていない奴が文句言うな。
54 :
デフォルトの名無しさん :2006/07/02(日) 14:28:56
>>53 一生懸命勉強しないと使いこなせないものってダメだと思う、Hibernateがそうなのかどうかは
別として。
>>54 ダメなものかどうかを自分で決められるのなら、そう言ってろ。
おまい自身が「一生懸命勉強しないと」と感じるかどうかが基準か?
ダメだどうのと言っている奴がダメだ。
この仕事をしている限り、デファクトスタンダードは避けて通れないんだよ。
今から勉強するとしたらejb3かねぇ
Hibernateを使ってたらわかると思うけど、O/Rマッパーが提供するのは 「SQL記述の冗長な部分のみを自動化する」機能であって システムとしてはよりDBに依存した形になる。 DBの存在を隠蔽するとか、SQL的な記述を隠蔽するとかいう説明は誤り 作成されるSQLを完全に理解できるくらいでないと、O/Rマッパーを使うのは難しい SELECT文でカラムをJOINしたテーブル毎に全部書いたり、結合の度にJOIN句を書いたり INSERTやUPDATEを書く処理は、どれもテーブル定義さえ知っていたら自動化できる処理だから そこら辺はO/Rマッパーに任せる。 逆に検索条件や副問い合わせを駆使するようなSELECT文は、SQLだからこその機能だからSQL寄りに書く。 Hibernateなら、HQLを使えばSQLとほぼ同レベルのことが書ける。 HQLではFROM句での副問い合わせやUNIONが書けないのは不満だが、そんなときはSQLQueryを使えばいい
58 :
54 :2006/07/02(日) 16:16:29
>>55 いやー、おまいみたいな優秀な奴だけを集めてプロジェクトを進めるのが難しいという現実がある以上、
一生懸命勉強しなくても使えるものを採用しないとダメだと思うけどねぇ。
ダメだどうのと言っている奴がダメなのは同意するけど、だからといってそういう奴でも
開発メンバーに加えざるをえない状況もあるわけで。
ところでHibernateはO/Rマッピングのデファクトとまでいっちゃっていいものなんですかね?
>>58 >>55 が優秀かどうかもわからないのに、口だけ調子いいこと言ってる奴もダメだな。
メンバー全員がHibernateに精通していないと、という前提になっているところもダメ。
設計やフレームワークの使い方を間違っている可能性大。
全員がHibernateに精通している必要なんてないだろ。 一人だけ詳しい奴がいれば、あとの連中の生産性を最大化することが できる。 むしろそれがORMの最大の狙いで、SQLを使ったやり方だと、メンバー 全員がDB設計SQL設計に精通している必要が出てくる。
>>59 「優秀かどうかもわからないのに、口だけ調子いいこと言ってる」
ただのイヤミだろ。
「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。
>>61 >「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
>「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。
矛盾してないか?
メンバー全員がHibernateに精通していることが前提でなければ、
メンバーの一部に使いこなせる奴がいれば充分だろ?
メンバー全員が
>>55 みたいに優秀な奴である必要はないんだよ。
この先生きのるのはEJB3.0、Hibernate、S2Daoどれ?
HibernateはJPAに対応したし、S2DaoもJPAに対応する(Kuina)予定らしい
O/R マッピングを有難がる奴ってのは
>>52 >select * from table
こんなのばっかりなのか?
シンプルが一番
シンプルってよく言うけど、どういう状態がシンプルなのか 理解している奴は少ない。 シンプルに実装しました、とかベタで書きましたとかいって for文の5段ネストとかそんな感じのソースが出てくる。
ORマッピングって今いち楽だねって実感が無いね。 楽するためにプログラミングしてるはずなのに、全然楽じゃない。 XMLなんて醜くて遅くなるだけだし。 一人の詳しい香具師が居ればいいってのもいまいち。 その一人が逃亡した時点で終わるし、その一人の給料だけ高くすると不満が出るし、他がやる気無くすし、その一人のために他の香具師が低い賃金でこき使われることに成る。 詳しくなくても簡単に使えるORマッパが求められてると思う。
>>68 使ってみたORマッパーとその問題点を具体的にきぼん。
> XMLなんて醜くて遅くなるだけだし。
だけでは根拠が弱い(XMLを使うと遅くなるわけではないので)。
XML に何の関係が?
XMLを使用しないとなるとRoRのActiveRecordとか? この辺りは使ったことないけど、どうなんだろう?
書き方が変わるだけで楽にはならない。
XMLのマッピングファイルで遅くなるってのは
実装速度じゃなくて開発効率の話しかな?
マッピングファイルを手書きしていたらORMのメリットはかなり低下するだろうな。
ここは、現実的にはMiddlegenとかXDocletを使って自動生成する部分だろう。
手書きめんどくさいと言っている人は雑誌やWebのサンプルに沿って
ちょっとモノを作ってみただけで判断してないか?
>>68 はフレームワークの使い方やプロジェクトでの役割分担を根本的にわかっていない希ガス
ORMのメリットがわかんねー云々以前に、ドメインモデルを使ってるかどうかを 問いたい。
おれ、ドメインモデルがよくわかんねぇ。
いっつも
http:// (domain)/hogehoge/mogemoge.jpg
↑の意味のドメインが頭に浮かんできて、何の事やらサッパリわからんくなる。
解説頼む
じゃ mailto:sage@(domain) ってのは?
つまり、
http:// (domain)/ の(domain)はドメインではなく、ホストを表す文字列だということ。
ホストを表す文字列に (domain) というのはおかしいという話では?
OK,(host)と(domain)の違いはなんとなくわかった。 (host)からwww1とかwwwとか、ftpを取り除けば(domain)になるってことだな。 で、結局、ドメインモデルと(domain)では、ドメインって別のものを指してるよな? そこら辺がおれにはよく分からんのだよ。 では、そこを起点に議論の再開を求む。
domainといっても色々種類があるが、最も一般的なのは 代数的かつ整合完備な半順序集合bcdomだろう。 bcdomは関数構成子に関して閉じており、圏としてみた場合 cccをなす
ドメインというのは大雑把に言って(何かで区切られた)「領域」。 DNS におけるドメインというのは、ネットワークにおける(管理上)の「領域」、 企業や部門などの管理者が置かれる単位。 データモデリングにおけるドメインは、データにおける「領域」、 つまり、対象領域とする業務やアプリケーションに含まれる(モデル化すべき) データの集合、ないし、データが存在する対象領域そのもの。
まずは英和辞書を引いてから 考えてみようって話だな。 カタカナでドメインだと確かに この業界、初学者にはまぎらわしいですな。
88 :
87 :2006/07/17(月) 04:22:52
それと、「領域」ってのも間違いじゃないんだろうけど どうも物理的な場所のイメージが強くてよくわからん。 「問題領域」なんて訳がよく使われるけど、 なんか頑張って考えたのが伝わってきちゃっていかん。 「うちはA社とはドメインが違うから競合しません」 みたいな言い方もよく聞く。 そうすると、「業界」みたいな意味もあるように思える。 正確には粒度はもっと小さいんだろうけど。 てことは、ドメインモデルって 「業界用語」って事でいいんじゃないの? ただの業界用語集ってだけでなく、 構造まで表現したもの、てなかんじ。 寝ようと思って布団に入ったら思いついたから また書いた。
縄張り
>ドメインモデルって「業界用語」って事でいいんじゃないの? ちがうだろ。
91 :
87 :2006/07/17(月) 16:46:27
うーんやっぱちがうか。
普通に、解決しようとしている対象をちゃんとモデル化しているかってことだろ ドメインという言葉よりモデルの中身の方が大事だよね
もう、メンドイ
恕面モデル
ドメインメンドイイドメンってことか、やるねぇ
メイドインドメイン
メイドインインド
なんかよくわからんが O/Rマッピングに妙に肩入れしてるのはJAVA界隈の人だけだと言うことは分かった。
まあ、毎回スキーマーとプログラムを見比べて、 SELECT 文の出力を、変数に代入するコードを書くことを 「あたりまえ」 だと思って何の不満も感じてないなら、 OR マッピングなんて必要ないわな。
ORマッピングは SELECT文の出力を変数に代入するコードを書かなくてもいい代わりに、 SELECT文の出力を変数に代入する設定ファイルを書かなくてはいけない。 本質的には何も変わらない。
>>102 設定ファイルを手書きするバカなんていないけどな。
class Hoge < ActiveRecord::Base end で完了だけどな
105 :
デフォルトの名無しさん :2006/07/31(月) 09:45:01
外部結合と抽出条件、グループ化を伴うちょいと複雑なSQLと、O/Rマッピングで
それと同等のSQLを吐くプログラムコードを見せて欲しい。
>>101 でもいいよ。
いまだにこういうこと言う奴がいるのか。
SQLでJOINするよりも、 ORMがさらっとやってくれるCacheとLazyLoadingの方が パフォーマンス上がる場合が多いよ。 自力でCacheしろという意見はきかん。
>101 >SELECT 文の出力を、変数に代入するコードを書くことを そんなことしないってw
>>108 お前がそうしないのは勝手だが
お前の事情など知った事ではない。
今時SELECTの結果をいちいち変数に入れなければいけないような実装は
ないんじゃないのか? API直接叩くなら別だけど。
>>101 がどういうつもりで言ってるのか知らないけど。
いや、SELECT 文の結果を変数に入れないなら、 どうやってSQL以外のプログラムからDBにアクセスするんだ。
馬鹿だな、みんなwww 変数に入れないって事は M a p に 入 れ る って事じゃないか。
Map厨キタ━━━━━━(゚∀゚)━━━━━━ !!
>>112 おおー久々のネタだ!!!
よく覚えてたなw
>111 直接レコードセットのフィールド参照すりゃいいじゃん
117 :
デフォルトの名無しさん :2006/08/03(木) 15:10:14
いちいち変数に代入したがる奴っているよな。
それはORMとどう違うのだ? それとも Javaで言うと ResultSet をViewから直接参照するのか? 非常識な設計だな。
>それはORMとどう違うのだ? >それはORMとどう違うのだ?
>とどう違うのだ? そのコードを、作成するたび、変更があるたび、 いちいち人間さまが書く必要があるかないか。
>>120 つまり、ViewでResultSetを直接参照してるってこと?
データをオブジェクトとして扱うという発想がないってこと?
.NETってWebでもそんなことするの?
>>121 っていうか、なんでそこでView がでてくるのかわけがわからん。
仮にいちいち書くとしても、データアクセス層の話だぞ。
>>122 ん?じゃあ、最終的にはどこかで取り出したデータを
オブジェクトに入れ替えるコードは書くわけ?
>>123 >取り出したデータをオブジェクトに入れ替える
だから、それがORマッパの機能で、それ(ORマッパ)を使わない場合は、
そのコードを人間がいちいち手で書くことになる、
というのが、
>>120 の文意だよ。
>>124 ああ、そういうことね。
>>120 を読み違えてた。
ResultSetを直接扱えば、変更があってもマッピング定義を
変えなくていいじゃん、という非常識な意見だと思ったよ。
じゃあ、結局ORMイラネって言ってるやつは
いちいち手書きしてるってことか。
なんと非効率なことか・・・・
アホか。
>>121 でいきなり.NETが出てくる理由がわからん。信者か?
>いちいち手書きしてるってことか。 なにを?
ループしてきた?
>>105 でも聞いたけど、例を出してその優位性を見せてくれれば一発で
片が付く議論なのに、なんで出してくれないの?
>>129 そもそも前提が間違ってるから。
今時おまいみたいなこと言う奴まだいるんだなw
>>130 で、例は? また出さずにグダグダやるわけ?
前提が間違ってると言われてるのに、例は?とかまだ言ってるのか。 どうしても何を言われてもオブジェクト指向を理解できないコボラーのように頭ガチガチなんだなw
まあ前提がおかしいのは
>>1 から既にそうだしな。
>>132 前提とかその辺はどうでもいいのよ。
オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
単純にO/Rマッピングの利点の話。
単にオブジェクト指向ってだけならデータセットレベルでもオブジェクト指向してるワケで
O/Rマッピングを採用することでどんな具合に楽になるの? ってことが知りたいわけ。
だから
>>105 に挙げた例を出してくれって言ってる。
>>134 >オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
ホントにわかってないなw
そんな話をしてるんじゃないだろ?
オブジェクトを永続化するのになぜ
>>105 のような例が出てくるのかまったく理解できない。
>>105 を前提に例を求める時点でORMの使い方をわかってないってこと。
そんな奴が無理矢理使っても失敗するからやめとけ。
>>135 オブジェクトの永続化なんて言っても、その永続化の先にあるのはあくまで
SQL完備のRDBMSが前提でしょ?
>>105 の何がおかしいわけ?
>>105 1. 関連するtableの全recordをobjectにmapping
2. 1で生成したobjectの集合に対して、好きな方法で必要なobjectを抽出する
オブジェクトの永続化という視点でモデリングをして
どうしたら
>>105 みたいな状況になるんだかw
設計とモデリングがヤバいだろ。
ちゃんと説明を行わないからだよ。 ORMの利点と欠点を説明すれば納得するはずだ。 そもそもはオブジェクトの世界とデータレコードの世界の インピーダンスミスマッチの解消のための技術。 そのため、相互マッピングというオーバーヘッドが発生するのは デメリットといえる。 しかしその代わり、オブジェクトの世界における取り扱いの 柔軟性というメリットを享受できる。 その点に魅力を感じないのであれば、その人にはORMは必要なし。
>>138 関連テーブルにレコードが100万個あったら100万個オブジェクトを作るのか?
最悪だな。
>>141 そんなわけないだろ。アホか。
Lazy Loading ってのがあるんだよ。
だがjoinしようと思ったら結局全レコード分のオブジェクトを作る羽目になる…
臨機応変にVIEWとか使えばいいんじゃね? ORM使うのが目的じゃないし、ただの手段にこだわってもな。。
>>143 げー、なにそれ。
裏でSQL作って投げるんじゃなくて、全レコード引っ張ってきて自前で総当たりするのか…。
そういう代物だとは思わなかった。
んなわけない
>>129 オートマ市販車で、ワークスマシンと同等のタイムを出してみろ。
といっているのと変わらん。無意味な質問だ。
>>148 誰も実行速度の話なんてしてないじゃん。
>>149 うん、君を除いては「誰も」していないね。
>>105 JPQLがそれら全てに対応してることからわかるように
検索処理はSQL的な記述を最大限に利用するのが正解
O/Rマッピングが力を発揮するのは、データを取得した後の登録・更新処理
Hibernateの場合、Beanに値をつめてツールのメソッドにわたせばINSERT文が発行されるし
SELECT文で取得したBeanの値を変更すれば、トランザクション終了時に自動的にUPDATE文が発行される。
これらのINERT・UPDATE文はJDBCのバッチUPDATEを利用する為、ある程度のパフォーマンスも期待できる。
また、このとき排他処理が自動的に実行される。
Webアプリなどのロングトランザクション管理が必要な場合は必須といえるツールだと思う
データのBeanへのマッピングも便利だが、それは昔からDbUtilsなどで実現していた機能だからな
>>143 ツールで自動作成すればいい。外部キー制約をつけていれば、クラス間の関連定義まで自動でやってくれる
ぶっちゃけマッピング面倒だ。 自動化出来ないのか?
>>153 できるよ
ってか、するのが当然・普通・あたりまえ。
155 :
デフォルトの名無しさん :2006/08/06(日) 02:35:34
ORMうんぬんよりも ここにいる人達は正直イタイと思った。 まずは日本語をw
日本語をマッピングするのか?
ぶっちゃけ脳内→日本語マッピング面倒だ。 自動化出来ないのか?
>>157 できるよ
ってか、するのが人として当然・普通・あたりまえ。
Java以外ではろくなORマッピングが存在しない。 あっても、逆に手間がかかる。
Javaが一番SQL分からない馬鹿による被害が甚大なんだろ
>>160 シッタカ乙。
ORMの役割・メリットはそこじゃないっつーの。
>>161 > ORMの役割・メリットはそこじゃないっつーの。
じゃあどこさ?
エンティティとデータの関係を言語ソースの外に出せることだろ
そもそもPGって日本語不自由な香具師が多いよね。 ソースで会話したほうが速いことが多杉!
ORMなんて小ざかしい事せずに、OODBのほうが良いような気がしてきた。
>>163 SQLを知ってる・知らないではなく、
SQLとオブジェクトのマッピング作業をフレームワークがやってくれる点。
>>163 ORMはSQLを知っていることが利用の最低条件
目的は、SQL記述から冗長な部分を省いて永続化処理の生産性を上げること
【ORMの役割・メリット】 ・エンティティとデータの関係を言語ソースの外に出せること(>164) ・SQLとオブジェクトのマッピング作業をフレームワークがやってくれる(>167) ・SQL記述から冗長な部分を省いて永続化処理の生産性を上げる(>168) 色んな表現があるが、同じことを意味している?
てか日本語じゃ良く分からんから ソースで示してくれんかの?
>>170 ResultSet rs;
・・・
Bean bean = new Bean();
bean.setProperty01(rs.getString("column01"));
bean.setProperty02(rs.getString("column02"));
bean.setProperty03(rs.getString("column03"));
bean.setProperty04(rs.getString("column04"));
bean.setProperty05(rs.getString("column05"));
bean.setProperty06(rs.getString("column06"));
bean.setProperty07(rs.getString("column07"));
bean.setProperty08(rs.getString("column08"));
bean.setProperty09(rs.getString("column09"));
bean.setProperty10(rs.getString("column10"));
・・・
上記のような単純で退屈でコピペミスしやすく、
しかし大量に書かなければ行けないような処理を、
テーブル毎・検索処理毎に書かなくて良い。
上記のコードを手書きするとカラム名やカラムの型を間違える可能性もあるが
マッピング定義ファイルを自動生成すればカラム名やカラムの型を間違えることもない。
カラムの追加変更があっても、このようなコードだと影響箇所を修正するのは骨が折れるが
マッピング定義ファイルを自動生成すればかなりの省力化が可能。
テーブル構造をオブジェクトにマッピングするツール × オブジェクトをテーブル構造にマッピングするツール ○ RDBMSとオブジェクト指向言語との親和性を高めるツール × オブジェクトを永続化する先の入れ物としてRDBMSを使うためのツール ○ 既存のテーブル構造にORMを適用する事も自動化ツールのサポートで容易 × ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○ この辺りを理解してないORM信者も多すぎる。 所詮はラッピングツールであり、余程単純なシステムでもない限りSQL直書きは避けられない。 ここを勘違いすると、JAVAコードをすっきりさせるために一貫性の無いVIEWやストアドを大量に作成して DBの中を阿鼻叫喚地獄絵図にしてしまうという本末転倒をやらかす。
まあ、DBの中が阿鼻叫喚地獄絵図になってしまうようなやりかたで、 Java コードだけはすっきりしてるなんてありえないけどな。
>>172 >ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○
別に困難じゃなかったぞ
重要なのは適用検討しているテーブル構造の正規化の度合い
主キー無し、外部キー無し、結合条件がDBの制約では決まらないetcな構造だったら諦めるべきだが
普通に正規化されたテーブルなら適用は容易
ORMって結局DB側に寄ったツールであることを勘違いしてはいけない
SQL直書きサポート必須は同意。最近のツールはどれもサポートしてるけど
なんでもかんでもSQLでやって、UIだけプログラムで作れば
作れば・・・
>>175 なんでもかんでもSQLでやって、UIだけプログラムで作れば、
UI部分のプログラムにはカラム名を指定して値を一つ一つ取り出す記述や
入力値をSQLに埋め込む処理を大量に書くことになる・・・と。
どんな開発ツールを使ったそんなへっぽこな発想になるんだ
なんでもかんでもVBでやって、ばぐった時だけ外注で作れば
ぐらーぐらとにえる♪
db4oならORマッピング不要ですね
もうDLinqでいいじゃん
>>181 とりあえず本1冊読んでみたけど、組み込み向けじゃん。
RDBMSの代用には向かない気がするけど。
OODBをRDBMSの代用として考える方がおかしい気がするけど。
db4oの中の人はリレーショナルの代用になるって言ってる。 実際のところ、どうかは知らんが。
188 :
デフォルトの名無しさん :2006/10/07(土) 04:11:26
Hibernate最強でしょう。 いまどきJavaの世界にSQL持ち込んでる糞は氏んでよしと。
Hibernate ってそこまで(SQLを一切使わなくて良くなるほど)万能なものとは 思えんのだけど。
Map最強説唱える奴にはそう見られても仕方が無い
∧∧ (,,゚Д゚) ヨイショ.... / つ〜⌒ヽ ( (';; _, ...,,) ∪,)....´;;;,,,..(ヽ (::::::ノ⌒)_ヽ)  ̄ ∩⌒>⌒ヽ ゴソゴソ /(';; _, ...,,) ( ,)...´;;;,,,..(ヽ U(::::::ノ⌒)_ヽ) ∧∧ /(*゚Д゚) オフトンサイコー♪ / :::У~ヽ (__ノ、__) _ カタカタカタ .//|.| /'∧ | |..|.| (Д゚,ノ⌒ヽ マッピングサイキョー♪  ̄ll ]-、と/~ ::ノ:::)  ̄ ̄ ̄|(_.( :: ,:_)
個人で作ってような実験アプリとか趣味アプリだったらdb4oで良いんじゃねーか? 今はtomcat + hibernate + postgres だけどそのうち時間があったらtomcat + db4oに変えてみる。 どれだけ生産性があがるかレポートしますね。
db4o ってリファクタリングに追従できんの?
>>188 Hibernate in Actionを一度読んでみるべき
「HibernateはSQLを熟知した開発者こそが使うべきツールである」
と開発者自身がはっきり宣言している
>>193 知らないけど、既存データを捨てていいなら、自動じゃないの?
既存データの扱いが問題なんだよなー 1.SQLで以降処理を作る 2.変更後のDBは別のDBとして作り、マッピングベースで以降プログラムを作る 3.その他 どうするのがいちばんいいのか。
197 :
188 :2006/10/08(日) 10:43:46
>>194 はい、読んでます。
SQLの知識は必要ですよ。
それは否定してませんが。
ただ、
ソース上にSQLを直書して、
StringBuffer#appned
なんて、まじありえない。氏んでよし。
>>197 みたいなレスみると
お前が氏ねよ。って思います。
>>197 こんな感じ?(jdbc 直というのはあんまりやったことがないので心許ないが・・・)
それほどダメとも思えないが・・・。
public class HogeHogeDAOImplJDBC implement HogeHogeDAO {
public void appendHogeHoge( HogeHoge hoge ) {
・・・
Statement sql;
・・・
sb.append( "INSERT INTO HOGEHOGE VALUES(" );
ab.append( hoge.getValue1().toString() );
sb.append( "," );
ab.append( hoge.getValue2().toString() );
sb.append( ")" );
・・・
sql.addBatch( sb.toString() );
sql.executeBatch();
}
}
SQLを使っても「ソース上に直書して、StringBuffer#appned」なんてまじありえないのだが。
普通はResourceBundleやPreparedStatementを組み合わせるからな。
「SQLを使う」イコール「直書&StringBuffer」なんて発想の奴はHQLも直書するんだろうねw
>>199 それはいくらなんでもダメだよ。
201 :
188 :2006/10/08(日) 11:29:54
>>200 あなたの言うことは正しい。
SQLを外だしにして、管理しているならまだましだ。
だが、現実はコンサルと称して、そんなことすら
できない無能な奴がいる。
理由は
「複雑なSQLが多いので、ハードコーディングじゃないと
やりにくい」
などと言っていたよ。
そういうやつらはまじ氏んでいいよ。
ただ、ResoureBundleを組み合わせるといっているが、
ようするにそういう場合、ある種のフレームワークを
作っているんだと思うが、そういうフレームワークでは
Hibernateが最強なんだよ。
かけられている工数、開発者のレベルが世界トップクラスだし。
>>202 とりあえず、単発のSQLなら判らないことは無いがPreparedStatementを使うほうがベターかな?
あと、サニタライズやなんかをどうするって話も出てくる
SQLインジェクションって言われる脆弱性のほとんどは
>>197 みたいなソースを使ってることが原因
>>197 「いまどきJavaの世界にSQL持ち込んでる糞は氏んでよし」って言ってるじゃん
HQLだってSQLのテーブル定義をクラスに置き換えて、結合条件を省略したり継承戦略追加してるだけだし
ソース上に書くかNamedQueryで外出しするかはHibernate使っても選択肢の一つでしかない
>>199 のような書き方は、JDBC使ってても普通やらないしw
今からHibernateのAPIを覚える必要性はないな。 JPAでいいだろ。 コンテナにJBossやjboss-EJB-3.0_Embeddableを使った場合に JPA実装としてHibernateを内部的に使うことはあるかもしれないが。
>>203 それは、jdbc を使う(と決めた)場合の技法の問題であって、
後からいくらでも(DAO内部の問題として他に影響を与えずに)
修正の利く問題じゃないの。
>>207 だからさ、SQL直に書かずに済むなら、
そのほうがいい、ってことは誰も否定してないだろう。
自分が言っているのは、じゃあ、SQL直書きが、
「それほど(SQLのコードがわずかでも存在したら、そのシステムが全否定されるほど)深刻な問題なのか?」ということ。
>>108 パラメータをPreparedStatementで代入することと、SQL直書きが混同されて話されてるからな
前者はJDBCでやるときも同じだから、別にHibernateを選ぶ理由にはならない
後者は別に目くじら立てて否定するようなことでもない。
動的にクエリを組み立てるときはソースに書いたりすることもある。
Criteria使うこともあるだろうけど、JPAでサポートされてないからな
で、Hibernateってどこまで出来るの? joinしまくったSQLの生成とかできるの? これができるのなら導入もありなんだが
joinぐらいならできるよ。マニュアル見れ。
>>210 JOIN程度ならHibernate使ったほうが楽
SELECT句やWHERE句ならサブクエリも書ける
>>213 Hibernate EntityManager
>>213 つ JBoss EJB3(JPA部分の実装はHibernate)
つ Glassfish/JavaEE SDK(JPA部分の実装はToplink)
>>196 ん?db4oの話だよね?
リファクターは既存のクラスをさわらないで、新しいクラスを作りそこで行う
既存のクラス>新しいクラスへの変換methodを適当につくる。
既存のクラスを全部ロード>新しいクラスに変換、全部保存
これで既存データもリファクター完了。
既存sqlからのデータ抽出はhibernate使ってれば上記プロセスでOK
jdbcだったら ちょっとつらいかな。
ibatisとかのこと忘れないであげてください。 っていうかSQL直書きに拘るならよさげなんですが。
218 :
デフォルトの名無しさん :2006/10/25(水) 18:27:25
,、‐ " ̄:::゙:丶、 ,r::::l3゙::::::::/ハヽ:ヽ::::、:ヽ {::://:::::::// ヽ\ト、:::::::! ヾ l:::::::/ 丶 `ヾ ィ、:::| |;:r::| O` 'O ゙ハ| ORマッピング!? ヽハ :.:. :.: レ ´\ r‐--‐、,ノ いらんいらん r、 r、/ヾ ̄下ヘ ヽヾ 三 |:l1、_ヽ/__ .ィヽ \>ヽ/ |` } n_n| | ヘ lノ `'ソ l゚ω゚| | /´ /  ̄|. | \. ィ ___ | | | ノ l | |
特定の言語に依存した環境なんぞクソ。RDBはデータ構造とアルゴリズムを分離す るためのインフラなんだよ。SQLで書けないシステムなんかつぶし効かんからあと あと苦労するよ。わかってないやつが集計処理をループで書いたりすんだよな。
RDBじゃなくってXMLとかでも分離できるんでないの? RDBMSって長期保存のデータストレージとしては最低最悪の場所だから。
221 :
デフォルトの名無しさん :2006/11/08(水) 13:25:26
Execlで保存の方が最低最悪だろ
んーとRDMSっていうのはデータ量が巨大化してある一線を超えると CPUの負荷が爆発的に上がってシステムダウンしたりするの。 ある程度、容量に限度があるってことと、 OSの更新の時のデータの移行とかの問題もある。 だから、分離だけが目的ならDBを使うべきじゃない。
データ量が巨大化しても越えるべき一線かやってこない素敵なストレージを教えてくれよハニー。
四次元ポケットとか
ブラックホールとか
ハクション大魔王の胃袋とか
/dev/null
メーカーの工作員は インターフェースの統合とトランザクションの管理を解きつつ、 RDMSの導入しかないって決め付ける。 ロジックは正しいけど解答は一つではないんだよね。
でも、実際DBMS使ったほうが楽だぜ 見渡せる範囲ならスケーラビリティあるしでDBMS使って楽すりゃ良いだけじゃね 一線越えたときはうちの会社じゃおさらばした方が良いしな
>>222 漏れAS/400(中身RS/6000の)を使っているけどDBの容量が増えたからって
CPUの不可が爆発的に上がるなんて事ないんだが・・・。
そりゃ、システム全体のDiskの容量が90%くらいになると
ちょっと遅くなったなぁ、とは感じるけど。
それってWindowsでAccessとかSQL Serverとかの話じゃねーの。
インデックス張り損ねて全レコードなめまわすようなバカクエリーや ブロック分断されまくったまま放置してたとかそんなんでしょ。
>>231 Disk I/OがボトルネックになってCPUのSYSが跳ね上がったことはあるよ。
当時DBのサイズは100GB弱程度でPostgreSQL8.1利用。
OracleならDiskの使い方がもっと上手いんだろうけど。
234 :
231 :2006/11/12(日) 17:47:37
>>233 それOracleとかPostgreがどーこーじゃなくて、最初のハードウェアと
OSの選定が間違っていたってオチかと。
AIXなりOS/400だと「ある一線」とかは体感しないんだが。
もしかしてWindowsとかLinux使っておいてトロくなるとか
言っているなら、それを基準に「RDBMSとは・・・」と語るのも
微妙なんだが。
ストレージの劣化の問題もあるし、 ハードウェアのリプレースの時、文字コードの問題もあるだろ。 営業のRDBMSマンセーは異常だと思う。
それはRDB関係なくおきる問題では・・・。
規格どおりのXMLだと起きない問題。
HIbernateは複雑なSQLでもおk 他のもきっとおk
AS/400ってファイルが排他ロックされるからゴミだよな。 オラクルなら同時更新も可能ですよ。
>>239 スレ違いだと思うがAS/400は更新モードでロックしたら排他ロックするは当たり前だが。
Oracleは更新モードでロックして他人からも更新できたらそれこそ異常だと思うが。
ゴミアプリしか作れないロック恐怖症の初心者ゴミプログラマには
その方がいいかもしれんな。
行レベルロックってことじゃね
ロックしているオブジェクトを他のトランザクションから更新する事はオラクルでも出来まい
239は分離レベルとかの存在を知らんだけじゃねーのか? インデックスのないカラムに対して更新モードで全件検索する SQL投げておいて「ファイルがロックする」とかヌカしていると思うんだが。
とりあえず239がAS/400もOracleも理解できてないのはわかった。
まあ、AS/400使いにはCOBOLerの仲間みたいな化石なSEが ゴロゴロしてるからなぁ、アフォな設定のAS/400でもちょっとイジって 挫折したクチじゃね。 だからと言ってOracleマンセーもどーかと思うが。
分離レベルなんて知らない初心者でも 簡単に扱えるOracle最強ということで
MySQLもInno使えばOracleと同じ動作(分離レベル)じゃなかったか? ただ初心者最強を言うならAccessとかODBCなEXCELじゃねーか?
ODBCもEXCELもDBじゃないし Accessでもある程度できるやつじゃないと まともなものは作れない
「まとも」の意味にもよるな
ロックの仕組みや分離レベルもしらんOracle厨が指す「まとも」とか言うんだったら 初心者(?)がADO.NETでアレコレするのと大差ない「まとも」なのが出来るだろ。
251 :
デフォルトの名無しさん :2007/01/28(日) 13:17:16
普段DB使わないので、初歩的な質問なのですが、 継承関係にあるクラスをRDBテーブルへ定義する場合 どうするのが自然なのでしょうか? 一応型の識別子と派生クラスの属性もテーブルに定義しといて、基底クラスの インスタンスの場合、無い属性はNullのまま保存する感じで考えています。 ただ、これだと派生クラスの場合は自然ではありますが、基底クラスにも派生の 情報を持つことになるので、どうなんだろう?と思ってしまいます。
252 :
デフォルトの名無しさん :2007/01/28(日) 13:29:38
JAVA言語のGUIでおかしげなゲームを作りたいんですが、いい案が浮かびません。 誰か参考までに何かないでしょうか?ソース貼付でお願いします。m(__)m
254 :
デフォルトの名無しさん :2007/01/28(日) 14:11:54
>>251 良い記事ですね。ありがとうございます。
この方法は実際の継承関係に当てはめたやり方ですね。やっぱりこっちがしぜんなのでしょうか。
たしかにこのやり方のほうが、設計的には良いと思いますし、スペース的にも
効率的ですね。ただ設計の良さを優先して、実装が複雑になっている感じもあります。検索速度的にも気になる。
まあORマッピングツールとか色々有るみたいなので、自動で
やってくれるから良い。といった感じなのでしょうか。
>>254 その記事は2ページにわたってて、2ページ目にNULLをつかう
>>251 の方法もある。
ケースによって最適解がかわるので選択汁。
256 :
デフォルトの名無しさん :2007/01/28(日) 19:56:06
>>255 次のページも有ったのですね。
とりあえず何か作って見ようと思い、参考図書を買いにいってました。
でRuby on Rails Up and Running(O'Reilly)を買ってきたのですが、ページ数の
割に内容があってなかなか良書です。
この本にちょうどテーブルの"ラッピング"(ORマッピングではない)についても
書かれていましたが、
Railsでは単一テーブル継承を使ってるようです。
っていうか OODB使えってことだろ?
いっこうにOODBが普及しないことが全てを物語ってるだろ
つまりORマッピングも・・・
>>259 ORマッピングはOODBが普及しないからあるんじゃないの?
OODBがRDBより圧倒的に速くなれば使う。
RDBと同程度のパフォーマンスでも十分過ぎる。 ちょっとくらい遅くても普及すると思う。
長年培われた信頼性、性能、安定性、バックアップのしやすさ、接続性、データ検索、操作のしやすさなど外部の永続ストレージとしては申し分ない。 せっかくあるんだからこれをオブジェクトの永続化先にしちまおうぜ? ってのがORマッパだとおもわれ。 しかし、オブジェクトを永続化するって考え方はよくわかるんだが、よくある業務システムって結局帳票の電子化だろ。 抽出した情報のつまらんCRUDユースケースしかねーんだからドメインモデルなんていらなくね? 人がいます。属性は名前、空腹度、疲労度。操作には歩く、食べる、寝るがあります。寝ると疲労が回復します。そして人は永続化されます。 なんて実際の業務システムじゃやらねーよ。 そもそもオブジェクト名に「〇〇情報」って書いてある時点で、データとしかみてないしな。
>>263 単なるExcelの延長線だよね、業務アプリのほとんどって。
二次元の表でほとんどのデータを表せて、
必要なナチュラルキーで結合してやればデータモデル完成。
後はそれのCRUDを用意してやればシステム完成ってことも多くない?
ORマッピングはそう言う典型的な業務システムを構築する際には
大変役に立つと思うんだけど。
ORっていうよりRelation->Objectの方向だね。
R/Oマッピングツールって呼んだ方が正確かも。
今からORACLEの牙城を崩す事はできまい よほど画期的なモンでもなければ・・・・
ヌーヌー教徒「ORマッピング 入りません」
TopLinkはオラクルだよ。EJB3.0のど真ん中食い込んでるジャン。
>>268 今月のDBMagazine見る限り一番良さそうだな
咽返るほどのORACLEの宣伝臭がしたけどw
DBから情報を読み取って、DBにアクセスする部分のJDBCコードあるいはそれを 含むDAOクラスを自動生成してくれるものってないですか? 他の言語では、前に自分で作成したDBアクセスコード生成ツールを使って開発し てますが、JAVAですでに同じようなものがあれば、自分で作らずに済みますので。
>>270 君はどこに来てどのレベルで話をしているんだ?
270です。
現在、Hibernateを使ったりもしてますが、DBの情報がマッピングされたBeanと
>>171 のようなJDBC丸出しの基本的なDBアクセスコードを含むDAOクラスを
自動生成する、単なるコード生成ツールのようなものがあれば使いたいなと思
いまして。「ORマッピングはいらない」スレなんで、代わりになるようなもので、
Hibernateなどに比べてほとんど抽象化されていないものがあればなぁと思って
書いたのですが。なければ自分で作ります。
Hibernate Tool 3.2.0 beta8 beta9a使ってんだけど、突然DBに接続できなくなってしまった 新規のコネクションも作れなくなってしまった なんでだろう?
つまりDBスキーマからのコード生成が出来なくなってもうたって事
Antでやったら解決したからいいや なんかEclipseというかBEA Workshop for JSPがおかしい
270ですが、空いた時間にちょろっとコード自動生成ツールを作ってみた。 俺的にはこれで十分。 ボタンをクリックするだけで、DBのスキーマからJavaBeanとDAOクラスのコード を自動生成するという簡単なものだけど。 DAOは、挿入・更新・削除・検索などの基本コードに加えて、自分が比較的よく 使うメソッドが、JDBC丸出しのコードで作られる。 まあ、かなり原始的だけど、フィールド数が仮に何百あろうとボタンをクリックする だけで必要なフィールド数や型に合わせてコードが一通り自動生成されるから、 1から作るよりはかなり時間の節約になるよ。 細かいことは自動生成されたコードをカスタマイズして作らないといけないけどね。
車輪の再発明乙。
>>277 車輪にすらならんだろ・・・生ゴミ生成機だろ
わざわざレスをつけるほどのもんでもないよ 完全な自己満の世界
280 :
デフォルトの名無しさん :2007/02/07(水) 23:58:29
まあjavaだと車輪の再発明ってことになるけど、c++のプロジェクト とかでは、コード自動生成スクリプトとか良く作ったりするよ。 javaだってそういうケースはあるんじゃない? それに1つのプロジェクトで複数言語使うこと多いし、無駄じゃないだろ。
つかなんだこのすれ
OODBってたとえばJavaならVMと統合されてないとOOの意味なくね? シリアライズして外部プロセスと通信するならRDBとやってることが変わらないわけで。
VMと統合は余計だろ。 っていうかそれっぽいAPI用意してくれれば良いきがするけどな。 近いうちに、今のようなDBじゃなくてネットワークにつながるもの全てが OODBというかオブジェクトで、接続先のクライアントも、クエリーで指定して つながるような分散型のが出てくるんじゃない? 現実的にはCAみたいな物が居て、IP電話なんかと同じだろうけど。 簡単なAPIというかIFがあれば電話やIMなんかはかなり楽に作れるようになる。 まあ標準化がうまくいけばだけど。
PreparedStatementのログは、sqlと?の値が別々になるけど 一緒にしたログを出すことはできないでしょうか? select ? from XXX BBB ↓↓↓↓↓↓↓↓↓↓↓↓ select BBB from XXX
286 :
デフォルトの名無しさん :2007/02/14(水) 16:28:38
もう涙はいらない
289 :
デフォルトの名無しさん :2007/02/14(水) 21:13:53
まぁ
>>1 の気持ちはわかるけど。
だから逆にiBATIS使ったら病み付きになると思う。
今北。 数個のテーブルと簡単な仕様を提示して、各々がアプリを作ってみると O/Rマッパー使う派/使わない派のコードとかいろいろ見えてきておもしろいと思うんだけど どうだろうか。
だからー、ORMはテーブルありきで考えるんじゃないんだって。 何度も言わすな。
っていうか・・・・・(ry
ラスモチセセニミミキナカカイミチミニ・
294 :
デフォルトの名無しさん :2007/02/15(木) 21:51:52
結果セットをDTOのMAPに書き出すくらいの認識だと、いらないという感想にもなるんだろう。 おまいらがORMに無きゃいけないと思ってるプロパティというのはなんだ。
295 :
デフォルトの名無しさん :2007/02/17(土) 14:17:53
話の流れからみればね
いまいちよくわからん。 先にテーブル渡されて、ORM使う派と使わない派がコードを提示しあったら ORM使う派のほうがあきらかに不利だとおもうんだけど。。
単純なCRUD用DAO作るときはORM用のTOOLで自動生成する方が圧倒的に楽
>>299 俺はそのやり方にちょっと懐疑的なんだけど。
ドメインモデルがトランザクションスクリプト・テーブルモジュールと比べて
有利な点ってモデル設計の自由度由来で
オブジェクト指向の恩恵を引き出しやすいことだけでしょ。
なのにテーブル構造に引きずられてモデル構造が決定されてしまったら
複雑さっていうデメリットだけが残るんじゃね?
マッピングコードを書かないってだけで十分メリットあるけど
テーブルモジュールだってマッピングコード不要だけど。
そもそもそういうのをORMっていうんじゃね
ちがうだろ。オブジェクトモデルとリレーショナルモデルのマッピングのことだろ。 インピーダンスミスマッチってやつを解消することそのものがORMであって、 自動化とかそういうのはオマケだろ。
ならテーブルありきだって別にいんじゃねーの? そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
306 :
290 :2007/02/17(土) 21:48:31
俺自身ORMに詳しいわけじゃないが、 スレ読んでても実装の話が出てこないのでイメージが掴めなかったんだよ。 だから実際にコードにしたらよく分かるんじゃないかと思って話を振ってみた。 個人的にはどうやってオブジェクトを切り出すとか、途中でどうやって改良するとかを知りたい。 テーブルありきだろうがそうじゃなかろうが、その辺はあまり重要視してなくて 束縛が仕様だけだと自由度高すぎるかなとおもって制約付けただけ。 ちなみに俺はORMに対しては>304の認識と一緒。
ORMは仕様も限定するからな〜
ORMの実装はそこらに転がってるだろ。まずは自分なりにいろいろ工夫して見なきゃ ここでコードを提示したとしても良さも悪さも伝わらんと思うけどなあ。
>>305 >そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
どういう理屈だよ。
テーブル設計はデータアクセスに最適化されるべき
>>310 全部ORMでやろうとしたり、全部SQL直打ちでやろうと考えるからおかしくなる。
>>310 実際そういった設計少ないけどな・・・
もう疲れたよママン・・・
ORMメリットって何よ っていうか、ここでぎろんされているORMの定義がわからん たとえばHibernateのような実装の事をいっているんか、理論の事をいってるのか わしは理論はいらん 実装は、バインディングツールとして使える
>>313 ん?OOPのメリットがわかれば自明だろ。
それとも、永続データついてはOOPは諦めればいいの?
つか、オブジェクト指向を是として考えることが前提であれば、 理論って言うほど大層なものは無いと思うぞ。 つか、オブジェクト指向イラネなら無条件でORMイラネで正しい。
ならマッピングなんてものではなくOODBしかあるまいw どの道現状では、永続化データのOO化は、メリットより デメリットの方が勝ってしまっているからねぇ
>>316 現状っていつの現状だよ。
5年前だったらあんたの言ってたことで正しかったよ。
ならいまの技術でOODBつくればいいんじゃねーの?w
結局、Objectの定義が言語ごとにずれてる以上、各言語固有のOODBしか作れないだろ。 そしたら、RDBのような可汎用が保てないからダメよな。
保存するものって、オブジェクトが持ってる状態と関連なんじゃないの? それだけなら言語依存しないようにできるように思うけど 言語用のドライバとかで読み込めばインじゃね?
型も一緒にストックできるDBがあったら楽しそうだな。
322 :
デフォルトの名無しさん :2007/02/18(日) 12:39:30
少なくともDBアクセス、オールHibernateは最低な解だろう?
>>311 の言ってることが核心を突いてると思うのだが。
結局、RDBとオブジェクト指向言語の間に
完全なインピーダンスミスマッチの解消を求めること自体が間違っている。
>>つか、オブジェクト指向イラネなら無条件でORMイラネで正しい。
"オブジェクト指向イラネ" な部分をPG内に意図的に設けるのが、結局◎だと思う。
そもそもその部分を隠蔽化する役割もORMapperにはあるんだろうけど、抽象化の漏れがありすぎる。
>>313 の言うようなバインディングツールとしての使い方に押さえるぐらいが、
最終的に一番幸せになれるんじゃないかね。
バインディングツールとして使えば、DBアクセスオールHibernateもありだよ JDBCっぽいつかい方も出来るし、その上問い合わせ結果とのマッピングも やってくれるのはお得だ。
バインディングツールとしてだけに使うならO-Rマッピングでなくてもいい。 もちろんあってもかまわないが、他の選択肢もあるように思う。 たとえばADO.NETは厳密な意味でのORMじゃないんだよね。 あれはR-OマッピングというかXMLスキーマ中立型マッピングというか割と独特な構造をしている。 とにかく何を指して、いるいらないを議論しないと始まらない。
325 :
デフォルトの名無しさん :2007/02/20(火) 20:37:04
じゃぁとりあえず Hibernate for Java といってみる
いらない。学習コスト、ハマリコストに見合うほどの効果は得られない。 SQLチューニングできない。SQLの便利な関数が使えない。
つかえるよー
ネイティブSQLもなげられるし
>>326 >SQLチューニングできない。
Session#createSQLQuery
>SQLの便利な関数が使えない。
org.hibernate.dialectにDB毎の関数を登録しているDialectがあるのでHQLでも使える
330 :
デフォルトの名無しさん :2007/02/21(水) 16:26:23
キャシュ処理の隠蔽とかも考えるとsql直は駄目だろ。 そんなだからゲッティになるんだよ。
ORMいらないといっている奴はOOが理解できないカス野郎wwwwww
>>330 同意。ORMみたいな隠蔽の恩恵はOOLだけが受けるものじゃないと思う。
>>331 だいたいjavaなんてcobol2.0だろ。
コボラとも仲良くやれば良いんじゃね。
>>332 > cobol2.0
エエー
本当にそうならよかったと思うことあるけどさ
>>332 >だいたいjavaなんてcobol2.0だろ。
こんなこという奴にOOわかんのか?
javaをcobol2.0とかいわれた時に OOだの技術面でしか考えられないような 人が使ってるようではやっぱりjavaはcobol2.0。 まあ長い事だらだら食えそうという事でもあるな。
>>334 そういうことじゃないだろ。
視野狭すぎ。
>>335 COBOLを名乗るならもっと帳票作りやすくしてくれ。
>>337 レポーティングツールとしての機能は
SQLに吸収されたと考えてはどうでしょか。
データの整形だけの話だけど。
SQL*Plusの整形機能のことか? あんなキモイもの誰も使わないだろ。
言葉が足らなかったかな。 違いますよ、クロス集計だなんだの話。 みんなSQLでやらないの?
なんで帳票の話してるのに集計の話が出てくるわけ?
帳票に集計はつき物だからだろ?
「このプレート、もうちょっと焼肉がおいしく焼けたらいいのに…」 「俺は最高級の炊飯ジャーを使ってるよ」 「なんで焼肉の話してるのに炊飯ジャーの話が出てくるわけ?」 「焼肉に白いご飯はつき物だからだろ?」
入力チェックリストとか登録データ一覧程度の 帳票しかやった事ない人にはわからん話だよなあ。 俺はCOBOLの事は知らないけど 業務に使う様々な帳票に出力するデータを 作るのに向いてたって読んだ事がある。 WEB+DBプレスかな。その記事はSQLだか RDB絡みの話だったな。>338と主旨は一緒。 その記事読んだんじゃないのかな。
ああでもそもそも337の言ってる意味が 帳票レイアウトを簡単に作れる Accessみたいな環境作れ、てな 意味だったら話がすれちがっちゃってますな。
>>322 Hibernateには一応、独自のSQL構文をサポートしているが
>>338 今なら、EclipseのBIRT
帳票作成はBIRTで決まり!
Hibernateいいな つーかSQL書くの面倒だから1行丸ごとloadする問い合わせばっかりしちゃうw
SQLゴリゴリ書く時代は終わったな
SQLをショリショリ書いたり,カリカリ書いたりする時代に突入したってこと?
ゴリゴリっていうのは既製品組み立てるのではなく素材の加工から始める感覚の比喩。 漏れが最初に使ったつもり。
>漏れが最初 なんというジジイw
スレの趣旨と違うけど、 JDBCかつ全てPreparedStatementってのが最強かなと思ってるんだけど、 上のような簡易なライブラリってないのかな。Dbutilsみたいな感じで。 PreparedStatementは早いし、SQLインジェクション対策してくれるからいい。
例えばHibernateだったら、それプラス結果とクラスインスタンスのバインディングもするからなー ただ、バインダー目的で使うとJDBCのようには逝かない場合があるからなー
>>354 iBATISはどうなん?
S2Daoも結局は結局はPreparedStatementつくるO/Rマッパーだし。
しかし、当たり前だがJDBCよりもちょろっと遅いんだよな。
この辺りは楽してる反動なので仕方ないと思うが。
むしろそこにボトルネックを感じるとはなんと言うクソ設計
JDBC直コーティングはどう考えも最速だろ。 「O/Rマッパー使ったらJDBCより早くなりました」とか言われたら それこそクソコーダー認定だと思うが。
そのは速さの差は、生産効率や保守効率と天秤にかけて それでも十分にメリットがある速さなのかどかって言うのが問題でして・・・
>>359 それすら判らないんだから放っておけばいいんだよ
エンドユーザーには生産効率とか保守効率とかまったく関係ないけどね
あるだろ 生産効率悪けりゃ要件の実現性が低くなるし 製品の安定性だって悪くなるし 保守効率悪けりゃメンテコストかかるし、新機能追加の実現性も低くなる もっともそれを無理やり開発サイドが受け入れてデスマってパターン なのかも知れないけどw
最速を求めるんならストアド作ったほうが何倍も・・・
DBはボトルネックになりやすいし、構成変えにくいから いまいちORに手を出せないってのが俺の困ったところ
気にしなければ いい事あるさ
ちょろっとしたオーバーヘッドぐらいならどうということもないが、 SQLの書き方一つで速度が激変することは良くある。 それ考えると、動的生成に頼るのはちょっと不安があるな。
勝手に作られるのは簡単なのしかないよ どの道複雑なSQLは自分で書くしかなかとね
今はHibernateとかはやってるのかな。 昔あったTorqueはなくなったのかな。ちょっと現場離れると機能レベルの変更についてけないや。 ORだのDIだの、学習コストかかるし、 どういうメリットがあるのかかわからん。 再利用性云々とか、疎結合だの、N階層だの…ほんとに再利用してる? ほんとにメンテナンスコスト上がってる? 生産性あがってる? プロジェクト運営とか、もっと根本的な所を改善しないとこういうのは解決しないのでは。 結局のところ、みんなが知ってるJDBCで十分というのが俺の結論。 Struts1.2とJDBCとTomcat5をみんなが覚えれば、WEB系の奴は幸せになれるんじゃないの。 これ以上はよっぽど革新的な技術が出ない限り、手をつける必要がないのではと。 以上グチでした…
>>369 メンドクサイ・わからない・覚えられないってだけだろ?
君の能力が足りてないだけ
>>370 俺もそう思う。
ついて行けてないだけじゃないか。
生産性・メンテナンス性は格段に上がってるよ。
学習コストとパフォーマンスがトレードオフになるけどな。
>>369 IBM JSF+SDOくらいだとポトペタ(というのか?)でWebアプリが作れる。
単純なのならほとんどコードを書かずに作れる。
おそらくはひとつの理想系だと思う。
かなり革新的だと思うが、誰も話題にしない。w
ポトペタかっこわるいから
生産性、メンテナンス性が上がってるって言うけど、 所謂、定型的な力技作業が省力できるだけであって、 決して大幅なコスト減ってわけではなさそうな気がするけど。 それより、導入することによる学習コストや引継ぎのメンテナンスコストはかかるような 気がする。初期は解決できないエラーとかに悩まされるし。 372が言ってるのは、コードレスのGUIツール?だよね。genexusとか… 開発工程では、それくらい抜本的なものじゃないとコスト減らせないな。 あと、オフショアくらいか。 なんか話が脱線してるな… これにて失礼。
小規模少人数の開発だとポトペタの方が早いし前提や手続きの多いフレームワークは面倒に感じるが、 大規模開発だと分業や保守のために面倒なルールや手順を踏んだほうが全体的な開発効率が上がってる。 この辺がJSFが流行らない理由のように思える。
>大規模開発だと分業や保守のために面倒なルールや手順を踏んだほうが全体的な開発効率が上がってる。 これって、その開発の時だけ効率が上がったような錯覚を受けるんだけどさ、 実際、ポトペタの人海戦術(?)の方が生産性高いんじゃないか?って常々思うんだが。 あとで、そのシステムの拡張や保守・リプレースとかやりだすと、 後任者って大抵元チームよりスキルが下もしくは少人数だったりするんだが、 その面倒ルール&手順を再学習ってコストがバカにならんし。 でJSFのEase-of-Use, Standardization, Device Independenceのアプローチは 正しいと思う。 JSFで簡単に成果物が出来るのは素直にありがたい。 とか言う漏れはJSF+SDO+SpringFramework+iBATISが一番理想だと思っているが。
俺はこれかな。単純明快だし。 (velocity+自作マクロライブラリ)+改造struts+spring+自作DAO
Hibernateや、SpringやSeasar等のDIコンテナは、ポトペタのベースとして使えば使いやすいが、 ポトペタ部分が無いんだよなー Javaで作ると動き悪いからなー
>Javaで作ると・・・・ ポトペタUIの部分の事
今まではJSF敬遠していたけど、NetBeansのVisualWebPackはやってみたくなった 簡単なCRUD処理ならウィザードですぐ作れるし
NetBeansのを実際に使ってみていっているわけじゃないけど、 簡単にウィザードで作れるって言うのは、簡単に作れるものしか 簡単には出来ないんだよねー ソコから一歩飛び出ると結局同じ的な・・・・
つまり意味ねーってことか
>>382 使ったことないだろうから、そういう印象があるのだろうけど、
たとえばJSFだとJSF以上の事は出来ない。
それを指して簡単なのしか出来ないというのなら解らなくも無いが、
「servlet+JSPならこんな事も出来るぜ!」と言う話なら、
フレームワークなんか使うなよ、って話になるから勘弁な。
しかし、平均的(?)なプログラマの技量だとJSFでウィザートつかった方が
servlet+JSPよりも遥かに凝った事が出来ると思うが。
>>385 そうだなぁ。
けど一番恐ろしいのはJSFへの習熟度が低いが為に、
JSFの機能で提供されているものを力技実装をされた
カオスなシステムが出来上がる事だと思うんだ。
うちでも出て間もないフレームワークを採用したプロジェクトは酷いもんだ。
ベストプラクティスを知らないが為に酷い実装になってしまったプロジェクトの多いこと。
漏れはJ2EE5の商用版のJSFがどこまで機能アップしているかしらんけど、 SUNのJSF RIで「JSFはあれくらいしかできん」と誤解されているのかもしれんな。 漏れはIBM JSFの人だけど、カレンダーとかの部品もあるし、 RDBへのアップロードやダウンロードなんかもムチャ簡単に実装できる 拡張コンポーネントとかあったりするので、フレームワークの選択は慎重に、 ってのはあるな。 どのフレームワークでもあることなんだが、フレームワークにない機能を 実装しようと思うと、とたんに面倒&泥臭いコーティングが始まるので、 そういうのが嫌でフレームワークを嫌うヤツはいるかもな。 JDBCでいいじゃん、と言うのもそういうある境界を越えたときの泥臭さが嫌で主張しているんだろうし。
>>369 Strutsは2.0系のほうが学習コストもメンテコストも大幅に下がると思うぜ
別物になってるけど
今はHibernate専用よりJPA汎用で実装をきりかえれるようにしておくのが都合がいい
>>387 JavaEE5だろ?というつっこみはおいといてNetBeansのJSFコンポーネント、
つまりRaveのものだけど、他社と同じくカスタムしまくりで素のコンポーネントは誰も使わんよ
今までだってSwing等GUIコンポーネント使ったアプリも配置だけですらIDE間で互換性はないし
JBuilderは知らないうちに組み込まれるようになってるから、誰でも気がついてると思いたい
だが実際きりかえねーけどな
実際切り替えないけどJPAの実装のほうが技術者集めるのに便利だし ツールのサポートもあるしな
SeasarからSpringって切り替えはあると思うが、Hibernateまでやっちまったら、 切り替えは現実的にない希ガス。 まあ、今後の新規アプリは、ってならJPAで無難だとは思うけど。
>SeasarからSpring・・・・・ 十分非現実的な希ガスw
↓見たいなの書いてんの? @NamedNativeQuery(name="night&area", query="select night.id nid, night.night_duration, " + " night.night_date, area.id aid, night.area_id, area.name " + "from Night night, Area area where night.area_id = area.id", resultSetMapping="joinMapping") @SqlResultSetMapping(name="joinMapping", entities={ @EntityResult(entityClass=org.hibernate.test.annotations.query.Night.class, fields = { @FieldResult(name="id", column="nid"), @FieldResult(name="duration", column="night_duration"), @FieldResult(name="date", column="night_date"), @FieldResult(name="area", column="area_id"), discriminatorColumn="disc" }), @EntityResult(entityClass=org.hibernate.test.annotations.query.Area.class, fields = { @FieldResult(name="id", column="aid"), @FieldResult(name="name", column="name") }) } )
>>393 なにこれ?最近のアノテーションベースのフレームワークってこんなの書かせてるの?
こんなの書くぐらいならまだメソッド内に実装した方がまだ見やすいわwww
>>393 はHibernate Annotationsのドキュメントのコピペ
J2EEだけど、JPAとか色々出てきてはいるが、 正直DAOパターンに特化して、洗練させる方向で開発して欲しい気分。 うちはExcelとかCSVとかもよく使ってのと、 JDBCのが汎用性高いってのがその理由。
J2EEはJPA使えないと思うが
Hibernate EntityManagerつこてるとSQL書くのあほらしくなる
399 :
デフォルトの名無しさん :2007/04/14(土) 00:16:31
俺は永続化ツールそのものを使わなかったりするな。 自分でDAO書いてJDBCごりって終わり。 そら永続化ツールの洗練されたキャッシュ機構に比べたら遅くなるが それがボトルネックになることはまずない。 JPAを否定する気は無いが、トラブルを抱え込みたくない。
S2Dao を Spring向けに書くって言うプロジェクトはちょっと期待している。
O/Rマッピング自体は否定しないけど、Javaの氾濫したフレームワークはやばい。
JPAでトラブル出るか? とりあえずDAOでファサードパターンになってるんだからどうにでもなるしな
>>401 と言っても自前でORMやDIxAOP部分をコーティングしてるワケ?
たぶん、担当者が変わったら「あの自慰野郎」とか言われて恨まれるのがオチな希ガス
勝手にテーブルも作ったりしてくれるのがいい。 情報照会系のアプリにはなんだが、マスター更新系ならウマー
>>404 SQLも発行できるORマッパーを利用して
情報照会はSQLで、編集・更新処理でEntity使いまくると
両者の長所が生かせてウマーだったよ
検索はSQLを駆使できて、更新系ではSQLを一切発行しなくていいからかなり楽
そもそもSQL発行できないO/Rマッパなんてあるか?
SQLを自動生成しない、って意味ならiBATISがソレだな。 xmlファイルに記述するスタイルのO/Rマッパー。
Javaの世界はフレームワークだのコンポーネントだのが氾濫しずぎ。 ただ単に、WEBアプリケーションを作りたいだけでしょ? それなら技術は限りなく絞って、もっと他の事にパワーを注いだ方がいい。 Servletだけで開発してた頃に比べて、顧客に提示する見積もり工数は減ったか? 主にI○Mを主体とした組織だけが、儲かってるだけじゃないのかな。 それに比べてVBはなんとすばらしいことか。クラサバだから目的は違うけどね。 Studioで用意されたものをさえ使えばいい。DB接続にしても、ADO使うのがスタンダードでしょ。 最終的には、Javaも周辺技術が統一されて、VBみたいなGUIライクな、 低レベルな開発に落ち着くような気がする。 Eclipseのような統合開発環境がアプリケーションフレームワークともっと密接に パッケージングされた感じかな。
>>408 フレームワークという名前にふりまわされてるやつ乙
自分が指揮できる立場ならちゃんとした環境用意できるだろ
Servletだけのときに比べて俺は大幅に工数は減ったよ
定型的な処理は任せてロジックだけに集中するのがフレームワークやライブラリというものだよ
VBサイコーでWEBアプリダメってのはまぁ言いたいことはわかるが
細かいことをやろうとするとVBにしろDelphiにしろ苦労してたなぁ
Swingは最初から低レベルライブラリなので同じ感覚で使うとはまる
まだバインディングAPIが標準化されてないからね
密接な連携ならEclipseはあきらめてNetBeansにするがよろし
>>408 藻前は一度IBMのi5(AS/400)のJava+Web開発をやってみろ。
藻間の妄想程度のモノはすでにある。
#開発キットがやたら重いのが難点だが。
>>408 Microsoft製品は一貫した開発環境、手法があるからJavaに比べると生産性が高い
そんな風に思っていた時期が、オレにもありました。
よーし、パパRPG IIIでWebアプリ作っちゃうぞ〜
>>408 VBはよーわからんけど、JUnitみたいなのってマイクロソフトが用意してくれるの?
ソースを変更せずにクラスのロギングとか、トランザクション制御とか出来るの?
>>412 ビジネスロジック部に関しては可能だな。w
Javaから呼び出せるし。
別にクライアントサーバーのソフト需要へってねーしな VBだろうが、何の言語だろうが顧客の望むシステムを高品質に作り上げたもん勝ち 流行ということで入力系をすべてWEBシステムに変えて大幅に生産性を下げた会社をいくつか知ってる もちろん、コストや期間は大幅に増え、誰も得をしないという状態 WEBだと顧客は選択行が色が変わることとか、キーボードでの操作とか要望がどんどん膨らみやすいっぽい 用意されているコンポーネントを使える状況じゃないときの業務アプリでのJavaScript大量の直書きなんてまさに地獄
>別にクライアントサーバーのソフト需要へってねーしな
漏れの周りでは普通に減っている点について
まあ、それまでのC/Sがヘボすぎたってだけだな。
つか
>>414 の周りはヘボエンジニア揃いって事か。
>>414 >顧客の望むシステムを高品質に作り上げたもん勝ち
だったらWebでも作れない事はないだろ。
鬼の様なパンチャーがいるデータエントリー系の処理だったら、そこだけ
>>412 にRPGで入力画面作ってもらえ。VBなんか比にならんほど堅牢で生産性が高い。w
厨房は適材適所で技術を使い分ける事を知らん上に知ったかをするからウザいな。
>>415 WEBアプリになったあとリッチクライアント(いわゆる3層式C/S)に戻してるところは多いけどな
それも含めてのことだ
>>416 適材適所が出来てないのは本当に困る
照会系はWEBでかまわんけど入力系では開発コストが上がることをちゃんと説明しない
マネージャーや営業は死ねよと
>>417 つまり、藻前の周りの案件は最初デタラメなのをワザと納品しておいて
「やっぱアレはダメでしたね」と言い、さらに開発費をボる悪徳ベンダー、って事でFA
営業、開発とバカ揃いの組織でつな。
関係ない話は他所でやれよ
WEBはもう終わりだろ。どう考えても。 っつうか営業とか案件の話はマ板でやれよ。
不利になるとマ板でやれ、ってwww
釣りは「w」をつかうからすぐわかるな
TopLinkって@Entityつけただけじゃエンティティクラスって認めてくれないのか? Hibernateで使ってたHibernate固有のアノテーション使っていないクラスが 動かん・・・
普通に@Entityだけでいいけど?
persistence.xmlにも書かなきゃジャね? 両方書かんと例外が出る。
persistence.xmlは個別記述しても言いし、しなくてもいい
429 :
428 :2007/04/14(土) 21:41:28
ちなみにHibernate EntityManagerはこのまま動くのだ・・・ Hogeクラスを実行してね
430 :
428 :2007/04/14(土) 21:45:31
連投スマソ DBはHSQLで、テーブルやデータはhsqldb\src\org\hsqldb\sampleにあるsampledata.sqlで作ってね
hsqldbならすべてワンパッケージにしてくれんかね DBつくるのめんどくさす
ぱっとみprovider指定がないな
ぽmつけろよ
434 :
428 :2007/04/14(土) 23:44:35
つ
ttp://www.42ch.net/UploaderSmall/cgi-bin/../source/1176561351.zip 解凍してhsql.batを実行すれば、java.exeへのパスが通っていれば動くはず
で、Hogeクラスを実行すると、↓の例外が出る。
Exception in thread "main" java.lang.IllegalArgumentException: Unknown entity bean class: class test.Customer, please verify that this class has been marked with the @Entity annotation.
at oracle.toplink.essentials.internal.ejb.cmp3.base.EntityManagerImpl.findInternal(EntityManagerImpl.java:291)
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerImpl.find(EntityManagerImpl.java:133)
at test.Hoge.main(Hoge.java:17)
435 :
428 :2007/04/14(土) 23:48:02
Hibernateの実行結果 〜Hibernateのログは省略〜 test.Invoice@15e3dc4 test.Customer@1aa5882 test.Invoice@2942da test.Customer@1aa5882 test.Invoice@e3fd79 test.Customer@1aa5882
437 :
428 :2007/04/15(日) 00:15:36
>>436 だよねー
ちなみに
>>426 はオレなんだけどねw
で、persistence.xmlのコメントをはずして<class>も<provider>も
ある状態にしても例外発生。
Customerに@OneToManyが付いてるのがイカンらしいがなんで?
Internal Exception: Exception [TOPLINK-7160] (Oracle TopLink Essentials - 2.0 (Build b41-beta2 (03/30/2007))):
oracle.toplink.essentials.exceptions.ValidationException
Exception Description:
@OneToMany for attribute name [invoice] in entity class [class test.Customer] should not have @JoinColumn(s) specified.
In the case where the @OneToMany is not mapped by another entity (that is, it is the owning side and is uni-directional),
it should specify (optional through defaulting) a @JoinTable.
at oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.predeploy(EntityManagerSetupImpl.java:615)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.callPredeploy(JavaSECMPInitializer.java:146)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initPersistenceUnits(JavaSECMPInitializer.java:226)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initialize(JavaSECMPInitializer.java:242)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.initializeFromMain(JavaSECMPInitializer.java:278)
at oracle.toplink.essentials.internal.ejb.cmp3.JavaSECMPInitializer.getJavaSECMPInitializer(JavaSECMPInitializer.java:81)
at oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createEntityManagerFactory(EntityManagerFactoryProvider.java:119)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83)
at javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60)
at test.Hoge.main(Hoge.java:15)
438 :
428 :2007/04/15(日) 00:29:34
Customerクラスの@OneToManyを↓のようにして、@JoinColumnを削除したら、TopLinkでもHibernateでも動きました♪ お騒がせしました @OneToMany(mappedBy="customer")
ソース見てみたがEntity定義おかしくね? 自前で一から実装してミス犯すくらいならNetBeansですべて自動生成させたほうがよさそうだが
TopLinkめんどいな Hibernateでいーや
EclipseのHibernate Toolsプラグインか、NetBeansで自動生成させてから 好きな形に手を入れていく方法がお勧め。 とりあえず関連定義の失敗で動かないってことはなくなるからな
hibernateはデタッチがめんどくせ Toplinkのほうがはるかに上だな
Toplinkってoracleから情報提供されてどっかに取り込まれるんでしょ?
今はGlassfishで使われてるし、リファレンス実装になってる。 同じようにServletのリファレンス実装がオープンソースになってTomcatになったのを考えると かなり影響はあるだろうね。 今のところJavaEEはGlassfish一人がち状態ってのもある もちろん、JavaSEからも使えるようになってるのでGlassfishの上でhibernate使ってもいいけど
>>444 そだったdd
hibernateとToplinkのいいトコ鳥になるって話だった希ガス
JBossもGeronimoも、JavaEE5フル対応に関しては出遅れてるな JSF1.2の実装がGlassFishでデフォルトになりつつあるのも大きい ORマッパー単独で比べるとHibernateの方が多機能だけど、 TopLinkがGlassFishに載ってるというのは大きいな
これでNetBeansの巻き返しがあるのだろうか・・・
去年の時点でEclipseを越えたとオライリーは思ってるようだな。 そういやJBOSSもJSF実装をglassfishのに切り替えたんだっけ。 BEAもやっとJavaEE5だしてきたし、これから加速しそうだ。 肝心のSunが商用JavaEE5鯖が遅れてるのが気になる。 プラットフォーム版はすごい早かったのに。 あとglasshfishがすごい軽いってのも開発者には朗報だな。 10秒以内に起動するEE鯖ってあまりない。
つかJavaEEいるのかよ? JSFもEJBもJPAもJAX-WSもその他諸々もオレにはいらないんだぜ?
サーブレットはいるだろ。
俺は逆に、今回初めてJavaEEを普通に使ってみたいと思ったな いい加減、竹の子のように出てくる非標準のフレームワークを 組み合わせ続けるのにも疲れてきた
サーブレット/JSP、JSF、JPA、JAX-WS、EJB 標準APIは開発環境が整備されやすいってのも大きいねぇ いろいろと選べたりするし
てかカスタムタグの作り方知らずに今まで来た俺に引いた。 POHP系にWicket使う程度にとどめておくか。可能なら。
いいぞ その調子だ
456 :
デフォルトの名無しさん :2007/05/06(日) 16:15:07
toplinkあげ
457 :
デフォルトの名無しさん :2007/05/07(月) 21:58:35
hibernateあげ
glassfishさげ
459 :
デフォルトの名無しさん :2007/05/08(火) 21:07:49
OpenJPAage
他には?
iBATISsage
ActiveRecord最強
結局JavaならJPAだけでお手軽開発でいいのな・・・
自作JPA実装あげ
EJB2でエンティテイビーン使うならHibernateとか使ったほうが120倍くらいましなんだが・・・・
そもそもO/Rマッピングってオブジェクトの保存先としてリレーショナルデータベースを使えるようにするものだったのに すでに構築されてるデータベースにたいしてO/Rマッピングしようとするヤシばかりだから話がややこしくなってるんだな
Hibernate使うよりJPA汎用のほうが100倍ましなんだが
JPA汎用ってつまりHibernateやらToplinkやらをJPAの仕様の範囲内で使うってこと?
まさかJPAってライブラリが存在すると思っているのな・・・?
hibernate=JPAじゃねーだろ hibernateEntityManagerいれてはじめてそういう動きになる 実際はToplink以外のJPA実装はクソだけどな
>>466 はJPAについての言及は何もしていない件
>>466 はまたHibernateについても「Hibernateとか」といって、Hibernateに限定しているわけでもない件
そして、その事が理解できない厨が存在する件
むしろおまいさんが(ry
同じ事なんですけど・・・・
意味がわからん・・・?
>>468 はHibernateとばっちり書いてますけど・・・?
>>468 の内容が意味不明という話の最中に「
>>466 はこう言ってるんだ」とか言われても意味不明だし
その指摘に対して「同じことなんですけど」とだけ返されたってますます意味不明なわけで
さ ORマッピングの話を や ら な い か ?
既に構築済みのデータベースに対して必死にO/Rマッピングしようとするのは馬鹿だと思います
そんなこと無いと思います。
日本語を理解できない香具師らとORマッピングの話はできん
構築済のDBにO/Rマッピングするのは別に普通 構築済のアプリに導入しようとすると苦労するだけ 新規アプリが望ましいね
Hibernateはマニュアル読むのがめんどくさくて使ってない iBatisのが直感的だと思うのは、単に俺がレガシーなだけかな
dynamicとか面倒なのがなければいいんだけれどもね JPAだとセットされたカラムのみupdateされる
学習コストがかかるくせにいつ廃れるかわかんないからいらない
そこでJDBCですよ。
人 (_ ) (__) JDBC