- 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
- 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使うべき場面です
- 338 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:00:25.43 ]
- できるできるってHQLのことかよ
HQL書かないといかんのなら使わんよそんなもん
隠蔽されて実行されるSQLを最適化してくれるよう
進化してるかが質問の意図だったんだが
- 339 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:09:20.82 ]
- >>338
だよな
それをわかってないんだよ
ここの奴らは
- 340 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:11:33.54 ]
- は？その意図が「1000件DELETEするときに」で伝わると思ってんの？
少なくとも10年選手なんだろ？大丈夫かお前
ついでに言っておくと、2002年の1.1からバッチ更新使うから
「1000回DELETE文が走る」も成立しない
だいたいHQL書かないならDELETE関係なくHibernate使えないじゃねーか
1000件フェッチしてくるのだって大概HQL書くだろ
idとナビゲーションだけでやるつもり？アフォですか
「10年前は未熟でした」で終わらせておけばいいものを「今も」バカだって晒してどうする
- 341 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:14:31.73 ]
- ファビョるなw
- 342 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:16:26.44 ]
- 一応書いておくが、俺(340他)はHibernate使えるとは思ってない
↓がバカだと思っただけだ
> 1000件DELETEするときに
> 1000回DELETE文が走るとかでこれは使えないと断念
- 343 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:16:53.38 ]
- そもそもオブジェクトを操作するだけでSQLと遜色ない速度で
動いてくれないと意味ないんだよ。
- 344 名前：デフォルトの名無しさん mailto:sage [2013/03/15(金) 01:16:45.46 ]
- 亀レス＆スレチですまん。
>>224
いまだにメインはJavaなんだけど、node.jsを使い始めてる。
フロント側をJavaScript+jQueryでやることが多くなって
サーバ側も同じ言語が使えるのは良い感じ。
ただ、JSはタイプセーフじゃないから、巨大なシステムにはまだ不安。
- 345 名前：デフォルトの名無しさん mailto:sage [2013/03/15(金) 14:12:49.96 ]
- タイプセーフは重要
- 346 名前：デフォルトの名無しさん mailto:sage [2013/03/16(土) 00:31:32.17 ]
- >>344-345
同じ言語を使えるってのは楽でいいね
言語の問題は置いておいて、node用のフレームワークの出来はどう？
expressだっけ？
TypeScript使えばJSも部分的にTypeSafeになるんじゃない？
- 347 名前：デフォルトの名無しさん mailto:sage [2013/03/16(土) 00:47:09.87 ]
- Expressが必要なところでNode.jsを使ったら負けだと思ってる
- 348 名前：224 mailto:sage [2013/03/16(土) 22:53:33.58 ]
- >>344
node.jsか。レスありがとう!
- 349 名前：デフォルトの名無しさん mailto:sage [2013/03/18(月) 20:10:52.78 ]
- Mybatisのセカンドレベルキャッシュってどこに保存されてるんだろ
Serializableを要求するからTEMPフォルダでも指定してるのかと思ったが見あたらない？
もしかしてインメモリなのか？ローカルキャッシュよりは全然遅いのだが
- 350 名前：デフォルトの名無しさん mailto:sage [2013/03/18(月) 20:49:09.28 ]
- ああreadonlyに設定してないと読み取りの度にシリアライズが走るのか
イミュータブルにすると周囲にやや不評だろうけど安全だしそうするか
- 351 名前：デフォルトの名無しさん mailto:sage [2013/03/20(水) 00:08:40.52 ]
- mapper XMLでinsertをする時、useGeneratedKeysを指定すれば自動採番されたIDが取得できるのは
わかってるんだけど、これって単発insertのときだけじゃないですか。
insert selectで複数行をinsertしたとき、全部の自動採番IDを取ることって出来るんですか？
- 352 名前：デフォルトの名無しさん mailto:sage [2013/03/20(水) 01:00:57.18 ]
- 生JDBCのgetGeneratedKeys()はResultSetを返すんだからできるんじゃねーの？
- 353 名前：351 mailto:sage [2013/03/20(水) 01:13:31.36 ]
- いろいろ端折り過ぎてた
spring + myBatisでPostgreSQLです
keyPropertyに指定するフィールドを配列やListにしてみたんだけどダメだったなー
生JDBCでできているてことは、自前でhandlerとか作ってやればいいのかな
- 354 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:00:30.07 ]
- O/R マッピングは便利なんだけど何を使ってもテーブル結合と集計で悩む.
Entityと1:1にならない1000SQLのために対応するDTOを1000作るのか？ みたいな.
型の安全性とか名前の管理とか考えたらList<Map>よりずっとマシなんだけど数がなぁ…
- 355 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:10:09.19 ]
- あと、Tableに対応するクラスはEntityでいいとして、SQLに対応するクラスは何と定義してどのパッケージに突っ込んでる？
前者をDomainEntity, 後者をCustomizeEntityと呼んで同じパッケージに突っ込んでるプロダクトもあるみたいだけど.
- 356 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:31:00.42 ]
- だからまったくSQLを意識しなくてすむレベルまでオブジェクトにしても
パフォーマンスがぜんぜん問題にならないくらいになるまで
使うべきじゃない。時期尚早。
- 357 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:52:33.44 ]
- >>356
使わないのも選択肢としてありだと思うけど>>354-355の課題は使用有無に関わらず発生するよね
これみんなどうしてるのかねぇ
- 358 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 12:15:04.22 ]
- >>354
適材適所でいいんじゃないの
SQL使うほうが楽な場所はSQLで直接やればいい。
お決まりの処理で性能を満たす場合はORMで。
- 359 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 14:06:30.14 ]
- >>358
まったくそのとおりだと思う。
実際ORマッパには生SQLを発行できるタイプもあるし、
生SQLで検索したものをオブジェクトにマップもできる。
(マップできないようにもできる。集計やグループ化もたいていは対応してるんじゃないかな。)
SQLインジェクションにならないようにするだけでも価値があるし、
コネクションプーリングだけでも有用だと思う。
ORマッパにもよると思うがあまり毛嫌いする要素はないと思う。
- 360 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 14:31:52.65 ]
- SQLインジェクションとコネクションプール用途で使うには重すぎるだろ
そんなのcommonsあたりで簡単に対応できるしな
- 361 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:17:03.51 ]
- >>360
え、そんなことないよ。軽いものなんていくらでも。例えばS2JDBCとか。
マップする用途からしない用途までわざわざ書いたのはそういうことですよ。
CommonsだとCommons使わない人が出てくるのでSQLインジェクション対策としては
片手落ちだと思っています。
あえて言っておきますがORマッパを使わない選択肢は否定していませんからね。
- 362 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:36:33.34 ]
- >>359
＞生SQLで検索したものをオブジェクトにマップもできる。
ここが気になるって話じゃないの？
マップできるのはいいとして、SQLに対応するクラスをSQLの数だけ作るのか、
またはList<Map<String, Object>>とかで済ませてるのか
うちは後者で統一されてて、生SQLのSELECT句に対応するDTOは作成が禁止されてる
Mapのキー管理がかなり面倒だけどクラスの数を増やしたくないらしい
- 363 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:49:27.32 ]
- >>362
あーORマッパ書いて公開しているんですが、
その手のものはいろいろ手法があって、ResultSetを便利にしたようなもの
を使ってもらうことが多いと思います。
フィールド値を取得するときにその型で取ると。
int value = result.intValue(column);
とか
> SQLに対応するクラスをSQLの数だけ作るのか
そういう手法もあります。GenericsなTuple作る手もありますね。
Scala的に書くと、
val (id, name, date) = result.get[M: (Long, String, Date)]
とか。
- 364 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 17:45:17.21 ]
- >>354-355
俺はある程度割り切ってクラスを共有するよ。
ざっくりとした例なので批判されるかもしれないけど
会員名、店舗名、都道府県名を格納できるDTOを用意して
会員→店舗までしかJOINしない場合もそのDTOを使用する。
都道府県名はnullなので都道府県名が欲しい場合は別のSQL使ってねと。
- 365 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 17:50:01.38 ]
- ありだな
- 366 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 18:22:48.02 ]
- ありだと思うよ
ただその場合だと複数機能で共有するだろうからパッケージに悩みそうかな
SQL書くときって機能でパッケージ分けてると共有しづらいよなー
ドメインモデリングは理解できる奴少なかったりするし
- 367 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 18:59:18.05 ]
- >>363
マッピングせずにResultSet(風)を触らせるのもありか
SQL発行した側はカラム名も型もわかってるはずだしな
この前久しぶりにMyBatis採用案件見たけど
これくらいシンプルな方が設計者も実装者もわかりやすくていいのかもしれないな
- 368 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:05:13.70 ]
- ようするにO/Rマッピングは現段階では不要だな
- 369 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:26:38.33 ]
- >>368
それはさすがに極論すぎて、ORマッパ以前にバグやセキュリティホールの温床になりそうです。
現状Webアプリなどの場合はORマッパがボトルネックになるより、
RDBMSの処理の方がボトルネックになることが多くて、
ORマッパの意義はむしろ昔より重みが増しているように感じられます。
＃つまりCommons DbUtils使ってやれはちょっと...ということです。
＃そして最近のORマッパは結構薄いラッパであることが多く、
＃そんなに重たくありません。
ただ素のSQLやPLSQL/pgSQLなどの手続き言語を併用するのを
否定することではなく、バッチ処理のようなデータベースで処理だと
ORマッパ以前にフロントエンドの処理がボトルネックになることが
あると思います。その場合はそれを選択すればいいだけです。
- 370 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:37:43.30 ]
- >>369
O/Rマッパーを使わないとバグやセキュリティホールの温床になるってのは
技術職、開発会社としてどうなんだ？
俺は条件によってはO/Rマッパーが有効なプロジェクトもあると思ってるが
上記のことは本質とはだいぶ違うと思うのだが。
- 371 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:40:36.78 ]
- SQL生成用クラスを一個つくればいいよね
- 372 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:45:11.79 ]
- >>370
本質じゃないというか言いたいのは「直接JDBC触らせるな」(DbUtils含む)ということですよ。
ORマッパはDAOみたいな機構も持っていることがあるので、
それなら最初からORマッパを使えば?ということです。
そういう汎用性をちゃんと持っているという認識が必要です。
>>371
そうですね。
でもそのサポートもDAOやORマッパがやってくれますけどね。
- 373 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:48:36.82 ]
- あと聞きたいのですが、JDBCなどを使っている場合、
java.sql.PreparedStatementをちゃんと使ってますか?
- 374 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 20:04:13.30 ]
- SQL生成用クラスでPreparedStatementを使ってバインドしてるよ。
- 375 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:20:56.00 ]
- Javaソースの中で文字列連結しながらSQL作るようなのはダメ絶対
- 376 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:40:04.61 ]
- 別にダメじゃないだろ
O/RマッパーやPreparedStatementがないと
基本的なセキュリティ対策すらできないことのほうが問題
Javaじゃないと作れない人になってしまうよ
- 377 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 02:09:42.74 ]
- JavaスレだからJavaソースと書いたがどの言語でも同じ
ただしSQLを組み立てるライブラリは除く、を書き忘れた
アプリで文字列連結しながらSQL作るようなのはダメ絶対
- 378 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 05:36:16.05 ]
- >>376
PreparedStatementを積極的に使わない理由が思いつかない。
動的SQLなんて大抵の言語とRDBMSで使えるでしょ。
Javaじゃないと作れない人になってしまう理由がない。
- 379 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 07:38:05.65 ]
- >>376
他の言語もJDBCに相当する機能では、今はPreparedStatement的な手法が主流だし問題ないと思う
- 380 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 11:20:44.10 ]
- 昔は、文字列と、変数の配列(リスト)の2つを受け取って、
SQLをStringBuffer(StringBuilder)で連結しつつ、 ? を埋め込んで、
PreparedStatement 発行したもんだ。
- 381 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 12:31:12.72 ]
- オープンソースJava O/Rマッピングソフト一覧（2013年1月版） | Unofficial DB2 BLOG
ttp://db2.jugem.cc/?eid=2540
- 382 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 22:37:34.34 ]
- PreparedStatementってDBサーバ側の機能だからな
>>376の発想がおかしい
- 383 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 05:23:30.46 ]
- >>382
「Javaじゃないと作れない人になってしまうよ」と言っている当人がJavaでしか作ったことがないパターンでは。
- 384 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:43:10.56 ]
- DBとのやり取りにDAOパターンを採用するとき何をどこに入れるかってどうすることが多い？
(1) Aテーブルに対する主キーでの1件取得、全件取得、挿入、更新、削除などの基本的な操作
(2) Aテーブルに対する業務に特化した操作(他業務で使うことはない)
(3) 複数テーブルを結合する複数業務で利用する操作
うちの周りだと下記のようにすることが多いんだけど、保守フェイズに入ると(3)が問題になりがちなんだよね
(1)は全テーブル分用意して共通パッケージに突っ込んでる
(2)は業務ごとにパッケージとDaoクラスを作成してそこに突っ込む
(3)は代表的なテーブルのDao(上記1に該当するもの)に突っ込んで他の業務でも使う
- 385 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:52:59.87 ]
- 開発の規模によるがうちなら⑴と⑶だけかな
⑵は他の業務から使えないのが微妙
- 386 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:54:46.69 ]
- 問題の内容忘れてたわ…
問題1. どの業務が使っているかわかりにくいから触るのが怖い
問題2. 最初は(2)のパターンだったけど改修の結果(3)のパターンになった時に共通パッケージに移動しづらい
(移動すると共通Daoを触る全業務の再テストが必要になる)
個人的には問題1はお前保守なんだから調査しろよ、
問題2はそこの客の方針がそうなら移動諦めて各業務Daoで重複させるか再テスト頑張れよ
って思ってて、実際そう伝えたんだけど納得されなくてなあ…
銀の弾丸はなかなかないんだよ
- 387 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 09:12:01.84 ]
- 結局生SQLが一番いいという結果になるな
- 388 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:55:44.21 ]
- >>382
その上「基本的なパフォチューすらできない」っていうねw
SQLがどうやって実行されるか気にしたこともないんだろうな
- 389 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:58:16.26 ]
- 結局SQLがどうやって実行されるか気にしなければならない
O/Rマッパは使わないほうがいい。
- 390 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 12:49:51.63 ]
- >>388
なんでセキュリティ対策のこと書くとパフォーマンスチューニングについて
わかってないことになるの？議論がめちゃくちゃ
- 391 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 13:35:29.45 ]
- 前から言ってるけどO/RマッパやDAO、DSLか生SQL、どれを選択するのかは使う用途によると思う。
その前提がなくただO/Rマッパは使わないほうがいいというのは、少なくとも今のトレンドに
あっていないことも自覚すべきじゃないかと思う。
#特に国内と国外との違いにいつも愕然とするんですよね。
SQLやその実行過程を理解しガリガリにチューニングしなければならないというのも間違っていないし、
そしてO/Rマッパを使って抽象化・簡略化するのも間違っていないと思う。
何が目的でどういう手段を使うべきかをもうちょっと考察して議論したほうがいいと思う。
PreparedStatementを例に出したのはちょっとしたトラップで、
* PreparedStatementの利点を理解しているか?
* そもそも(たいていの場合)PreparedStatementを直接書くのが間違っているのを認識しているか?
を知りたかったからです(すみません)。
- 392 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:38:38.18 ]
- でもJavaの用途はWebがほとんどだからパフォーマンス重視なのは
仕方ない。だから生SQLが一番いい。
- 393 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:49:37.60 ]
- >>392
興味本位で聞くのですけど、O/Rマップってどのくらい遅いのですか?
具体的にベンチマークしましたでしょうか?
＃「あおり」じゃないので興味あったらで。
十分選択肢に入るくらい軽くなってますよ。
＃さらにいうと生SQLも書けるのですが(例えばMyBatis)。
- 394 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:02:22.39 ]
- O/Rマッピングはアンチパターン？ | スラッシュドット・ジャパン デベロッパー
ttp://developers.slashdot.jp/submission/42933/
- 395 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:14:44.15 ]
- >>393
びっくりするほど遅い。んで生SQLに書き直さないといけなくなる。
せめて生SQLにしないといけない割合が全体の1割未満なら使ってもいいけど
実際のプロジェクトではマスタメンテのような機能以外は
生SQLになってしまうので使い物にならない。
- 396 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:29:57.81 ]
- どういうケースでどんな理由で遅くなるのか具体例が欲しいな。
- 397 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:40:04.67 ]
- >>395
(また言いますけど煽りじゃないです。O/Rマッパ開発者としては現状認識を知りたい。)
生SQLをO/Rマッパに使ってもですか?
私の思う生SQLやストアドプロシージャを使う場面は、
* 長大で複雑ななクエリ(検索)
* バッチ処理など、検索以外にも挿入や更新が多い処理
だと思うのですけど、そういうケースですか?
あとO/Rマッパ(名前およびバージョン)に何使ったのかも気になりますね。
一般的なケースだとあまりボトルネックにならないのですが...。特にWebアプリだと。
>>395
そうそう気になりますよね。参考になりますし。
- 398 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 16:47:15.90 ]
- RailsみたいにORマッパに適したテーブル設計ができていれば、
結構不都合無いパフォーマンスになるんですけどね。
IOの激しいWeb系とかゲームだと設計的に厳しいし、
がちがちの業務系だとそういう設計のできないアホなSEばっかだし、
そもそも設計をフレームワークに合わせるのか、とか不毛な議論が始まるので。。。
小規模なアプリをサクッと作る場合には便利なんですけどねぇ。
- 399 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:42:51.07 ]
- 社内システムならDBの負荷はたかがしれてるから
ORM使っても性能上の問題ないよ
開発スピードも上がる。
パフォーマンスが大きく変わるのはメモリ上にDBのデータが
のっているかどうかだろう
WebサービスであってもほとんどORM使って問題ないと思うし
本当に性能が必要な場面はストアドプロシージャ使えばSQLより速くなる。
必死にORM否定してる人は使い方が分からないか、
使いどころがわからないだけ
- 400 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:50:31.65 ]
- ストアドプロシージャは使いたくないです。
- 401 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 18:09:34.30 ]
- まぁ2:8の法則だわな。
8割の処理はORMで十分だし、利用頻度が高かったり負荷の高い2割の処理は生SQL。
ってのが常道だと思う。
俺がよく使ってるのはHibernateJPAだけど、速度的には不満は無いね。
むしろDBにきちんと索引張ったり外部キー設計する方が大事だと思う。
- 402 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:02:46.76 ]
- ORMいらない、と言っている人間ははよくわからんな。
Micro-ORMで十分、なら理解できるが。
- 403 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:14:49.27 ]
- ORMと一括りにして議論している時点で程度が知れてる、というべきだな。
- 404 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 00:33:47.55 ]
- 同じSQLでO/Rマッパーだけ遅いなら外すしかないね。
内部のリフレクションとかが遅いんじゃないの？
- 405 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:24:46.14 ]
- 問題になる遅さなのそれ。
- 406 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:29:38.75 ]
- 生SQLとかORMいらないとか連投してるのは荒らしだろ
現実的にはこのどっちか
・SQLを暗黙的に発行することがあるHibernate含むJPA系のORM
・プログラムで指定したとおりのSQLを発行するMyBatisやSeasar系などのORM
- 407 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:06:46.51 ]
- 生SQLの定義がわからんね
SQL*Plusなんかで直接実行できるSeasarの2way SQLは生SQLなのかどうか
- 408 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:32:20.33 ]
- フレームワークが勝手に作ったSQLを発行するんじゃなくて、
開発者が書いたSQLを流すのが生SQLでいいと思う
MyBatisとかDOMAとかの生SQLベースのマッピングはめんどくさいところもあるけど入門編にはいいと思うわ
- 409 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:41:14.77 ]
- だとするとJPA系を除く多くのORMは生SQLが主なんだが
生SQL君が言いたいのはORMイラネじゃなくJPAイラネなのか？
ORMイラネ君と同一人物かと思ってたんだが
- 410 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:49:50.56 ]
- >>407 >>409
ORMはSQLを生成して、SQLを投げるだけだよ
複雑なJOINしない限り、ほとんど性能は落ちない。
生SQLってのは自分でSQL文を書くってことだろう
JPAもORMの一種
ORM要らないって連呼してるひとは、
上のほうでフレームワークも要らないと必死に主張していたひとと同一人物だと思う。
- 411 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 15:07:49.10 ]
- >>410
自分で書いたSQLをORMで実行した場合も生SQLだとしたら、
生SQLが必要だからORMイラネってのはおかしいという話
生SQLが主のORMもたくさんあるわけだから
生SQL君とORMイラネ君が同一人物かどうかはしらんけど
- 412 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 18:43:58.87 ]
- 俺は生SQL書きやすいORMならOK派かな。
Hibernateみたいなのは勘弁。
フレームワークも不要。
- 413 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 20:20:44.35 ]
- MyBatis+標準SQL(SQL92あたり)でいいわ
- 414 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 22:50:54.10 ]
- まぁ日本の開発現場ではNIH症候群が蔓延してるからな。
車輪の再発明大好きだし。
- 415 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 00:30:58.37 ]
- おれもMyBATIS＋SQLだな
学習コスト少なめだし、バグがあっても追いやすいし
裏で動的にSQL生成してるようなフレームワークで
いい思いをしたことがない
- 416 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 05:58:23.38 ]
- ＳＱＬ方言だけ吸収してくれれば
- 417 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 07:20:01.88 ]
- Hibernateかなぁ。
幸い個々のエンティティに関して比較的単純なCRUDしか必要が無いのでMyBatisでSQL書いた
ところでHibernateが生成するSQLとあまり大差無いものを書くことになったり。
個人的にはエンティティ引っぱってくるときに射影相当の演算や、関連を引っぱってくるのを
LazyにするのかEagerにするのか、固定ではなく場面に応じて簡単に指定出来ると有り難い。
HibernateだとCriteriaに頼ることになるので面倒。
- 418 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 09:24:08.73 ]
- >>415
どれでも発行SQLだけ確認やログ出しも出来るし
2WAYならチェックした上でマズいの手書きできる
フレームワークで統一性のない動的生成ルールが面倒だけどな
それよりもDTO周りの議論に戻ってくれ
俺も今DTO増殖中で疲れてる
- 419 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 10:34:49.59 ]
- DTOはある程度割り切って共有で結論出てなかったっけ
割り切り共有＋継承＋テーブル定義とにらめっこ、
すればそこまで増殖しないと思うが。
- 420 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:05:35.15 ]
- DTOのクラスが増えるのが嫌なら、全部Mapに突っ込んでしまえば？ｗ
- 421 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:07:19.28 ]
- Mapでええやろ
- 422 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:37:01.55 ]
- mapでいいならJavaじゃなくていいだろ
getterがあるからキーの文字列を意識しないで済んでるのに
- 423 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 19:32:32.72 ]
- MapとDTOは使い分ければ良いと思うけどなぁ。
- 424 名前：デフォルトの名無しさん [2013/03/31(日) 10:16:31.71 ]
- Java系のフレームワーク、海外ではGrailsがすごい人気高くて驚いた
Java系だとGrailsはトップ3に入ってる
Java系でサクサク開発できるのはGrailsとPlayみたいだ
Javaの方言のGroovyだからといってGrailsを敬遠しないほうがよさそう
- 425 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 11:10:40.80 ]
- GroovyはJavaの資産は使えるなら積極的に使おうって姿勢かな
- 426 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 22:08:24.97 ]
- GroovyはJavaの方言というかJavaプラスアルファぐらいに考えた方が良いと思う。
Javaの文法にRuby風の文法やメソッドも付け加えた感じで、両方を混ぜて書ける。
JavaとRuby両方の素養がある人だとすごく便利だと思うよ。
Grailsだと根っこのドメインロジックはJava風にカッチリ書いたりそれこそJavaとして書いて、
逆にGSP(Grails版JSPみたいなもの)に埋め込むコードとか簡単なコントローラーはGroovyの
文法駆使して簡単に書く。
- 427 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 00:51:09.20 ]
- Groovy、Rubyほどギークでもない人でもゆるく書けるし、scalaより難しくないので、もっと流行ってもいいと思うんだけどな。
といいつつ周りではやっとこさ少しずつ広がってきて、以下のようなことをやるような人が増えてきた。
→納品物(webアプリケーション本体)はJavaだが、UTコード、内部ツールはGroovy、など。
ビルドはgradle、とか。
といいつつRubyに素養がある人はRubyでやっちゃうんだよな。
- 428 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 02:41:51.01 ]
- JavaのView層はいつまでも安定しないね
似たようなコードの書き方、次から次に覚えないといけないのはきつい
他の言語はほとんど安定してるのになあ
- 429 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 03:21:29.18 ]
- Grailsは確かにもっと流行っても良い気はする。
会社でやっているプロジェクトも最近ようやくGrails2.2.1にバージョンアップして依存性管理を
Mavenに移行出来たので他のプロジェクトとの連携がよりやりやすくなった。
- 430 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 07:00:39.53 ]
- フレームワーク使わない人ってURLマッピングはどうやっているのだろう。
例えばクエリーを使ったレガシーなaaa/product_comment?id=12345&comment=6789みたいな
URLではなく、よりRESTfulなaaa/product/12345/comment/6789みたいなURLを使う場合。
フレームワーク無しの生Servertだと毎度自前でpathをパースしたりサブリソース毎に条件分岐したりと
手作りできるにせよ無駄に面倒だと思う。
- 431 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 11:03:54.12 ]
- >>430
mod_rewrite
|
 |
