あぼーん
あぼーん
501:あぼーん
あぼーん
あぼーん
502:あぼーん
あぼーん
あぼーん
503:あぼーん
あぼーん
あぼーん
504:あぼーん
あぼーん
あぼーん
505:あぼーん
あぼーん
あぼーん
506:あぼーん
あぼーん
あぼーん
507:あぼーん
あぼーん
あぼーん
508:デフォルトの名無しさん
10/11/10 11:58:52
JPAでテーブルに関連付けたEntityに
「テーブルに紐付かないフィールド」を追加したいんだけどどうやんの？
エンティティクラスのフィールドは必ず何かの列にひもづいてなきゃだめなの？
509:デフォルトの名無しさん
10/11/10 23:23:35
@Transientじゃない？
510:あぼーん
あぼーん
あぼーん
511:あぼーん
あぼーん
あぼーん
512:あぼーん
あぼーん
あぼーん
513:あぼーん
あぼーん
あぼーん
514:あぼーん
あぼーん
あぼーん
515:デフォルトの名無しさん
10/11/29 22:03:52
JPAのpersistence.xmlで詰まった
tomcatのmyapp/WEB-INF/classes/META-INF/persistence.xmlであってる？
516:デフォルトの名無しさん
10/11/29 22:20:09
>>515
おれの1年半前いじっていたときのフォルダの残骸を見ると、
あっている
517:デフォルトの名無しさん
10/11/30 22:28:16
>>515
俺の適当な記憶だとクラスパス上にあるものが参照されるはず
クラスパス上に複数あるんじゃね？
518:あぼーん
あぼーん
あぼーん
519:あぼーん
あぼーん
あぼーん
520:デフォルトの名無しさん
10/12/10 00:06:13
Hibernate 3.6でSQLのバインドパラメータをログ出力する方法が分からず困ってます。
過去のバージョンではlog4jの設定でorg.hibernate.typeカテゴリのログレベルをTRACEにすれば出力されてたのに3.6では出力されません。
どなたか3.6でバインドパラメータをログ出力する方法ご存じないですか？
521:あぼーん
あぼーん
あぼーん
522:>>515
10/12/13 04:56:03
わかった。実行側（WEB-INF/lib）に
hibernate-entitymanager.libが入ってなかった。
523:>>515
10/12/13 20:28:26
java.persistence.EntityManager(実装が無いやつ)だけで動いてたから
persistence unit が見つかりませんとかエラーがでていたのか
524:デフォルトの名無しさん
10/12/16 00:58:24
>>520
私、ご存知ですよ
525:520
10/12/16 09:12:07
>>524
差し支えなければ教えて頂けますか。
526:あぼーん
あぼーん
あぼーん
527:あぼーん
あぼーん
あぼーん
528:あぼーん
あぼーん
あぼーん
529:あぼーん
あぼーん
あぼーん
530:524
10/12/22 04:05:22
>>525
traceではなくてdebugにしてみてください
531:デフォルトの名無しさん
10/12/27 09:45:42
@Entity
public class A{
@Entity
public static class B{
}
}
こんな状態なんだけどpersistence.xmlでＢがよみとれない
内部クラスの表記って以下で間違ってる？
<class>A</class>
<class>A.B</class>
532:デフォルトの名無しさん
10/12/27 10:37:07
自己解決した
$マークなのね
<class>A</class>
<class>A$B</class>
533:520
10/12/27 17:03:25
>>530
試してみたのですが、やはりダメでした…
↓こんな感じでlog4j.xmlに指定しているのですが(泣。
<category name="org.hibernate.type">
<priority value="DEBUG"/>
</category>
うーん…
534:デフォルトの名無しさん
10/12/28 15:06:01
もっと上部階層のレベルから下げて実験してみたら？
<logger name="org.hibernate">
<level value="debug"/>
<appender-ref ref="myConsole"/>
</logger>
535:520
10/12/28 18:08:00
>>534
それも試してみたんですがやっぱり出ないんです（泣
公式のマニュアルにも特に変更されたとも記述されてないし…
これはもうソースたどるしかないかなぁ。 (-_-;
536:デフォルトの名無しさん
10/12/28 19:56:50
>>535
>>534 の設定で、ログレベルの trace は試してみた？
少なくとも通常の Logging フレームワークでは、ログレベルを trace から debug に上げた場合、ログの量が減るだけで
違うログが出てくると言うことはないよ。
537:デフォルトの名無しさん
10/12/29 10:18:35
>>536
自己解決しました。
log4j.xmlのアペンダー設定のThresholdオプションがDEBUGに設定されていたというマヌケな原因でした。
お騒がせして申し訳ありませんでした。
538:デフォルトの名無しさん
11/01/10 23:41:19
S2JDBCみたいなああいう系列のマッパー使ってる人いる？
流れるなんとかってやつ
void test(){
..Query query = new Query(){
....public void build(){
......select("P.name");
......select("H.age");
......from("P", Person.class);
......from("H", Home.class);
......join( "P.key = H.key" , JOIN.INNER);
......where("P.name = ? AND H.age > ?" );
......bind(1,"人の名前");
......bind(2,"家の年齢");
......result( new ResultList(){
........void invoke(String name, Integer age){
..........Printer writer = new Printer();
..........writer.print(name, age);
........}
......});
....}
..});
..query.bind("人の名前", "太郎");
..query.bind("家の年齢", i * 10);
..query.invoke();
}
539:デフォルトの名無しさん
11/01/11 00:53:25
あれは簡単なSQL書くには良いんだけどねえ
540:デフォルトの名無しさん
11/01/11 01:55:50
まあゴミだね。すぐ消えるよ。
そして消えたあとは典型的なメンテ困難ソース。
541:デフォルトの名無しさん
11/01/13 01:01:42
評判悪いのかｗ
542:デフォルトの名無しさん
11/01/13 01:11:38
Datanucleusってどうなん？
543:デフォルトの名無しさん
11/01/13 02:27:56
>>542
知らなかったので少しググってみたけど、JDOの実装の一種なのかな。
まぁ流行らないかも知れないけど、個人的に JDO はすきだ。
Hibernate を知る前に JDO は少し追いかけていたけど、
O/R マッパーが Object → DataBase を関連づけるのに対し、
JDO は、データベースにこだわらない。
データベースにこだわった O/R マッパーのほうが実業に即していたので
いろんなフレームワークが出たし流行った。
でも JDO のほうが触っていて面白いんだよね。
なんか SmallTalk などで、一生懸命オブジェクト指向しているみたいな。
544:デフォルトの名無しさん
11/01/18 15:51:13
オブジェクト指向しすぎるとパフォーマンス悪いからかな
545:こうですか！？わかりません＞＜
11/01/18 21:28:28
まずいな～！こんなにオブジェクト指向しすぎたら
パフォーマンス悪くなっちゃってまずいな～！
546:σ‐￣)ホジホジ・・・(￣▽￣)δ⌒・ピンッ
11/01/18 23:24:51
ですよね～
547:デフォルトの名無しさん
11/01/19 07:50:44
ぼくのちんちんもオブジェクト指向しちゃいました
548:デフォルトの名無しさん
11/01/22 00:04:45
ActiveObjectsを使ってるのだけど sumとかして合計求めたい時ってどうやってやればいいんだ？
EntityManager#findWithSQLとか使おうにもEntityクラスに何設定したらいいのか分からなくて行き詰まった。。
ちなみにDBはMySQL
549:548
11/01/22 01:13:12
ああ、わかった。asを使って別名付けてあげればいいのか。
で、sumした結果はBigDecimalだから上手いこと変換してあげると必要があると。。。
550:デフォルトの名無しさん
11/01/31 07:25:43
BeanKeeperとかpBean知ってる人いる？
プロトタイプ開発によさそうだけど
551:デフォルトの名無しさん
11/02/01 00:32:07
>>550
両方とも初めて知った。
BeanKeeper 、面白そう。少しいじってみようかな。
552:デフォルトの名無しさん
11/02/01 07:21:08
>>551
ナイス 俺も調べてみるよ
553:デフォルトの名無しさん
11/02/01 07:42:47
pBeanは中に入ってたサンプルソース見る限り中途半端で使う価値ないな
BeanKeeperは実に単純でよろしい
URLﾘﾝｸ(d.hatena.ne.jp)
554:あぼーん
あぼーん
あぼーん
555:あぼーん
あぼーん
あぼーん
556:あぼーん
あぼーん
あぼーん
557:デフォルトの名無しさん
11/04/29 23:44:03.50
Hibernateは糞。異論は認めない。
558:デフォルトの名無しさん
11/04/29 23:54:30.72
むしろ異論を見てみたい
まともなのが出せるなら
559:デフォルトの名無しさん
11/04/30 00:42:12.92
>>558
そんなに異論ないほど糞なのかｗ
あれ最初の一歩から間違ってる感じがして記事くらいしか読んでないんだけど、
実際に使った人の感想は聞いてみたいんだよね。
560:デフォルトの名無しさん
11/04/30 05:06:12.70
S2もHibernateと似たり寄ったりだよなぁ。
つかiBatisだけでいいわ。結局複雑なクエリ発行したいときはSQL書くんだし。
561:デフォルトの名無しさん
11/04/30 09:34:25.37
S2はHibernateほど悪いイメージないのだが。
HQLとかLazy/Eagerみたいな糞仕様ないでしょ。
562:デフォルトの名無しさん
11/04/30 12:37:55.99
JDBCでいいじゃんｗ
563:デフォルトの名無しさん
11/04/30 13:35:08.80
SpringJDBCぐらいは使いたいわｗ
564:デフォルトの名無しさん
11/04/30 22:56:42.27
RDB使う以上、SQLは無理に避けないほうがいいんだろうな
Hibernate使って遠回りするなら、JDBCのほうがよっぽどいいと思う
565:デフォルトの名無しさん
11/04/30 23:15:30.50
一人くらいはHibernate支持者来てくれｗ
566:デフォルトの名無しさん
11/05/01 00:08:51.86
>>257
＞＞256以前のレスがあぼーんされているみたいだが、何が書いてあったんだ
まあそんなことより。
JavaDBに相応しいO/Rマッパーってなんだろう
Hibernateが最強かな？
567:デフォルトの名無しさん
11/05/01 21:38:13.81
JavaのHibernateの問題点を元に他の言語ではO/Rマッパーを上手く使ってると思う
そしてJavaだけはいつまでもJDBCレベルで作り続けていると
568:デフォルトの名無しさん
11/05/01 22:01:14.66
Javaの言語仕様だと、Hibernateより先の世界に行くのはめんどくさいし。
インテグレーテッドされた式木だとか、動的な処理とか、関数言語的な要素が入ってくると違うんだけど…。
中途半端なものしか出来ないなら、SQL書く方が良いわ、っと思う。
569:デフォルトの名無しさん
11/05/01 22:20:44.94
JavaでSQLベタ書きをメインにするのなら、自分だったらストアド使う
570:あぼーん
あぼーん
あぼーん
571:デフォルトの名無しさん
11/05/01 22:53:32.86
ストアドはデバッグしにくいから嫌い
572:デフォルトの名無しさん
11/05/02 00:58:51.44
Hibernate糞だからってJDBCってのは極端すぎるだろう…
573:デフォルトの名無しさん
11/05/02 02:43:22.78
そこでS2DAOですよ
574:デフォルトの名無しさん
11/05/02 08:19:40.04
2Way-SQLの所だけ文字列Utility化してくれれば、後は好きなマッパーでqueryなりexecuteなりするわ。
Javaだと2Way-SQLあたりが現実的な対応な気はする。
575:デフォルトの名無しさん
11/05/02 08:42:58.52
2Way-SQLは筋はいいけど条件分岐まで入れると見てられなくなりそうだな。
576:デフォルトの名無しさん
11/05/02 11:19:30.78
O/Rマッパーへの拒否反応って、だいたいO/Rマッパーそのものじゃなくて
Hibernateに対する拒否反応だよな
577:デフォルトの名無しさん
11/05/02 12:02:21.35
ここだけ５年前みたいなスレだな
Hibernateの有用性は今更疑うべくもないはずなのに糞扱いで
それに代わるのがSQLべた書き、ストアド、S2Daoって…
ネタだよな？
578:デフォルトの名無しさん
11/05/02 12:12:03.51
やっとHibernateのすばらしさを語ってくれる人が来たぞ！
579:デフォルトの名無しさん
11/05/02 12:16:37.57
> Hibernateの有用性は今更疑うべくもないはず
ならなんで全然普及してないんだろうね。
本当にいいものならもっと使われてるはずなんだけど。
煽りじゃなくてマジで疑問なんだよ。
580:デフォルトの名無しさん
11/05/02 12:46:59.14
俺としては、むしろHibernateの良さを語って俺を啓蒙して欲しい。
他の言語、例えばLINQ to SQLやArelなんかは良いと思うけど、Hibernateは中途半端というイメージがあって。
なら、2Way-SQLでいいやと思う人なので。
581:デフォルトの名無しさん
11/05/02 13:13:13.87
>579
>> Hibernateの有用性は今更疑うべくもないはず
>ならなんで全然普及してないんだろうね。
多くのプロジェクトで Java 屋さんが入る頃には腐った DB が FIX していて、
アプリからは超絶技巧のSQLを書かなきゃいけないからでは？
そういう状況なら、下手に OR マッピングをするよりは iBatis とか
S2DAO とかで直に SQL 文を書いた方が幸せ。
まともに正規化された DB を扱うなら JPA が第一候補ぢゃないの？
・JavaEE 標準技術
・使える人が多い、参考文献が多い
・たいていの JavaEE コンテナに入っている (知財部門の審査不要)
・Eclipse / NetBeans で自動生成
Hibernate を使うにしても Hibernate Entity Manager から
JPA として使う。
582:デフォルトの名無しさん
11/05/02 13:30:36.16
Hibernateも使っていないような所は、DB設計もまともにできていないような糞現場だ、
…っというのはちょっと言い過ぎだとは思うけど。
単純にDBの正規化の問題というより、必要とされるクエリのパターンの問題なんじゃないの。
単純なケース、サンプルによくあるようなWeb系のDB構造(Blogとか)みたいなものであれば、
JPA最強説に異論は無いけど。
もう少しだけ複雑なクエリを考えると、HibernateというかJavaの言語仕様的にうまく
式を表現できないんだよな～というような話じゃないのかな。
583:デフォルトの名無しさん
11/05/02 13:40:15.70
今から新たにやるならJPA？それともHibernate？
584:デフォルトの名無しさん
11/05/02 14:41:15.73
> ・使える人が多い、参考文献が多い
別に使える人も参考文献も多くないよね。
むしろ少ないくらい。まあ他も似たようなものだけど。
あと標準だってのはEJB2の悪例があるし。
585:デフォルトの名無しさん
11/05/02 20:19:37.18
>>583
JPAはインターフェース、hibernateは実装クラスの１つだと考えろ。
もちろん実装クラスを直に扱えば秘密の隠し機能も使えるから
良い面もあるかもしれんが、まずはJPA経由で使えるように
なってからの方が良い。
俺はタイプセーフなSQLがほしいな。
専用言語→コンパイル→SQL文字列get()する
javaのFactoryクラス生成とかどうよ？
586:デフォルトの名無しさん
11/05/02 20:49:09.18
SQLの文法ミスなんて適当に一度流せば分かるんだから意味ないと思うけど。
そのための2Way-SQLだし。
587:デフォルトの名無しさん
11/05/02 20:50:47.56
JPAは２でおかしな方向にいってしまったし
JavaEE自体少なくとも日本じゃ広まってないし
Java自体Oracleがめちゃくちゃやったせいで公式絡みはコミュニティ壊滅状態だしで
Javaに限ってはもう標準なんてあてにしない方がいい
588:デフォルトの名無しさん
11/05/02 21:33:23.59
S2JDBCで十分
589:デフォルトの名無しさん
11/05/02 21:45:04.65
ちゃんとした式木が扱えるとかならともかく、Fluent Interfaceしてみたいだけだったり、
Type safeにするためのメタ情報用のクラスを自動生成したりとかださいことをするくらいなら、
2Way-SQLの方が良いよ派だな、自分は。
590:デフォルトの名無しさん
11/05/03 01:02:37.12
JamiroquaiのVirtual Insanityってかっこいいなあと改めて気付かされたセッションが
終わってから描き上げた、第8話13ページ目です。
URLﾘﾝｸ(dl8.getuploader.com)
本当はマイナーペンタとブルース・スケールは成り立ちが違うみたいですけど。
違うからこそメジャーコードに乗っかるんですけどねｗ
理論的なところを細かく正確に学ぶ漫画でもないので、それは専門の教習本で
各自調べていただくような読者設定でいいですかね。
>>388
なんかうｐローダーサーバの調子が悪いみたいです。
見れなくなってるファイルがすでにいくつかありますね。
591:あぼーん
あぼーん
あぼーん
592:デフォルトの名無しさん
11/05/03 03:58:16.82
O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して
URLﾘﾝｸ(d.hatena.ne.jp)
タイムリーな投稿で、分かりやすいまとめ。
結局、ガラパゴス日本ではDDDが広まらなかったから５年遅れってことかな。
593:デフォルトの名無しさん
11/05/03 06:44:01.05
つまり、今日の日本の現場ではDDDすることなんてまず無いので、HibernateイラネっということでFA。
俺らがやってる業務システム程度では、データストア(RDB)よりの課題解決の方が有効に機能するし。
DAOをRepositoryと言い換える程度のDDDごっこをする意味も無いと言うことで。
あと、ドメインドメイン言うならHibernateとかよりもう一段オブジェクトを抽象化したものが必要だと思うし、
Persistenceな要素は敢えて排除して話をしないと変な誤解が増えるケースもあると個人的には思うけど。
594:デフォルトの名無しさん
11/05/03 09:13:39.49
個人的にはDDD自体砂上の楼閣だと思うけど、
少なくとも現実的には>>593だろうね。
RDBMS寄りの方がいろいろと楽。SQLの抽象化とか業務だと誰得だし。
Javaを使わないことはあっても、RDBMSを使わない業務システムとか考えられないし。
そしてRDBMSを使わないシステムはますますHibernateとか縁がない。
595:デフォルトの名無しさん
11/05/03 09:36:39.99
今までやってきた中では、RailsやPHPのRailsクローンFWのActiveRecord系がいちばん使いやすかった
HibernateはDBを規約通りに作ればそこそこ便利だけど、教育コストが高すぎて多人数の現場に採用できないし
少人数ならそもそもJavaでやろうと思わないしで、結局使いどころが見つからない
596:デフォルトの名無しさん
11/05/03 18:45:47.44
インピーダンス・ミスマッチを解決する作業が煩わしいって本末転倒だよな
597:デフォルトの名無しさん
11/05/03 21:18:39.36
何かやっとマトモな話題が出てるな
598:あぼーん
あぼーん
あぼーん
599:デフォルトの名無しさん
11/05/04 04:14:32.28
>>581
ｿﾚﾀﾞ！
俺もそんな目に遭ったことがある。
すでに安定(しているようにみえる)して動いているシステムに
いまさらORマッピングはしたくないみたいな
マネージャが「まだいいんじゃないかな…」とか言って
新しいフレームワークを導入してもまずそれをテストしなきゃいけないから
コストがかかるから導入しないってさ
そんなにHibernateのようなオープンソースフレームワークが信用できないかねって思いつつね
元請けが書いたコードより読みやすくて全然信用できるのに
たとえオープンソースで信頼と実績があってもものすごく拒絶するんだよね
それでなんでもかんでも自作しようとする。自作したはいいがショボくて汎用性がなくて扱いづらい
600:デフォルトの名無しさん
11/05/04 04:15:30.43
>>582
実際クソ現場だと思うよ
っていうかクライアントにDB設計させてそれに合わせて作ってる
偉そうなクライアントの野郎どもがHibernateという便利なツールの実態を知っていればいいんだけどね
601:デフォルトの名無しさん
11/05/04 09:23:53.64
オープンソースプロダクトを使うのは勝手だが、
オープンソースプロダクトに不具合があったときに
「オープンソースプロダクトの不具合なので我々では直せません」と言う
低レベルの業者はなんとかならんのかね。
てめーらの勝手で使っておいて直せませんはないだろうに。
602:デフォルトの名無しさん
11/05/04 11:04:23.38
フリーライダー。。。
レベルどうこうより、どういう契約してんだそれて思ってしまう
普通は吐けない台詞だよねえ
603:デフォルトの名無しさん
11/05/04 11:30:22.54
で具体的にHibernateのどのへんが便利なの
604:581
11/05/04 15:25:29.52
>>603
テーブル構成が
・ちゃんと正規化されていて、
・全テーブルに人工キーのＰＫ項目があり、
・ＦＫの設定もきちんと設定されているならば、
テーブル構成からＤＢアクセスプログラム（ＤＡＯ）
がサクッと自動生成されるし、
業務処理からはＤＢの行(レコード)をＰＯＪＯのオブジェクト
として扱える。
たとえば、
部署テーブル
[PK:ID] [部署コード] [部署名] [最終更新時刻]
従業員テーブル
[PK:ID] [従業員コード] [氏名] [FK:所属部署ID] [最終更新時刻]
という感じになっていれば
・ID の自動採番も、
・楽観ロックも
・(部署 1---n 従業員) や (従業員 1---1 部署) の読み出しも
ORマッパー側でやってくれる。
# 厳密には、自然キーをPK にしてもいいんだけど、
# 一律に、全テーブルに [ID] と [最終更新時刻] 列を作ってください
# ってお願いした方が間違えが少ない
その代わり、テーブル構成がグダグダだと、
直接 SQL 分を発行し、結果セット(ResultSet) を Map なり
List<Map> するくらいのフレームワークの方が遙かに楽。
605:デフォルトの名無しさん
11/05/04 16:25:51.47
なんつーか、ORMがどうこう以前の現場で働いてるの人も多いのな…。
どのレベルの話をしているのか、正直、それじゃかみ合わない事が出てきてもしょうが無いな、っと思った。
606:デフォルトの名無しさん
11/05/04 16:38:40.63
そんなレベルの話だったのかよ、っというガッカリ感。
陳腐な話というか、それこそ何年前の議論だよという感じ。
DB設計が糞だとかつまらない話ではなくて、LINQ to SQL、Entity Framework、Arelとか、
近年のORMを見てきた上で、その上でのHibernateのメリット/問題点や、DDDとか
アプリケーションアーキテクチャを考慮した上でのデータストアに対する戦略だとか、
そういう話になるのかと期待した俺が馬鹿でした。
607:デフォルトの名無しさん
11/05/04 17:32:05.60
２ちゃんねるごときにそこまで求めるのはどうかと思うよ。
608:デフォルトの名無しさん
11/05/04 17:58:22.51
Hibernateに管理されたEntityオブジェクトはトランザクション境界内で状態管理され
プロパティに定義した関連オブジェクトの遅延呼び出し、
変更したフィールドのトランザクション終了時の自動更新などの特長を持つ
よってEntityオブジェクトを基点とした処理ではDB関連の処理が隠蔽されるので
普通のJavaオブジェクトとしてロジック記述に集中させることができる
・・・と、ここら辺の特長をもって、ドメインなんちゃら関連の基盤としてアピールしてるみたい
他言語のActiveRecord系のライブラリが持つ機能もある程度揃えてはいるけど、
作られたのが古いので、後発のものに比べてあまり洗練されてはいない
609:デフォルトの名無しさん
11/05/04 19:19:44.18
この国の現場て604みたいなしょうもないレベルばかりなのかねえ
Hibernate便利（）
610:デフォルトの名無しさん
11/05/04 19:23:43.83
＿＿＿_
／ ＼ ／＼ ｷﾘｯ
. ／ （ー） （ー）＼
／ ⌒（__人__）⌒ ＼ Hibernateが使われないのは
| |r┬-| | DB設計が糞だからだお
＼ `ー'´ ／
ノ ＼
／´ ヽ
＿＿＿
／ ＼
／ノ ＼ u. ＼ ！？
／ （●） （●） ＼
| （__人__） u. | ｸｽｸｽ>
＼ u.｀ ⌒´ ／
ノ ＼
／´ ヽ
＿＿＿_
<ｸｽｸｽ ／ ＼！？？
／ u ノ ＼
／ u （●） ＼
| （__人__）|
＼ u .｀ ⌒／
ノ ＼
／´ ヽ
611:581
11/05/04 21:30:37.06
>>605-610
連休の開放感からか、場違いにも日頃の鬱憤を投稿してしまいました。
スレ汚しにはなりましたが、無かったものと思って議論をお進めください。
こっちは、Spring+JPA or JavaEE6(SessionBean+JPA) を導入して貰う
だけでも一苦労。
さらに、OR マッピングできるような DB 設計をして貰うのにもう一苦労の世界。
そこまでが限界で、アプリのアーキテクチャは、トランザクション・スクリプト
でやらざるを得ない。
もちろん当初の要件はきっちり満たしたものを作るけど、将来的な拡張性は絶望的。
最近は、世の中そんなもんだと思って、特に罪悪感もなくそんなアプリを
作ってきてたけど、目が覚めました。どうもありがとう。
ドメイン駆動デザインが当たり前で、その上で Entity 層の実装はどうある
べきかなんて今のオレには夢のまた夢の世界。まったくうらやましい
612:デフォルトの名無しさん
11/05/04 22:08:34.46
ORMとかDDD以前に、なんか勘違いしている感じがするが…
アスペか？
613:デフォルトの名無しさん
11/05/04 22:19:08.49
Hibernateやドメイン駆動に幻想持ちすぎじゃね？
俺はどっちも否定しない派だけど、>>831 が今やっていることにそれが本当に有効なの？
まあ、鬱憤の本当の原因が商流の話だったり、やってるシステムの種別だったり、
自分の立場だったりにあるというのなら、そりゃここで何かを言っても解決しないし、
職場をかえるしかねーよ。
614:デフォルトの名無しさん
11/05/04 22:22:05.25
結論としては、柔軟性抜群なiBatis系最高に落ち着くわけか
615:デフォルトの名無しさん
11/05/04 22:25:09.12
リレーショナルDBとオブジェクト指向を無理にマッピングさせようなんて
思うからインピーダンスミスマッチなんかに悩まされるんだが、
そういうのが分かってねーんだよクソオタは。
黙ってiBatisかS2Dao使ってろよアホ共が。
616:デフォルトの名無しさん
11/05/04 22:28:36.24
iBatisは今はmybatisになったらしいよ
617:デフォルトの名無しさん
11/05/04 22:37:57.92
ネーミングはちょっとダサくなったな。
618:デフォルトの名無しさん
11/05/04 22:58:47.67
S2Dao（笑）2Way-SQL（）
なんだこの結論ｗ
619:デフォルトの名無しさん
11/05/04 23:07:57.26
だって便利便利いうだけでどう便利なのか誰も言ってくれないんだもん
620:デフォルトの名無しさん
11/05/04 23:17:22.92
俺はHibernateが便利なんて言ってないけどな
LINQ to SQL、Entity Framework、Arelとか、近年のORMを見てきて出た答えがS2Dao（笑）
なんの冗談だよｗｗ
621:デフォルトの名無しさん
11/05/04 23:22:16.07
つまりJavaはオワコンということでFA？
622:デフォルトの名無しさん
11/05/04 23:24:52.27
>>621
それでいいと思う
623:デフォルトの名無しさん
11/05/04 23:50:00.74
それを言っちゃあ…
624:デフォルトの名無しさん
11/05/05 01:24:35.99
デカイ話ならDB設計とアプリ開発は別会社だし1アプリとは限らないからそれに合わせる設計もおかしい
小さい話ならそもそもそこまでコストをかけれないから他の選択肢を取る
Hibernate使うとしたらPMやPLの暴走かチーム全員どっぷり浸かってる所くらいじゃないかな
と俺は思う
S2Daoも嫌いじゃないけどな俺はｗ
625:デフォルトの名無しさん
11/05/05 01:38:52.19
だからiBatis使えっての
626:デフォルトの名無しさん
11/05/05 01:43:27.73
そんなに言うからArelの紹介記事見てみたけど、
そもそもSQLを隠蔽すること自体が目的になっててろくでもないとしか言いようがない。
一番の問題はSQLを使ってることじゃなくて、
SQLがソースに埋め込まれていて変更がしづらいことだろ。
文法を変えたところで何も変わらない。
627:デフォルトの名無しさん
11/05/05 02:04:07.48
iBatisじゃなくてMyBatis見てみたけど、これでいいんじゃないの。
少なくとも余計な概念とかトラブルの温床とかバッドノウハウだらけのHibernateよりはいい。
628:デフォルトの名無しさん
11/05/05 02:08:21.40
>>626
自分も見てみたけど、これってどっちかというとS2JDBCみたいなメソッドチェイン型Criteriaに近いものじゃない？
こういう形式はSQLベタより断然修正はしやすいと思うよ
629:デフォルトの名無しさん
11/05/05 02:16:07.47
>>628
まあ使わずに言ってるけど、
SQLの方が「直接実行できる」という大きな利点がある。なのでテストしやすい。
あとちょっと複雑なクエリになると難しい。
サブクエリのサブクエリを含むSQLくらいは普通にあるけど、この方式だと無理だよね。
S2JDBCはJavaだからIDEでの補完が出来る利点はあるけど、
これにはその利点はないし。
630:デフォルトの名無しさん
11/05/05 03:46:51.09
業務アプリはDBの参照・更新がメインなんでSQLを直接扱えるiBatisが一番だと思ってます。
悩みはDBベンダ依存のSQL。
大抵のSI案件はDB固定だろうけど、規模拡大とか横展開とかしてDB変えるときは
どうするのがいいんだろ。
外部結合とかCASE文あたりはSQL標準形式で書けばいいとして、日付とか文字列関数
とかキーの値生成とかがいちいち違うからなー。
631:デフォルトの名無しさん
11/05/05 11:03:29.65
>>629 にもあるけど、サブクエリのネストとか、その辺をサポートしているかどうかが
SQLを書かないタイプのORMを採用できるかどうかの分水嶺な気はする。
勿論、SQLの代わりにxQLみたいなものを書くとか、富豪的アプローチは無しで。
後、本当に複雑なクエリはストアドでやったり、そもそもOLTPとOLAPを分けたりするので、
それは除外するで良いとして。
っで、Javaでこの辺をサポートしているSQLを書かないORMてあるの？
この辺をサポートしようとすると、Expression Treeとか遅延評価とかが必要になりそうで、
Javaでは言語仕様的に難しい気がするんだけど。
タイプセーフにするために列名や演算子のメタデータクラスを作って、staticインポートして、
みたいなモドキはあると思うけど、そのレベルならSQL書いた方が良いわ、っと思う。
＃その種の事を自分ではやっていたりもするけど…
これが、俺の考えるHibernateとかが採用されない理由。
632:デフォルトの名無しさん
11/05/05 12:42:21.07
> 勿論、SQLの代わりにxQLみたいなものを書くとか、富豪的アプローチは無しで。
採用されない理由っていうか、採用しない理由を必死に考えたみたいな話だなｗ
そもそも日本以外では採用されてるんだし
633:デフォルトの名無しさん
11/05/05 12:45:17.41
別にHibernateでも他のO/RマッパーでもSQLをそのまま書くことも可能なんだから
全ての記述をSQLに拘るのが理解できない
難しいのだけとか言ってないで、全てストアドで書けばいいんじゃない？
Javaでは単なる文字列に過ぎないSQLもソースとして解釈できるようになるのに
結局、Javaでしか仕事が出来ない人の言い訳にしか聞こえない
634:デフォルトの名無しさん
11/05/05 12:55:49.60
VIEW使うのが簡単だけど、それはDDDじゃないとかファビョる。
xQL使うとか言うけど、学習コストは無視。
N+1問題とかなかったことにする。生産性重視と言いつつテスト段階で出た
パフォーマンス問題が生産性を落とす原因になってるのに気づかない。
635:デフォルトの名無しさん
11/05/05 13:09:37.56
お前ファビョりすぎだろｗ
636:デフォルトの名無しさん
11/05/05 14:10:23.30
MyBatis 3系の使い方紹介ってどこかにある？
マッパーインタフェース使って、Springと連携させて、なるべく楽に処理を書きたいんだけど。
637:デフォルトの名無しさん
11/05/06 20:07:43.41
MyBatisはResultMapがちと面倒だな。
DBのUnderscoreとBeanのCamelを変換するだけで書かないといけないし。
SELECT句の方にASを書くのもどうかと思うし。
この辺をStrategyにして交換できるようにしてくれれば良いんだけどな。
そうすれば、JPAの@Columnアノテーションを使ったマッピングとかもできるのに。
MyBatisの@Results/@Resultアノテーションだと、マッパーのメソッド毎に書かないといけないし、
なんだそりゃって感じだが。
638:デフォルトの名無しさん
11/05/06 20:38:01.63
なんだそりゃゴミだな
639:デフォルトの名無しさん
11/05/06 21:02:28.38
とりあえず、
org.apache.ibatis.reflection.Reflector.findPropertyName()
を弄ればネーミングルールの変更には対応できるみたいだけど。
つーか、ソース見たけどMyBatisは全般的に拡張ポイントとか弱いな。
Strategyにしておいてくれればカスタマイズできるのに、っという所があって。
SELECT時のマッピングに関して言えば、Spring JDBCみたいにRowMapperを指定できるようにして欲しいわ。
640:デフォルトの名無しさん
11/05/06 21:21:31.03
myBatis(iBatis3)はわりと出たばっかだからな。
ちょっと前までSpring連携も非対応だったし。
641:デフォルトの名無しさん
11/05/06 22:56:46.37
むしろiBatis時代から古い作りのままって事だろ。
642:デフォルトの名無しさん
11/05/07 14:37:10.74
>>633
ストアドとJavaじゃ、デバッグ効率が天地。
643:デフォルトの名無しさん
11/05/07 16:39:00.54
ついでに聞かせて。
ストアド主体の場合って、単純なCRUDや、ちょっと条件句が異なるだけのクエリも全部ストアドにするの？
その作成、修正コストって結構なものになったりはしない？
誰が書いても違いの無いレベルのクエリはORMに自動生成させて、それ以上のものはストアドっていう
切り分けも現実的なケースかとは思うんだけど。
644:デフォルトの名無しさん
11/05/07 16:44:39.75
ストアドは積極的に使うものではないと思う
645:デフォルトの名無しさん
11/05/07 21:48:40.32
この辺については、全部ストアドでやればっていう人達の意見を聞きたいな。
646:デフォルトの名無しさん
11/05/07 22:03:36.19
開発効率、移植性、保守性どれも低いからな
あんな2階層時代の遺物なんぞ今更誰が好き好んで
647:デフォルトの名無しさん
11/05/08 00:51:12.63
PostgreSQLで全部ストアドにしてiBatisからcallしたんだ。
普通にselectするだけのSQLだったんだけど。
ストアドよりSQLのが速かった…。orz
だからバックグラウンドで処理しなくちゃいけないのしかストアドにしてないよ。
648:デフォルトの名無しさん
11/05/08 00:54:54.33
確か同じ内容のSQLだったかなぁ…。
もう細かいとこまでは覚えてないけど。
ストアドのが極端に遅かったのだけ覚えてる。
649:デフォルトの名無しさん
11/05/08 01:17:29.81
>>640
URLﾘﾝｸ(www.h3.dion.ne.jp)
Spring + MyBatisの連携はSpring + iBatisの連携と大して変わらんかった…。
つか、MyBatisとSpringの連携はSpring3.1からだったかと。
650:デフォルトの名無しさん
11/05/08 01:19:31.36
MyBatis + SpringでもSelectBuilder使いたいなぁ…。
651:デフォルトの名無しさん
11/05/08 01:22:01.57
私の場合バッチ処理が遅すぎてどうしょうもないときにストアドで書き直してました。
バッチ処理というからには複数行のデータを一括でまとめて更新すればいいんでしょうけど、
複雑な分岐が入るような処理になると対象を一件ずつ処理する設計になりがちです。
すると、SQLでデータをDBから転送してJavaなりでロジック処理して更新SQLを実行という
形になるけど、ストアドなら全てDB内で処理されるので転送処理の時間が節約できるわけです。
大量のデータを処理する場合だとかなりの時間節約になります。
652:デフォルトの名無しさん
11/05/08 01:32:18.14
INSERT/UPDATEの場合はそうなるかなぁ？
>>202 のやり方で遅いとなるとストアド化するしか無いような気はする。
653:デフォルトの名無しさん
11/05/08 10:26:28.12
だからストアドは仕方なく使うもので
>>651みたいに、これでストアドは神と認識して
なんでもかんでもストアドにしようとする思考に入って
しまうようなやつが多すぎる。勘弁してほしい。
654:デフォルトの名無しさん
11/05/08 10:29:20.97
>>653
のような、文章に書いていない事を妄想してしまう人はSEやPGに向いていない。
655:デフォルトの名無しさん
11/05/08 12:13:43.13
>>652
>>202のやり方は結構な件数でも遅くないけど上限がある
656:デフォルトの名無しさん
11/05/08 12:14:06.58
今更だけど、Hibernateが採用されない現状を訴えるときに、
本当にgdgdなDB設計(最近、さすがにこういうのにはお目にかからない)と、
DOA的には問題無いがORM向きにはなっていないDB設計とをいっしょくたに扱うなは勘弁な。
657:デフォルトの名無しさん
11/05/08 12:34:01.37
ストアドはアセンブリ言語のようなもの
使いどころはあるけど常に使うものじゃない
658:デフォルトの名無しさん
11/05/09 01:46:16.77
>>606
間違ってもJavaにLINQ・ラムダ式は導入しないで欲しいと願う。
あれやるなら別ファイルでやろうよ
Apache Verocityみたいな感じで
659:デフォルトの名無しさん
11/05/09 01:47:08.77
>>610
実際クソすぎてHibernateの真価がほとんど活かされず
誤解されている頭の悪い現場もあるがな
660:デフォルトの名無しさん
11/05/09 01:48:05.98
>>611
いってることはほとんど同意だし、鬱憤にも見えないが
JPAってHibernateより難しくないか？
661:デフォルトの名無しさん
11/05/09 20:14:49.17
>>658
心配しなくても、Javaでラムダが使えるようになるのなんていつかわからないし、
式木の話も無いから真LINQが導入されることも無いでしょ。
それ以前に、1.4を使い続けている現場とかも多いんでしょ。
似非LINQというか、内部DSL型は正直イマイチだと思うし、俺もJavaでは
テンプレート処理が出来る外出しSQLとDAOのメソッドを関連づけるような
フレームワークで良いと思うわ。
662:デフォルトの名無しさん
11/05/12 15:42:03.97
そもそもまともに正規化されたdbを期待するのが無謀。
そこはハイバネ用に最適化したdbでも、まともに正規化されてるとはいえないわけで。
java以前のコボラ環境の業務システムなら、コボル前提のdbに最適化されてて当たり前。dbの柔軟性こそが最適化原理主義の障害に成っている。
データベースは過去のデータが資産だから、全面的にdb載せ変えでもしない限りハイバネで扱いやすいdbに変えていくのは難しい。
結局は過去のシステムとの連携でsql駆使して回避できたほうが小手先菊からハイバネ導入せずに使いにくくてもjdbcでがんばったほうが効率的に成ってしまう。
javaにシステム移行で、過去のデータ無しで新規に仕切り直しで始められるのでもなければハイバネ採用は厳しいと思う。
ハイバネに限らずオープンソースの保守は面倒な問題だね。
業務システムなら開発時の環境で１０年とか運用したりもするから、１０年後まで保守し続けれるのかとか問題が発生する。
オープンソースの開発成果にただ乗りして導入したのは良いけど、早々に開発討ち切られて自分で保守なんてことになるくいらいなら、ハイバネより糞でも困らない程度に自分たちで保守できる独自フレームワークに成ってしまうのは仕方ないと思う。
まだ1.4vm用にオープンソースのフレームワークをバックマージし続けてメンテしてる業務システムなんて皆無だろ。面倒見きれないと放置に成るのがヲチ。それなら保守性が高いと主張されることの多いオープンソースを導入したメリット無い。
１０年稼働に対応してくれる商用フレームワークも高額過ぎて手が出ないだろうけど。
あるいはphpやror的に使い捨て言語で凌いで、後で苦労することには目をつぶってしまうか。
663:デフォルトの名無しさん
11/05/12 23:26:52.74
>あるいはphpやror的に使い捨て言語で凌いで、後で苦労することには目をつぶってしまうか。
このチョイスに素晴らしいセンスを感じる
664:デフォルトの名無しさん
11/05/12 23:34:56.56
普通じゃないのか？
・使い捨てならRoRなど楽なのを使う
・10年持たせるなら最初大変でもJDBCか薄いフレームワークを使う
Twitterとかまさにそれで最初はRoRだったのが大きくなるとJavaでごりごり書いてる。
Hibernateとか出る幕なし。
665:あぼーん
あぼーん
あぼーん
666:デフォルトの名無しさん
11/05/13 03:33:39.20
実際ウェブ屋に発注すると後先考えないシステム納入してくれるよｗｗｗ
まあie10の事も考えてウェブ作れとか無理なんだろうけど。
667:デフォルトの名無しさん
11/05/16 13:21:14.30
おまいら、(やや過去とループ気味だけど)面白い議論してるな。
乗り遅れた! 4年ぐらい前の、 Java⇔RDB スレが盛り上がっていた頃を思い出したよ。
1年前だけど、似たような展開のスレ↓
ドメインモデル VS トランザクションスクリプト
ｽﾚﾘﾝｸ(php板)
668:デフォルトの名無しさん
11/05/16 14:20:59.60
ドメインモデルよく知らないけど、
データベース側とJava側でそれぞれモデルを作って
それをHibernateでマッピングさせるとかアンチパターンにしか見えない。
669:デフォルトの名無しさん
11/05/16 21:16:48.25
ちょっとしたアプリを作る場合、cayenneが一番すき。
670:デフォルトの名無しさん
11/05/16 21:36:09.72
DDDの話をしたがる人はさ、どうして直ぐにPersistentな話に絡めたがるのかね？
しかも、しょぼい業務アプリみたいなものをモデルにして。
個人的には、ドメイン駆動が効果を発揮するのって、計画とかシミュレーションとか、インテリジェントな
思考モデルを扱うときだと思うんだけど。
っで、そういうモデルとRDBの構造には当然差異があるので、高度なマッピングフレームワークを使用して
Repositoryを作る…っという話なら分かるんだけど。
それが、データを画面に表示するだけの簡単なアプリケーションで扱うような、たかだかデータ構造的には
親子関係しかないようなものを持ち出して、それでやれDDDだHibernateだ言うからアンチを増やす結果にも
なっていると思うんだよね。
DDDの話をしたいなら、むしろPersistentな話が関係ない所にすべきだと思うわ。
671:デフォルトの名無しさん
11/05/16 22:10:07.61
>>670
そんな気がする。
あとよく分からんけどHibernateにあるようなキャッシュ機構は
業務システムではむしろトラブルの元で邪魔な気がする。
そういう意味でも業務システムとは相性が悪いんじゃね。
672:デフォルトの名無しさん
11/05/16 22:29:28.77
>>670
いったい誰と戦ってるわけ？
どのレスの事を言ってるのかよく分からん。
むしろこのスレではアンチが必死に粗探しばかりしてるように見えるんだけど。
ていうか、ここはORMのスレなんだからPersistentな話をするのが当然だし
670の個人的な考えとか>>667のリンク先のことを言ってるのなら勝手にそっちでやれば？
673:デフォルトの名無しさん
11/05/16 22:56:40.56
みんなHibernate嫌いなんだな。
キャッシュが楽だったり、排他も楽だし、少人数でアプリ作るときは、
大規模でやるような基盤チームつくれないから結構いいとおもうんだけど。
674:デフォルトの名無しさん
11/05/16 23:03:05.35
○○というフレームワークは最高！
ただし、そのフレームワークが想定する問題を解決する範囲のみにおいて。
675:デフォルトの名無しさん
11/05/17 17:10:53.53
想定してない津波でメルトダウン発生したしなあ。
想定してない障害児にはフレームワークは役に立たない。
676:デフォルトの名無しさん
11/05/17 21:45:48.45
フレームワークじゃなくてシステムだな
677:デフォルトの名無しさん
11/05/18 17:37:18.90
つうか、なんでこのスレをアニオタのキモオタが荒らしていたの？
ああいうのって、水遁の術で撃退できるからまあどうでもいいとも言えるんだけど
なんでこのスレが狙われたんだ？
678:デフォルトの名無しさん
11/05/19 00:06:47.49
科学と魔術が交差するとき、ローソンでキャンペーンが始まる。
とある飲料の販促活動キャンペーン 5/24(火)～6/6(月)
URLﾘﾝｸ(www.lawson.co.jp)
679:デフォルトの名無しさん
11/05/19 00:44:26.11
とある魔術の禁書目録
上条当麻：森久保祥太郎
インデックス：阿澄佳奈
御坂美琴：竹達彩奈
月詠小萌：花澤香菜
ステイル：大川透
神裂火織：能登麻美子
一方通行：宮野真守
土御門元春：小野坂昌也
680:デフォルトの名無しさん
11/05/20 00:14:38.10
『とある魔術の禁書目録Ⅱ』第６話に関するQ&Aができたよー
URLﾘﾝｸ(yunakiti.blog79.fc2.com)
681:デフォルトの名無しさん
11/05/21 00:33:40.89
HibernateでDDD最高！、っていうサンプルはどこかにある？
682:デフォルトの名無しさん
11/05/21 01:26:23.11
あるあるｗｗ
683:デフォルトの名無しさん
11/05/21 16:27:57.90
結局これを見ろって言うものはないのか。
ぱっとしねーなー。
684:デフォルトの名無しさん
11/05/25 00:05:31.25
イカ娘第2期のスタッフ発表でイカスレが通夜会場になっとる
685:デフォルトの名無しさん
11/05/26 02:42:48.47
GORMはそろそろ使えるようになってる？
686:デフォルトの名無しさん
11/06/21 01:01:16.94
余裕で判別可能
URLﾘﾝｸ(blog-imgs-30-origin.fc2.com)
687:デフォルトの名無しさん
11/06/21 02:00:08.12
"ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない"
URLﾘﾝｸ(tech.a-listers.jp)
・ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
・効率はどんなプロジェクトでも最初の頃は十分。
・不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、
抽象化は破綻し、開発者はSQLを使わなければならなくなる。
・ORMの抽象化はほぼ100％のプロジェクトで破綻する。
・オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
・不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り
簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
・オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。
これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。
688:デフォルトの名無しさん
11/06/21 02:09:05.83
こっちくんな
689:デフォルトの名無しさん
11/06/21 08:45:45.65
外人は率直に言うなｗ
690:デフォルトの名無しさん
11/06/21 09:55:10.57
>>687の記事ってHibernateみたいな
複雑なフレームワークがアンチパターンと言ってるだけで、
MyBatisみたいなのは否定してないんじゃない？
むしろこのスレの大多数の人が思ってることと同じ。
691:デフォルトの名無しさん
11/06/21 13:20:12.80
オブジェクト関係マッピングはアンチパターン ?
URLﾘﾝｸ(slashdot.jp)
って、ソースは >>687 か。
速攻でHibernateがdisられててﾜﾛﾀ
692:デフォルトの名無しさん
11/06/21 21:32:01.27
そもそもORMって別にSQL排除が目的じゃないよな
なんか今はそれが目的になってる感じだけど
693:デフォルトの名無しさん
11/06/21 21:58:06.21
MyBatisとDBUtilsだけでなんでもできるわ
694:デフォルトの名無しさん
11/06/21 22:41:43.30
ORMな人ってSQL書いたら負けとか思ってそうでキモい
695:デフォルトの名無しさん
11/06/21 23:12:40.22
SQLではなくJPQLとか、無駄に冗長なCriteriaを使えば良いんですとか、そんなこと言っているところがなおキモい。
696:デフォルトの名無しさん
11/06/22 01:54:48.02
なんだろう・・・めんまはインなんとかさんを思い出させるんだよね・・・
697:デフォルトの名無しさん
11/06/22 02:34:52.91
最適化考えたら結局sql弄ることになるしなあ。
sql埋め込むのに抵抗示すけど、じゃあ汎用命令でパフォーマンス出せよとw
pl/sql,transact-sql,sqlステートメントを使う分には問題ないとは主張に穴空きまくりだね。
698:デフォルトの名無しさん
11/06/22 07:16:18.77
もともとオブジェクト指向と言われてるオブジェクトが
本来のオブジェクトを指してないんだから
言語が矛盾してんだよ
オブジェクトであるべきはテーブルや内包される列なのにwww
699:デフォルトの名無しさん
11/06/22 21:34:21.92
保守性とか可読性とか生産性がSQL排除でSQL使うときより上がればいいんだけど
贔屓目にみても下がるからな
やっぱJDBCでよくね？
700:デフォルトの名無しさん
11/06/22 22:10:22.07
いいんじゃね？
701:デフォルトの名無しさん
11/06/22 22:11:41.46
スクリプト言語とJavaを比べて「ほーらスクリプトの生産性はこんなに高い！」
っていってステップ数比較するときの、Java側の長ったらしいコードはだいたいHibernateだな
702:デフォルトの名無しさん
11/06/22 22:32:01.01
せめてDbUtilsくらい使えよｗ
703:デフォルトの名無しさん
11/06/23 02:54:24.72
ハイバネが１０年後にもメンテされて使われてるって分かってれば導入するけどねえ。
あっさり消えてる可能性が高いオープンソースだと導入するのはリスク高過ぎる。
ついつい枯れ切ってるjdbcでいいじゃんとか保守契約前提で商用フレームワ－くに頼りがち。
オープンソースのフレームワークのサポ－ト自体では飯喰えないからな。担当の業務システムのサポートをきっちりと行ってこそ飯喰えてる訳で。
704:デフォルトの名無しさん
11/06/23 05:13:26.65
>あっさり消えてる可能性が高い
禿
705:デフォルトの名無しさん
11/06/23 07:41:26.05
商用だって10年保守されてるとは到底思えん。
そんなときソースがオープンな方が最終手段が取れる分、リスクが低いと思うけどなぁ。
706:デフォルトの名無しさん
11/06/23 08:33:00.09
>>705
Hibernateのソースコードをメンテしたいと思うかい？
707:デフォルトの名無しさん
11/06/23 12:02:19.04
jdbcは無いだろ。せめてMyBatisぐらい使えよ。
どうせ自前で似たような仕組み作っちゃったりするんだろ？
俺々フレームワークメンテするよりは名前知られたOSSの方がまだマシ。
708:デフォルトの名無しさん
11/06/23 14:49:17.10
だからさ１０年前のオープンソースをメンテしてみろってw
１０年前のwin2000とかまだ普通に動いてるぞw
709:デフォルトの名無しさん
11/06/23 15:33:15.59
10年前のオープンソースと言ってもピンキリだろ。
710:デフォルトの名無しさん
11/06/23 16:20:42.13
10年前のオープンソースの方が、10年前に前任者が作ってそれきりなソースよりナンボかマシ。
後者が前者より高品質なことはめったに無いし、資料も無かったりする。
前者ならまだ知ってる人や資料を見つけやすい。
どっちもピンキリはあるけど。
711:デフォルトの名無しさん
11/06/23 22:32:19.42
Batis系のORMとSQL排除系のORMはわけたほうが混乱しなくていいよな
目指すところが同じORMでも全然違う気がするし
712:デフォルトの名無しさん
11/06/24 01:08:42.41
MyBatisって、DbUtilsに毛が生えただけだろ。
良くも悪くも。
713:デフォルトの名無しさん
11/06/24 11:52:16.42
>>712
おまえ iBatis とか MyBatis とかつかったことないだろ
714:デフォルトの名無しさん
11/06/24 11:56:52.71
そもそもソースコードからSQLを分離したいという発想がダメ
715:デフォルトの名無しさん
11/06/24 12:00:03.28
そういや、ソースコードからSQLを分離するメリットって何？
716:デフォルトの名無しさん
11/06/24 12:02:41.59
条件を修正したい時に再ビルドが不要とか。
VIEW使えばいいという話もあるが。
717:デフォルトの名無しさん
11/06/24 12:18:22.71
そこら中に同じようなSQLがコピペされるのを抑止する。
別ファイルにSQLを集約することで、SQLの保守性が向上する。
ヒント句足さなきゃいけないとか、テーブル分けるとかなったときに圧倒的に楽。
性能問題で調査するときも、SQL詳しい人にSQLだけ見てもらうとかできる。
Javaなりのソースから長ったらしいSQLを分離することで、
プログラム側の可読性も向上する。
ビジネスロジックとDBアクセスのための手続きとSQLを
全部ごっちゃにして書くバカが悪さできないようにする。
718:デフォルトの名無しさん
11/06/24 13:01:29.79
SQLもビジネスロジックだからなー
719:デフォルトの名無しさん
11/06/24 13:20:43.23
SQLはビジネスロジックでもSQL文生成はビジネスロジックでは無くて、
それがごっちゃになってるのは多々見た。
720:デフォルトの名無しさん
11/06/24 13:44:41.64
>>703-704 を呼んでいて思ったけど、
Hibernate は今後メンテされないのかな？
なんだかんだで長生きすると思うが。
そりゃ2003-2005年ごろはアップデートも頻繁にあったし、
いまは停滞している気もするけど、なんだかんだで使っている層はそれなりにいると思うんだよね。
いまは、フルマッピング形ORMを使うとしたら、Hibernate そのものというより JPA なのかな。
OpenJPA、EclipseLink はまだまだバージョンがあがっていくのだろうか。
721:デフォルトの名無しさん
11/06/24 13:59:36.26
個人的体験としては、今までSQLを別ファイル化して良いことなんか無かったな。
分けた方がかっこいいかなと思って分けてただけ。
国際化の予定が皆無なのに文字列リソースを分けるコーディングをした時のような気分。
Javaにヒアドキュメントや複数行文字列リテラルが有れば、気分も変わりそうだが。
722:デフォルトの名無しさん
11/06/24 21:27:16.57
お前ら数千行のゴリゴリSQL条件組み立てロジックをメンテさせられた苦い思い出ないの？
アレ経験してたらSQL切り出す事の良さ痛感する
SQL書かないまで行くとやり過ぎな気がするけどね
723:デフォルトの名無しさん
11/06/24 21:34:23.57
それは数千行のSQLを書くのが悪いんじゃないの？
724:デフォルトの名無しさん
11/06/24 21:47:36.81
ごめん。
725:デフォルトの名無しさん
11/06/24 22:22:57.13
数百行のSQLが散在したJavaコードで、動的にWHERE句とか
文字列連結して生成してるのは割とよく見かけるし、
何度か保守させられた。
修正クソ大変で、ちょっと間違えると
特定パターンだけシンタックスエラーとか言われるし、
たいがいの場合SQLインジェクションの脆弱性も埋め込まれてるので、
SQL切り出さない奴は首つって死ぬべき。
まあ動的に条件変わるようなのは、SQL切り出しても面倒なんだけど。
726:デフォルトの名無しさん
11/06/24 22:29:20.11
「SQL切り出し」とは？
727:デフォルトの名無しさん
11/06/24 22:42:47.41
>>726
他言語のコードにリテラル文字列として埋め込まれたSQL文を何らかの形で
分離・集約して管理すること。
728:デフォルトの名無しさん
11/06/24 22:52:39.58
>個人的体験としては、今までSQLを別ファイル化して良いことなんか無かったな。
のことですね
729:デフォルトの名無しさん
11/06/24 22:58:36.67
SQLリテラル派だけど、動的に文字列連結なんかしねえよ。
730:デフォルトの名無しさん
11/06/24 23:05:20.05
view作っておいてwhereとorderbyだけ連結(といってもダラダラ書くんじゃなくて生成器にする)でしょ
731:デフォルトの名無しさん
11/06/25 17:09:46.21
経験的には分けるメリットは感じられなかったな。
システムの利用者がどんな情報を求めてるかも会わせて作り込むことがほとんどだったし。
普段の仕事でも実際の仕事する人が別に居て伝言ゲームしてたりする状況に仕事しやすいと感じちゃってるとか？
プログラマ思考的に、プログラマはプログラムの仕事さえ遣ってれば、顧客と会話することも上司や同僚と会話することも無駄とmvc的に分けて別の人に任せたほうがいいと思ってるとか？
732:デフォルトの名無しさん
11/06/25 19:11:45.51
>>730
それだとHibernateのCriteriaクエリと一緒になるんじゃね？
733:デフォルトの名無しさん
11/06/25 20:33:44.60
>>731
伝言ゲームは最悪だが、MVCの分割や役割分担には意味があるぞ？
一人のプログラマにJavaもSQLもHTMLもJavaScriptもCSSも全て精通していろ、
というのは今となっては無茶な話だ。
必ずしも分けろとは言わないが、SQLだけ特定のパッケージに集約なりは必須だろ。
734:デフォルトの名無しさん
11/06/25 20:37:16.98
対象とするシステムの種別によって、動的な組み立ての必要性は大小があるよね。
集計済みの結果を表示するものなら不要。
検索条件の有無、ページング、ソートありなものなら必要。
735:デフォルトの名無しさん
11/06/25 20:59:13.02
＞一人のプログラマにJavaもSQLもHTMLもJavaScriptもCSSも全て精通していろ
別に無茶じゃないと思うが・・
ドカタコーダーとばかり仕事しすぎじゃね？
736:デフォルトの名無しさん
11/06/25 21:04:52.82
世の中のSEを名乗る人材の９割は土方以下のコーダー。
そういう人たちを使って仕事を回す知恵も必要だよ。
恵まれた環境でしか保守できないようなプロジェクトじゃ
成り立たない現場もある。
737:デフォルトの名無しさん
11/06/25 22:08:27.27
なんという三姉妹
URLﾘﾝｸ(brunhild.sakura.ne.jp)
738:デフォルトの名無しさん
11/06/25 22:36:53.09
>>735
どんだけスーパーマン有り気な仕事してんだよｗ
その基準で仕事したら世の中の大半の職場は回らないよ。
仮に全部やってますって奴がいても、HTMLがテーブルでレイアウトしてたり、
プログラムが中途半端だったり、全部プロレベルの超人なんてまずいねーよｗ
739:デフォルトの名無しさん
11/06/25 23:57:07.30
精通のレベルにもよるがJavaもSQLもHTMLもJavaScriptもCSSも一通り分かるのって普通じゃ？
まあうちは少数精鋭かもしれんが、他の会社どれだけレベル低いんだよ…
740:デフォルトの名無しさん
11/06/26 00:10:22.34
JavaとSQLはセットだし、HTMLとJavaScriptとCSSもセットだから実質2つだな
プロレベルっていうのがすごく抽象的だからあれだけど、とりあえず普通の仕事でつかえる程度のレベルなら
つかえないやつのほうが少ないと思う
741:デフォルトの名無しさん
11/06/26 00:15:58.33
CSSは例えが悪すぎる。デザイン重視のサイトならデザイナに外注すべきだろ。
JavaとC++とアセンブラに精通していろ、ならスーパーマンかもしれんが
SQL,HTML,JavaScriptあたりはJavaでWeb系やってりゃある程度精通するだろ。
もちろん向上心ない奴ならいつまでもダメだろうが、そんな話じゃないよな。
742:デフォルトの名無しさん
11/06/26 00:43:13.55
WebKitw
743:デフォルトの名無しさん
11/06/26 06:56:40.37
最近はブラウザ側のコーディング比重が大きくなっているから
DBアクセスとビジネスロジック・コントローラまでを担当するサーバ側と
Viewを担当するクライアント側に分けて開発者集めればいいんじゃない？
744:デフォルトの名無しさん
11/06/26 09:23:26.73
最近は社内にデザイナーも雇わないと失注するな
厳しい世の中になってきた。
745:デフォルトの名無しさん
11/06/26 10:53:27.06
SQLファイル外出しの利点の1つはCRUDの調査をSQLファイルのみ
grepすればできるところ。あとはeclipseでそのSQLを呼び出している
メソッドを見つけて、Javaからどうやって呼び出しているかを見ればよいと。
あと、ビューでもservletから文字列出力で作るよりテンプレートエンジンで
作るほうが、どんな出力になるかの見通しがいいですよね。
テンプレート見ればだいたい想像がつく。
SQLだってテンプレートを元に作るほうが見通しがいいわけです。
バインド変数があるからビューのテンプレートエンジンと同じものは
使えず、SQL専用のものが必要ですが。
で、MyBatisはまさにそういうものかなと。Hibernateとかは全く別ものだけど。
746:デフォルトの名無しさん
11/06/26 13:20:42.48
SQL外出しなら別にHibernateでも出来るから
そこがORマッパーの違いというほどの機能でもない
747:デフォルトの名無しさん
11/06/26 18:17:40.57
/ | ／: : :／: !:/ !ハ: : !Vい: ::!
/ :| /: : :/ Ｔ ナー匕 Ｖﾄ､_レ:┌――――┐
/ ' /: : :/ r ⌒` '⌒V: | 青の祓魔師 .|
｀＝ニニニV: : : :| ヽ ﾋﾘ ﾋ} 〉.| 出演依頼の .|
{｜: |: |: : :! ` ｰ , ｰ‐ ! .| お知らせ |
'. j :ﾑ:|∨:', !: r―-､ r―ﾍ
∨: :{ r|: :ﾍ ／￣ ｱ' 人/ 二ﾆ> (二 }
/: : : ヽ|: :|: :ヽ ､ こ＿ ﾉ ,∠.: :/ つ (二.,}
／ : : /: :/: :| : : ＼` ｰr＜ >' ノ
748:デフォルトの名無しさん
11/06/26 20:38:11.74
スレチだけど、うちは社内にデザイナーいるよ。
最近のシステム開発は、技術のニーズがエッジ(UIのリッチ化、データストア処理の最適化)よりになってきている気はする。
749:デフォルトの名無しさん
11/06/27 11:08:40.24
>>748
> データストア処理の最適化
って具体的にはどういうこと？
RDBに入れていたのを、データ件数が多くなって検索処理をあげるために、NoSQLに移行しました、見たいなの？
ちょっと違うかもしれないけど、最近BIツール、あるいはBI的な機能への要求が多くなってきた。
スクラッチで検索画面、登録画面を作っても Excel みたいに柔軟に情報検索したりグラフが描けない。
でもまともなBIツールはないし、高いんだよな。おれたちもJava開発は知識があっても、BIツールの使い方は詳しくないし
750:デフォルトの名無しさん
11/06/28 03:02:02.28
cssってデザイナ任せでも仕事料減らないからなあw むしろ仕事増やしてくれる元凶w
css入りhtml5とjavaのマッピングフレームワーク無いの？
java的に使いにくいcssを作り出すのを抑制する機能がアドビのつ－るに有ればいいのに。
ジャバ側である程度仕様決めてビューのマニュフェストをxmlで吐いて、それをアドビツールで読み込むとちゃんとjava側を考慮してそのまま使えるhtml5を吐き出してくれるとかw
自分でデータベース系のサイト組んだことあるデザイナとしか仕事したくないw
biは求められてもちょっと違う気がする。sap的にbiの一部を切り抜いて定型業務化されたお決まりのものなら組み込む意味あるけど、
biを使いこなして新たな収益を見つける様なのだと、顧客情報や企業ノウハウの流出に考慮した上での、biツール専用のオンメモリデータベースを用意して業務データベースから定期バッチでレプリケーションして
業務に支障を与えない様に自由に儲かる何かを探し出してもらったほうが糞高いbiツールの元が取れそうに思うけどね。
おれらがデータベースを駆使して儲ける方法まで探してやるのは何か違うし、仮に儲けること探すなら経営者として事業部長を拝命するなりしてそれなりの報酬貰わないと割に合わない気がするw
まあそれよりit馬鹿のままじゃ全然無理過ぎるから、経営系の大学に入り直したほうがいいかもしれないw
751:デフォルトの名無しさん
11/06/28 05:54:24.94
まずは改行を覚えた方が良いと思うよ
752:デフォルトの名無しさん
11/06/28 08:19:55.38
>>750
Javaでコントロールしようと考えるのがまずおかしい
クライアントとサーバでしっかり切り分けろよ
753:デフォルトの名無しさん
11/06/28 08:36:09.67
典型な知ったかだなｗｗｗ
754:デフォルトの名無しさん
11/06/30 00:47:01.46
>>750
Eclipse3.7で導入されたWindowsBuilder使ってGWTやれ。捗るぞ。
755:デフォルトの名無しさん
11/07/01 18:52:02.50
ウチの場合はBIっつうか、役員連中がよく分からない基準で、
営業成績とか売上状況をいろんな切り口から見たい、って駄々こねて、
情報システム部がその都度SQL書いたりして頑張ってる、ってケースが多いな。
直感的なグラフでバーっと表示して、知りたい情報がパパっと見られて、
問題点がスパッと切り出せるのが理想なんだと。
んなもん知るか。
756:デフォルトの名無しさん
11/07/02 09:24:32.80
役員向けにグラフも作成できない情シスは脳無し過ぎる
757:デフォルトの名無しさん
11/07/02 10:23:31.99
役員が営業部長にこーんなグラフが欲しいんだけど
営業部長が情シス部長にあーんなグラフが欲しいんだけど
情シス部長がシステム担当SE(こいつはコード書けない)にそーんなグラフが
システム担当SEが俺(別システム担当コード書ける)にこーんな仕様で、
って謎の伝言ゲームが行われている我が社。
俺に拒否権も選択権も無いのに動きが悪いからって査定下げられたオワタ。
ところでHibernateが叩かれてるみたいだけど、
JPA規格の部分だけ使えば他のフレームワークとも切り替えられていいんじゃね？
と机上の空論を展開してみる。
758:デフォルトの名無しさん
11/07/02 11:28:05.26
切り替えるタイミングっていつ来るのさ
759:デフォルトの名無しさん
11/07/02 11:59:17.69
使ってるフレームワークがオワコンになったら。。。とか？
JSFとかJPAとか規格化されてる奴なんかだと偉い人にウケがいい、とか無いかな？
760:デフォルトの名無しさん
11/07/02 12:10:43.93
EJB2が実質オワコンになったような例もあるから安心出来ない。
というか自分はEJB3もオワコンになると読んでるけどね。
761:デフォルトの名無しさん
11/07/02 23:44:13.51
期待のstruts2も終わってた気がw
762:デフォルトの名無しさん
11/07/02 23:49:46.18
結局JSP+Servlet+JDBCがいいな
763:デフォルトの名無しさん
11/07/03 02:23:49.01
複雑なフレームワークほど、人員が確保出来なくなるとメンテ不能になるはず。
764:デフォルトの名無しさん
11/07/03 09:38:43.50
>>763
正しくは、スキルの高い人員を1人でも確保できないと保守不能になる だな。
765:デフォルトの名無しさん
11/07/03 09:54:45.43
>>763
単純なフレームワークだと、その上に俺々フレームワーク構築されてメンテ不能か、
重複コードだらけでメンテ不能になるけどな。
766:デフォルトの名無しさん
11/07/05 17:20:34.74
ヲレヲレじゃなくてもメンテされてない古いフレームワークのまま放置されてたりで大差ない。
ヲレヲレでもメンテされてたほうがまだいい。
ヲレヲレをヲレヲレフレームワークで呼べばいいだけだし。
767:デフォルトの名無しさん
11/07/05 18:39:19.14
propertiesファイル使うiBatisモドキとSpringモドキを作らされた俺が通りますよ。
propertiesファイルに書かれたSQLをIDで指定して実行する、
インタフェース指定すると、propertiesファイルに書かれたクラスをロードする、
とかいう、それぞれの劣化版みたいなの。
2006年ぐらいに。
内部での評判は、イレギュラーなことをやろうとすると機能が足りない、
中途半端でメリットが判らない、と散々だった。俺もそう思った。
後々iBatisとSpringの存在を知って、当時のSEは何でそれら使わずこんなの設計したんですか？
と聞いたら、マネージャーが、集めた中国人プログラマのスキル的に使えない
と思って却下したと言っていた。
こんなわけ判らないものより、既知のものの方がみんな使いやすかったと思うんだ・・・。
768:デフォルトの名無しさん
11/07/06 07:03:36.46
Nか？
769:デフォルトの名無しさん
11/07/06 10:47:47.65
Nです。
770:デフォルトの名無しさん
11/07/06 19:42:03.96
おっとSDEの悪口は（ｒ
771:デフォルトの名無しさん
11/07/08 23:20:30.61
日本のIT業はどこもそんなもんじゃね
772:デフォルトの名無しさん
11/07/11 13:21:58.98
>>761
擦れ違いだが、Struts2 って終わっちゃったの？
自分自身はほとんど触ったことないけど、SpringMVC + Spring を選択しないケースや、選択しない層が
わりと Struts2 を選んでいて、Struts2 の ver.2 系になってからは、そこそこ実績も聞こえるようになってきたと思ったのだけど。
773:デフォルトの名無しさん
11/07/11 14:20:50.60
Struts2とかSpringMVCとかはもういい
裏側なんて難しくないしめんどくさくも無いからどれでも大差ないDBアクセスはORに切り離されてるし
ViewをJSPやvelocityじゃなくてHTMLで書きたいわ
774:デフォルトの名無しさん
11/07/11 14:30:35.83
>>773
Wicket や Click は、ちょっと違うか(HTML に、フレームワーク固有のコードが入るっけ?)
たぶん >>773 がのぞむのは、HTML の各要素に id属性を振って、
サーバサイドから HTML を DOM で舐めて、id のタグを置き換えるとか、そんなのがいいということかな？
teeda がそんなのだっけ。
>>773 さんが、こんなのがいいというフレームワークがあれば教えてほしい。
775:デフォルトの名無しさん
11/07/11 14:56:13.38
>>774
まんま名前上がってる奴だね、どれも下火過ぎて泣ける・・・
teedaは最新じゃJSPに戻してたはずだけど
ORは色々出るのにView切るだけのは出てこないよねFreeMarker、velocityくらい？
と思ってググったら結構あるのねｗ知らないだけでした
776:デフォルトの名無しさん
11/07/11 22:49:09.86
mayaaもあるでよ
777:デフォルトの名無しさん
11/07/12 00:10:43.02
Struts2とSpringMVCはコントローラの汚くなりかたが逆方向に向かってて面白いな。
つうかこれのどっちかしか使えないってのは有り得ないのでまさにどっちでもいい。
個人的にはこの2つに比べてのClickの残念さが際立つ感がある。
ViewはなんだかんだでJSPが一番無難で次点でVelocityだなぁ。
FreeMarkerは5年後も存在するとは思えない。
778:デフォルトの名無しさん
11/07/13 01:47:10.15
wicketをもっとDOMにしたようなのはどうよ？
画面をHTML・CSSなしで全部Javaにするとソース書く量が多くなるから
HTMLから下書きソースを生成するジェネレータ必須だけど。
class MyPage extends Page {
Head head = new Head().in(this);
Body body = new Body().in(this);
Form form = new Form().in(body);
Div div = new Div().text("name").in(form);
TextField field = new TextField().in(form)
}
779:デフォルトの名無しさん
11/07/13 19:59:40.73
Ruby の haml みたいだな。
URLﾘﾝｸ(haml-lang.com)
haml を Java 上でも動かせるようにしたらいいんじゃね？
ついでに Spring Integration とかやってみるとか。
780:デフォルトの名無しさん
11/07/14 10:02:03.12
それだとやっぱりhtmlもどきを別に編集する必要があるからなー。
wicketもxhtmlのみにもかかわらずタグidの階層間違えたりしやすかったから
100% JavaでHTML出力するのがいいと思う。
781:デフォルトの名無しさん
11/07/14 11:16:03.56
>>780
100％javaじゃ何の意味もない
客に見せてそのまま預けてデザインさせてそのまま使うってのがいい
782:デフォルトの名無しさん
11/07/14 13:04:18.74
>>781
客がJSP書くのか？
それとも客の目の前でデザインを変えて即システムを動かしてみたいのか？
後者なら上位レイヤーにCMSでもおくしかないと思うが。
俺はホームページビルダーとかデザイナーツールから
でてきたHTMLをツールを使って100% javaソースに変換して
そこから繰り返し処理や分岐、ロジックのソースを書き足せばいいと思うのだが
783:779
11/07/14 13:34:53.07
まぁ >>780 (= >>782 ?) の考えていることもわかる。
デザイナーとかがいなくて、プログラマが HTML 層まですべてやれる場合、
Java でやったら、手間はかかるかもしれないけどかなり構造的というか論理的な HTML が
作れるかも。
HTML のテストもしやすそう。
784:デフォルトの名無しさん
11/07/16 02:56:40.72
おいおまいら、RDBとのマッピングの話しる！
785:デフォルトの名無しさん
11/07/16 09:47:33.69
スレの名前見るといいよ
786:デフォルトの名無しさん
11/07/16 12:55:14.96
フルスタックはもういらねってことで
787:デフォルトの名無しさん
11/07/17 11:00:27.86
__ _,,.. -─‐- .､.._ ＿|＿＿ﾉ
ヽ . ´ ＿＿｀丶_ / .ヽ
} ／ ,． ´: : : : : : : : :｀ 、 ､＿＿＿ノ
/＼／ ／: : : : : : : : : :、: : : : : : : : ＼ / /
._/ ＼ .／ : : : : :/＼: : : : : ∧: :､ : : !⌒/ /
＼ ＼ /: : : :∧: /⌒ ＼ : :/ ∨､＼:.|. / /
＼ '{.: :/ : / ∨,,.__｀ ∨ __, /ヽ}/ /
∨ ｲ |:〃ﾞ￣` '⌒ヾ{ : :j/ /
ヽ ﾏ:j！ ´´´ ´´´ ; : / /
Y } / ￣￣} j∨ / 今週から全国のミニストップとセーブオンで
∧ ./:ﾊ. ｛ ,′ 人:ヽ. /
. / ∧ /:/ 丶、 ､＿ノ ／ ＼`く＼ イカ娘フェアが開催されるでゲソよ～♪
＿__／_厶／; ' ＼_}＞ーr＜ヽ >:ー-=:ｰ‥ ﾆ二 : 丶、
／,-─ｧ ┬─:‐ﾍ .}|丶、 ﾍ.l l l / /: ＼ : :＼ ｀ヽ: ＼ﾍ
: : > /: :/ /: :∧ !ヾ､ // l ′/＼ ＼: :.＼__ ＼: : :',
`^ .|: : | /: :/ ', / ヾ､ // { /＼: :＼ ＼ : : :＼ /_／
|: : | ／／ ∧ / `∨/ ∨ ＼: :＼. ￣＼ :＼、
.ﾉ: :ﾉ |: :| /: :ト′ Ｙ >; : > <: : : : >
<: :<__ ヽヽ ./: :/'; } <: : < ＼／
ノ: : :/／: /<: :< ! .:::::.:. .::::.:.;′ .ゝ └,
`ヽ;/.」: ∠ ＼:ヽ,| =- 〈 ＼/
＼_/. ＼:} _. {
ﾉ │
788:デフォルトの名無しさん
11/07/24 14:42:59.29
みんな、ミニストップでイカ娘コラボ商品を買ったかいw
俺はえび満月とティシュとカレースナックを買って
うちわをもらったzo！
789:デフォルトの名無しさん
11/07/27 18:25:19.12
JPAで生成したテーブルのカラムにインデックスを貼るのって出来ないので
しょうか。
もちろんスキーマ生成した後にRDBMS上から手作業でインデックスを貼る
ことは出来るのですが、出来るのであればJavaソース上のアノテーション
でインデックス作成の指定をしたいです。
790:デフォルトの名無しさん
11/07/28 08:29:46.83
OpenJPAにはあるけどJPAには少なくても1.1にはないよ
JPA2.0調べてみるか諦めろ
791:デフォルトの名無しさん
11/07/28 19:06:44.14
う～ん、やはりそうですか。プロジェクトではHibernateを使って
いるのですが。
でもJPAの規格にも無いって何を考えているのだろう。
JPQLでID以外の属性で絞り込みをする度にフルテーブルスキャン
がかかるのですが。WHERE句を使うなって事か。
792:デフォルトの名無しさん
11/07/29 08:38:28.04
インデックスってこまめに張り替えるもんじゃないし、別にいらないだろ
793:デフォルトの名無しさん
11/07/29 08:40:39.05
JPA2.0にもなかったよ
XMLでテーブル定義すればできたような覚えがあるけど
テーブル生成だけはアノテーションやめるか
JDO or OpenJPA使うよろし
おれはAntでテーブル生成SQLを自動化してる
794:デフォルトの名無しさん
11/07/29 11:03:22.09
そもそもO/Rマッピングすべきではないね
795:デフォルトの名無しさん
11/07/29 14:50:39.42
RDBMS間のSQLの仕様や方言の違いを考慮してDBスキーマ作成用の
SQLを複数用意したりSQL生成する仕掛けを手作りせずとも、Javaの
コード上でよろしくアノテーションつけておけば後はJPAの実装が
ターゲットのRDBMSに向けたSQLをよろしく自動生成してくれると
思ったのに・・・
インデックス一本張ろうとしただけで破綻してしまうのね。切ない。
共同プロジェクトの中の一部分を作っているだけなのでJPAの実装は
Hibernateで動かせないし、うちだけDB作成用のSQLを添付しますと
言ったら嫌な顔されるだろうなぁw
796:デフォルトの名無しさん
11/07/29 15:20:24.80
こうしてアンチHibernateがまた一人生まれるのであった
797:デフォルトの名無しさん
11/07/30 00:46:52.41
O/Rマッピングは甘え。
798:デフォルトの名無しさん
11/07/30 08:51:20.93
hibernate4.0には@Indexアノテーションあったけど
JPAインターフェースでは使えないんだよな
799:デフォルトの名無しさん
11/07/31 13:23:31.23
JDBC最強説ｗ
800:デフォルトの名無しさん
11/07/31 16:34:26.60
ご免なさい。インデックスの話また蒸し返します。
単純に興味があるので聞きたいのですが、JPAの2.0でもインデックス
作成をアノテーションで指定出来ないという事は規格の作成者たちは
必要性が薄い、無くても別の解決策があると考えているんですよね?
おそらく。
となると、例えばdouble値として身長、体重を持つ人物エンティティ
を永続化したとして、DBから人物を身長で絞り込んで引っ張ってきて
アレコレする、という操作はどう実装するのでしょうか。
単純にエンティティクラス定義にアノテーションつけてスキーマ作成
した場合は何時だってフルテーブルスキャンになりますよね。
操作自体はごくごく一般的だと思うので、何か自分の知らない上手い
解決策(全然違うデータモデリングとか)が存在すると思うのですが。
801:デフォルトの名無しさん
11/07/31 20:36:20.74
>>800
インデックス貼って最適化とかは、O/Rマッピングで抽象化すべき範疇じゃなくて、
RDBMSごとに行うもの、という認識なんじゃない？
インデックスといっても、微妙に種類だってあるわけだし。
俺はいつもDB作ってからJava側を生成する感じでいたから、
生成して欲しいという感覚がよく分からんが・・・。
テーブル定義のSQLなら、モデリングツールなんかで自動生成してくれたり
もするし、そういうのでもいいんじゃない？ERMasterとか。
802:デフォルトの名無しさん
11/07/31 21:11:48.99
RDBMS毎と言えばそもそもDDLやDMLからして方言の違いがあるわけで、
JPAのスキーマ自動生成とかJPQLとかはその上に一段抽象化された層を
重ねる事でその辺の差を吸収してくれるものだと期待していたので。
どうしてそこからインデックスを外すのかなぁと。インデックスの種類に
してもデフォルトのB-Treeで大敗して初めてRDBMS毎の最適化を考えれば
良いのではないかと。
なぜこんな事を気にするのかというと、今関わっているプロジェクトでは
開発側はPostgres+Hibernateで統一されているのだけど、出来た成果物
自体は(HibernateのDialect定義が提供されている範囲で)任意のRDBMSが
走っている環境上に展開出来る事を意図しているみたいなので。
なんでスキーマ定義の直書きやJDBC直叩きば御法度で、スキーマ定義から
DB操作までJPAのAPIの範囲内で済ませなさいと言うお達しなんです。
803:デフォルトの名無しさん
11/07/31 21:34:20.05
>>802
そういう済ませなさいという決断をする前に
DDLの主な操作がJPAだけで出来るかどうか調査するべきだろ
出来ない時点でその決断自体が間違っていたんだよ
804:デフォルトの名無しさん
11/07/31 22:10:29.15
>>803
そう思う。そう思う。下っ端の僕に言わないでぇ(涙)
でも本当に不思議。だってキー以外にインデックス張らないなんて。
JPAのアノテーションで生成されたスキーマって全行スキャンかけても
困らない程度にテーブルが小さいか、条件絞り込みの必要無いアプリ
にしか使えないような。
本当に不思議、というか本当に使われているの？
805:デフォルトの名無しさん
11/07/31 23:16:00.69
>>804
だから、普通は使えるかどうか調査してから使うもんだろw
とりあえず、Hibernateのindex属性またはアノテーションを使えるよう
上を説得するのがいちばん現実的じゃないの？
806:デフォルトの名無しさん
11/08/01 23:28:17.56
血Cの監督の水島ってガンダムとかやってる方の水島かと思ったら
イカちゃんとかやってる方の水島だったのな
クソツマンネーからガンダムやってる方かと思ってたわ
さすがの水島も脚本とキャラデが絶望的なんじゃどうしようもないな
まさに水島の無駄遣いだよなぁ
素直にイカ2期をやらせておけばよかったのに
807:デフォルトの名無しさん
11/08/18 22:18:55.27
>>791
Hibernateアノテーションにあったはず。
808:デフォルトの名無しさん
11/08/23 22:27:44.93
URLﾘﾝｸ(www.zero-tsukaima.com)
インデックスさんなにやってんすか
809:デフォルトの名無しさん
11/08/27 01:29:10.89
BSジャパンで今日からイカ娘の再放送＼(^o^)／ﾊｼﾞﾏﾀ
毎週金曜23:00-0:00
810:デフォルトの名無しさん
11/08/27 18:34:31.19
URLﾘﾝｸ(livedoor.blogimg.jp)
811:デフォルトの名無しさん
11/08/30 00:24:34.15
URLﾘﾝｸ(27.media.tumblr.com)
付き合いたい
812:デフォルトの名無しさん
11/08/30 00:33:22.74
2010年、人気アイドル声優
8人以上知ってたら重症
平野綾 …アイドル声優の模範のような活動を展開、アンチも多い
水樹奈々 …オリコン常連。声優活動も積極的
釘宮理恵 …ショタからツンデレまで。中毒者多数
井上麻里奈…モデル顔負け、多彩な才能を持つ
茅原実里 …長門で有名。歌手としても活躍中
小清水亜美…いいとも出演で有名になる
堀江由衣 …ピークは過ぎたが人気今だ衰えず
日笠陽子 …けいおんでﾌﾞﾚｲｸ、非常にアグレッシブで芸人声優との声も
花澤香菜 …棒声優,彼氏などあったが実力を付け大沢の次期ｴｰｽに成長
戸松遥 …実力はあるが事務所のゴリ押しもあってアンチも多い
悠木碧 …子役出身、09頃から露出が増え人気急上昇
伊藤かな恵 …あむちゃん。新人賞を取り今波に乗る１人
喜多村英梨…多彩な才能、演技の幅も広く実力派。しかし影は薄い
豊崎愛生 …08頃から頭角を現す。現在波に乗っている若手の1人
竹達彩奈 …けいおんでﾌﾞﾚｲｸ、アイム期待の新鋭
井口裕香 …インデックスでﾌﾞﾚｲｸ、大沢期待の新鋭、しかし役に恵まれず
金元寿子 …ソラノヲトで注目される、イカ娘に抜擢され波に乗る新人
後藤沙緒里 …今にも消えそう
813:デフォルトの名無しさん
11/08/30 22:53:39.15
Rd6.富士戦にオリジナルTシャツを着ていこうじゃなイカ！！
URLﾘﾝｸ(ameblo.jp)
814:デフォルトの名無しさん
11/09/13 22:24:37.07
イカ娘ウェットタオル買ったわw ２つもww
815:デフォルトの名無しさん
11/09/15 00:49:55.28
万能文化ｲｶ娘
816:デフォルトの名無しさん
11/09/16 00:41:01.44
URLﾘﾝｸ(2ch-ita.net)
817:デフォルトの名無しさん
11/09/21 02:18:13.90
URLﾘﾝｸ(livedoor.2.blogimg.jp)
818:デフォルトの名無しさん
11/09/27 00:48:34.55
Hibernateのマッピング定義って
XML書くのとアノテーションで指定するのどっちがおぬぬめ?
hibernate.orgのドキュメントみるとXMLが基本なんだろうけど
アノテーションも専用のドキュメントがRedHatにあったり、立ち読みした本はアノテーションメインだったり
結局どっちやねん、てキブンになったので
819:デフォルトの名無しさん
11/09/27 01:55:59.21
金元さん乳でか過ぎだろ・・・
URLﾘﾝｸ(iup.2ch-library.com)
URLﾘﾝｸ(iup.2ch-library.com)
820:デフォルトの名無しさん
11/09/27 23:57:09.39
イカ娘は、イカちゃんがかわいい作品であって
イカ娘という作品がとても面白いわけではない。
1期のころからそれを勘違いしてる人多いよね
821:デフォルトの名無しさん
11/09/28 07:03:40.47
でも2期のイカちゃんはちょっとあざとくないか？
1期の自然なかわいさとちょっと違う
822:デフォルトの名無しさん
11/10/02 15:37:31.10
映画化決定！
URLﾘﾝｸ(www.project-index.net)
823:デフォルトの名無しさん
11/10/05 04:26:37.39
>>818
好みでいいんじゃないの?
XMLであれば、マッピング情報はXMLだけを眺めればよい。
アノテーションにすると、*.java まで追いかけなければならないので、ちょっと面倒。
だけど XML 書くのめんどくさい。
あと XML 形式だと、Hibernate とは関係ないソースから持ってきた
エンティティクラスのソースを、ソース修正なしで Hibernateで扱えるが、
アノテーションにするなら、持ってきたソースを修正して、アノテーション情報を追記していかないといけない。
つまりソースを共有できない(そういう局面があるかどうかは別だけど)
824:デフォルトの名無しさん
11/10/07 01:26:42.18
URLﾘﾝｸ(uproda.2ch-library.com)
825:デフォルトの名無しさん
11/10/08 00:47:20.11
.／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣／|
|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣| |
| 花王 ランチタイムデモ in 東京 開催決定だゲソ！ | |
| | |
| 集合時間 １０月２１日 金曜日 午前１１時３０分 | |
| 集合場所 中央区 坂本町公園 （花王本社のすぐ近く） | |
| 東京メトロ 東西線・日比谷線 茅場町駅１２番出口すぐ | |
| | |
| フジテレビと花王と韓国の問題に関心のある人間は大集合だゲソ | |
| | |
| 手ぶらで一人でも、家族や仲間といっしょでも、仮装でもOKでゲソ ｜ |
| みんなで約１時間、数千人の侵略、もとい大行進を楽しまなイカ！ ｜ |
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|／
／ |i |／: : : : : : : : : : : : : : : ヽ＼ ./
< ／'|i |: : : : : : : : : : : ﾊ: :.∧__ : : : ＼ ./
ゝ..ｲ´|i | : : 人.: : : : : / ∨'''∨.: : : : : 〃
i : : |i |:|: :| ＼ : :./_／≠=ﾐ∨.: : : : :｀＼
i : : |i |:ﾄ┼===ヽ:/ ´ んﾊ . ∨ : :.∧￣
i: : |i |.Ⅳ/ ん下 弋:リ i∨/ ヽ∧
_∨|i |::| .{. 弋:リ , i: : i丿 ∧
/〆 二ヽ,ﾄ _ ,,...-‐┐ i |',: : :∧
i ´ ___｀Y.∧ <: : : : : : | .／l :|ゝ-- ∧
∨. ,-‐-_）.i: ゝ._ ゝ: : : _／ | /: :i .}
826:デフォルトの名無しさん
11/10/08 09:37:59.04
>>823
アノテーションのほうがラクではあるけど
ケアレスミスしたときにトレースするのが大変だな
Eclipseのhibernate tool(JBossToolsの中にあった)で
アノテーション形式でエンティティビーン(?)が児童生成できるのにはビビタ
> あと XML 形式だと、Hibernate とは関係ないソースから持ってきた
> エンティティクラスのソースを、ソース修正なしで Hibernateで扱えるが、
あれ、そっちだとエンティティくらすは継承の記述が必要じゃなかったか
827:823
11/10/10 01:19:52.44
>>826
もう昔なので忘れてしまったけど、XML形式だと、
エンティティクラスは、完全なPOJOでよかったと思う。
以前のソースを引っ張り出して見直したが、スーパークラスも特に何も指定しなくてよい。
アノテーションみたいに、import javax.persistence... という記述がいらないので、
POJOをコンパイルするだけなら j2ee.jar みたいなのがいらない。
828:デフォルトの名無しさん
11/10/10 11:14:08.65
>>827
xmlは管理がめんどくせ
といいながらhibernate.cfg.xmlを引っ張った後に
「アノテーションが定義されてないよﾆﾔﾘ」みたいなエラーがでるのはなんとかしてほしい…
自動生成だから書いてあるっての @Entity のパッケージも間違ってないっての!! もうわけわかんね
829:デフォルトの名無しさん
11/10/15 06:49:06.15
SQLQueryでCHAR(N)型取得しようとするとN文字のうち先頭文字しか取得できなくてわろた
フォーラムとか見回してみたらバグなのな
今更CHAR使うなとかはいわないでくれ orz
830:デフォルトの名無しさん
11/10/16 01:28:58.22
複合キーのテーブルからHibernate toolsでEntityクラス作ったら
複合キーの項目に関しては更新ができないのな
シリアル型項目のプライマリキー追加して
元複合主キーはユニーク制約つけておけばいいかな
831:デフォルトの名無しさん
11/10/18 08:21:33.97
キー更新するとかどういう状況だよ
832:デフォルトの名無しさん
11/10/18 12:31:24.01
>>831
複合ユニーク項目(更新あり)なので
「サロゲートキー用意してさらにあんたの作ったクソテーブル正規化していいっすか」
といったら殴られた場合とか
833:デフォルトの名無しさん
11/10/18 12:38:41.83
ついでにそのオッサンはVARCHAR禁止令を出してた
これは無理矢理SQLを使ってる奴に永続化を叩き込むチャンスにはなった…
834:デフォルトの名無しさん
11/10/18 15:21:50.92
JPAの話題はここでいいのかしらん
835:デフォルトの名無しさん
11/10/18 17:43:43.55
良いんじゃないのかな。
836:デフォルトの名無しさん
11/10/23 18:37:26.15
>>828
アノテーションで定義すると
ソースファイルに散在することになる
後々のメンテ管理を考えるとお勧めできない
837:デフォルトの名無しさん
11/10/23 18:42:15.15
「?オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。」
この一言に尽きるな
838:デフォルトの名無しさん
11/10/23 20:58:45.84
誰がORMとSQL撲滅を関連付けちゃったんだろう
839:デフォルトの名無しさん
11/10/23 21:18:07.27
客先から見たら
DBなんて高速で問い合わせして結果を返してくれるのが一番だ
ドメイン駆動がどうたら～、
ビジネス層からの呼び出しは良くない～
だからJPAのDDDこそが～
そんなの客にとっちゃ、どうでも良いんだよ
エセ技術者のエゴを客に押し付けるなよ
840:デフォルトの名無しさん
11/10/23 21:54:22.30
>>838
Hibernate(笑)?
841:デフォルトの名無しさん
11/10/23 22:26:08.80
JPA・DDD・Hibernate
このスレだと異常な叩かれ方だな
コンプレックスを抱えた人が多いんだろうか？
まぁ、なんだかんだいって難しいからね（笑）
842:デフォルトの名無しさん
11/10/23 22:54:03.13
とあるプロジェクトであるレコードが辞書で管理された単語への参照を持っていたのだが、
その辞書というのが単語数1万件程度で20弱の階層を持つツリーとして管理されていた。
で、そのチームから出てきたコードではJPAでレコードと単語をオブジェクトにマッピング
していたのだが、参照が全部EAGERだったので、レコードを一つDBから引っ張ると参照
している単語をDBから引っ張り、さらにその単語の親や子供を引っ張り、さらにその
祖父母や孫、と辞書内の全ての単語を雪崩的に引っ張るので結果的に一つレコードを
引っ張るのに5000件ほどSELECT文を実行する大変面白いインプリだった。
単にLAZYに書き換えてもテストが通らなかったので面倒なので突き返した。
ORM使うのはかまわないけれども、一応生成されるDBスキーマやSQL文のレビューは
ちゃんとして欲しい。
843:デフォルトの名無しさん
11/10/23 23:26:50.50
>>839
そんなのより客にとっては開発費用が先だろ
作る側も効率化が「できれば」開発期間が少なくなって安く提案できるし
というわけでうちの上司はORMが嫌いらしい
あと速さが重視される部分て
最後はストアドプロシージャゴリゴリなんで、あれをなんとかしてほしいな…
844:デフォルトの名無しさん
11/10/23 23:54:53.06
叩かれるのは本質的に簡単なものを間違って難しくしてるから。
845:デフォルトの名無しさん
11/10/24 00:31:16.43
>>842
こういうのを使うと
中でどんな効率の悪いSQLが生成されてるのか怖いな
そもそも直接SQLで問い合わせるのが一番高速なのに
わざわざ変なフレームワークで改悪SQLを流してるんだから
技術的に見れば後退してるよな
846:デフォルトの名無しさん
11/10/24 00:41:26.17
ORM使うのは嫌いじゃないけれどもRDBの素養がない人間に使わせるのは大嫌い。
847:デフォルトの名無しさん
11/10/24 00:42:21.60
>>844
エンティティなんて「ただの入れ物」なのに
それを神格化させすぎなんだよ
ORMに固執するあまり実際の業務で必要なデータを扱うときには
まるで実用には値しない
あるテーブルを副問い合わせして、group byしたものを別のテーブルとjoinした結果と
別のテーブルとexistsする、とか
そんな要求は普通にあるのだが
こういう場合はHibernateやらJPAではどうやって実現するんだ？
まさか「直接SQLで取得して下さい」とか言うんじゃねーだろうなｗ
そんなことしたら、ワザワザ定義ファイルとかを作ったり、クラスを作ったりして
素のJDBCでSQL書くよりも、余計に手間かかるじゃねーかｗ
何の為のORMなんだ？ｗ
848:デフォルトの名無しさん
11/10/24 00:42:32.31
最初に有名になったのがiBatisなら
変な方向に進んでいくこともなかったんだろうが・・・
849:デフォルトの名無しさん
11/10/24 00:44:22.17
>>845
遅い上にEAGER/LAZYという概念を意識する必要があって
SQL直書きより分かりづらくなってるからどうしようもないね。
こんなゴミを標準にするくらいなら標準なんてない方がマシ。
850:デフォルトの名無しさん
11/10/24 00:45:04.58
>>847
JPQL、かな?
851:デフォルトの名無しさん
11/10/24 00:45:46.83
>>846
この手のFWが浸透してきたら
それしか知らない若い奴とか増えてるのかも
ちょっと前までは一人でSQLから画面から何から何までやるのが当然だったんだが
852:デフォルトの名無しさん
11/10/24 00:55:20.67
フレームワークが増えるのはいいが
人間は退化してるようだな
特に開発要員、フレームワークの使い方に特化してるが
基本のJavaのコア部分やSQLなど知識ないのもいるからな
853:デフォルトの名無しさん
11/10/24 12:43:06.61
宗教はろくでもないってことだな
854:デフォルトの名無しさん
11/10/24 20:46:47.05
>>850
副問い合わせの入れ子の
JPQLなんて見たことないがｗ
855:デフォルトの名無しさん
11/10/24 20:53:43.50
>>854
まぁ見たことはないが、仕様的には書けるんじゃないのかなw
EXISTSみたいな述語もあるみたいだし。
856:デフォルトの名無しさん
11/10/24 20:59:14.13
理論的に書けるのと
実践は全然違う
たとえ文法上書けたとしても
パフォーマンスが異常に遅くて使い物にならんとか
生成されるＳＱＬが糞すぎるとか容易に想像できる
857:デフォルトの名無しさん
11/10/24 21:09:52.77
実際にやってみると良いんじゃないのかな。
JPQLはSELECT文の構造もSQLのそれととよく似ているし、パス表現を沢山の
JOINに置き換える事を除けばJPQLでのSELECT文からそれとそこそこよく似た
SQLのSELECT文を吐くよ。
858:デフォルトの名無しさん
11/10/24 21:16:09.09
Hibernateでテーブルとのマッピングの際に
何かのツールがあるのか？
まさかエンティティクラスとhibernate.cfg.xmlと各定義の.hbm.xmlを
全部手書きとか爆笑回答するんじゃねーだろうな？ｗ
それならば
ＪＤＢＣで直接書いたほうが遥かに開発コストが高いだろ
859:デフォルトの名無しさん
11/10/24 21:22:34.58
今はアノテーションが主流だし
ツールだって無い訳がないだろ
ちょっと馬鹿すぎない？
860:デフォルトの名無しさん
11/10/24 21:36:43.62
JPQLで出来なければ迷わずSQL書けばいい
システムの大部分を占める簡単なSQLをいちいち書く方が馬鹿らしいわ
861:デフォルトの名無しさん
11/10/24 21:44:11.23
RailsのActiveRecordくらいお手軽ならそれも通じるんだが・・・
862:デフォルトの名無しさん
11/10/24 22:17:24.13
小規模ならそれこそActiveRecordの方がいいし、
大規模ならSQL直書きする薄いフレームワークの方が開発効率もいいし、
Hibernateほどうんこなものはないね。
863:デフォルトの名無しさん
11/10/24 22:27:53.13
フルスタックのRailsと比べたらアノテーションを付けるとこまでの準備が多少面倒ではあるけど、
その先は（言語自体の差は別として）同じくらいか、むしろ型情報が多い分Java（+IDE）の方が
楽な意味もある
大規模ならSQL直書きって…
864:デフォルトの名無しさん
11/10/24 22:33:17.30
>>859
具体名が全く出てこないのが不思議だなぁ
幾つか出てるけど、案件で実用には耐えられないんだろｗ
865:デフォルトの名無しさん
11/10/24 22:35:15.10
>>862
Hibernateが生成するウンコＳＱＬに任せてたら
パフォーマンス自殺行為だからな
シビアな要求には直ＳＱＬに勝るものは無い
866:デフォルトの名無しさん
11/10/24 22:38:41.31
>>864
ツールが出力するのはあくまでも雛形みたいなものなんだから
気の済むまで手を加えればいい
それが不満なら自分で作ればいいだけの話だろ
867:デフォルトの名無しさん
11/10/24 22:42:58.50
>>866
開発効率を上げる為にツール導入してるのに
そのツールを自作しろとか
本末転倒も甚だしいなｗ
868:デフォルトの名無しさん
11/10/24 22:43:01.29
>>866
フレームワークは与えられたマッピング情報やクエリに忠実にSQLを生成するだけなんだから、
うんこSQLを生成させてるお前が悪い
チューニングまで期待しているとしたらその方がおかしい
それに更新系はむしろORMの方が効率が良い
869:デフォルトの名無しさん
11/10/24 22:44:44.86
>>867
ツールやプログラムってのはそういうもの
全く本末転倒じゃないよ
870:デフォルトの名無しさん
11/10/24 22:47:55.23
>>868
うんこＳＱＬしか吐き出さないんだから
信者がいくらフォローしても無駄なんだよカス
ＳＱＬ経験がある奴は、副問い合わせの取り方・順序など
書き方に工夫をするが
一方Hibernateが吐き出すウンコＳＱＬは何も考えてない糞
とりあえず通ればいい的な糞ツールだからなｗ
お得意のＯＲＭマッピングがどーたらこーたらで改善してみろよカス
ＤＤＤなら素晴らしいパフォーマンスが得られるんだろｗ
871:デフォルトの名無しさん
11/10/24 22:59:41.15
>>870
だから、与えられた情報に忠実にSQLを生成するだけだって言ってるだろ
それが問題になる箇所は自分でSQLを書けばいいの
その割合がかなり多いなら、そもそもORMがそのシステムに向いていないか
ORMの使用を考慮したDB設計になっていない
ORMは優れたツールだけど所詮はツールだから、使うほうがうんこなら力を
発揮させることはできないってこと
872:デフォルトの名無しさん
11/10/24 23:13:53.15
>>871
設計をうまく出来れば何とかなるとでも思ってるのか？ｗ
どんだけお花畑なんだよｗ
そもそもＲＤＢをjavaのオブジェクトに落とし込むんだから
効率的な設計など夢のまた夢なんだよ
実際は出来上がったモデル見るとカスのようなエンティティ設計ばかり
これが現実だ
873:デフォルトの名無しさん
11/10/24 23:20:57.34
オマエラ、ホントにそのネタ好きね。
よく飽きもせずに同じ話を繰り返すわ。
874:デフォルトの名無しさん
11/10/24 23:22:52.67
>>872
おまえ見苦しいわ
それはJavaでRDBを扱う事自体を否定してるようなもんで、ORM云々とか関係ないだろ
だったら全部ストアドで書いとけよ
ほんと阿呆らしい
875:デフォルトの名無しさん
11/10/24 23:23:45.98
ORM信者が今日も必死に抵抗してるなｗ
876:デフォルトの名無しさん
11/10/24 23:24:52.20
>>874
javaでSQLを直書きすればいいだけの話を
ORMとかウダウダ言ってる時点で馬鹿丸出しだな
877:デフォルトの名無しさん
11/10/24 23:29:48.80
>>875
正確にはHibernate信者だなｗ
iBATISとか誰も否定してない。
878:デフォルトの名無しさん
11/10/24 23:33:45.77
ORM信者が作ったシステムを俺がSQL直書きでリプレイスしたら
サックサクに動くって大評判
今までのはなんだったの？って言われた。
879:デフォルトの名無しさん
11/10/24 23:35:48.24
>>875,876,877,878
おまえ見苦しいわ
880:デフォルトの名無しさん
11/10/24 23:36:31.47
>>879
Hibernate(笑)信者乙
881:デフォルトの名無しさん
11/10/25 06:30:18.46
>>878
パフォーマンス求めるなら最適解だな
882:デフォルトの名無しさん
11/10/25 21:27:10.91
Railsが流行り始めのころは、もっぱらHibernateとActiveRecordを比較して
「ほーらJavaはこんなに無駄だらけだけどRubyはお手軽！素晴らしい！」
って宣伝が行われまくってたくらいHibernateはうんこだからな
883:デフォルトの名無しさん
11/10/25 23:04:41.21
>>882
こんなのとかね。
URLﾘﾝｸ(thinkit.co.jp)
そりゃJavaのいちばんうんこなものと比較したらRails勝つわｗ
884:デフォルトの名無しさん
11/10/26 00:53:23.52
>>883
どう見てもJavaとRubyの言語の差だな
比べるなら同じ言語で比べないと
885:デフォルトの名無しさん
11/10/26 01:04:48.44
ActiveRecordはBeanの定義まで省くのが嫌だな。
設定ファイルとか余分なアノテーションいらない
BeanKeeperぐらいがいんじゃないか。
URLﾘﾝｸ(d.hatena.ne.jp)