- 1 名前：デフォルトの名無しさん [2012/06/03(日) 16:18:39.74 ]
-
Java用のWeb Application Frameworkについて語るスレッド
海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド
Web Application Framework のリスト
en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
特徴の比較
en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features
- 237 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:09:52.61 ]
- >>229
デモ見るとGrailsはかんたんに扱えそうな感じだね
grails.org/learn
JavaじゃなくてGroovyになってるから性能が心配なところだけど
実行前にはすべてJavaのバイトコードに事前コンパイルされるのかな？
>>230
ゴリゴリJSPでやるのは生産性が悪いと思う
>>232
例えば今まで何のフレームワークを試したの？
- 238 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:24:12.80 ]
- 単にフレームワークを使うだけの力もなかったんだろ
- 239 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:29:33.88 ]
- サンプルからちょっと外れるとクソハマリなんてフレームワークの流儀や
コンセプトを知らずに使ってる証
- 240 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:53:35.30 ]
- フレームワークってその流儀やコンセプトの押し付けがましいのが嫌。
- 241 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:57:37.87 ]
- >>238
力がないと使えないならいらない
servletやjspなら力なんて一切必要ないぞ
- 242 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:21:15.89 ]
- ３次元配列が扱えるフレームワーク無いもんなー
使えないよな
- 243 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:28:15.29 ]
- >>241
効率よく作るにはむしろ相当な力が必要じゃね？
それこそ小さな画面一つ作って終わりじゃないだろ
- 244 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:31:37.49 ]
- >>243
そりゃライブラリの類はたくさん必要だよ
でも外から自由を奪いにくるフレームワークは不要
- 245 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:32:09.71 ]
- 力ないやつが生servlet/jspで作ったらメンテ不可能なものしかできなそう
- 246 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:25:47.22 ]
- >>244
規模が大きくなってくるとそのうちそのライブラリの中にフレームワークが入ってくるんじゃないのかw
- 247 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:32:52.10 ]
- >>246
入らないよ。ライブラリは実装から呼び出される側、
フレームワークは実装を呼び出す側、役割が全然違う
- 248 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:42:19.97 ]
- 匿名で使えるgistでもあればそのライブラリ使ったコード貼ってみろよで終わりなんだけどな
お互い相手を下に見てるどうしが1、2行の文章だけでやりあっても不毛
- 249 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 06:14:07.70 ]
- >>236
誰も「さいきょうフレームワーク」の醍醐味なんか求めていない。趣味かよ。
オレオレにせよ商用にせよOSSにせよ、今すぐに使えてどれだけ継続的にアップデートが
続くかが問題。
どこかの天才が気まぐれで作ったさいきょうフレームワークよりも沢山のユーザに使われて
ある程度の期間バグを叩かれまくっているそこそこのフレームワークを使うね自分は。
- 250 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 08:43:31.29 ]
- 画面が多いだけの大規模システム（いわゆる業務系）なら
フレームワークも有効だろうねぇ
- 251 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 15:56:03.63 ]
- 「画面が多いだけ」ってよくわからん。
画面が多い「から」、フロントエンドの規模が大きいからウェブアプリのフレームワークを
使うのであって、その後ろに画面の多さ以外の何があろうが別問題だと思うのだが。
上から下まで全部一つのフレームワークで作ることしか頭にないのか。
- 252 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:10:25.88 ]
- でもおまいらの言ってるのは何が何でもフレームワークなんだろ？
とにかくまずフレームワークを使うことが第一であとは
どうでもいいって感じ。
- 253 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:20:28.86 ]
- じゃなくて、Java使ってWAF使って開発すると決めた後の話題が主なのがこのスレ
違う決断した後の話は別スレでする
- 254 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:24:17.70 ]
- JavaとWAF使うってことは型にはめやすい、型にはめるメリットがある(似た画面多い、人が多い)案件って事
そうじゃないこともあるが、それをここで話す意味がわからない
- 255 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:36:01.22 ]
- >>254の「そうじゃないこと」は「そうじゃない案件」です
- 256 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:43:44.27 ]
- >>237
Grailsは実質Spring MVCで、その上に動的言語と名前ベースのCoCの薄皮をかぶせた物だから。
なのでドメインクラスとかサービス層など内側の大事なところはJavaでカッチリ型安全に書いて
おいて、それをGrailsアプリの上にデプロイするのは案外自然に出来る。
そうしておけば重さが気になるのはVCのウェブ層だけの部分になるけれども、ここは開発も実行
も重いよw GroovyもJSPのGroovy版であるGSPも事前コンパイルされるけれども、Groovy
自体が遅い。ただ生産性は高いと思う。GroovyやRubyの経験があればVCは本当に書きやすい。
意外にはまったのが依存性の解決かな。Mavenでなくてivyベースで、Mavenリポジトリから
依存性を引っぱってくることも出来るのだけれども、Mavenとは微妙に振る舞いが違うことも
あってMavenベースのプロジェクトと連携するさいに妙にはまったことがある。
Maven統合プラグインもあるのだけれども評価時にはイマイチで以後使っていない。
- 257 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:23:53.38 ]
- >>256
Grailsって、ORMはHibernateを同梱しているんだよね？
Hibernateあまり使いたくないんだよなぁ。
MyBatisなどに差し替えられないの？
- 258 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:36:40.23 ]
- >>257
Mを構成するGORMというORマッパーはJPAどころかがっつりHibernateに依存しているので
無理っぽい。WAR等からHibernateだけ切り離すのも無理じゃないのかな。
ただ別のORMで書かれたMをVCから叩くのは普通に出来ると思う。たぶん。
- 259 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:39:36.67 ]
- >>256
ありがとう。
CoCが魅力的だったけど、速度も重視したいからSpring MVCも見てみる。
GrailsはJavaでも書けるようになってほしいな
- 260 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:46:34.27 ]
- やっぱり不自由が発生してるじゃん
Aだけを使いたいのに使いたくないBまで使わなきゃいけないとかw
技術力が普通にあるのなら使う必要ないんだよ
- 261 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:57:29.88 ]
- >>260
ORMは好きなの使えるっていうフレームワークもある。
JPA使えるやつなら大半の人は文句ないんじゃないの
JPAデファクトスタンダードだろうし
- 262 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:04:53.41 ]
- JPAｗ
- 263 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:05:31.48 ]
- デファクトｗｗ
- 264 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:16:01.10 ]
- なに草はやしてるんだ？
JPAはJavaでは一番メジャーなORMだろう
- 265 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 22:06:26.45 ]
- >>260
フレームワークの実装が特定のライブラリにがっつり依存しているか交換可能なように
設計されているかの違いだろうなぁ。
そしてそれはフレームワークの開発の速さや使い勝手とのトレードオフでもある。
GrailsはHibernate似のcriteriaも提供していたりとHibernate以外に交換するのは
しんどそう。
- 266 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 02:05:35.35 ]
- >>260
「やっぱり」って、不自由が発生するのを否定してるやついたか？
制約する・型にはめることによるメリットが不自由というデメリットより大きいってだけだろ
- 267 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 02:16:55.15 ]
- 「特殊なこと」ってのが曖昧だから話にならんのだよな
ビューに関してはJSP使ってるフレームワークだったら不自由もないだろ
コントローラにしたって所詮HTTPの範疇じゃたいして特殊なことなんかできんだろ？
- 268 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 07:21:32.53 ]
- listの中にlistが入ってて、さらにlistが入ってるような
データが受け渡しできないから糞
そんなフレームワークばっかり。フレームワーク作ってる奴は
単純なサンプル画面しか作ったことないやつばっかり。
- 269 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 07:45:04.59 ]
- >>268
どのフレームワークのことを言っているのか皆目不明なのでざっくりMVCを使って尋ねるけど、
「受け渡しが出来ない」ってM・V・Cのどれからどれの間で受け渡しが出来なかったのさ。
フレームワークが使えない理由としてなにか高尚なものが来るかと思いきや、いきなり脱力な
例が飛び出してぐんにゃりですよ。
- 270 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 08:05:17.79 ]
- どこで受け渡しできないかも知らない程度の知識なんだとわかった
- 271 名前： 忍法帖【Lv=40,xxxPT】(2+0：5) mailto:sage [2013/03/08(金) 08:14:16.37 ]
- >>268
批判するならどのフレームワークを使ったかくらい書くべきだね
すべてのフレームワークが同じわけではない
- 272 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 09:52:29.11 ]
- 仕事以外の時間もプログラム板に来るような勤勉でスキルも高いであろうおまえらは
不便なフレームワークでハマる必要ないんだよ
流行りに流されてるのに気づいたほうがいい
チームに新人やスキルが低い人間がたくさんいてそいつらに大部分を任せないといけないから
スパゲッティを避けるため仕方なく使ってるという話ならわかるけど
- 273 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 11:04:32.79 ]
- そこでPlay! Frameworkですよ
Play! は Scala が話題になっているが、Javaでもかける。
- 274 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 11:58:37.45 ]
- wicketってのがXML書かなくていいらしいんだけど、うらやましい。
- 275 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 15:19:03.90 ]
- Playは独自感が半端なく強かったり、1.0=>2.0を見る限り不安定感が否めない。
wicketは素直な設計だし、1.5=>1.6を見る限り安定していて実用的な時期に思える。
用途に合わせて様々なフレームワークを使うぐらいなら、
wicketみたいな大規模向けフレームワークをベースに、
小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？
- 276 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 15:57:00.15 ]
- フレームワークいらんという人はORMやDIは使うのかな。
今時手組のSQLに生のJDBCとか勘弁。
- 277 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:06:37.78 ]
- ORMなんか使わないよ。パフォーマンス悪いし。
- 278 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:12:45.10 ]
- >>276
ibatisはたまに使う。
一番いらないと思うのはDIかな。
newぐらい自分でしたい。
- 279 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:24:05.63 ]
- とはいえweb.xmlにサーブレット登録した時点でサーブレットクラスのnewに関しては既に
サーブレットコンテナに委譲しているわけだからなぁ。
その先、各サーブレットクラスが必要とする依存性を自前でnewするかこれも委譲するかで
自前ファクトリをゴリゴリ書くかapplicationContext.xmlを書くかの違いが出てくる。
インスタンス生成の委譲の程度問題だと思うんだよね。個人的にはサーブレット使うことと
DIを使うことの間にはあまり断絶はない。
- 280 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:33:16.09 ]
- とくにWebアプリでORMとかアホかと思う。
Webアプリなんてサーバー集中型なのになるべく負荷を減らさないでどうする。
ORMはクラサバアプリ向けだろ。少しは考えて欲しい。
- 281 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:55:04.22 ]
- DB知らない素人が手組みしたDBスキーマとクエリ。
DB知らない素人が定義したORマッピングとそれから自動生成されたDBスキーマ。
どちらを使えと問われれば自分は絶対に後者を使う。前者は墓穴の宝庫だが後者は
一応それなりに定石を外さないスキーマやクエリを吐く。
DBの素養のある人が手組みしたDBスキーマとクエリ。
DBの素養ある人が定義したORマッピングとDBスキーマ。
どちらを使えと問われれば、まあ使い勝手次第であって基本的にはどちらでも良い。
結局スキーマもマッパーが吐くクエリも手組と大差無いものに大抵は落ち着くから。
ただし成果物のAPIレベルでの使い勝手は当然ORMを使った方が初めから機能豊富。
結局DB理解している人間が担当しているか否かが重要なのであって、その上の上物
はプロジェクト毎に好きに決めれば良い。ただし手組みさせるとそのDB理解している
人間の手作業がバカにならん。許させる範囲でORMで楽させてあげても。
- 282 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:58:19.38 ]
- そうやって、もっさりアプリ量産してくれ。
俺の超サクサクアプリが高評価なのはおまいらのおかげだ。
- 283 名前：デフォルトの名無しさん [2013/03/08(金) 17:56:34.47 ]
- どうやらただの釣りだったようだな
- 284 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 19:25:26.20 ]
- ORMの必要性はわかるけど後でJDBCに差し替えにくい
Hibernateとかはバッドノウハウだなと思ったり。
- 285 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 19:39:04.75 ]
- 最近のHibernateはJPA準拠してるんでしょ
JPAならそのままSQLも扱えるとおもうけど
- 286 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 20:00:01.24 ]
- ORMから外れたことをするにしても外れ具合の程度によってJPQLから生SQLまで
それなりに逃げ口は用意されているよね。
普通にORMを使って、困ったときにピンポイントでそういう逃げを利用するだけでも
大概のシナリオはカバーできると思う。
- 287 名前：デフォルトの名無しさん [2013/03/08(金) 21:11:52.51 ]
- ORMを使うなら範囲検索にJPQL使うのは避けられないだろ。
プロトタイプだとしても主キーと全検索だけで作るわけにはいくまい。
- 288 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 21:29:37.43 ]
- その辺りはクライテリアとかフレームワークごとのDSLとか。
でもJPQLは良いものだ。サクッと使うのにちょうど良い。
- 289 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:00:06.57 ]
- >>281
DB知らない素人の件は俺なら前者かな。
ORMを理解してないやつが定義したものに
ORM適用するとか足かせにしかならん。
もちろんベストはそれなりにわかってるやつにDB定義をさせることだが
知らないやつが定義した場合は昔ながらのSQLで対応する他ないと思う。
- 290 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:03:09.87 ]
- >>282
俺もフレームワークとかDIとかORMとか否定派なので主張には賛成なのだけど
スマホアプリでもないただのWebアプリで
評価が高いとか低いとかどうやってわかるの？
- 291 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:29:45.60 ]
- DIを使うのって、短期的に楽をしたりするためより、変更に耐えやすいように作るためだと思うけど・・・・
(これも、スパゲッティなコードをメンテするより、長期的に楽になる)
Springスレだったかにも書いたけど、最初は Dao の実装を1つしか作らなかったけど
(Implが１つしかないのに、わざわざインターフェースを作っていた)、
途中で、一部のテーブルだけKVSに移行したので、MyBatisImplから別のDaoImplを作って移行した。
このとき、Daoのメソッドのインターフェースを変えないようにできたので、
修正はapplicationContext.xml だけ。コントローラやサービスクラスは変更無しで済んだ。
あとUT時は、サービスクラスにDaoをDIするときにモックにするとか。
こういうことを経験すると、よほど小さかったり使い捨て以外では、DIを使った方がいいと思っている。
DIをつかうための面倒なコストは、2回ぐらい変更があったら、回収できていると思う。
- 292 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:49:16.30 ]
- JavaEEが複雑すぎたために、DIが生まれたという解説をある本で読んだ。
- 293 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 03:27:23.17 ]
- >>291
レイヤごとにインターフェイス統一するのは
それなりのエンジニアなら誰でもやるし
そのケースでDIコンテナを使う必然性は感じられないが…
- 294 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 06:22:09.43 ]
- こまめにインターフェイスを定義することとDIコンテナを使うことは別に考えるべきだと思う。
インターフェイスを定義して抽象度を上げると実装の差し替えなど融通が効くのは別にDIを
使わずとも得られる恩恵だし、DIコンテナを使うにしても別にインターフェイスの定義は
必須ではない。注入される口の型が実クラス名で決め打ちでもDIコンテナは使える。
それならDIコンテナの利点は一体なにかというと、う〜ん、DIコンテナを使っているフレーム
ワークを使うときは自分もDIコンテナを使った方が楽という点が正直一番でかいかなw
例えばSpringを使ったフレームワークを使うときは基本的にコンポーネントもDI前提で開発
するのが殆ど作法になっている。コンポーネントはDIコンテナのコンテキストに登録すること
でアプリ上にデプロイするという手順が大抵のフレームワークでほぼ共通なので、DI使えば
どのフレームワークでも簡単に似た手順でデプロイ出来るのに対して他の方法だと途端に
苦労することになる。
- 295 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 06:38:14.57 ]
- DIコンテナの作者が後年DIコンテナはいらないと言ってた件
- 296 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 10:57:51.80 ]
- 当人がいらんと思ってても他の人が必要なら別にいいんじゃないの
- 297 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 11:04:21.79 ]
- >>296
いらないと思ってるやつが
いると思ってるリーダーの下についたときは悲惨だぞ←俺の今の状況
だからもっといらない流れができてほしいわ
- 298 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 11:13:19.54 ]
- >>295
ひがやすお？
- 299 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 12:11:10.88 ]
- >>298
YES
テストがしやすければDIコンテナは必要ないってSlim3の時に
- 300 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 15:35:31.76 ]
- DIの目的はテストじゃないと思うけどな。
- 301 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 15:50:02.45 ]
- ソースコード資産を別のフレームワークにそのまま移行する例って実は少ないだろ
- 302 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:34:51.64 ]
- wicket は Play! と同じくらい独自色がある気がする。 Play! で Java の時は、 DB のテーブル定義は ebean で、sql は 生 sql がいい気がする。
- 303 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:39:17.86 ]
- iBATISがやはり最強だな。
今まで使わないで来て今じゃMyBatisになってるようだがやはり最強。
- 304 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:42:53.41 ]
- HibernateやJPA実装の類がダメな理由はなんだろう?
- 305 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:54:23.60 ]
- RDBMSとの対応を把握する必要があるなら
最初からSQLに書けばいいじゃない。
- 306 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 17:07:23.68 ]
- Entityオブジェクトのクラスが決まっているのならそちらに必要最小限の
マッピング情報を書き足せば良いじゃない。
変なスキーマ相手だと苦労するけどJPA。
- 307 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:17:55.52 ]
- >>301
少ないっていうかほとんどない
著作権が客に移るからそのまま再利用できないし
- 308 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:45:15.19 ]
- >>300
DIの目的はオブジェクト(コンポーネント)を疎結合にすること、
DIコンテナによってそれが交換しやすくなる、
それが最大のメリットになるのが単体テスト。
だが単体テスト以外じゃ交換性は実は必要ない、
だったらテストがしやすけりゃDIコンテナはいらん、と読んだ。
- 309 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:52:55.16 ]
- 「DBスキーマが何も無い状態から」素直なスキーマを使う小規模Webアプリをサクッと開発する
のであればMyBatisでも生JDBCでもなくJPA系が一番楽だと思う。要するにアノテーションからの
スキーマの自動生成で事足りる範囲であればこれが一番コード量が少ない。
開発序盤はデフォルトのマッピングでORMにどんどん生成させて、ある程度エンティティクラスが
出そろったり怪しげなスキーマ吐くようになった時点で一旦止めてマッピングに手を入れる。
そっから先の苦労は、結局扱うドメインモデルの複雑さそのものなのでどのフレームワーク使っても
あまり大差はないようにも思う。
- 310 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 19:08:28.23 ]
- >>304
JPA1.0の頃だが、一覧とかエンティティ以外の形で取るのが絶望的にダメだったところ
今はどうよ？
- 311 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 20:42:00.68 ]
- >>310
1.0にも、それ以前のHibernateにも、一覧結果をEntity以外の形（普通のBeanやMap）で取得する方法はあったぞ
JPQL使う必要があったけど
どうしてもSQLで書かなければいけない場合でも、HibernateネイティヴのAPI使えば普通にEntity以外の形で取れていたし
その手法を実際に適用して開発したこともある
- 312 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 20:56:08.16 ]
- >>311
HibernateにResultTransformerがあるのは知ってるが、それは標準じゃない
JPA標準でできるのは、
・JPQLでnew Xxx(a, b, c, ...)
・SQLで@SqlResultSetMapping(columns={@ColumnResult(name="a")}, ...})
しか知らん
前者はJPQLってところが×。関連のマッピングがないと結合もできない。Mapが使えないのも×
後者は面倒なので×。結果がObject[]なのも×
間違ってたりJPA2.0で改善されてるところがあれば教えて欲しい
- 313 名前：デフォルトの名無しさん mailto:sage [2013/03/10(日) 21:32:05.66 ]
- ほんのちょっと前にJPA推しレスしてるやつ数人いるのに、
具体的な話になったらレス付かないとかwww
- 314 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:11:59.19 ]
- 軽く調べた
・JPA2.0のJPQLではFUNC("関数名",...)でネイティブSQLの関数が使えるようになった
JPQLに無い関数も使えるのでカバーできる範囲が広がるが、
RDBに依存するならわざわざJPQL使わねーだろw
・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw
これ誰も使ってねーだろw
・EclipseLinkは@QueryHint(name=QueryHints.RESULT_TYPE, value=ResultType.Map)でObject[]の代わりにMapになる
結局非標準w
集計的な一覧が多い日本の業務系では使い物にならんぞJPA
- 315 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:24:30.49 ]
- >>311 >>314
「一覧」という言葉を多用してるけど何のこと？
多数のテーブルをJOINするようなクエリを意味してる？
一覧とは何を指しているのかわからなかったからレスのつけようがなかった。
業務系では使えないという主張もよくわからない
JPAに限らず、ORMはマッピングさえ終えてしまえば使えるでしょう
- 316 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:52:26.07 ]
- JPAが良いって言っている人達は、どんな用途にでもJPA最高って主張しているのか？
JPAで簡単に出来る範囲のことをやる分には、JPA最高っていう主張なのかと思っていたけど。
- 317 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:56:14.85 ]
- >>315
>>310に書いただろ、「エンティティ以外の形で取る」って
>>311には伝わってたぞ
例えばMAXとかAVGとか集計関数使って部署別、期間別などの一覧を出すケース
当然、SELECT句の並びは元になったテーブル(エンティティ)とはまるで異なる
単純だがSELECT COUNT(*), AVG(a), MAX(a), MIN(a), AVG(b), MAX(b), MIN(b), ...
が必要な時、JPAではどうする？(その答えが>>312と>>314だ)
>>316
じゃあJPAで簡単にできる範囲を示さないとな。どんだけ狭いか見物だわ
- 318 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 22:13:39.98 ]
- >>316
>>286は「それなりに逃げ口は用意されている」から「大概のシナリオはカバーできる」
と主張してるな。「大概のシナリオ」だ、意味はわかるよな？
- 319 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 00:11:12.75 ]
- >>314
> ・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw
いやそれは無いはず。JPA1.0の時代にHibernate実装でそれを使っていたから
JPAを使ったことのある身から言うと、SQLの直接記述が要件として必須なら、標準には拘らない方がいいと思う
また、JPQLをまったく使う気が無いのなら最初から止めておいた方がいい
JPA標準のNativeQuery関連は本当に使い物にならないし、SQL記述がほとんどならMyBatisで十分だろう
今はJavaの仕事していないので、最近のことについてはわからない
- 320 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 00:29:13.67 ]
- JPA とか吐き出されるSQLが微妙なときがあるから、変なSQL吐いてたら普通のSQLにするとか、速度的に気にしなくて良いならJPAで通すとか。各DBの方言を吸収してくれるのは便利だと思う。
- 321 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 01:55:03.35 ]
- hibernateから10年以上経ってて
いまだにこんなややこしい議論が必要なら
もうSQL書いたほうが早いってことだろ
- 322 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 09:13:52.20 ]
- でもこの差は何なんだろうね。
www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&geo=JP&date=today%2012-m&cmpt=q
www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&date=today%2012-m&cmpt=q
日本ではHibernateを使いにくい特殊事情でもあるのかな。
こんなのも。
www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&geo=JP&date=today%2012-m&cmpt=q
www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&date=today%2012-m&cmpt=q
- 323 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 09:42:51.79 ]
- 俺の考えを述べさせてもらうと
O/Rマッピングだけでも生SQLと速度差がほとんどなくなるか
そもそもオブジェクトをそのまま扱えるDBが一般的になるまで
生SQLのほうがいいと思う。
- 324 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 21:47:36.02 ]
- >>319
Hibernate3.6以降の話かな
https://hibernate.onjira.com/browse/HHH-6304
SSHから使ってた連中は別として、今JPA使うとしたらGlassFish(EclipseLink)が多いだろ
「Hibernateならできるし(震え声)」じゃダメなんだよ
あえて標準技術を選ぶ意味がない
俺はJPA(JavaEE)への移行を却下したんで「止めておいた方がいい 」のは最初からわかってる
そんなのよりJPA推し連中からのポジティブな反論を期待してたんだがな
- 325 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 23:22:04.17 ]
- 余談だけど、JPAと言いつつHibernate前提の話をしたり、JAX-RSと言いつつ特定実装系前提の話をするJava EE推称派は、そこんとこキッチリしてくれ。
- 326 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 23:34:07.08 ]
- MyBatis触ってみたがこれで十分だわ
EJBに組み込む方法も割と簡単だし
- 327 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 00:27:43.05 ]
- >>325
標準ですむ範囲の要件であれば標準ですませた方がよい、それだけの話では？
- 328 名前：デフォルトの名無しさん [2013/03/13(水) 01:04:42.17 ]
- >>327
文盲乙
- 329 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 01:10:39.93 ]
- hibernateって昔、1000件DELETEするときに
1000回DELETE文が走るとかでこれは使えないと断念したことがあるのだけど
いまのhibernateとかJPAとやらはそのへんは改良されてるの？
- 330 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 01:13:34.55 ]
- 横断的な処理をする場合はJPQLを使って処理するんだろ
JPAはSELECTがJava側から見て綺麗になるくらいで後は方言吸収くらいが利点か
- 331 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 11:42:57.54 ]
- Linuxサーバーって一回設定したら以後放置だよね。Windows Update + Windows Serverの方がよいよね
engawa.2ch.net/test/read.cgi/poverty/1363142026/
- 332 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 15:53:58.68 ]
- >>329
調査不足つか調査力不足
Hibernate2.xの頃ですらできてた
- 333 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 16:53:32.09 ]
- >>332
昔って書いたのに何でそういう否定の仕方するんかね。
俺が見たのは2003年ごろだよ。バージョンは忘れた。
- 334 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 17:18:16.36 ]
- 別に1000回DELETEすることは問題じゃないと思う。
それが1回のSQLでDELETEするのと同じ速度なら。
でもまだそういう時代じゃないからO/Rマッピングは悪だと思う。
- 335 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:07:27.21 ]
- >>333
事実だから
2002年1月リリースの0.9.2からできてたことに気づけず断念とか調査力不足だろ
- 336 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:34:57.15 ]
- >>335
まさかHQLのことじゃないよね？
- 337 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:50:25.71 ]
- すり替えｷﾀwww
少なくとも10年選手なんだろ？情けねぇ・・・
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
どう見てもHQL使うべき場面です
|
 |
