アカウント名:
パスワード:
どれも使ったことなくて記事での紹介やブログだけの印象ですが、
Hibernate: 最悪。間違いなくアンチパターン。ActiveRecord: RoRが使える領域に限れば問題ないと思う。Doctrine: 全く知らない
あとMyBatisとかS2DaoとかSQLを活かすフレームワークはこのパターンに当てはまらないような感じですね。
なので、実質的にはHibernate = アンチパターンだと思います。
> どれも使ったことなくてそれがすべてを物語ってるんじゃないの?
挙げてるものを使ったことがないだけで、ORM自体使ったことないわけじゃないですよ。Hibernateはちょっと検索してみれば分かるけど、あまりに酷いというコメントばかりで、使わなくても想像するだけでこりゃおかしいなと分かります。
「おかしい」とか抽象的な事書くからおかしなコメントがでてくるわけで。
自分がHibernateちょっと使って思ったのが、使い方覚えるのに時間がかかりそうということです。SQL書けない人でも使えるか又は、SQL直接書くより楽じゃなければORマッピングツール使う意味なんて無いわけだけど、Hibernateにはどちらも当てはまらないと思いました。(Hibernateバリバリ使いこなせるようになれば違うんだろうけど)
コメントが沢山あるのは、ORマッピングツールとして世に出てきたのが最初の頃だったからかと思います。
その点、S2Daoは現実的に使えると感じます。
親コメのアンチパターンかどうかは自分にはわかりませんが、もっと良いパターンあるのでしょうか?(今より工数かからず安全に作れるパターン)
マッピングツールという名前がそもそも詐欺的。結局SQLを発行している以上SQLのパフォーマンスを超えられるはずがないわけで、ラッピングツールとでも言うべき。NoSQLみたいなDBMSを直接操作できるようなツールなら話は別だろうけどもはや関係データベースにマッピングしてないし。
一応こちらにもコメント。
> SQL書けない人でも使えるかこれが破綻してると思います。
まず、ORMの一番の問題はパフォーマンスが出ないことで、SQLを使うように変えたら何倍~何十倍も速くなることはざら。SQLが不要ということはないです。本当に最小限のプロジェクトなら問題ないとしても、そのためにJava + Hibernateというのが重すぎます。(なのでRoRは否定してない)
次に、中でどんなSQLを発行してるのか分かりにくいことです。無駄なSQLを発行してパフォーマンスが落ちたり、Lazy/Eagerローディングの問題があったり。一方、生のSQLは単独で実行できるので、デバッグもしやすく、パ
> 次に、中でどんなSQLを発行してるのか分かりにくいことです。C/C++/アセンブラ使いが他の高級言語に対して抱く感想そっくりなのが面白い。でも「DBMSのオプティマイザがどんな機械語コードに展開するかわかったもんじゃないからSQLなんか信用できん」と言ってるC/C++使いは見たことないなあ。不思議だ
・遅くなる問題の質が違う。例えばJavaだとせいぜい無駄なコードが入るくらいだけど(ただしGC問題除く)、 Lazy/Eagerの「N+1検索問題」は本質的に別のロジックが動く。 http://s2container.seasar.org/2.4/ja/s2jdbc_abstract.html# [seasar.org]トラブリにくい
・元コメに書いてあるけど、抽象化でむしろ開発効率が落ちるという大きな問題がある。
似てるようで全然違いますね。
>あまりに酷いというコメントばかりなんでそれだけコメントがいっぱいあるのか。ってところが鍵かも。
あとどこがひどいのか理解せずにヒドイっていうのもヒドイかと。# javaはポインタが無いからヒドイ。ってよく言われてたな・・・
元記事では、> 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。なので、アドホックには使えるというよりは、アドホックにしか使えないということ。
古いですけどこんなのとか。http://www.tsuyukimakoto.com/blog/2005/09/23/145/ [tsuyukimakoto.com]今この問題解決してるなら教えてくださいw
> どちらにしろ、使い方を間違っている可能性が大きいと思います。これは「バッドノウハウ」ですね。普通に使ってて使い方を間違っていると言われるのは設計が間違っているパターンがほとんどですよ。
> 別にHibernateを擁護する気はないですが、> 批判だけして代替案を提示しない姿勢には賛成できませんね。他の書き込みでいくらでも代替案は書いてますよ。例えばJavaならもっと薄いSQLを生かしたフレームワークを使えばいいだけ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Hibernate = アンチパターン (スコア:0)
どれも使ったことなくて記事での紹介やブログだけの印象ですが、
Hibernate: 最悪。間違いなくアンチパターン。
ActiveRecord: RoRが使える領域に限れば問題ないと思う。
Doctrine: 全く知らない
あとMyBatisとかS2DaoとかSQLを活かすフレームワークはこのパターンに当てはまらないような感じですね。
なので、実質的にはHibernate = アンチパターンだと思います。
Re: (スコア:0)
> どれも使ったことなくて
それがすべてを物語ってるんじゃないの?
Re:Hibernate = アンチパターン (スコア:0)
挙げてるものを使ったことがないだけで、ORM自体使ったことないわけじゃないですよ。
Hibernateはちょっと検索してみれば分かるけど、あまりに酷いというコメントばかりで、
使わなくても想像するだけでこりゃおかしいなと分かります。
Re:Hibernate = アンチパターン (スコア:4, すばらしい洞察)
「おかしい」とか抽象的な事書くからおかしなコメントがでてくるわけで。
自分がHibernateちょっと使って思ったのが、使い方覚えるのに時間がかかりそうということです。
SQL書けない人でも使えるか又は、SQL直接書くより楽じゃなければORマッピングツール使う意味なんて無いわけだけど、Hibernateにはどちらも当てはまらないと思いました。(Hibernateバリバリ使いこなせるようになれば違うんだろうけど)
コメントが沢山あるのは、ORマッピングツールとして世に出てきたのが最初の頃だったからかと思います。
その点、S2Daoは現実的に使えると感じます。
親コメのアンチパターンかどうかは自分にはわかりませんが、もっと良いパターンあるのでしょうか?(今より工数かからず安全に作れるパターン)
Re:Hibernate = アンチパターン (スコア:2)
Re: (スコア:0)
マッピングツールという名前がそもそも詐欺的。結局SQLを発行している以上SQLのパフォーマンスを超えられるはずがないわけで、ラッピングツールとでも言うべき。
NoSQLみたいなDBMSを直接操作できるようなツールなら話は別だろうけどもはや関係データベースにマッピングしてないし。
Re: (スコア:0)
一応こちらにもコメント。
> SQL書けない人でも使えるか
これが破綻してると思います。
まず、ORMの一番の問題はパフォーマンスが出ないことで、
SQLを使うように変えたら何倍~何十倍も速くなることはざら。SQLが不要ということはないです。
本当に最小限のプロジェクトなら問題ないとしても、
そのためにJava + Hibernateというのが重すぎます。(なのでRoRは否定してない)
次に、中でどんなSQLを発行してるのか分かりにくいことです。
無駄なSQLを発行してパフォーマンスが落ちたり、Lazy/Eagerローディングの問題があったり。
一方、生のSQLは単独で実行できるので、デバッグもしやすく、パ
Re: (スコア:0)
> 次に、中でどんなSQLを発行してるのか分かりにくいことです。
C/C++/アセンブラ使いが他の高級言語に対して抱く感想そっくりなのが面白い。
でも「DBMSのオプティマイザがどんな機械語コードに展開するかわかったもんじゃないからSQLなんか信用できん」と言ってるC/C++使いは見たことないなあ。不思議だ
Re: (スコア:0)
・遅くなる問題の質が違う。例えばJavaだとせいぜい無駄なコードが入るくらいだけど(ただしGC問題除く)、
Lazy/Eagerの「N+1検索問題」は本質的に別のロジックが動く。
http://s2container.seasar.org/2.4/ja/s2jdbc_abstract.html# [seasar.org]トラブリにくい
・元コメに書いてあるけど、抽象化でむしろ開発効率が落ちるという大きな問題がある。
似てるようで全然違いますね。
Re: (スコア:0)
Re: (スコア:0)
>あまりに酷いというコメントばかり
なんでそれだけコメントがいっぱいあるのか。
ってところが鍵かも。
あとどこがひどいのか理解せずにヒドイっていうのもヒドイかと。
# javaはポインタが無いからヒドイ。ってよく言われてたな・・・
Re: (スコア:0)
Eclipseのpluginを使った開発環境込で考えれば、
アドホックな開発用途で使う分には、十分アリだと思うけど?
Re: (スコア:0)
元記事では、
> 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
なので、アドホックには使えるというよりは、アドホックにしか使えないということ。
Re: (スコア:0)
古いですけどこんなのとか。
http://www.tsuyukimakoto.com/blog/2005/09/23/145/ [tsuyukimakoto.com]
今この問題解決してるなら教えてくださいw
Re: (スコア:0)
シチュエーション1、2、4は解決済みですよね。
3、5はHibernateでなくてもORマッパを使っている限り同じ問題が発生するのでは?
どちらにしろ、使い方を間違っている可能性が大きいと思います。
別にHibernateを擁護する気はないですが、
批判だけして代替案を提示しない姿勢には賛成できませんね。
Re: (スコア:0)
> どちらにしろ、使い方を間違っている可能性が大きいと思います。
これは「バッドノウハウ」ですね。
普通に使ってて使い方を間違っていると言われるのは設計が間違っているパターンがほとんどですよ。
> 別にHibernateを擁護する気はないですが、
> 批判だけして代替案を提示しない姿勢には賛成できませんね。
他の書き込みでいくらでも代替案は書いてますよ。
例えばJavaならもっと薄いSQLを生かしたフレームワークを使えばいいだけ。
Re: (スコア:0)
http://d.hatena.ne.jp/koichik/touch/20051007/1128711612