アカウント名:
パスワード:
どれも使ったことなくて記事での紹介やブログだけの印象ですが、
Hibernate: 最悪。間違いなくアンチパターン。ActiveRecord: RoRが使える領域に限れば問題ないと思う。Doctrine: 全く知らない
あとMyBatisとかS2DaoとかSQLを活かすフレームワークはこのパターンに当てはまらないような感じですね。
なので、実質的にはHibernate = アンチパターンだと思います。
> どれも使ったことなくてそれがすべてを物語ってるんじゃないの?
挙げてるものを使ったことがないだけで、ORM自体使ったことないわけじゃないですよ。Hibernateはちょっと検索してみれば分かるけど、あまりに酷いというコメントばかりで、使わなくても想像するだけでこりゃおかしいなと分かります。
「おかしい」とか抽象的な事書くからおかしなコメントがでてくるわけで。
自分がHibernateちょっと使って思ったのが、使い方覚えるのに時間がかかりそうということです。SQL書けない人でも使えるか又は、SQL直接書くより楽じゃなければORマッピングツール使う意味なんて無いわけだけど、Hibernateにはどちらも当てはまらないと思いました。(Hibernateバリバリ使いこなせるようになれば違うんだろうけど)
コメントが沢山あるのは、ORマッピングツールとして世に出てきたのが最初の頃だったからかと思います。
その点、S2Daoは現実的に使えると感じます。
親コメのアンチパターンかどうかは自分にはわかりませんが、もっと良いパターンあるのでしょうか?(今より工数かからず安全に作れるパターン)
一応こちらにもコメント。
> SQL書けない人でも使えるかこれが破綻してると思います。
まず、ORMの一番の問題はパフォーマンスが出ないことで、SQLを使うように変えたら何倍~何十倍も速くなることはざら。SQLが不要ということはないです。本当に最小限のプロジェクトなら問題ないとしても、そのためにJava + Hibernateというのが重すぎます。(なのでRoRは否定してない)
次に、中でどんなSQLを発行してるのか分かりにくいことです。無駄なSQLを発行してパフォーマンスが落ちたり、Lazy/Eagerローディングの問題があったり。一方、生のSQLは単独で実行できるので、デバッグもしやすく、パ
> 次に、中でどんなSQLを発行してるのか分かりにくいことです。C/C++/アセンブラ使いが他の高級言語に対して抱く感想そっくりなのが面白い。でも「DBMSのオプティマイザがどんな機械語コードに展開するかわかったもんじゃないからSQLなんか信用できん」と言ってるC/C++使いは見たことないなあ。不思議だ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
Hibernate = アンチパターン (スコア:0)
どれも使ったことなくて記事での紹介やブログだけの印象ですが、
Hibernate: 最悪。間違いなくアンチパターン。
ActiveRecord: RoRが使える領域に限れば問題ないと思う。
Doctrine: 全く知らない
あとMyBatisとかS2DaoとかSQLを活かすフレームワークはこのパターンに当てはまらないような感じですね。
なので、実質的にはHibernate = アンチパターンだと思います。
Re: (スコア:0)
> どれも使ったことなくて
それがすべてを物語ってるんじゃないの?
Re: (スコア:0)
挙げてるものを使ったことがないだけで、ORM自体使ったことないわけじゃないですよ。
Hibernateはちょっと検索してみれば分かるけど、あまりに酷いというコメントばかりで、
使わなくても想像するだけでこりゃおかしいなと分かります。
Re: (スコア:4, すばらしい洞察)
「おかしい」とか抽象的な事書くからおかしなコメントがでてくるわけで。
自分がHibernateちょっと使って思ったのが、使い方覚えるのに時間がかかりそうということです。
SQL書けない人でも使えるか又は、SQL直接書くより楽じゃなければORマッピングツール使う意味なんて無いわけだけど、Hibernateにはどちらも当てはまらないと思いました。(Hibernateバリバリ使いこなせるようになれば違うんだろうけど)
コメントが沢山あるのは、ORマッピングツールとして世に出てきたのが最初の頃だったからかと思います。
その点、S2Daoは現実的に使えると感じます。
親コメのアンチパターンかどうかは自分にはわかりませんが、もっと良いパターンあるのでしょうか?(今より工数かからず安全に作れるパターン)
Re: (スコア:0)
一応こちらにもコメント。
> SQL書けない人でも使えるか
これが破綻してると思います。
まず、ORMの一番の問題はパフォーマンスが出ないことで、
SQLを使うように変えたら何倍~何十倍も速くなることはざら。SQLが不要ということはないです。
本当に最小限のプロジェクトなら問題ないとしても、
そのためにJava + Hibernateというのが重すぎます。(なのでRoRは否定してない)
次に、中でどんなSQLを発行してるのか分かりにくいことです。
無駄なSQLを発行してパフォーマンスが落ちたり、Lazy/Eagerローディングの問題があったり。
一方、生のSQLは単独で実行できるので、デバッグもしやすく、パ
Re: (スコア:0)
> 次に、中でどんなSQLを発行してるのか分かりにくいことです。
C/C++/アセンブラ使いが他の高級言語に対して抱く感想そっくりなのが面白い。
でも「DBMSのオプティマイザがどんな機械語コードに展開するかわかったもんじゃないからSQLなんか信用できん」と言ってるC/C++使いは見たことないなあ。不思議だ
Re:Hibernate = アンチパターン (スコア:0)