ORマッピングはいらない

このエントリーをはてなブックマークに追加
1デフォルトの名無しさん
あんなもん、レスポンス悪くなるだけ。
SQL直書きがいいに決まってる。
2デフォルトの名無しさん:2006/06/22(木) 12:03:52
まあ、同意だな。

複雑なSQLに対処できないし、
簡単なSQLならORマッピング使うまでも無い。
パフォーマンスを考慮したら、邪魔になること間違いない。

コードなかなくても、定義ファイルを作らなきゃいけないから
結局、何も楽にならないし。

データベースのフィールドの値を変数に代入する、
またはその逆の関数程度があれば十分。
3デフォルトの名無しさん:2006/06/22(木) 15:30:38
ORマッピングを使うメリットってなんでしょう?
4デフォルトの名無しさん:2006/06/22(木) 16:54:53
1. SQLを直書きしなくていい。直書きしないメリットは省略。
2. DBの存在を意識せず、オブジェクトのことだけ考えればいい。

けど現実には>>2が言ってるみたいなことになったりもする。
俺自身はORマッパの是非は要件と使い方によると思うので、いるともいらないとも断言できない。
5デフォルトの名無しさん:2006/06/22(木) 17:34:42
必要になるシチュエーションってあんの?
6デフォルトの名無しさん:2006/06/22(木) 17:35:12
UPDATEやINSERTもORマッピングって対応してんの?
7デフォルトの名無しさん:2006/06/22(木) 17:43:56
UPDATEやINSERTには対応しているが、
ちょっと複雑なJOINには対応していないことが多い。

複雑なSQLかかないのなら、直で書いても手間じゃない。
8デフォルトの名無しさん:2006/06/22(木) 23:59:45
Commons DbUtilあたりがちょうどいいなぁ。
中で何やってるか丸わかりで安心だし、
SQL直接指定できて、検索結果はBeanで返ってくる。
コンバータ書けばO-R任意のマッピングもできる。

ただ、リフレクション使うから遅い。
大規模やパフォーマンスにシビアなシステムでは使えない。
9デフォルトの名無しさん:2006/06/23(金) 00:44:49
オブジェクトにマッピングするなら、
本格的にオブジェクトにしてくれよ。

たとえば継承やメソッドまで使えるようにする。
10デフォルトの名無しさん:2006/06/23(金) 00:57:34
>>9
何を言いたいのか。わけわからん。
11デフォルトの名無しさん:2006/06/23(金) 01:01:42
以前どこかのスレでMap最強厨が異常に叩かれていたが、俺は結構Mapもアリだと思う。
最近はDIと絡めて、色々自動生成したりリフレクションに頼ったりしてるが、
トランザクションの最初と最後を強制的に決めてしまう
クロージャや内部クラスのような使い方さえ躾けとけばいいと思う。
12デフォルトの名無しさん:2006/06/23(金) 01:37:45
ORMつーより、むしろドメインモデルが何の役に立つのか
分かって無いって感じだな。
13デフォルトの名無しさん:2006/06/23(金) 09:48:14
マスメンみたいな簡単なのは
マッパー使って
帳票とかはSQL書きたい。
てなことでS2Daoがしっくりきた。
14デフォルトの名無しさん:2006/06/24(土) 14:29:20
はげどう。両方使えるのがいいよな。
15デフォルトの名無しさん:2006/06/24(土) 14:31:55
すまん、あげてしまった。

というか、複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ?
8割9割は簡単なSQLですんで、1割くらいはちょっと複雑になることがある。
それを考えると、すべてをSQL直書きは面倒くさい。
ORマッパーで楽できるところは楽して、SQL手書きでがしがしやりたいところは手書きでやるのがいちばん。
16デフォルトの名無しさん:2006/06/24(土) 15:14:17
簡単だが、手間のかかるところを
ORマッピングするわけだが、
どういうこっちゃ?
はぁ?
17デフォルトの名無しさん:2006/06/24(土) 15:30:12
>>16
フィールドが200〜300あるのを毎回打ち込むのマンドクセ
18デフォルトの名無しさん:2006/06/24(土) 15:55:34
フィールドが三桁もあるのはどっかおかしいのではないかと
思うのは俺だけか?
19デフォルトの名無しさん:2006/06/24(土) 15:56:37
訂正:
×: フィールドが三桁も
○: フィールドの個数が三桁も
20デフォルトの名無しさん:2006/06/24(土) 15:58:35
書いてから200は多いなと思った
2〜3って読んどいて
21デフォルトの名無しさん:2006/06/24(土) 16:04:50
Hibernateしか使ったことないけど、HibernateはSessionから
JDBCのコネクションオブジェクト取れるしね。
ってことは、Hibernate使うときは素のSQL書かせないようには
当然してないと。

Mapに詰めるのは、メンバーが合意してるんだったらいいんじゃね?
って思う。漏れはHibernate使う人だから進んでは合意しない。
getter,setterがあると、eclipseでコード補完効くから、楽だしな。

あと、オブジェクト指向かDB指向かと言われたら、間違いなくDB指向だ。
まあHibernateのObjectの永続化の考えに反するかもしれないが、
RDBには、RDBなりの設計が重要だと考えてるから。
いつなんどき、変態DB屋が現れるかわからんしなw 
22デフォルトの名無しさん:2006/06/24(土) 16:09:25
ちょっと屁理屈かもしれんけど、
オブジェクトを使う以上は、フルSQLであろうとなんだろうと、
何らかのORマッピングをやってるわけで、
>>1 の言ってる話は、
なんらかのORマッピングフレームワークによる(半)自動化が、
必要かどうか、という話なんでないの?
23デフォルトの名無しさん:2006/06/24(土) 16:25:15
まぁ世の中には流行っているって理由だけで、バッチ処理にORマッピング使う馬鹿がいるからな〜
24デフォルトの名無しさん:2006/06/24(土) 16:29:34
    ?
   ∧∧
   (,,゚Д゚)
  /  |
〜OUUつ
25デフォルトの名無しさん:2006/06/24(土) 16:58:17
seaserの作者がspringとベンチマーク比較を載せてるけど
結局どっちも遅いな
26デフォルトの名無しさん:2006/06/24(土) 17:44:36
>>25
それがORマッピングと何か関係が?
27デフォルトの名無しさん:2006/06/26(月) 13:26:32
>>15
>複雑なSQLが書きたい場面って、あんまり多くないとおもうのだがどうよ?

そっかなー、帳票にしろ、更新にしろ単純なSQLはあんまり無いけどなー。
特に更新系のSQLは WHERE を見れば仕様が分かるから
ORマッピング使ってダラダラ書かれると後からおっかけにくい。。
28デフォルトの名無しさん:2006/06/27(火) 13:04:08
それは1回のSQL呼び出しですべてを完了させようとするから。
たしかにパフォーマンス考えるとそっちがいいに決まってるんだけど、
パフォーマンス的にシビアでない場合なら簡単なSQLを数回発行するほうが
プログラムが簡単になる。
29デフォルトの名無しさん:2006/06/27(火) 15:05:42
UPDATE 売上
SET 請求フラグ = 1
WHERE 売上日 = NOW

みたいなのは

if (obj.UriageDate == Now) {
  obj.SeikyuFlag = 1;
}

これを対象件数分繰り返すの?
30デフォルトの名無しさん:2006/06/27(火) 15:47:19
売り上げアクセス dao = コンテナのDAOビルダ.create( 売り上げアクセス.class );
dao.set請求フラグofToday( 1 );

みたいな感じジャマイカ

31デフォルトの名無しさん:2006/06/27(火) 17:23:54
更新対象が画面で選択されたものの場合とかどうすんの?
32デフォルトの名無しさん:2006/06/27(火) 19:02:08
>>31
対応するインスタンスの状態が変わる→任意のタイミングでDBに反映
って感じかな?俺は元はDB屋なんだけど、ORマッピングに関しては、オブジェクト寄り。
上に出てる多量の行を一気に更新する、ってのはORマッピングに対する反論としてよく出るけど、
オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケースなわけ。
だからSQL直書きでもいいし、ストアドキックでもいいと思ってる。その間、インスタンスは使いづらく
なるけどね。
33デフォルトの名無しさん:2006/06/27(火) 21:21:42
mysql+hibernateでトランザクションがロールバックできないってホント?

空気嫁って?
34デフォルトの名無しさん:2006/06/28(水) 00:17:57
mysqlってトランザクションサポートしてるの一部のテーブルタイプだけだろ?
35デフォルトの名無しさん:2006/06/28(水) 00:52:53
        /つ_∧
  /つ_,∧ 〈( ゚д゚)
  |( ゚д゚) ヽ ⊂ニ)  エェ ── ッ !?
  ヽ__と/ ̄ ̄ ̄/ |
   ̄\/___/ ̄ ̄
36デフォルトの名無しさん:2006/06/28(水) 10:02:49
>>35の反応が気になって調べてみた。やっぱInnoDB指定しないと駄目よね。
多分、InnoDB指定しないで「使えねぇ」って言ってるアホと思われ
37デフォルトの名無しさん:2006/06/28(水) 15:51:25
>オブジェクト(クラス・インスタンス)のほうから設計をすると、そういうのは例外ケース

まじで??
38デフォルトの名無しさん:2006/06/28(水) 19:29:49
まぁ、業務から設計すると帳票とかのデータ構造がまず先に来るから、
仕事では「オブジェクト(クラス・インスタンス)のほうから設計」するのが
まず例外ケースだと思うけどね。
39デフォルトの名無しさん:2006/06/28(水) 19:32:11
SQLの代替、進化版じゃなくて、オブジェクトの永続化にDB製品使ってるって話だからさ
SQLとORマッピングの比較じゃなくて、プレーンなファイルを使った場合とDB使った場合での
オブジェクトの永続化のやりやすさ、ってとこを考えないといけない
4032:2006/06/28(水) 19:38:46
>>37
たまたま見たのでレス。
マジだよ。ただ、前提条件があるんだが、そこには触れていなかった。

・多量データの更新というのは、データをひとかたまりに見ていれば当然でてくるだろうけど。
 多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
 てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
 する人は、無意識に「データベース」が頭にあるんだと思う。
・で、メンテナンス以外での一括更新ですが、これは単純にはあるクラスで集約するという
 概念になります。データへの変更はなし、ただし特定クラスのインスタンスで集約されている
 状態になる。
・集計などは夜間バッチで集計表に移したり、ストアドプロシージャを利用します。
 得られた結果は元の表とは別のオブジェクトと考えればいい。

抽象的過ぎて、非現実的と思われるでしょうが、データベースにアクセスするんじゃなくて、
あくまでもインスタンスを永続的にストレージに保持する必要があって、たまたまデータベースを
利用するに過ぎないって観点です。そしてデータベースの中で済む処理はすべてお任せ。

上にも書いたけど、クラス・オブジェクト設計して、多量のインスタンスを変更するなんて、
お粗末な設計でしょ。一括ってことは、そこに関連性と法則性があるんだから。

って、いっぱい反論あるんだろうな…繰り返しになりますが、自分はSQL直書きでもストアドでもいいって
立場です。むしろそうやることでドメインモデルから距離を置いたほうがいいよねーって感じ。
41デフォルトの名無しさん:2006/06/28(水) 20:14:02
まあ
UPDATE 売上
SET 請求フラグ = 1
WHERE 売上日 = NOW

みたいのは、「請求(乃至イベント)」クラスに1レコード当日日付持たす、でいいわ
日別状態クラスの当日ステータス更新ってかたちでもいい
42デフォルトの名無しさん:2006/06/29(木) 10:46:33
データ更新用オブジェクトを作ればいいじゃないか
43デフォルトの名無しさん:2006/06/29(木) 17:43:38
意味がわからんが、部分集合に対するupdate文を発行するオブジェクトって意味だとすると、
メモリ上の各レコードのインスタンスとの整合性保持するのが困難
44デフォルトの名無しさん:2006/06/29(木) 19:17:29
データを大量にインスタンスとして持とうとすると、一挙にややこしくなるねえ。
45デフォルトの名無しさん:2006/06/29(木) 22:37:48
>>38
帳票とかのデータ構造が先に来るってのは、
DB屋の設計手法としても間違ってると思うのだが。

Sヨお得意の画面/帳票まんまな糞DBじゃんw
46デフォルトの名無しさん:2006/06/30(金) 01:59:28
帳票(現在)→DBエンティティ→帳票(改修)
47デフォルトの名無しさん:2006/07/01(土) 21:58:23
>>29
>これを対象件数分繰り返すの?
ORマッピングだけをつかうなら、そういうことになる。
あとはdeleteのときも、件数分delete文を発行する。
もちろんこれは効率が悪いけど、それで速度的に問題ない場面ならORマッピングをそのまま使う。
問題ある場合だけSQLをがしがし書く。
だからORマッピングだけで完結させるのは難しいし、そんなことにはこだわらないほうがいい。

>>40
>多数のインスタンスという観点で見れば、それに一緒くたに変更をかけるのは、何か間違っ
>てるでしょ?データベースなしと考えてみて。そういうクラス設計には絶対にしないはず。
そんなばかな。業務システムではしょっちゅうあるけど。なぜこんなことを言い切れるのか不思議。
48デフォルトの名無しさん:2006/07/02(日) 09:55:24
とりあえずHibernate+Springは俺には無理だったな
セッションやらキャッシュやら自動トランザクションやら訳判らんし、データ更新してもTomcat再起動すると元に戻ってたりと、
ORマッパーが裏で何やっているか完全に把握している人間がいないとダメだわ

まぁ俺が不勉強なだけだけど、
普通にJDBC直書きでトランザクション制御はTemplateMethodパターンの方が遥かにわかりやすかった
49デフォルトの名無しさん:2006/07/02(日) 10:21:17
>まぁ俺が不勉強なだけだけど、
自分でわかってんじゃん。
新しい物を覚える能力に欠けていると自覚するなら
この業界でやっていくのは難しいよ。
オブジェクト指向が理解できないCOBOLオヤジと一緒。
早く別の道を探した方が良さそうだね。

50デフォルトの名無しさん:2006/07/02(日) 10:38:46
>>48
そんなあなたにS2DAOをお勧めする
設定ファイルもシンプルで簡単だし、サンプルもわかりやすくてマジ最高
51デフォルトの名無しさん:2006/07/02(日) 11:33:46
結論:ORマッピングはいらないと言っている連中はオブジェクト指向が理解できないCOBOLオヤジと一緒。
52デフォルトの名無しさん:2006/07/02(日) 14:04:16
select * from table
でとってきた奴はO/Rマッピングオブジェクトに入れた方が
その後ガシャガシャやるのに便利じゃないか。
ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
全カラムupdateするのは嫌だな。
うっかり変更する必要がないプロパティ変更しちゃってたら大変だ。
なのでupdateは、必要なカラムだけupdateするSQL呼び出しをDAOを作る。
53デフォルトの名無しさん:2006/07/02(日) 14:14:27
>>52
>ただHibernateみたいにupdateでO/Rマッピングオブジェクト渡して
>全カラムupdateするのは嫌だな。

無知。使いこなせていない奴が文句言うな。
54デフォルトの名無しさん:2006/07/02(日) 14:28:56
>>53
一生懸命勉強しないと使いこなせないものってダメだと思う、Hibernateがそうなのかどうかは
別として。
55デフォルトの名無しさん:2006/07/02(日) 14:34:44
>>54
ダメなものかどうかを自分で決められるのなら、そう言ってろ。
おまい自身が「一生懸命勉強しないと」と感じるかどうかが基準か?

ダメだどうのと言っている奴がダメだ。
この仕事をしている限り、デファクトスタンダードは避けて通れないんだよ。
56デフォルトの名無しさん:2006/07/02(日) 14:39:09
今から勉強するとしたらejb3かねぇ
57デフォルトの名無しさん:2006/07/02(日) 14:45:19
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を使えばいい
5854:2006/07/02(日) 16:16:29
>>55
いやー、おまいみたいな優秀な奴だけを集めてプロジェクトを進めるのが難しいという現実がある以上、
一生懸命勉強しなくても使えるものを採用しないとダメだと思うけどねぇ。

ダメだどうのと言っている奴がダメなのは同意するけど、だからといってそういう奴でも
開発メンバーに加えざるをえない状況もあるわけで。
ところでHibernateはO/Rマッピングのデファクトとまでいっちゃっていいものなんですかね?
59デフォルトの名無しさん:2006/07/02(日) 16:35:10
>>58
>>55が優秀かどうかもわからないのに、口だけ調子いいこと言ってる奴もダメだな。
メンバー全員がHibernateに精通していないと、という前提になっているところもダメ。
設計やフレームワークの使い方を間違っている可能性大。
60デフォルトの名無しさん:2006/07/02(日) 19:31:55
全員がHibernateに精通している必要なんてないだろ。
一人だけ詳しい奴がいれば、あとの連中の生産性を最大化することが
できる。
むしろそれがORMの最大の狙いで、SQLを使ったやり方だと、メンバー
全員がDB設計SQL設計に精通している必要が出てくる。
61デフォルトの名無しさん:2006/07/02(日) 21:11:10
>>59
「優秀かどうかもわからないのに、口だけ調子いいこと言ってる」
ただのイヤミだろ。

「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。
62デフォルトの名無しさん:2006/07/02(日) 21:26:59
>>61
>「メンバー全員がHibernateに精通していないと」という前提をしてないからこそ
>「一生懸命勉強しないと使いこなせないものってダメだと思う」という書き込みがあるわけだが。

矛盾してないか?

メンバー全員がHibernateに精通していることが前提でなければ、
メンバーの一部に使いこなせる奴がいれば充分だろ?
メンバー全員が>>55みたいに優秀な奴である必要はないんだよ。
63デフォルトの名無しさん:2006/07/03(月) 00:27:25
この先生きのるのはEJB3.0、Hibernate、S2Daoどれ?
64デフォルトの名無しさん:2006/07/03(月) 00:32:20
HibernateはJPAに対応したし、S2DaoもJPAに対応する(Kuina)予定らしい
65デフォルトの名無しさん:2006/07/04(火) 13:24:50
O/R マッピングを有難がる奴ってのは
>>52
>select * from table
こんなのばっかりなのか?
66デフォルトの名無しさん:2006/07/05(水) 01:13:27
シンプルが一番
67デフォルトの名無しさん:2006/07/08(土) 01:01:09
シンプルってよく言うけど、どういう状態がシンプルなのか
理解している奴は少ない。

シンプルに実装しました、とかベタで書きましたとかいって
for文の5段ネストとかそんな感じのソースが出てくる。
68デフォルトの名無しさん:2006/07/08(土) 16:41:11
ORマッピングって今いち楽だねって実感が無いね。
楽するためにプログラミングしてるはずなのに、全然楽じゃない。

XMLなんて醜くて遅くなるだけだし。

一人の詳しい香具師が居ればいいってのもいまいち。
その一人が逃亡した時点で終わるし、その一人の給料だけ高くすると不満が出るし、他がやる気無くすし、その一人のために他の香具師が低い賃金でこき使われることに成る。
詳しくなくても簡単に使えるORマッパが求められてると思う。
69デフォルトの名無しさん:2006/07/08(土) 16:52:19
>>68
使ってみたORマッパーとその問題点を具体的にきぼん。
> XMLなんて醜くて遅くなるだけだし。
だけでは根拠が弱い(XMLを使うと遅くなるわけではないので)。
70デフォルトの名無しさん:2006/07/08(土) 17:32:22
XML に何の関係が?
71デフォルトの名無しさん:2006/07/08(土) 17:38:47
XMLを使用しないとなるとRoRのActiveRecordとか?

この辺りは使ったことないけど、どうなんだろう?
72デフォルトの名無しさん:2006/07/08(土) 20:40:12
書き方が変わるだけで楽にはならない。
73デフォルトの名無しさん:2006/07/08(土) 20:45:29
XMLのマッピングファイルで遅くなるってのは
実装速度じゃなくて開発効率の話しかな?

マッピングファイルを手書きしていたらORMのメリットはかなり低下するだろうな。
ここは、現実的にはMiddlegenとかXDocletを使って自動生成する部分だろう。

手書きめんどくさいと言っている人は雑誌やWebのサンプルに沿って
ちょっとモノを作ってみただけで判断してないか?

>>68 はフレームワークの使い方やプロジェクトでの役割分担を根本的にわかっていない希ガス
74デフォルトの名無しさん:2006/07/10(月) 00:39:47
ORMのメリットがわかんねー云々以前に、ドメインモデルを使ってるかどうかを
問いたい。
75デフォルトの名無しさん:2006/07/11(火) 23:41:51
おれ、ドメインモデルがよくわかんねぇ。

いっつも

http://(domain)/hogehoge/mogemoge.jpg

↑の意味のドメインが頭に浮かんできて、何の事やらサッパリわからんくなる。
76デフォルトの名無しさん:2006/07/12(水) 06:39:49
http://(domain)/

↑これ自体間違いだしな
77デフォルトの名無しさん:2006/07/14(金) 01:15:07
解説頼む
78デフォルトの名無しさん:2006/07/14(金) 13:39:42
http://

↑これ自体間違いだしな
79デフォルトの名無しさん:2006/07/14(金) 22:38:17
じゃ
mailto:sage@(domain)
ってのは?
80デフォルトの名無しさん:2006/07/15(土) 09:25:47
おまえ、もしかして知ったかしてねぇ?>>76,>>78
どうなんだよ、オラオラ
81デフォルトの名無しさん:2006/07/15(土) 09:35:52
http://(domain)/
については、間違いだとは判るが
http:// 自体のどこが間違っているのかは俺には判らん。

http://www.yahoo.co.jp/ の場合、
インターネットドメインは yahoo.co.jp であって www.yahoo.co.jp ではない。
http://203.216.247.249/ だったらインターネットドメインはどこにも含まれない。
82デフォルトの名無しさん:2006/07/15(土) 09:36:44
つまり、 http://(domain)/ の(domain)はドメインではなく、ホストを表す文字列だということ。
83デフォルトの名無しさん:2006/07/15(土) 09:50:55
ホストを表す文字列に (domain) というのはおかしいという話では?
84デフォルトの名無しさん:2006/07/15(土) 11:01:55
OK,(host)と(domain)の違いはなんとなくわかった。
(host)からwww1とかwwwとか、ftpを取り除けば(domain)になるってことだな。

で、結局、ドメインモデルと(domain)では、ドメインって別のものを指してるよな?

そこら辺がおれにはよく分からんのだよ。

では、そこを起点に議論の再開を求む。
85デフォルトの名無しさん:2006/07/15(土) 11:15:15
domainといっても色々種類があるが、最も一般的なのは
代数的かつ整合完備な半順序集合bcdomだろう。
bcdomは関数構成子に関して閉じており、圏としてみた場合
cccをなす
86デフォルトの名無しさん:2006/07/15(土) 11:32:59
ドメインというのは大雑把に言って(何かで区切られた)「領域」。
DNS におけるドメインというのは、ネットワークにおける(管理上)の「領域」、
企業や部門などの管理者が置かれる単位。

データモデリングにおけるドメインは、データにおける「領域」、
つまり、対象領域とする業務やアプリケーションに含まれる(モデル化すべき)
データの集合、ないし、データが存在する対象領域そのもの。
87デフォルトの名無しさん:2006/07/17(月) 04:05:39
まずは英和辞書を引いてから
考えてみようって話だな。

カタカナでドメインだと確かに
この業界、初学者にはまぎらわしいですな。
8887:2006/07/17(月) 04:22:52
それと、「領域」ってのも間違いじゃないんだろうけど
どうも物理的な場所のイメージが強くてよくわからん。
「問題領域」なんて訳がよく使われるけど、
なんか頑張って考えたのが伝わってきちゃっていかん。

「うちはA社とはドメインが違うから競合しません」
みたいな言い方もよく聞く。

そうすると、「業界」みたいな意味もあるように思える。
正確には粒度はもっと小さいんだろうけど。

てことは、ドメインモデルって
「業界用語」って事でいいんじゃないの?
ただの業界用語集ってだけでなく、
構造まで表現したもの、てなかんじ。

寝ようと思って布団に入ったら思いついたから
また書いた。

89デフォルトの名無しさん:2006/07/17(月) 10:17:57
縄張り
90デフォルトの名無しさん:2006/07/17(月) 10:40:47
>ドメインモデルって「業界用語」って事でいいんじゃないの?

ちがうだろ。
9187:2006/07/17(月) 16:46:27
うーんやっぱちがうか。
92デフォルトの名無しさん:2006/07/17(月) 17:31:01
普通に、解決しようとしている対象をちゃんとモデル化しているかってことだろ
ドメインという言葉よりモデルの中身の方が大事だよね
93デフォルトの名無しさん:2006/07/18(火) 13:57:23
もう、メンドイ
94デフォルトの名無しさん:2006/07/18(火) 15:38:56
恕面モデル
95デフォルトの名無しさん:2006/07/18(火) 23:36:57
>>93
もちょっとふんばってイドメ
96デフォルトの名無しさん:2006/07/18(火) 23:42:04
ドメインメンドイイドメンってことか、やるねぇ
97デフォルトの名無しさん:2006/07/19(水) 02:17:55
メイドインドメイン
98デフォルトの名無しさん:2006/07/19(水) 10:27:12
>>97
これがトドメだな
99デフォルトの名無しさん:2006/07/19(水) 11:10:26
メイドインインド
100デフォルトの名無しさん:2006/07/28(金) 19:08:27
なんかよくわからんが
O/Rマッピングに妙に肩入れしてるのはJAVA界隈の人だけだと言うことは分かった。
101デフォルトの名無しさん:2006/07/29(土) 14:29:49
まあ、毎回スキーマーとプログラムを見比べて、
SELECT 文の出力を、変数に代入するコードを書くことを

「あたりまえ」

だと思って何の不満も感じてないなら、 OR マッピングなんて必要ないわな。
102デフォルトの名無しさん:2006/07/29(土) 22:45:35
ORマッピングは
SELECT文の出力を変数に代入するコードを書かなくてもいい代わりに、
SELECT文の出力を変数に代入する設定ファイルを書かなくてはいけない。
本質的には何も変わらない。
103デフォルトの名無しさん:2006/07/29(土) 22:57:44
>>102
設定ファイルを手書きするバカなんていないけどな。
104デフォルトの名無しさん:2006/07/29(土) 23:11:59
class Hoge < ActiveRecord::Base
end

で完了だけどな
105デフォルトの名無しさん:2006/07/31(月) 09:45:01
外部結合と抽出条件、グループ化を伴うちょいと複雑なSQLと、O/Rマッピングで
それと同等のSQLを吐くプログラムコードを見せて欲しい。

>>101でもいいよ。
106デフォルトの名無しさん:2006/07/31(月) 09:59:25
いまだにこういうこと言う奴がいるのか。
107デフォルトの名無しさん:2006/07/31(月) 10:48:49
SQLでJOINするよりも、
ORMがさらっとやってくれるCacheとLazyLoadingの方が
パフォーマンス上がる場合が多いよ。

自力でCacheしろという意見はきかん。
108デフォルトの名無しさん:2006/07/31(月) 13:34:07
>101
>SELECT 文の出力を、変数に代入するコードを書くことを

そんなことしないってw
109デフォルトの名無しさん:2006/07/31(月) 15:24:39
>>108
お前がそうしないのは勝手だが
お前の事情など知った事ではない。
110デフォルトの名無しさん:2006/07/31(月) 15:34:20
今時SELECTの結果をいちいち変数に入れなければいけないような実装は
ないんじゃないのか? API直接叩くなら別だけど。

>>101がどういうつもりで言ってるのか知らないけど。
111デフォルトの名無しさん:2006/07/31(月) 21:01:13
いや、SELECT 文の結果を変数に入れないなら、
どうやってSQL以外のプログラムからDBにアクセスするんだ。
112デフォルトの名無しさん:2006/07/31(月) 23:08:40
馬鹿だな、みんなwww
変数に入れないって事は

M a p に 入 れ る

って事じゃないか。
113デフォルトの名無しさん:2006/07/31(月) 23:18:46
Map厨キタ━━━━━━(゚∀゚)━━━━━━ !!
114デフォルトの名無しさん:2006/07/31(月) 23:21:44
>>112
おおー久々のネタだ!!!
よく覚えてたなw
115デフォルトの名無しさん:2006/08/01(火) 14:05:45
>111
直接レコードセットのフィールド参照すりゃいいじゃん
116デフォルトの名無しさん:2006/08/02(水) 00:24:50
>>115
だよな。
117デフォルトの名無しさん:2006/08/03(木) 15:10:14
いちいち変数に代入したがる奴っているよな。
118デフォルトの名無しさん:2006/08/03(木) 15:21:03
それはORMとどう違うのだ?
それとも Javaで言うと ResultSet をViewから直接参照するのか?
非常識な設計だな。
119デフォルトの名無しさん:2006/08/03(木) 17:49:55
>それはORMとどう違うのだ?
>それはORMとどう違うのだ?
120デフォルトの名無しさん:2006/08/03(木) 19:27:19
>とどう違うのだ?
そのコードを、作成するたび、変更があるたび、
いちいち人間さまが書く必要があるかないか。
121デフォルトの名無しさん:2006/08/03(木) 19:47:01
>>120
つまり、ViewでResultSetを直接参照してるってこと?
データをオブジェクトとして扱うという発想がないってこと?
.NETってWebでもそんなことするの?
122デフォルトの名無しさん:2006/08/03(木) 19:53:34
>>121
っていうか、なんでそこでView がでてくるのかわけがわからん。
仮にいちいち書くとしても、データアクセス層の話だぞ。
123デフォルトの名無しさん:2006/08/03(木) 19:59:47
>>122
ん?じゃあ、最終的にはどこかで取り出したデータを
オブジェクトに入れ替えるコードは書くわけ?
124デフォルトの名無しさん:2006/08/03(木) 20:04:41
>>123
>取り出したデータをオブジェクトに入れ替える

だから、それがORマッパの機能で、それ(ORマッパ)を使わない場合は、
そのコードを人間がいちいち手で書くことになる、
というのが、>>120 の文意だよ。
125デフォルトの名無しさん:2006/08/03(木) 20:12:13
>>124
ああ、そういうことね。>>120 を読み違えてた。
ResultSetを直接扱えば、変更があってもマッピング定義を
変えなくていいじゃん、という非常識な意見だと思ったよ。

じゃあ、結局ORMイラネって言ってるやつは
いちいち手書きしてるってことか。
なんと非効率なことか・・・・
アホか。
126デフォルトの名無しさん:2006/08/03(木) 23:12:32
>>121でいきなり.NETが出てくる理由がわからん。信者か?
127デフォルトの名無しさん:2006/08/04(金) 11:49:37
>いちいち手書きしてるってことか。

なにを?
128デフォルトの名無しさん:2006/08/04(金) 12:23:00
ループしてきた?
129デフォルトの名無しさん:2006/08/04(金) 17:15:53
>>105でも聞いたけど、例を出してその優位性を見せてくれれば一発で
片が付く議論なのに、なんで出してくれないの?
130デフォルトの名無しさん:2006/08/04(金) 17:29:50
>>129
そもそも前提が間違ってるから。
今時おまいみたいなこと言う奴まだいるんだなw
131デフォルトの名無しさん:2006/08/04(金) 17:31:44
>>130
で、例は? また出さずにグダグダやるわけ?
132デフォルトの名無しさん:2006/08/04(金) 17:48:35
前提が間違ってると言われてるのに、例は?とかまだ言ってるのか。
どうしても何を言われてもオブジェクト指向を理解できないコボラーのように頭ガチガチなんだなw
133デフォルトの名無しさん:2006/08/04(金) 18:19:28
まあ前提がおかしいのは >>1 から既にそうだしな。
134デフォルトの名無しさん:2006/08/04(金) 18:31:11
>>132
前提とかその辺はどうでもいいのよ。
オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
単純にO/Rマッピングの利点の話。

単にオブジェクト指向ってだけならデータセットレベルでもオブジェクト指向してるワケで
O/Rマッピングを採用することでどんな具合に楽になるの? ってことが知りたいわけ。

だから>>105に挙げた例を出してくれって言ってる。
135デフォルトの名無しさん:2006/08/04(金) 18:46:28
>>134
>オブジェクト指向はかくあるべき云々なんて教条的で頭ガチガチ(笑)な話じゃなくて
ホントにわかってないなw
そんな話をしてるんじゃないだろ?

オブジェクトを永続化するのになぜ>>105のような例が出てくるのかまったく理解できない。
136デフォルトの名無しさん:2006/08/04(金) 18:48:54
>>105を前提に例を求める時点でORMの使い方をわかってないってこと。
そんな奴が無理矢理使っても失敗するからやめとけ。
137デフォルトの名無しさん:2006/08/04(金) 19:18:13
>>135
オブジェクトの永続化なんて言っても、その永続化の先にあるのはあくまで
SQL完備のRDBMSが前提でしょ?

>>105の何がおかしいわけ?
138デフォルトの名無しさん:2006/08/04(金) 19:32:13
>>105

1. 関連するtableの全recordをobjectにmapping
2. 1で生成したobjectの集合に対して、好きな方法で必要なobjectを抽出する
139デフォルトの名無しさん:2006/08/04(金) 20:04:38
オブジェクトの永続化という視点でモデリングをして
どうしたら>>105みたいな状況になるんだかw
設計とモデリングがヤバいだろ。
140デフォルトの名無しさん:2006/08/04(金) 20:27:46
ちゃんと説明を行わないからだよ。
ORMの利点と欠点を説明すれば納得するはずだ。

そもそもはオブジェクトの世界とデータレコードの世界の
インピーダンスミスマッチの解消のための技術。
そのため、相互マッピングというオーバーヘッドが発生するのは
デメリットといえる。
しかしその代わり、オブジェクトの世界における取り扱いの
柔軟性というメリットを享受できる。
その点に魅力を感じないのであれば、その人にはORMは必要なし。
141デフォルトの名無しさん:2006/08/04(金) 20:38:42
>>138
関連テーブルにレコードが100万個あったら100万個オブジェクトを作るのか?
最悪だな。
142デフォルトの名無しさん:2006/08/04(金) 20:46:10
>>141
そんなわけないだろ。アホか。
Lazy Loading ってのがあるんだよ。
143デフォルトの名無しさん:2006/08/04(金) 20:49:32
だがjoinしようと思ったら結局全レコード分のオブジェクトを作る羽目になる…
144デフォルトの名無しさん:2006/08/04(金) 20:54:27
臨機応変にVIEWとか使えばいいんじゃね?
ORM使うのが目的じゃないし、ただの手段にこだわってもな。。
145デフォルトの名無しさん:2006/08/04(金) 21:10:00
>>144
正解。
146デフォルトの名無しさん:2006/08/04(金) 21:59:39
>>143
げー、なにそれ。

裏でSQL作って投げるんじゃなくて、全レコード引っ張ってきて自前で総当たりするのか…。
そういう代物だとは思わなかった。
147デフォルトの名無しさん:2006/08/04(金) 22:10:32
んなわけない
148デフォルトの名無しさん:2006/08/04(金) 22:37:11
>>129
オートマ市販車で、ワークスマシンと同等のタイムを出してみろ。
といっているのと変わらん。無意味な質問だ。
149デフォルトの名無しさん:2006/08/04(金) 22:57:43
>>148
誰も実行速度の話なんてしてないじゃん。
150デフォルトの名無しさん:2006/08/04(金) 23:24:33
>>146
ORMがそんなに便利になれるわけない
151デフォルトの名無しさん:2006/08/04(金) 23:59:52
>>149
うん、君を除いては「誰も」していないね。
152デフォルトの名無しさん:2006/08/05(土) 01:21:56
>>105
JPQLがそれら全てに対応してることからわかるように
検索処理はSQL的な記述を最大限に利用するのが正解
O/Rマッピングが力を発揮するのは、データを取得した後の登録・更新処理
Hibernateの場合、Beanに値をつめてツールのメソッドにわたせばINSERT文が発行されるし
SELECT文で取得したBeanの値を変更すれば、トランザクション終了時に自動的にUPDATE文が発行される。
これらのINERT・UPDATE文はJDBCのバッチUPDATEを利用する為、ある程度のパフォーマンスも期待できる。
また、このとき排他処理が自動的に実行される。
Webアプリなどのロングトランザクション管理が必要な場合は必須といえるツールだと思う

データのBeanへのマッピングも便利だが、それは昔からDbUtilsなどで実現していた機能だからな

>>143
ツールで自動作成すればいい。外部キー制約をつけていれば、クラス間の関連定義まで自動でやってくれる
153デフォルトの名無しさん:2006/08/05(土) 23:28:02
ぶっちゃけマッピング面倒だ。
自動化出来ないのか?
154デフォルトの名無しさん:2006/08/06(日) 02:28:23
>>153
できるよ
ってか、するのが当然・普通・あたりまえ。
155デフォルトの名無しさん:2006/08/06(日) 02:35:34
ORMうんぬんよりも
ここにいる人達は正直イタイと思った。

まずは日本語をw
156デフォルトの名無しさん:2006/08/06(日) 09:51:56
日本語をマッピングするのか?
157デフォルトの名無しさん:2006/08/06(日) 10:41:30
ぶっちゃけ脳内→日本語マッピング面倒だ。
自動化出来ないのか?
158デフォルトの名無しさん:2006/08/06(日) 10:44:04
>>157
できるよ
ってか、するのが人として当然・普通・あたりまえ。
159デフォルトの名無しさん:2006/08/06(日) 10:52:37
Java以外ではろくなORマッピングが存在しない。
あっても、逆に手間がかかる。
160デフォルトの名無しさん:2006/08/06(日) 13:09:24
Javaが一番SQL分からない馬鹿による被害が甚大なんだろ
161デフォルトの名無しさん:2006/08/06(日) 13:15:40
>>160
シッタカ乙。
ORMの役割・メリットはそこじゃないっつーの。
162デフォルトの名無しさん:2006/08/06(日) 14:29:52
>>157
PG云々以前の問題だなw
163デフォルトの名無しさん:2006/08/06(日) 17:01:51
>>161
> ORMの役割・メリットはそこじゃないっつーの。
じゃあどこさ?
164デフォルトの名無しさん:2006/08/06(日) 17:16:19
エンティティとデータの関係を言語ソースの外に出せることだろ
165デフォルトの名無しさん:2006/08/06(日) 18:11:45
そもそもPGって日本語不自由な香具師が多いよね。
ソースで会話したほうが速いことが多杉!
166デフォルトの名無しさん:2006/08/06(日) 19:27:07
ORMなんて小ざかしい事せずに、OODBのほうが良いような気がしてきた。
167デフォルトの名無しさん:2006/08/06(日) 20:13:48
>>163
SQLを知ってる・知らないではなく、
SQLとオブジェクトのマッピング作業をフレームワークがやってくれる点。
168デフォルトの名無しさん:2006/08/06(日) 23:34:16
>>163
ORMはSQLを知っていることが利用の最低条件
目的は、SQL記述から冗長な部分を省いて永続化処理の生産性を上げること
169デフォルトの名無しさん:2006/08/07(月) 00:28:57
【ORMの役割・メリット】
・エンティティとデータの関係を言語ソースの外に出せること(>164)
・SQLとオブジェクトのマッピング作業をフレームワークがやってくれる(>167)
・SQL記述から冗長な部分を省いて永続化処理の生産性を上げる(>168)

色んな表現があるが、同じことを意味している?
170デフォルトの名無しさん:2006/08/07(月) 00:55:58
てか日本語じゃ良く分からんから
ソースで示してくれんかの?
171デフォルトの名無しさん:2006/08/07(月) 01:14:48
>>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"));
・・・

上記のような単純で退屈でコピペミスしやすく、
しかし大量に書かなければ行けないような処理を、
テーブル毎・検索処理毎に書かなくて良い。
上記のコードを手書きするとカラム名やカラムの型を間違える可能性もあるが
マッピング定義ファイルを自動生成すればカラム名やカラムの型を間違えることもない。
カラムの追加変更があっても、このようなコードだと影響箇所を修正するのは骨が折れるが
マッピング定義ファイルを自動生成すればかなりの省力化が可能。
172デフォルトの名無しさん:2006/08/07(月) 23:13:03
テーブル構造をオブジェクトにマッピングするツール ×
オブジェクトをテーブル構造にマッピングするツール ○

RDBMSとオブジェクト指向言語との親和性を高めるツール ×
オブジェクトを永続化する先の入れ物としてRDBMSを使うためのツール ○

既存のテーブル構造にORMを適用する事も自動化ツールのサポートで容易 ×
ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○

この辺りを理解してないORM信者も多すぎる。
所詮はラッピングツールであり、余程単純なシステムでもない限りSQL直書きは避けられない。
ここを勘違いすると、JAVAコードをすっきりさせるために一貫性の無いVIEWやストアドを大量に作成して
DBの中を阿鼻叫喚地獄絵図にしてしまうという本末転倒をやらかす。
173デフォルトの名無しさん:2006/08/07(月) 23:18:47
まあ、DBの中が阿鼻叫喚地獄絵図になってしまうようなやりかたで、
Java コードだけはすっきりしてるなんてありえないけどな。
174デフォルトの名無しさん:2006/08/08(火) 01:04:35
>>172
>ORMを使っていない環境で構築されたテーブル構造への適用は困難 ○

別に困難じゃなかったぞ
重要なのは適用検討しているテーブル構造の正規化の度合い
主キー無し、外部キー無し、結合条件がDBの制約では決まらないetcな構造だったら諦めるべきだが
普通に正規化されたテーブルなら適用は容易

ORMって結局DB側に寄ったツールであることを勘違いしてはいけない
SQL直書きサポート必須は同意。最近のツールはどれもサポートしてるけど
175デフォルトの名無しさん:2006/08/08(火) 22:37:39
なんでもかんでもSQLでやって、UIだけプログラムで作れば
176デフォルトの名無しさん:2006/08/09(水) 09:35:08
作れば・・・
177デフォルトの名無しさん:2006/08/09(水) 09:45:51
>>175
なんでもかんでもSQLでやって、UIだけプログラムで作れば、
UI部分のプログラムにはカラム名を指定して値を一つ一つ取り出す記述や
入力値をSQLに埋め込む処理を大量に書くことになる・・・と。
178デフォルトの名無しさん:2006/08/09(水) 13:38:46
どんな開発ツールを使ったそんなへっぽこな発想になるんだ
179デフォルトの名無しさん:2006/08/11(金) 21:52:50
なんでもかんでもVBでやって、ばぐった時だけ外注で作れば
180デフォルトの名無しさん:2006/08/13(日) 14:35:29
ぐらーぐらとにえる♪
181デフォルトの名無しさん:2006/08/16(水) 18:20:02
db4oならORマッピング不要ですね
182デフォルトの名無しさん:2006/08/17(木) 06:07:00
もうDLinqでいいじゃん
183デフォルトの名無しさん:2006/08/19(土) 23:01:51
>>181
とりあえず本1冊読んでみたけど、組み込み向けじゃん。
184デフォルトの名無しさん:2006/08/20(日) 00:12:50
>>183
別に組み込み用では無いが。
185デフォルトの名無しさん:2006/08/20(日) 16:12:06
RDBMSの代用には向かない気がするけど。
186デフォルトの名無しさん:2006/08/20(日) 23:25:44
OODBをRDBMSの代用として考える方がおかしい気がするけど。
187デフォルトの名無しさん:2006/08/21(月) 21:09:59
db4oの中の人はリレーショナルの代用になるって言ってる。

実際のところ、どうかは知らんが。
188デフォルトの名無しさん:2006/10/07(土) 04:11:26
Hibernate最強でしょう。
いまどきJavaの世界にSQL持ち込んでる糞は氏んでよしと。
189デフォルトの名無しさん:2006/10/07(土) 08:32:52
Hibernate ってそこまで(SQLを一切使わなくて良くなるほど)万能なものとは
思えんのだけど。
190デフォルトの名無しさん:2006/10/07(土) 09:18:59
Map最強説唱える奴にはそう見られても仕方が無い
191デフォルトの名無しさん:2006/10/07(土) 09:51:14
    ∧∧
    (,,゚Д゚)    ヨイショ....
   / つ〜⌒ヽ
   ( (';; _, ...,,)
   ∪,)....´;;;,,,..(ヽ
    (::::::ノ⌒)_ヽ)
      ̄   
   ∩⌒>⌒ヽ ゴソゴソ
  /(';; _, ...,,)
  ( ,)...´;;;,,,..(ヽ
  U(::::::ノ⌒)_ヽ)

   ∧∧
  /(*゚Д゚) オフトンサイコー♪
  / :::У~ヽ
 (__ノ、__)

  _  カタカタカタ
 .//|.|   /'∧   
 | |..|.|  (Д゚,ノ⌒ヽ マッピングサイキョー♪
  ̄ll ]-、と/~ ::ノ:::)
  ̄ ̄ ̄|(_.( :: ,:_)
192デフォルトの名無しさん:2006/10/07(土) 16:46:05
個人で作ってような実験アプリとか趣味アプリだったらdb4oで良いんじゃねーか?

今はtomcat + hibernate + postgres だけどそのうち時間があったらtomcat + db4oに変えてみる。
どれだけ生産性があがるかレポートしますね。
193デフォルトの名無しさん:2006/10/07(土) 23:44:02
db4o ってリファクタリングに追従できんの?
194デフォルトの名無しさん:2006/10/08(日) 02:48:10
>>188
Hibernate in Actionを一度読んでみるべき
「HibernateはSQLを熟知した開発者こそが使うべきツールである」
と開発者自身がはっきり宣言している
195デフォルトの名無しさん:2006/10/08(日) 04:06:59
>>193
知らないけど、既存データを捨てていいなら、自動じゃないの?
196デフォルトの名無しさん:2006/10/08(日) 09:25:12
既存データの扱いが問題なんだよなー

1.SQLで以降処理を作る
2.変更後のDBは別のDBとして作り、マッピングベースで以降プログラムを作る
3.その他

どうするのがいちばんいいのか。
197188:2006/10/08(日) 10:43:46
>>194
はい、読んでます。

SQLの知識は必要ですよ。
それは否定してませんが。

ただ、
ソース上にSQLを直書して、
StringBuffer#appned
なんて、まじありえない。氏んでよし。
198デフォルトの名無しさん:2006/10/08(日) 10:51:38
>>197みたいなレスみると
お前が氏ねよ。って思います。
199デフォルトの名無しさん:2006/10/08(日) 10:58:39
>>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();
   }
}
200デフォルトの名無しさん:2006/10/08(日) 11:12:08
SQLを使っても「ソース上に直書して、StringBuffer#appned」なんてまじありえないのだが。
普通はResourceBundleやPreparedStatementを組み合わせるからな。
「SQLを使う」イコール「直書&StringBuffer」なんて発想の奴はHQLも直書するんだろうねw

>>199 それはいくらなんでもダメだよ。
201188:2006/10/08(日) 11:29:54
>>200
あなたの言うことは正しい。
SQLを外だしにして、管理しているならまだましだ。
だが、現実はコンサルと称して、そんなことすら
できない無能な奴がいる。
理由は
「複雑なSQLが多いので、ハードコーディングじゃないと
やりにくい」
などと言っていたよ。

そういうやつらはまじ氏んでいいよ。

ただ、ResoureBundleを組み合わせるといっているが、
ようするにそういう場合、ある種のフレームワークを
作っているんだと思うが、そういうフレームワークでは
Hibernateが最強なんだよ。
かけられている工数、開発者のレベルが世界トップクラスだし。
202デフォルトの名無しさん:2006/10/08(日) 11:35:50
>>200
>>>199 それはいくらなんでもダメだよ。
なんで?
203デフォルトの名無しさん:2006/10/08(日) 12:09:51
>>202
とりあえず、単発のSQLなら判らないことは無いがPreparedStatementを使うほうがベターかな?
あと、サニタライズやなんかをどうするって話も出てくる
SQLインジェクションって言われる脆弱性のほとんどは>>197みたいなソースを使ってることが原因
204デフォルトの名無しさん:2006/10/08(日) 12:51:14
>>197
「いまどきJavaの世界にSQL持ち込んでる糞は氏んでよし」って言ってるじゃん
HQLだってSQLのテーブル定義をクラスに置き換えて、結合条件を省略したり継承戦略追加してるだけだし
ソース上に書くかNamedQueryで外出しするかはHibernate使っても選択肢の一つでしかない
>>199のような書き方は、JDBC使ってても普通やらないしw
205デフォルトの名無しさん:2006/10/08(日) 13:17:29
今からHibernateのAPIを覚える必要性はないな。
JPAでいいだろ。
コンテナにJBossやjboss-EJB-3.0_Embeddableを使った場合に
JPA実装としてHibernateを内部的に使うことはあるかもしれないが。
206デフォルトの名無しさん:2006/10/08(日) 13:33:03
>>203
それは、jdbc を使う(と決めた)場合の技法の問題であって、
後からいくらでも(DAO内部の問題として他に影響を与えずに)
修正の利く問題じゃないの。
207デフォルトの名無しさん:2006/10/08(日) 13:42:20
>>206
話がずれてないか?
208デフォルトの名無しさん:2006/10/08(日) 14:07:05
>>207
だからさ、SQL直に書かずに済むなら、
そのほうがいい、ってことは誰も否定してないだろう。

自分が言っているのは、じゃあ、SQL直書きが、
「それほど(SQLのコードがわずかでも存在したら、そのシステムが全否定されるほど)深刻な問題なのか?」ということ。

209デフォルトの名無しさん:2006/10/08(日) 17:29:54
>>108
パラメータをPreparedStatementで代入することと、SQL直書きが混同されて話されてるからな
前者はJDBCでやるときも同じだから、別にHibernateを選ぶ理由にはならない
後者は別に目くじら立てて否定するようなことでもない。
動的にクエリを組み立てるときはソースに書いたりすることもある。
Criteria使うこともあるだろうけど、JPAでサポートされてないからな
210デフォルトの名無しさん:2006/10/08(日) 19:25:28
で、Hibernateってどこまで出来るの?
joinしまくったSQLの生成とかできるの?
これができるのなら導入もありなんだが
211デフォルトの名無しさん:2006/10/08(日) 19:30:11
joinぐらいならできるよ。マニュアル見れ。
212デフォルトの名無しさん:2006/10/08(日) 23:59:48
>>210
JOIN程度ならHibernate使ったほうが楽
SELECT句やWHERE句ならサブクエリも書ける
213デフォルトの名無しさん:2006/10/09(月) 10:17:13
>>205
JPAの実装ってどこにあるの?
214デフォルトの名無しさん:2006/10/09(月) 10:55:28
>>213
Hibernate EntityManager
215デフォルトの名無しさん:2006/10/09(月) 12:07:17
>>213
つ JBoss EJB3(JPA部分の実装はHibernate)
つ Glassfish/JavaEE SDK(JPA部分の実装はToplink)
216デフォルトの名無しさん:2006/10/09(月) 13:12:13
>>196
ん?db4oの話だよね?

リファクターは既存のクラスをさわらないで、新しいクラスを作りそこで行う
既存のクラス>新しいクラスへの変換methodを適当につくる。
既存のクラスを全部ロード>新しいクラスに変換、全部保存
これで既存データもリファクター完了。

既存sqlからのデータ抽出はhibernate使ってれば上記プロセスでOK
jdbcだったら ちょっとつらいかな。
217デフォルトの名無しさん:2006/10/09(月) 14:19:15
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 |  |
219ななすぃ:2006/11/07(火) 22:37:39
特定の言語に依存した環境なんぞクソ。RDBはデータ構造とアルゴリズムを分離す
るためのインフラなんだよ。SQLで書けないシステムなんかつぶし効かんからあと
あと苦労するよ。わかってないやつが集計処理をループで書いたりすんだよな。
220デフォルトの名無しさん:2006/11/07(火) 23:21:34
RDBじゃなくってXMLとかでも分離できるんでないの?
RDBMSって長期保存のデータストレージとしては最低最悪の場所だから。
221デフォルトの名無しさん:2006/11/08(水) 13:25:26
Execlで保存の方が最低最悪だろ
222デフォルトの名無しさん:2006/11/08(水) 15:59:08
んーとRDMSっていうのはデータ量が巨大化してある一線を超えると
CPUの負荷が爆発的に上がってシステムダウンしたりするの。

ある程度、容量に限度があるってことと、
OSの更新の時のデータの移行とかの問題もある。

だから、分離だけが目的ならDBを使うべきじゃない。
223デフォルトの名無しさん:2006/11/08(水) 22:16:37
データ量が巨大化しても越えるべき一線かやってこない素敵なストレージを教えてくれよハニー。
224デフォルトの名無しさん:2006/11/08(水) 23:06:29
四次元ポケットとか
225デフォルトの名無しさん:2006/11/08(水) 23:12:40
ブラックホールとか
226デフォルトの名無しさん:2006/11/08(水) 23:27:18
ハクション大魔王の胃袋とか
227デフォルトの名無しさん:2006/11/09(木) 00:03:34
/dev/null
228デフォルトの名無しさん:2006/11/09(木) 01:28:55
メーカーの工作員は
インターフェースの統合とトランザクションの管理を解きつつ、
RDMSの導入しかないって決め付ける。

ロジックは正しいけど解答は一つではないんだよね。
229デフォルトの名無しさん:2006/11/09(木) 09:59:54
>>227
それだ
230デフォルトの名無しさん:2006/11/09(木) 10:33:17
でも、実際DBMS使ったほうが楽だぜ
見渡せる範囲ならスケーラビリティあるしでDBMS使って楽すりゃ良いだけじゃね
一線越えたときはうちの会社じゃおさらばした方が良いしな
231デフォルトの名無しさん:2006/11/12(日) 11:13:29
>>222
漏れAS/400(中身RS/6000の)を使っているけどDBの容量が増えたからって
CPUの不可が爆発的に上がるなんて事ないんだが・・・。

そりゃ、システム全体のDiskの容量が90%くらいになると
ちょっと遅くなったなぁ、とは感じるけど。

それってWindowsでAccessとかSQL Serverとかの話じゃねーの。
232デフォルトの名無しさん:2006/11/12(日) 13:17:45
インデックス張り損ねて全レコードなめまわすようなバカクエリーや
ブロック分断されまくったまま放置してたとかそんなんでしょ。
233デフォルトの名無しさん:2006/11/12(日) 13:36:27
>>231
Disk I/OがボトルネックになってCPUのSYSが跳ね上がったことはあるよ。
当時DBのサイズは100GB弱程度でPostgreSQL8.1利用。
OracleならDiskの使い方がもっと上手いんだろうけど。
234231:2006/11/12(日) 17:47:37
>>233
それOracleとかPostgreがどーこーじゃなくて、最初のハードウェアと
OSの選定が間違っていたってオチかと。

AIXなりOS/400だと「ある一線」とかは体感しないんだが。
もしかしてWindowsとかLinux使っておいてトロくなるとか
言っているなら、それを基準に「RDBMSとは・・・」と語るのも
微妙なんだが。
235デフォルトの名無しさん:2006/11/12(日) 20:01:22
ストレージの劣化の問題もあるし、
ハードウェアのリプレースの時、文字コードの問題もあるだろ。
営業のRDBMSマンセーは異常だと思う。
236デフォルトの名無しさん:2006/11/12(日) 21:07:15
それはRDB関係なくおきる問題では・・・。
237デフォルトの名無しさん:2006/11/12(日) 21:33:57
規格どおりのXMLだと起きない問題。
238デフォルトの名無しさん:2006/12/21(木) 00:05:59
HIbernateは複雑なSQLでもおk
他のもきっとおk
239デフォルトの名無しさん:2006/12/23(土) 01:56:38
AS/400ってファイルが排他ロックされるからゴミだよな。
オラクルなら同時更新も可能ですよ。
240デフォルトの名無しさん:2006/12/23(土) 10:32:23
>>239
スレ違いだと思うがAS/400は更新モードでロックしたら排他ロックするは当たり前だが。
Oracleは更新モードでロックして他人からも更新できたらそれこそ異常だと思うが。

ゴミアプリしか作れないロック恐怖症の初心者ゴミプログラマには
その方がいいかもしれんな。
241デフォルトの名無しさん:2006/12/23(土) 10:34:50
行レベルロックってことじゃね
242デフォルトの名無しさん:2006/12/23(土) 11:52:24
ロックしているオブジェクトを他のトランザクションから更新する事はオラクルでも出来まい
243デフォルトの名無しさん:2006/12/23(土) 15:48:52
239は分離レベルとかの存在を知らんだけじゃねーのか?

インデックスのないカラムに対して更新モードで全件検索する
SQL投げておいて「ファイルがロックする」とかヌカしていると思うんだが。
244デフォルトの名無しさん:2006/12/25(月) 11:23:02
とりあえず239がAS/400もOracleも理解できてないのはわかった。
245デフォルトの名無しさん:2006/12/25(月) 19:38:05
まあ、AS/400使いにはCOBOLerの仲間みたいな化石なSEが
ゴロゴロしてるからなぁ、アフォな設定のAS/400でもちょっとイジって
挫折したクチじゃね。

だからと言ってOracleマンセーもどーかと思うが。
246デフォルトの名無しさん:2007/01/13(土) 14:03:29
分離レベルなんて知らない初心者でも
簡単に扱えるOracle最強ということで
247デフォルトの名無しさん:2007/01/13(土) 17:43:43
MySQLもInno使えばOracleと同じ動作(分離レベル)じゃなかったか?

ただ初心者最強を言うならAccessとかODBCなEXCELじゃねーか?
248デフォルトの名無しさん:2007/01/14(日) 12:08:09
ODBCもEXCELもDBじゃないし
Accessでもある程度できるやつじゃないと
まともなものは作れない
249デフォルトの名無しさん:2007/01/14(日) 14:51:24
「まとも」の意味にもよるな
250デフォルトの名無しさん:2007/01/14(日) 19:37:14
ロックの仕組みや分離レベルもしらんOracle厨が指す「まとも」とか言うんだったら
初心者(?)がADO.NETでアレコレするのと大差ない「まとも」なのが出来るだろ。
251デフォルトの名無しさん:2007/01/28(日) 13:17:16
普段DB使わないので、初歩的な質問なのですが、
継承関係にあるクラスをRDBテーブルへ定義する場合
どうするのが自然なのでしょうか?

一応型の識別子と派生クラスの属性もテーブルに定義しといて、基底クラスの
インスタンスの場合、無い属性はNullのまま保存する感じで考えています。

ただ、これだと派生クラスの場合は自然ではありますが、基底クラスにも派生の
情報を持つことになるので、どうなんだろう?と思ってしまいます。
252デフォルトの名無しさん:2007/01/28(日) 13:29:38
JAVA言語のGUIでおかしげなゲームを作りたいんですが、いい案が浮かびません。
誰か参考までに何かないでしょうか?ソース貼付でお願いします。m(__)m
253デフォルトの名無しさん:2007/01/28(日) 13:35:07
254デフォルトの名無しさん:2007/01/28(日) 14:11:54
>>251
良い記事ですね。ありがとうございます。
この方法は実際の継承関係に当てはめたやり方ですね。やっぱりこっちがしぜんなのでしょうか。

たしかにこのやり方のほうが、設計的には良いと思いますし、スペース的にも
効率的ですね。ただ設計の良さを優先して、実装が複雑になっている感じもあります。検索速度的にも気になる。

まあORマッピングツールとか色々有るみたいなので、自動で
やってくれるから良い。といった感じなのでしょうか。
255デフォルトの名無しさん:2007/01/28(日) 14:51:32
>>254
その記事は2ページにわたってて、2ページ目にNULLをつかう>>251の方法もある。
ケースによって最適解がかわるので選択汁。
256デフォルトの名無しさん:2007/01/28(日) 19:56:06
>>255
次のページも有ったのですね。
とりあえず何か作って見ようと思い、参考図書を買いにいってました。
でRuby on Rails Up and Running(O'Reilly)を買ってきたのですが、ページ数の
割に内容があってなかなか良書です。
この本にちょうどテーブルの"ラッピング"(ORマッピングではない)についても
書かれていましたが、
Railsでは単一テーブル継承を使ってるようです。
257デフォルトの名無しさん:2007/01/28(日) 23:55:36
っていうか
OODB使えってことだろ?
258デフォルトの名無しさん:2007/01/28(日) 23:56:48
いっこうにOODBが普及しないことが全てを物語ってるだろ
259デフォルトの名無しさん:2007/01/28(日) 23:59:22
つまりORマッピングも・・・
260デフォルトの名無しさん:2007/01/29(月) 20:39:55
>>259
ORマッピングはOODBが普及しないからあるんじゃないの?
261デフォルトの名無しさん:2007/01/29(月) 21:32:15
OODBがRDBより圧倒的に速くなれば使う。
262デフォルトの名無しさん:2007/01/29(月) 21:35:30
RDBと同程度のパフォーマンスでも十分過ぎる。
ちょっとくらい遅くても普及すると思う。
263デフォルトの名無しさん:2007/01/29(月) 22:12:01
長年培われた信頼性、性能、安定性、バックアップのしやすさ、接続性、データ検索、操作のしやすさなど外部の永続ストレージとしては申し分ない。
せっかくあるんだからこれをオブジェクトの永続化先にしちまおうぜ?
ってのがORマッパだとおもわれ。

しかし、オブジェクトを永続化するって考え方はよくわかるんだが、よくある業務システムって結局帳票の電子化だろ。
抽出した情報のつまらんCRUDユースケースしかねーんだからドメインモデルなんていらなくね?

人がいます。属性は名前、空腹度、疲労度。操作には歩く、食べる、寝るがあります。寝ると疲労が回復します。そして人は永続化されます。
なんて実際の業務システムじゃやらねーよ。

そもそもオブジェクト名に「〇〇情報」って書いてある時点で、データとしかみてないしな。





264デフォルトの名無しさん:2007/01/30(火) 00:43:59
>>263
単なるExcelの延長線だよね、業務アプリのほとんどって。
二次元の表でほとんどのデータを表せて、
必要なナチュラルキーで結合してやればデータモデル完成。
後はそれのCRUDを用意してやればシステム完成ってことも多くない?
ORマッピングはそう言う典型的な業務システムを構築する際には
大変役に立つと思うんだけど。

ORっていうよりRelation->Objectの方向だね。
R/Oマッピングツールって呼んだ方が正確かも。
265デフォルトの名無しさん:2007/01/30(火) 01:43:22
今からORACLEの牙城を崩す事はできまい
よほど画期的なモンでもなければ・・・・
266デフォルトの名無しさん:2007/01/30(火) 01:56:28
ヌーヌー教徒「ORマッピング 入りません」
267デフォルトの名無しさん:2007/01/30(火) 02:06:46
>>265
ORACLEも出してるんだが・・・
268デフォルトの名無しさん:2007/01/30(火) 02:11:12
TopLinkはオラクルだよ。EJB3.0のど真ん中食い込んでるジャン。
269デフォルトの名無しさん:2007/01/30(火) 02:55:05
>>268
今月のDBMagazine見る限り一番良さそうだな
咽返るほどのORACLEの宣伝臭がしたけどw
270デフォルトの名無しさん:2007/01/30(火) 17:45:20
DBから情報を読み取って、DBにアクセスする部分のJDBCコードあるいはそれを
含むDAOクラスを自動生成してくれるものってないですか?
他の言語では、前に自分で作成したDBアクセスコード生成ツールを使って開発し
てますが、JAVAですでに同じようなものがあれば、自分で作らずに済みますので。
271デフォルトの名無しさん:2007/01/30(火) 17:59:56
>>270
君はどこに来てどのレベルで話をしているんだ?
272デフォルトの名無しさん:2007/01/30(火) 19:04:23
270です。
現在、Hibernateを使ったりもしてますが、DBの情報がマッピングされたBeanと
>>171のようなJDBC丸出しの基本的なDBアクセスコードを含むDAOクラスを
自動生成する、単なるコード生成ツールのようなものがあれば使いたいなと思
いまして。「ORマッピングはいらない」スレなんで、代わりになるようなもので、
Hibernateなどに比べてほとんど抽象化されていないものがあればなぁと思って
書いたのですが。なければ自分で作ります。
273デフォルトの名無しさん:2007/01/31(水) 02:52:52
Hibernate Tool 3.2.0 beta8 beta9a使ってんだけど、突然DBに接続できなくなってしまった
新規のコネクションも作れなくなってしまった
なんでだろう?
274デフォルトの名無しさん:2007/01/31(水) 02:55:57
つまりDBスキーマからのコード生成が出来なくなってもうたって事
275デフォルトの名無しさん:2007/01/31(水) 23:28:47
Antでやったら解決したからいいや
なんかEclipseというかBEA Workshop for JSPがおかしい
276デフォルトの名無しさん:2007/02/06(火) 21:22:40
270ですが、空いた時間にちょろっとコード自動生成ツールを作ってみた。
俺的にはこれで十分。
ボタンをクリックするだけで、DBのスキーマからJavaBeanとDAOクラスのコード
を自動生成するという簡単なものだけど。
DAOは、挿入・更新・削除・検索などの基本コードに加えて、自分が比較的よく
使うメソッドが、JDBC丸出しのコードで作られる。
まあ、かなり原始的だけど、フィールド数が仮に何百あろうとボタンをクリックする
だけで必要なフィールド数や型に合わせてコードが一通り自動生成されるから、
1から作るよりはかなり時間の節約になるよ。
細かいことは自動生成されたコードをカスタマイズして作らないといけないけどね。
277デフォルトの名無しさん:2007/02/06(火) 21:43:53
車輪の再発明乙。
278デフォルトの名無しさん:2007/02/06(火) 22:18:18
>>277
車輪にすらならんだろ・・・生ゴミ生成機だろ
279デフォルトの名無しさん:2007/02/06(火) 22:55:59
わざわざレスをつけるほどのもんでもないよ
完全な自己満の世界
280デフォルトの名無しさん:2007/02/07(水) 23:58:29
まあjavaだと車輪の再発明ってことになるけど、c++のプロジェクト
とかでは、コード自動生成スクリプトとか良く作ったりするよ。
javaだってそういうケースはあるんじゃない?
それに1つのプロジェクトで複数言語使うこと多いし、無駄じゃないだろ。
281デフォルトの名無しさん:2007/02/08(木) 00:02:26
つかなんだこのすれ
282デフォルトの名無しさん:2007/02/09(金) 01:43:28
>>281
>>270の公開オナニーを観賞するスレ
283デフォルトの名無しさん:2007/02/09(金) 03:48:33
OODBってたとえばJavaならVMと統合されてないとOOの意味なくね?
シリアライズして外部プロセスと通信するならRDBとやってることが変わらないわけで。
284デフォルトの名無しさん:2007/02/14(水) 00:13:47
VMと統合は余計だろ。
っていうかそれっぽいAPI用意してくれれば良いきがするけどな。

近いうちに、今のようなDBじゃなくてネットワークにつながるもの全てが
OODBというかオブジェクトで、接続先のクライアントも、クエリーで指定して
つながるような分散型のが出てくるんじゃない?

現実的にはCAみたいな物が居て、IP電話なんかと同じだろうけど。
簡単なAPIというかIFがあれば電話やIMなんかはかなり楽に作れるようになる。
まあ標準化がうまくいけばだけど。
285デフォルトの名無しさん:2007/02/14(水) 11:38:36
PreparedStatementのログは、sqlと?の値が別々になるけど
一緒にしたログを出すことはできないでしょうか?

select ? from XXX
BBB
↓↓↓↓↓↓↓↓↓↓↓↓
select BBB from XXX
286デフォルトの名無しさん:2007/02/14(水) 16:28:38
関連スレ

SQL文をハードコーディングするやつはとっとと氏ね@マ板
http://pc10.2ch.net/test/read.cgi/prog/1170779576/
287デフォルトの名無しさん:2007/02/14(水) 16:59:41
もう涙はいらない
288デフォルトの名無しさん:2007/02/14(水) 17:29:00
>>286
ないよ・・・
289デフォルトの名無しさん:2007/02/14(水) 21:13:53
まぁ>>1の気持ちはわかるけど。
だから逆にiBATIS使ったら病み付きになると思う。
290デフォルトの名無しさん:2007/02/14(水) 22:22:00
今北。
数個のテーブルと簡単な仕様を提示して、各々がアプリを作ってみると
O/Rマッパー使う派/使わない派のコードとかいろいろ見えてきておもしろいと思うんだけど
どうだろうか。
291デフォルトの名無しさん:2007/02/14(水) 22:58:06
だからー、ORMはテーブルありきで考えるんじゃないんだって。
何度も言わすな。
292デフォルトの名無しさん:2007/02/14(水) 23:11:02
っていうか・・・・・(ry
293デフォルトの名無しさん:2007/02/15(木) 11:57:28
ラスモチセセニミミキナカカイミチミニ・
294デフォルトの名無しさん:2007/02/15(木) 21:51:52
結果セットをDTOのMAPに書き出すくらいの認識だと、いらないという感想にもなるんだろう。
おまいらがORMに無きゃいけないと思ってるプロパティというのはなんだ。
295デフォルトの名無しさん:2007/02/17(土) 14:17:53
296デフォルトの名無しさん:2007/02/17(土) 14:35:18
>>295

>>291って何かおかしいの?
297デフォルトの名無しさん:2007/02/17(土) 14:36:52
話の流れからみればね
298デフォルトの名無しさん:2007/02/17(土) 14:41:43
いまいちよくわからん。
先にテーブル渡されて、ORM使う派と使わない派がコードを提示しあったら
ORM使う派のほうがあきらかに不利だとおもうんだけど。。
299デフォルトの名無しさん:2007/02/17(土) 14:43:22
単純なCRUD用DAO作るときはORM用のTOOLで自動生成する方が圧倒的に楽
300デフォルトの名無しさん:2007/02/17(土) 14:50:16
>>299
俺はそのやり方にちょっと懐疑的なんだけど。
ドメインモデルがトランザクションスクリプト・テーブルモジュールと比べて
有利な点ってモデル設計の自由度由来で
オブジェクト指向の恩恵を引き出しやすいことだけでしょ。
なのにテーブル構造に引きずられてモデル構造が決定されてしまったら
複雑さっていうデメリットだけが残るんじゃね?
301デフォルトの名無しさん:2007/02/17(土) 15:02:53
マッピングコードを書かないってだけで十分メリットあるけど
302デフォルトの名無しさん:2007/02/17(土) 15:04:45
テーブルモジュールだってマッピングコード不要だけど。
303デフォルトの名無しさん:2007/02/17(土) 18:48:52
そもそもそういうのをORMっていうんじゃね
304デフォルトの名無しさん:2007/02/17(土) 19:51:49
ちがうだろ。オブジェクトモデルとリレーショナルモデルのマッピングのことだろ。
インピーダンスミスマッチってやつを解消することそのものがORMであって、
自動化とかそういうのはオマケだろ。
305デフォルトの名無しさん:2007/02/17(土) 20:40:12
ならテーブルありきだって別にいんじゃねーの?
そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
306290:2007/02/17(土) 21:48:31
俺自身ORMに詳しいわけじゃないが、
スレ読んでても実装の話が出てこないのでイメージが掴めなかったんだよ。
だから実際にコードにしたらよく分かるんじゃないかと思って話を振ってみた。
個人的にはどうやってオブジェクトを切り出すとか、途中でどうやって改良するとかを知りたい。

テーブルありきだろうがそうじゃなかろうが、その辺はあまり重要視してなくて
束縛が仕様だけだと自由度高すぎるかなとおもって制約付けただけ。

ちなみに俺はORMに対しては>304の認識と一緒。
307デフォルトの名無しさん:2007/02/17(土) 21:54:09
ORMは仕様も限定するからな〜
308デフォルトの名無しさん:2007/02/17(土) 21:58:29
ORMの実装はそこらに転がってるだろ。まずは自分なりにいろいろ工夫して見なきゃ
ここでコードを提示したとしても良さも悪さも伝わらんと思うけどなあ。
309デフォルトの名無しさん:2007/02/17(土) 22:19:02
>>305
>そもそもORM用に適したテーブル設計しなきゃいかん時点でORM使えねってことでしょ
どういう理屈だよ。
310デフォルトの名無しさん:2007/02/17(土) 22:25:04
テーブル設計はデータアクセスに最適化されるべき
311デフォルトの名無しさん:2007/02/17(土) 22:44:55
>>310
全部ORMでやろうとしたり、全部SQL直打ちでやろうと考えるからおかしくなる。
312デフォルトの名無しさん:2007/02/17(土) 22:48:48
>>310
実際そういった設計少ないけどな・・・
もう疲れたよママン・・・
313デフォルトの名無しさん:2007/02/17(土) 22:56:33
ORMメリットって何よ
っていうか、ここでぎろんされているORMの定義がわからん
たとえばHibernateのような実装の事をいっているんか、理論の事をいってるのか
わしは理論はいらん
実装は、バインディングツールとして使える
314デフォルトの名無しさん:2007/02/17(土) 23:07:53
>>313
ん?OOPのメリットがわかれば自明だろ。
それとも、永続データついてはOOPは諦めればいいの?
315デフォルトの名無しさん:2007/02/17(土) 23:12:29
つか、オブジェクト指向を是として考えることが前提であれば、
理論って言うほど大層なものは無いと思うぞ。

つか、オブジェクト指向イラネなら無条件でORMイラネで正しい。
316デフォルトの名無しさん:2007/02/17(土) 23:15:32
ならマッピングなんてものではなくOODBしかあるまいw
どの道現状では、永続化データのOO化は、メリットより
デメリットの方が勝ってしまっているからねぇ
317デフォルトの名無しさん:2007/02/17(土) 23:21:28
>>316
現状っていつの現状だよ。
5年前だったらあんたの言ってたことで正しかったよ。
318デフォルトの名無しさん:2007/02/17(土) 23:24:14
ならいまの技術でOODBつくればいいんじゃねーの?w
319デフォルトの名無しさん:2007/02/18(日) 00:06:32
結局、Objectの定義が言語ごとにずれてる以上、各言語固有のOODBしか作れないだろ。
そしたら、RDBのような可汎用が保てないからダメよな。
320デフォルトの名無しさん:2007/02/18(日) 00:18:57
保存するものって、オブジェクトが持ってる状態と関連なんじゃないの?
それだけなら言語依存しないようにできるように思うけど
言語用のドライバとかで読み込めばインじゃね?
321デフォルトの名無しさん:2007/02/18(日) 05:59:59
型も一緒にストックできるDBがあったら楽しそうだな。
322デフォルトの名無しさん:2007/02/18(日) 12:39:30
少なくともDBアクセス、オールHibernateは最低な解だろう?
>>311の言ってることが核心を突いてると思うのだが。

結局、RDBとオブジェクト指向言語の間に
完全なインピーダンスミスマッチの解消を求めること自体が間違っている。



>>つか、オブジェクト指向イラネなら無条件でORMイラネで正しい。

"オブジェクト指向イラネ" な部分をPG内に意図的に設けるのが、結局◎だと思う。
そもそもその部分を隠蔽化する役割もORMapperにはあるんだろうけど、抽象化の漏れがありすぎる。


>>313の言うようなバインディングツールとしての使い方に押さえるぐらいが、
最終的に一番幸せになれるんじゃないかね。
323デフォルトの名無しさん:2007/02/18(日) 16:46:50
バインディングツールとして使えば、DBアクセスオールHibernateもありだよ
JDBCっぽいつかい方も出来るし、その上問い合わせ結果とのマッピングも
やってくれるのはお得だ。
324デフォルトの名無しさん:2007/02/18(日) 21:45:56
バインディングツールとしてだけに使うならO-Rマッピングでなくてもいい。
もちろんあってもかまわないが、他の選択肢もあるように思う。
たとえばADO.NETは厳密な意味でのORMじゃないんだよね。
あれはR-OマッピングというかXMLスキーマ中立型マッピングというか割と独特な構造をしている。

とにかく何を指して、いるいらないを議論しないと始まらない。
325デフォルトの名無しさん:2007/02/20(火) 20:37:04
じゃぁとりあえず Hibernate for Java



といってみる
326デフォルトの名無しさん:2007/02/20(火) 23:44:43
いらない。学習コスト、ハマリコストに見合うほどの効果は得られない。
SQLチューニングできない。SQLの便利な関数が使えない。
327デフォルトの名無しさん:2007/02/20(火) 23:55:20
つかえるよー
328デフォルトの名無しさん:2007/02/20(火) 23:57:30
ネイティブSQLもなげられるし
329デフォルトの名無しさん:2007/02/21(水) 07:08:36
>>326
>SQLチューニングできない。
Session#createSQLQuery
>SQLの便利な関数が使えない。
org.hibernate.dialectにDB毎の関数を登録しているDialectがあるのでHQLでも使える
330デフォルトの名無しさん:2007/02/21(水) 16:26:23
キャシュ処理の隠蔽とかも考えるとsql直は駄目だろ。
そんなだからゲッティになるんだよ。
331デフォルトの名無しさん:2007/02/21(水) 19:30:05
ORMいらないといっている奴はOOが理解できないカス野郎wwwwww
332デフォルトの名無しさん:2007/02/21(水) 21:14:47
>>330
同意。ORMみたいな隠蔽の恩恵はOOLだけが受けるものじゃないと思う。

>>331
だいたいjavaなんてcobol2.0だろ。
コボラとも仲良くやれば良いんじゃね。
333デフォルトの名無しさん:2007/02/21(水) 22:16:41
>>332
> cobol2.0
エエー
本当にそうならよかったと思うことあるけどさ
334デフォルトの名無しさん:2007/02/22(木) 01:00:46
>>332
>だいたいjavaなんてcobol2.0だろ。
こんなこという奴にOOわかんのか?
335デフォルトの名無しさん:2007/02/22(木) 01:10:50
javaをcobol2.0とかいわれた時に
OOだの技術面でしか考えられないような
人が使ってるようではやっぱりjavaはcobol2.0。

まあ長い事だらだら食えそうという事でもあるな。
336デフォルトの名無しさん:2007/02/22(木) 01:16:04
>>334
そういうことじゃないだろ。
視野狭すぎ。
337デフォルトの名無しさん:2007/02/22(木) 08:31:03
>>335
COBOLを名乗るならもっと帳票作りやすくしてくれ。
338デフォルトの名無しさん:2007/02/22(木) 10:04:33
>>337
レポーティングツールとしての機能は
SQLに吸収されたと考えてはどうでしょか。

データの整形だけの話だけど。
339デフォルトの名無しさん:2007/02/22(木) 11:51:27
>>338
あほですか?
340デフォルトの名無しさん:2007/02/22(木) 12:26:03
SQL*Plusの整形機能のことか?
あんなキモイもの誰も使わないだろ。
341デフォルトの名無しさん:2007/02/22(木) 22:53:58
言葉が足らなかったかな。

違いますよ、クロス集計だなんだの話。
みんなSQLでやらないの?
342デフォルトの名無しさん:2007/02/22(木) 23:11:40
なんで帳票の話してるのに集計の話が出てくるわけ?
343デフォルトの名無しさん:2007/02/22(木) 23:14:35
帳票に集計はつき物だからだろ?
344デフォルトの名無しさん:2007/02/22(木) 23:25:57
「このプレート、もうちょっと焼肉がおいしく焼けたらいいのに…」
「俺は最高級の炊飯ジャーを使ってるよ」
「なんで焼肉の話してるのに炊飯ジャーの話が出てくるわけ?」
「焼肉に白いご飯はつき物だからだろ?」
345デフォルトの名無しさん:2007/02/22(木) 23:47:43
入力チェックリストとか登録データ一覧程度の
帳票しかやった事ない人にはわからん話だよなあ。

俺はCOBOLの事は知らないけど
業務に使う様々な帳票に出力するデータを
作るのに向いてたって読んだ事がある。

WEB+DBプレスかな。その記事はSQLだか
RDB絡みの話だったな。>338と主旨は一緒。
その記事読んだんじゃないのかな。
346デフォルトの名無しさん:2007/02/22(木) 23:50:28
ああでもそもそも337の言ってる意味が
帳票レイアウトを簡単に作れる
Accessみたいな環境作れ、てな
意味だったら話がすれちがっちゃってますな。
347デフォルトの名無しさん:2007/02/23(金) 00:02:01
>>322
Hibernateには一応、独自のSQL構文をサポートしているが
348デフォルトの名無しさん:2007/02/23(金) 00:08:40
>>338
今なら、EclipseのBIRT


帳票作成はBIRTで決まり!
349デフォルトの名無しさん:2007/02/23(金) 00:50:07
Hibernateいいな
つーかSQL書くの面倒だから1行丸ごとloadする問い合わせばっかりしちゃうw
350デフォルトの名無しさん:2007/03/20(火) 01:17:42
SQLゴリゴリ書く時代は終わったな
351デフォルトの名無しさん:2007/03/20(火) 01:33:15
SQLをショリショリ書いたり,カリカリ書いたりする時代に突入したってこと?
352デフォルトの名無しさん:2007/03/20(火) 03:01:42
ゴリゴリっていうのは既製品組み立てるのではなく素材の加工から始める感覚の比喩。
漏れが最初に使ったつもり。
353デフォルトの名無しさん:2007/03/20(火) 06:50:13
>漏れが最初
なんというジジイw
354デフォルトの名無しさん:2007/03/31(土) 12:22:52
スレの趣旨と違うけど、
JDBCかつ全てPreparedStatementってのが最強かなと思ってるんだけど、
上のような簡易なライブラリってないのかな。Dbutilsみたいな感じで。

PreparedStatementは早いし、SQLインジェクション対策してくれるからいい。
355デフォルトの名無しさん:2007/03/31(土) 12:39:08
例えばHibernateだったら、それプラス結果とクラスインスタンスのバインディングもするからなー
ただ、バインダー目的で使うとJDBCのようには逝かない場合があるからなー
356デフォルトの名無しさん:2007/03/31(土) 18:21:33
>>354
iBATISはどうなん?
S2Daoも結局は結局はPreparedStatementつくるO/Rマッパーだし。

しかし、当たり前だがJDBCよりもちょろっと遅いんだよな。
この辺りは楽してる反動なので仕方ないと思うが。
357デフォルトの名無しさん:2007/03/31(土) 20:50:53
むしろそこにボトルネックを感じるとはなんと言うクソ設計
358デフォルトの名無しさん:2007/03/31(土) 20:57:07
JDBC直コーティングはどう考えも最速だろ。

「O/Rマッパー使ったらJDBCより早くなりました」とか言われたら
それこそクソコーダー認定だと思うが。
359デフォルトの名無しさん:2007/04/01(日) 02:02:00
そのは速さの差は、生産効率や保守効率と天秤にかけて
それでも十分にメリットがある速さなのかどかって言うのが問題でして・・・
360デフォルトの名無しさん:2007/04/01(日) 02:47:57
>>359
それすら判らないんだから放っておけばいいんだよ
361デフォルトの名無しさん:2007/04/01(日) 03:53:26
エンドユーザーには生産効率とか保守効率とかまったく関係ないけどね
362デフォルトの名無しさん:2007/04/01(日) 09:50:22
あるだろ
生産効率悪けりゃ要件の実現性が低くなるし
製品の安定性だって悪くなるし
保守効率悪けりゃメンテコストかかるし、新機能追加の実現性も低くなる
もっともそれを無理やり開発サイドが受け入れてデスマってパターン
なのかも知れないけどw
363デフォルトの名無しさん:2007/04/01(日) 13:35:30
最速を求めるんならストアド作ったほうが何倍も・・・
364デフォルトの名無しさん:2007/04/02(月) 22:35:51
DBはボトルネックになりやすいし、構成変えにくいから
いまいちORに手を出せないってのが俺の困ったところ
365デフォルトの名無しさん:2007/04/03(火) 00:08:22
>>364
困ったところはそこじゃないだろ?
366デフォルトの名無しさん:2007/04/03(火) 08:37:08
気にしなければ
いい事あるさ
367デフォルトの名無しさん:2007/04/06(金) 00:54:19
ちょろっとしたオーバーヘッドぐらいならどうということもないが、
SQLの書き方一つで速度が激変することは良くある。
それ考えると、動的生成に頼るのはちょっと不安があるな。
368デフォルトの名無しさん:2007/04/07(土) 01:48:15
勝手に作られるのは簡単なのしかないよ
どの道複雑なSQLは自分で書くしかなかとね
369デフォルトの名無しさん:2007/04/07(土) 11:31:15
今はHibernateとかはやってるのかな。
昔あったTorqueはなくなったのかな。ちょっと現場離れると機能レベルの変更についてけないや。

ORだのDIだの、学習コストかかるし、
どういうメリットがあるのかかわからん。

再利用性云々とか、疎結合だの、N階層だの…ほんとに再利用してる?
ほんとにメンテナンスコスト上がってる?
生産性あがってる?
プロジェクト運営とか、もっと根本的な所を改善しないとこういうのは解決しないのでは。

結局のところ、みんなが知ってるJDBCで十分というのが俺の結論。

Struts1.2とJDBCとTomcat5をみんなが覚えれば、WEB系の奴は幸せになれるんじゃないの。
これ以上はよっぽど革新的な技術が出ない限り、手をつける必要がないのではと。

以上グチでした…
370デフォルトの名無しさん:2007/04/07(土) 12:11:44
>>369
メンドクサイ・わからない・覚えられないってだけだろ?

君の能力が足りてないだけ
371デフォルトの名無しさん:2007/04/07(土) 12:21:15
>>370
俺もそう思う。
ついて行けてないだけじゃないか。
生産性・メンテナンス性は格段に上がってるよ。
学習コストとパフォーマンスがトレードオフになるけどな。
372デフォルトの名無しさん:2007/04/07(土) 13:09:01
>>369
IBM JSF+SDOくらいだとポトペタ(というのか?)でWebアプリが作れる。
単純なのならほとんどコードを書かずに作れる。
おそらくはひとつの理想系だと思う。

かなり革新的だと思うが、誰も話題にしない。w
373デフォルトの名無しさん:2007/04/07(土) 16:05:02
ポトペタかっこわるいから
374デフォルトの名無しさん:2007/04/07(土) 19:50:15
生産性、メンテナンス性が上がってるって言うけど、
所謂、定型的な力技作業が省力できるだけであって、
決して大幅なコスト減ってわけではなさそうな気がするけど。
それより、導入することによる学習コストや引継ぎのメンテナンスコストはかかるような
気がする。初期は解決できないエラーとかに悩まされるし。

372が言ってるのは、コードレスのGUIツール?だよね。genexusとか…
開発工程では、それくらい抜本的なものじゃないとコスト減らせないな。
あと、オフショアくらいか。


なんか話が脱線してるな… これにて失礼。
375デフォルトの名無しさん:2007/04/07(土) 19:53:33
小規模少人数の開発だとポトペタの方が早いし前提や手続きの多いフレームワークは面倒に感じるが、
大規模開発だと分業や保守のために面倒なルールや手順を踏んだほうが全体的な開発効率が上がってる。
この辺がJSFが流行らない理由のように思える。
376デフォルトの名無しさん:2007/04/07(土) 23:24:29
>大規模開発だと分業や保守のために面倒なルールや手順を踏んだほうが全体的な開発効率が上がってる。

これって、その開発の時だけ効率が上がったような錯覚を受けるんだけどさ、
実際、ポトペタの人海戦術(?)の方が生産性高いんじゃないか?って常々思うんだが。

あとで、そのシステムの拡張や保守・リプレースとかやりだすと、
後任者って大抵元チームよりスキルが下もしくは少人数だったりするんだが、
その面倒ルール&手順を再学習ってコストがバカにならんし。

でJSFのEase-of-Use, Standardization, Device Independenceのアプローチは
正しいと思う。

JSFで簡単に成果物が出来るのは素直にありがたい。

とか言う漏れはJSF+SDO+SpringFramework+iBATISが一番理想だと思っているが。
377デフォルトの名無しさん:2007/04/07(土) 23:38:14
俺はこれかな。単純明快だし。

(velocity+自作マクロライブラリ)+改造struts+spring+自作DAO
378デフォルトの名無しさん:2007/04/07(土) 23:51:10
>>377
俺専用ザクって感じだな
379デフォルトの名無しさん:2007/04/07(土) 23:56:13
Hibernateや、SpringやSeasar等のDIコンテナは、ポトペタのベースとして使えば使いやすいが、
ポトペタ部分が無いんだよなー
Javaで作ると動き悪いからなー
380デフォルトの名無しさん:2007/04/07(土) 23:57:18
>Javaで作ると・・・・
ポトペタUIの部分の事
381デフォルトの名無しさん:2007/04/08(日) 03:02:23
今まではJSF敬遠していたけど、NetBeansのVisualWebPackはやってみたくなった
簡単なCRUD処理ならウィザードですぐ作れるし
382デフォルトの名無しさん:2007/04/08(日) 11:09:46
NetBeansのを実際に使ってみていっているわけじゃないけど、
簡単にウィザードで作れるって言うのは、簡単に作れるものしか
簡単には出来ないんだよねー
ソコから一歩飛び出ると結局同じ的な・・・・
383デフォルトの名無しさん:2007/04/08(日) 16:01:49
>>382
ウィザードってそういうもんだと思うよ
384デフォルトの名無しさん:2007/04/08(日) 17:10:05
つまり意味ねーってことか
385デフォルトの名無しさん:2007/04/08(日) 17:47:11
>>382
使ったことないだろうから、そういう印象があるのだろうけど、
たとえばJSFだとJSF以上の事は出来ない。

それを指して簡単なのしか出来ないというのなら解らなくも無いが、
「servlet+JSPならこんな事も出来るぜ!」と言う話なら、
フレームワークなんか使うなよ、って話になるから勘弁な。

しかし、平均的(?)なプログラマの技量だとJSFでウィザートつかった方が
servlet+JSPよりも遥かに凝った事が出来ると思うが。
386デフォルトの名無しさん:2007/04/08(日) 19:50:57
>>385
そうだなぁ。

けど一番恐ろしいのはJSFへの習熟度が低いが為に、
JSFの機能で提供されているものを力技実装をされた
カオスなシステムが出来上がる事だと思うんだ。

うちでも出て間もないフレームワークを採用したプロジェクトは酷いもんだ。
ベストプラクティスを知らないが為に酷い実装になってしまったプロジェクトの多いこと。
387デフォルトの名無しさん:2007/04/08(日) 20:52:12
漏れはJ2EE5の商用版のJSFがどこまで機能アップしているかしらんけど、
SUNのJSF RIで「JSFはあれくらいしかできん」と誤解されているのかもしれんな。

漏れはIBM JSFの人だけど、カレンダーとかの部品もあるし、
RDBへのアップロードやダウンロードなんかもムチャ簡単に実装できる
拡張コンポーネントとかあったりするので、フレームワークの選択は慎重に、
ってのはあるな。

どのフレームワークでもあることなんだが、フレームワークにない機能を
実装しようと思うと、とたんに面倒&泥臭いコーティングが始まるので、
そういうのが嫌でフレームワークを嫌うヤツはいるかもな。

JDBCでいいじゃん、と言うのもそういうある境界を越えたときの泥臭さが嫌で主張しているんだろうし。
388デフォルトの名無しさん:2007/04/09(月) 17:07:53
>>369
Strutsは2.0系のほうが学習コストもメンテコストも大幅に下がると思うぜ
別物になってるけど

今はHibernate専用よりJPA汎用で実装をきりかえれるようにしておくのが都合がいい

>>387
JavaEE5だろ?というつっこみはおいといてNetBeansのJSFコンポーネント、
つまりRaveのものだけど、他社と同じくカスタムしまくりで素のコンポーネントは誰も使わんよ

今までだってSwing等GUIコンポーネント使ったアプリも配置だけですらIDE間で互換性はないし
JBuilderは知らないうちに組み込まれるようになってるから、誰でも気がついてると思いたい
389デフォルトの名無しさん:2007/04/09(月) 21:00:26
だが実際きりかえねーけどな
390デフォルトの名無しさん:2007/04/09(月) 21:28:47
実際切り替えないけどJPAの実装のほうが技術者集めるのに便利だし
ツールのサポートもあるしな
391デフォルトの名無しさん:2007/04/09(月) 21:53:34
SeasarからSpringって切り替えはあると思うが、Hibernateまでやっちまったら、
切り替えは現実的にない希ガス。

まあ、今後の新規アプリは、ってならJPAで無難だとは思うけど。
392デフォルトの名無しさん:2007/04/09(月) 22:00:39
>SeasarからSpring・・・・・
十分非現実的な希ガスw
393デフォルトの名無しさん:2007/04/11(水) 01:09:13
↓見たいなの書いてんの?
@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")
  })
  }
)
394デフォルトの名無しさん:2007/04/11(水) 01:37:32
>>393
なにこれ?最近のアノテーションベースのフレームワークってこんなの書かせてるの?
こんなの書くぐらいならまだメソッド内に実装した方がまだ見やすいわwww
395デフォルトの名無しさん:2007/04/11(水) 01:44:00
>>393はHibernate Annotationsのドキュメントのコピペ
396デフォルトの名無しさん:2007/04/12(木) 18:58:37
J2EEだけど、JPAとか色々出てきてはいるが、
正直DAOパターンに特化して、洗練させる方向で開発して欲しい気分。
うちはExcelとかCSVとかもよく使ってのと、
JDBCのが汎用性高いってのがその理由。
397デフォルトの名無しさん:2007/04/12(木) 19:53:20
J2EEはJPA使えないと思うが
398デフォルトの名無しさん:2007/04/12(木) 22:00:46
Hibernate EntityManagerつこてるとSQL書くのあほらしくなる
399デフォルトの名無しさん:2007/04/14(土) 00:16:31
俺は永続化ツールそのものを使わなかったりするな。
自分でDAO書いてJDBCごりって終わり。
そら永続化ツールの洗練されたキャッシュ機構に比べたら遅くなるが
それがボトルネックになることはまずない。

JPAを否定する気は無いが、トラブルを抱え込みたくない。
400デフォルトの名無しさん:2007/04/14(土) 00:36:56
S2Dao を Spring向けに書くって言うプロジェクトはちょっと期待している。
401デフォルトの名無しさん:2007/04/14(土) 00:49:29
O/Rマッピング自体は否定しないけど、Javaの氾濫したフレームワークはやばい。
402デフォルトの名無しさん:2007/04/14(土) 00:50:24
JPAでトラブル出るか?
とりあえずDAOでファサードパターンになってるんだからどうにでもなるしな
403デフォルトの名無しさん:2007/04/14(土) 07:47:14
>>401
と言っても自前でORMやDIxAOP部分をコーティングしてるワケ?

たぶん、担当者が変わったら「あの自慰野郎」とか言われて恨まれるのがオチな希ガス
404デフォルトの名無しさん:2007/04/14(土) 08:51:49
勝手にテーブルも作ったりしてくれるのがいい。
情報照会系のアプリにはなんだが、マスター更新系ならウマー
405デフォルトの名無しさん:2007/04/14(土) 09:32:00
>>404
SQLも発行できるORマッパーを利用して
情報照会はSQLで、編集・更新処理でEntity使いまくると
両者の長所が生かせてウマーだったよ
検索はSQLを駆使できて、更新系ではSQLを一切発行しなくていいからかなり楽
406デフォルトの名無しさん:2007/04/14(土) 09:45:08
そもそもSQL発行できないO/Rマッパなんてあるか?
407デフォルトの名無しさん:2007/04/14(土) 10:58:11
SQLを自動生成しない、って意味ならiBATISがソレだな。
xmlファイルに記述するスタイルのO/Rマッパー。
408デフォルトの名無しさん:2007/04/14(土) 12:13:28
Javaの世界はフレームワークだのコンポーネントだのが氾濫しずぎ。

ただ単に、WEBアプリケーションを作りたいだけでしょ?
それなら技術は限りなく絞って、もっと他の事にパワーを注いだ方がいい。

Servletだけで開発してた頃に比べて、顧客に提示する見積もり工数は減ったか?
主にI○Mを主体とした組織だけが、儲かってるだけじゃないのかな。

それに比べてVBはなんとすばらしいことか。クラサバだから目的は違うけどね。
Studioで用意されたものをさえ使えばいい。DB接続にしても、ADO使うのがスタンダードでしょ。

最終的には、Javaも周辺技術が統一されて、VBみたいなGUIライクな、
低レベルな開発に落ち着くような気がする。
Eclipseのような統合開発環境がアプリケーションフレームワークともっと密接に
パッケージングされた感じかな。
409デフォルトの名無しさん:2007/04/14(土) 12:27:03
>>408
フレームワークという名前にふりまわされてるやつ乙
自分が指揮できる立場ならちゃんとした環境用意できるだろ
Servletだけのときに比べて俺は大幅に工数は減ったよ
定型的な処理は任せてロジックだけに集中するのがフレームワークやライブラリというものだよ

VBサイコーでWEBアプリダメってのはまぁ言いたいことはわかるが
細かいことをやろうとするとVBにしろDelphiにしろ苦労してたなぁ
Swingは最初から低レベルライブラリなので同じ感覚で使うとはまる

まだバインディングAPIが標準化されてないからね

密接な連携ならEclipseはあきらめてNetBeansにするがよろし
410デフォルトの名無しさん:2007/04/14(土) 12:56:46
>>408
藻前は一度IBMのi5(AS/400)のJava+Web開発をやってみろ。
藻間の妄想程度のモノはすでにある。

#開発キットがやたら重いのが難点だが。
411デフォルトの名無しさん:2007/04/14(土) 15:24:31
>>408
Microsoft製品は一貫した開発環境、手法があるからJavaに比べると生産性が高い
そんな風に思っていた時期が、オレにもありました。
412デフォルトの名無しさん:2007/04/14(土) 15:34:05
よーし、パパRPG IIIでWebアプリ作っちゃうぞ〜
413デフォルトの名無しさん:2007/04/14(土) 15:48:11
>>408
VBはよーわからんけど、JUnitみたいなのってマイクロソフトが用意してくれるの?
ソースを変更せずにクラスのロギングとか、トランザクション制御とか出来るの?

>>412
ビジネスロジック部に関しては可能だな。w
Javaから呼び出せるし。
414デフォルトの名無しさん:2007/04/14(土) 15:54:08
別にクライアントサーバーのソフト需要へってねーしな
VBだろうが、何の言語だろうが顧客の望むシステムを高品質に作り上げたもん勝ち

流行ということで入力系をすべてWEBシステムに変えて大幅に生産性を下げた会社をいくつか知ってる
もちろん、コストや期間は大幅に増え、誰も得をしないという状態

WEBだと顧客は選択行が色が変わることとか、キーボードでの操作とか要望がどんどん膨らみやすいっぽい
用意されているコンポーネントを使える状況じゃないときの業務アプリでのJavaScript大量の直書きなんてまさに地獄
415デフォルトの名無しさん:2007/04/14(土) 15:58:50
>別にクライアントサーバーのソフト需要へってねーしな

漏れの周りでは普通に減っている点について

まあ、それまでのC/Sがヘボすぎたってだけだな。
つか>>414の周りはヘボエンジニア揃いって事か。
416デフォルトの名無しさん:2007/04/14(土) 16:09:15
>>414
>顧客の望むシステムを高品質に作り上げたもん勝ち

だったらWebでも作れない事はないだろ。

鬼の様なパンチャーがいるデータエントリー系の処理だったら、そこだけ
>>412にRPGで入力画面作ってもらえ。VBなんか比にならんほど堅牢で生産性が高い。w

厨房は適材適所で技術を使い分ける事を知らん上に知ったかをするからウザいな。
417デフォルトの名無しさん:2007/04/14(土) 16:29:04
>>415
WEBアプリになったあとリッチクライアント(いわゆる3層式C/S)に戻してるところは多いけどな
それも含めてのことだ
418デフォルトの名無しさん:2007/04/14(土) 16:30:16
>>416
適材適所が出来てないのは本当に困る
照会系はWEBでかまわんけど入力系では開発コストが上がることをちゃんと説明しない
マネージャーや営業は死ねよと
419デフォルトの名無しさん:2007/04/14(土) 16:37:38
>>417
つまり、藻前の周りの案件は最初デタラメなのをワザと納品しておいて
「やっぱアレはダメでしたね」と言い、さらに開発費をボる悪徳ベンダー、って事でFA

営業、開発とバカ揃いの組織でつな。
420デフォルトの名無しさん:2007/04/14(土) 16:46:17
関係ない話は他所でやれよ
421デフォルトの名無しさん:2007/04/14(土) 16:47:13
WEBはもう終わりだろ。どう考えても。
っつうか営業とか案件の話はマ板でやれよ。
422デフォルトの名無しさん:2007/04/14(土) 16:48:37
不利になるとマ板でやれ、ってwww
423デフォルトの名無しさん:2007/04/14(土) 17:47:41
釣りは「w」をつかうからすぐわかるな
424デフォルトの名無しさん:2007/04/14(土) 19:19:50
TopLinkって@Entityつけただけじゃエンティティクラスって認めてくれないのか?
Hibernateで使ってたHibernate固有のアノテーション使っていないクラスが
動かん・・・
425デフォルトの名無しさん:2007/04/14(土) 19:58:43
普通に@Entityだけでいいけど?
426デフォルトの名無しさん:2007/04/14(土) 20:30:42
persistence.xmlにも書かなきゃジャね?
両方書かんと例外が出る。
427デフォルトの名無しさん:2007/04/14(土) 20:38:49
persistence.xmlは個別記述しても言いし、しなくてもいい
428デフォルトの名無しさん:2007/04/14(土) 21:39:23
なぜだ・・・orz
なにがわるいんかおせーてください・・・・
ttp://www.42ch.net/UploaderSmall/cgi-bin/../source/1176554246.zip
429428:2007/04/14(土) 21:41:28
ちなみにHibernate EntityManagerはこのまま動くのだ・・・
Hogeクラスを実行してね
430428:2007/04/14(土) 21:45:31
連投スマソ
DBはHSQLで、テーブルやデータはhsqldb\src\org\hsqldb\sampleにあるsampledata.sqlで作ってね
431デフォルトの名無しさん:2007/04/14(土) 22:16:10
hsqldbならすべてワンパッケージにしてくれんかね
DBつくるのめんどくさす
432デフォルトの名無しさん:2007/04/14(土) 22:22:08
ぱっとみprovider指定がないな
433デフォルトの名無しさん:2007/04/14(土) 22:24:17
ぽmつけろよ
434428: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)
435428: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
436デフォルトの名無しさん:2007/04/15(日) 00:00:21
>>435
persistence.xmlに<class>が無いから。
>>426の言うとおり。
437428: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)
438428:2007/04/15(日) 00:29:34
Customerクラスの@OneToManyを↓のようにして、@JoinColumnを削除したら、TopLinkでもHibernateでも動きました♪
お騒がせしました

@OneToMany(mappedBy="customer")
439デフォルトの名無しさん:2007/04/15(日) 00:30:23
ソース見てみたがEntity定義おかしくね?
自前で一から実装してミス犯すくらいならNetBeansですべて自動生成させたほうがよさそうだが
440デフォルトの名無しさん:2007/04/15(日) 05:15:07
TopLinkめんどいな
Hibernateでいーや
441デフォルトの名無しさん:2007/04/15(日) 07:46:11
EclipseのHibernate Toolsプラグインか、NetBeansで自動生成させてから
好きな形に手を入れていく方法がお勧め。
とりあえず関連定義の失敗で動かないってことはなくなるからな
442デフォルトの名無しさん:2007/04/15(日) 10:52:19
hibernateはデタッチがめんどくせ
Toplinkのほうがはるかに上だな
443デフォルトの名無しさん:2007/04/15(日) 13:58:52
Toplinkってoracleから情報提供されてどっかに取り込まれるんでしょ?
444デフォルトの名無しさん:2007/04/15(日) 16:01:27
今はGlassfishで使われてるし、リファレンス実装になってる。
同じようにServletのリファレンス実装がオープンソースになってTomcatになったのを考えると
かなり影響はあるだろうね。

今のところJavaEEはGlassfish一人がち状態ってのもある
もちろん、JavaSEからも使えるようになってるのでGlassfishの上でhibernate使ってもいいけど
445デフォルトの名無しさん:2007/04/15(日) 16:18:37
>>444
そだったdd

hibernateとToplinkのいいトコ鳥になるって話だった希ガス
446デフォルトの名無しさん:2007/04/15(日) 19:07:02
JBossもGeronimoも、JavaEE5フル対応に関しては出遅れてるな
JSF1.2の実装がGlassFishでデフォルトになりつつあるのも大きい
ORマッパー単独で比べるとHibernateの方が多機能だけど、
TopLinkがGlassFishに載ってるというのは大きいな
447デフォルトの名無しさん:2007/04/15(日) 19:34:45
これでNetBeansの巻き返しがあるのだろうか・・・
448デフォルトの名無しさん:2007/04/15(日) 20:56:34
去年の時点でEclipseを越えたとオライリーは思ってるようだな。

そういやJBOSSもJSF実装をglassfishのに切り替えたんだっけ。
BEAもやっとJavaEE5だしてきたし、これから加速しそうだ。
肝心のSunが商用JavaEE5鯖が遅れてるのが気になる。
プラットフォーム版はすごい早かったのに。

あとglasshfishがすごい軽いってのも開発者には朗報だな。
10秒以内に起動するEE鯖ってあまりない。
449デフォルトの名無しさん:2007/04/16(月) 00:29:03
つかJavaEEいるのかよ?
JSFもEJBもJPAもJAX-WSもその他諸々もオレにはいらないんだぜ?
450デフォルトの名無しさん:2007/04/16(月) 00:35:01
サーブレットはいるだろ。
451デフォルトの名無しさん:2007/04/16(月) 00:54:35
>>450
放置しておけばよいものを・・・
452デフォルトの名無しさん:2007/04/16(月) 07:28:43
俺は逆に、今回初めてJavaEEを普通に使ってみたいと思ったな
いい加減、竹の子のように出てくる非標準のフレームワークを
組み合わせ続けるのにも疲れてきた
453デフォルトの名無しさん:2007/04/16(月) 11:26:52
サーブレット/JSP、JSF、JPA、JAX-WS、EJB
標準APIは開発環境が整備されやすいってのも大きいねぇ
いろいろと選べたりするし
454デフォルトの名無しさん:2007/04/16(月) 18:41:59
てかカスタムタグの作り方知らずに今まで来た俺に引いた。
POHP系にWicket使う程度にとどめておくか。可能なら。
455デフォルトの名無しさん:2007/04/23(月) 22:46:07
いいぞ
その調子だ
456デフォルトの名無しさん:2007/05/06(日) 16:15:07
toplinkあげ
457デフォルトの名無しさん:2007/05/07(月) 21:58:35
hibernateあげ
458デフォルトの名無しさん:2007/05/08(火) 20:23:07
glassfishさげ
459デフォルトの名無しさん:2007/05/08(火) 21:07:49
OpenJPAage
460デフォルトの名無しさん:2007/05/09(水) 00:58:02
他には?
461デフォルトの名無しさん:2007/05/09(水) 01:06:12
iBATISsage
462デフォルトの名無しさん:2007/05/09(水) 13:05:13
ActiveRecord最強
463デフォルトの名無しさん:2007/05/09(水) 13:10:44
TopMindのjLynxっていうのもあるでよ. 軽量なのが特徴. 機能的にはソースの自動生成なんかもあって まぁまぁって感じ. http://www.topmind.biz/html/index.php
464デフォルトの名無しさん:2007/05/09(水) 13:43:02
結局JavaならJPAだけでお手軽開発でいいのな・・・
465デフォルトの名無しさん:2007/05/10(木) 23:13:38
自作JPA実装あげ
466デフォルトの名無しさん:2007/06/02(土) 07:56:09
EJB2でエンティテイビーン使うならHibernateとか使ったほうが120倍くらいましなんだが・・・・
467デフォルトの名無しさん:2007/06/02(土) 08:51:46
そもそもO/Rマッピングってオブジェクトの保存先としてリレーショナルデータベースを使えるようにするものだったのに
すでに構築されてるデータベースにたいしてO/Rマッピングしようとするヤシばかりだから話がややこしくなってるんだな
468デフォルトの名無しさん:2007/06/02(土) 09:24:42
Hibernate使うよりJPA汎用のほうが100倍ましなんだが
469デフォルトの名無しさん:2007/06/02(土) 10:08:56
JPA汎用ってつまりHibernateやらToplinkやらをJPAの仕様の範囲内で使うってこと?
470デフォルトの名無しさん:2007/06/02(土) 10:24:51
>>468
意味がわからん

>>469
少なくともHibernateは入っていないようだ
471デフォルトの名無しさん:2007/06/02(土) 10:54:42
まさかJPAってライブラリが存在すると思っているのな・・・?
472デフォルトの名無しさん:2007/06/02(土) 10:55:07
hibernate=JPAじゃねーだろ
hibernateEntityManagerいれてはじめてそういう動きになる
実際はToplink以外のJPA実装はクソだけどな
473デフォルトの名無しさん:2007/06/02(土) 10:58:43
>>466はJPAについての言及は何もしていない件
>>466はまたHibernateについても「Hibernateとか」といって、Hibernateに限定しているわけでもない件
そして、その事が理解できない厨が存在する件
474デフォルトの名無しさん:2007/06/02(土) 11:02:43
>>466必死棚
475デフォルトの名無しさん:2007/06/02(土) 11:06:40
むしろおまいさんが(ry
476デフォルトの名無しさん:2007/06/02(土) 11:06:47
>>468のJPA汎用に食いついてる最中に>>466はこうなんだと主張されても・・・
477デフォルトの名無しさん:2007/06/02(土) 11:10:16
同じ事なんですけど・・・・
478デフォルトの名無しさん:2007/06/02(土) 11:11:29
意味がわからん・・・?
479デフォルトの名無しさん:2007/06/02(土) 11:12:13
>>476は、>>473で言いたい事の本質が
>>466の解説ではなく最後の行だという事が理解できない厨
480デフォルトの名無しさん:2007/06/02(土) 11:13:36
>>468はHibernateとばっちり書いてますけど・・・?
481デフォルトの名無しさん:2007/06/02(土) 11:16:55
>>468の内容が意味不明という話の最中に「>>466はこう言ってるんだ」とか言われても意味不明だし
その指摘に対して「同じことなんですけど」とだけ返されたってますます意味不明なわけで
482デフォルトの名無しさん:2007/06/02(土) 11:51:41

ORマッピングの話を
や ら な い か ?
483デフォルトの名無しさん:2007/06/02(土) 12:04:21
既に構築済みのデータベースに対して必死にO/Rマッピングしようとするのは馬鹿だと思います
484デフォルトの名無しさん:2007/06/02(土) 12:09:20
そんなこと無いと思います。
485デフォルトの名無しさん:2007/06/02(土) 12:11:31
>>483
そんなこと無いと思います。
486デフォルトの名無しさん:2007/06/02(土) 12:13:28
日本語を理解できない香具師らとORマッピングの話はできん
487デフォルトの名無しさん:2007/06/02(土) 12:49:06
構築済のDBにO/Rマッピングするのは別に普通
構築済のアプリに導入しようとすると苦労するだけ

新規アプリが望ましいね
488デフォルトの名無しさん:2007/06/02(土) 12:50:33
Hibernateはマニュアル読むのがめんどくさくて使ってない
iBatisのが直感的だと思うのは、単に俺がレガシーなだけかな
489デフォルトの名無しさん:2007/06/02(土) 13:58:07
dynamicとか面倒なのがなければいいんだけれどもね
JPAだとセットされたカラムのみupdateされる
490デフォルトの名無しさん:2007/06/02(土) 15:06:25
学習コストがかかるくせにいつ廃れるかわかんないからいらない
491デフォルトの名無しさん:2007/06/23(土) 11:58:40
そこでJDBCですよ。
492デフォルトの名無しさん
          人
         (_ )
        (__)
         JDBC