【Java】 Java Web Application Framework 総合

【Java】 Java Web Ap ..

329:デフォルトの名無しさん
13/03/13 01:10:39.93
hibernateって昔、1000件DELETEするときに
1000回DELETE文が走るとかでこれは使えないと断念したことがあるのだけど
いまのhibernateとかJPAとやらはそのへんは改良されてるの？

330:デフォルトの名無しさん
13/03/13 01:13:34.55
横断的な処理をする場合はJPQLを使って処理するんだろ
JPAはSELECTがJava側から見て綺麗になるくらいで後は方言吸収くらいが利点か

331:デフォルトの名無しさん
13/03/13 11:42:57.54
Linuxサーバーって一回設定したら以後放置だよね。Windows Update + Windows Serverの方がよいよね
ｽﾚﾘﾝｸ(poverty板)

332:デフォルトの名無しさん
13/03/13 15:53:58.68
>>329
調査不足つか調査力不足
Hibernate2.xの頃ですらできてた

333:デフォルトの名無しさん
13/03/13 16:53:32.09
>>332
昔って書いたのに何でそういう否定の仕方するんかね。
俺が見たのは2003年ごろだよ。バージョンは忘れた。

334:デフォルトの名無しさん
13/03/13 17:18:16.36
別に1000回DELETEすることは問題じゃないと思う。
それが1回のSQLでDELETEするのと同じ速度なら。
でもまだそういう時代じゃないからO/Rマッピングは悪だと思う。

335:デフォルトの名無しさん
13/03/13 18:07:27.21
>>333
事実だから
2002年1月リリースの0.9.2からできてたことに気づけず断念とか調査力不足だろ

336:デフォルトの名無しさん
13/03/13 18:34:57.15
>>335
まさかHQLのことじゃないよね？

337:デフォルトの名無しさん
13/03/13 18:50:25.71
すり替えｷﾀwww
少なくとも10年選手なんだろ？情けねぇ・・・
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
どう見てもHQL使うべき場面です

338:デフォルトの名無しさん
13/03/13 19:00:25.43
できるできるってHQLのことかよ
HQL書かないといかんのなら使わんよそんなもん
隠蔽されて実行されるSQLを最適化してくれるよう
進化してるかが質問の意図だったんだが

339:デフォルトの名無しさん
13/03/13 19:09:20.82
>>338
だよな
それをわかってないんだよ
ここの奴らは

340:デフォルトの名無しさん
13/03/13 19:11:33.54
は？その意図が「1000件DELETEするときに」で伝わると思ってんの？
少なくとも10年選手なんだろ？大丈夫かお前
ついでに言っておくと、2002年の1.1からバッチ更新使うから
「1000回DELETE文が走る」も成立しない
だいたいHQL書かないならDELETE関係なくHibernate使えないじゃねーか
1000件フェッチしてくるのだって大概HQL書くだろ
idとナビゲーションだけでやるつもり？アフォですか
「10年前は未熟でした」で終わらせておけばいいものを「今も」バカだって晒してどうする

341:デフォルトの名無しさん
13/03/13 19:14:31.73
ファビョるなw

342:デフォルトの名無しさん
13/03/13 19:16:26.44
一応書いておくが、俺(340他)はHibernate使えるとは思ってない
↓がバカだと思っただけだ

> 1000件DELETEするときに
> 1000回DELETE文が走るとかでこれは使えないと断念

343:デフォルトの名無しさん
13/03/13 19:16:53.38
そもそもオブジェクトを操作するだけでSQLと遜色ない速度で
動いてくれないと意味ないんだよ。

344:デフォルトの名無しさん
13/03/15 01:16:45.46
亀レス＆スレチですまん。

>>224
いまだにメインはJavaなんだけど、node.jsを使い始めてる。
フロント側をJavaScript+jQueryでやることが多くなって
サーバ側も同じ言語が使えるのは良い感じ。
ただ、JSはタイプセーフじゃないから、巨大なシステムにはまだ不安。

345:デフォルトの名無しさん
13/03/15 14:12:49.96
タイプセーフは重要

346:デフォルトの名無しさん
13/03/16 00:31:32.17
>>344-345
同じ言語を使えるってのは楽でいいね

言語の問題は置いておいて、node用のフレームワークの出来はどう？
expressだっけ？

TypeScript使えばJSも部分的にTypeSafeになるんじゃない？

347:デフォルトの名無しさん
13/03/16 00:47:09.87
Expressが必要なところでNode.jsを使ったら負けだと思ってる

348:224
13/03/16 22:53:33.58
>>344
node.jsか。レスありがとう!

349:デフォルトの名無しさん
13/03/18 20:10:52.78
Mybatisのセカンドレベルキャッシュってどこに保存されてるんだろ
Serializableを要求するからTEMPフォルダでも指定してるのかと思ったが見あたらない？
もしかしてインメモリなのか？ローカルキャッシュよりは全然遅いのだが

350:デフォルトの名無しさん
13/03/18 20:49:09.28
ああreadonlyに設定してないと読み取りの度にシリアライズが走るのか
イミュータブルにすると周囲にやや不評だろうけど安全だしそうするか

351:デフォルトの名無しさん
13/03/20 00:08:40.52
mapper XMLでinsertをする時、useGeneratedKeysを指定すれば自動採番されたIDが取得できるのは
わかってるんだけど、これって単発insertのときだけじゃないですか。
insert selectで複数行をinsertしたとき、全部の自動採番IDを取ることって出来るんですか？

352:デフォルトの名無しさん
13/03/20 01:00:57.18
生JDBCのgetGeneratedKeys()はResultSetを返すんだからできるんじゃねーの？

353:351
13/03/20 01:13:31.36
いろいろ端折り過ぎてた
spring + myBatisでPostgreSQLです
keyPropertyに指定するフィールドを配列やListにしてみたんだけどダメだったなー
生JDBCでできているてことは、自前でhandlerとか作ってやればいいのかな

354:デフォルトの名無しさん
13/03/25 11:00:30.07
O/R マッピングは便利なんだけど何を使ってもテーブル結合と集計で悩む.
Entityと1:1にならない1000SQLのために対応するDTOを1000作るのか？みたいな.
型の安全性とか名前の管理とか考えたらList<Map>よりずっとマシなんだけど数がなぁ…

355:デフォルトの名無しさん
13/03/25 11:10:09.19
あと、Tableに対応するクラスはEntityでいいとして、SQLに対応するクラスは何と定義してどのパッケージに突っ込んでる？
前者をDomainEntity, 後者をCustomizeEntityと呼んで同じパッケージに突っ込んでるプロダクトもあるみたいだけど.

356:デフォルトの名無しさん
13/03/25 11:31:00.42
だからまったくSQLを意識しなくてすむレベルまでオブジェクトにしても
パフォーマンスがぜんぜん問題にならないくらいになるまで
使うべきじゃない。時期尚早。

357:デフォルトの名無しさん
13/03/25 11:52:33.44
>>356
使わないのも選択肢としてありだと思うけど>>354-355の課題は使用有無に関わらず発生するよね
これみんなどうしてるのかねぇ

358:デフォルトの名無しさん
13/03/25 12:15:04.22
>>354
適材適所でいいんじゃないの
SQL使うほうが楽な場所はSQLで直接やればいい。
お決まりの処理で性能を満たす場合はORMで。

359:デフォルトの名無しさん
13/03/25 14:06:30.14
>>358
まったくそのとおりだと思う。
実際ORマッパには生SQLを発行できるタイプもあるし、
生SQLで検索したものをオブジェクトにマップもできる。
(マップできないようにもできる。集計やグループ化もたいていは対応してるんじゃないかな。)
SQLインジェクションにならないようにするだけでも価値があるし、
コネクションプーリングだけでも有用だと思う。
ORマッパにもよると思うがあまり毛嫌いする要素はないと思う。

360:デフォルトの名無しさん
13/03/25 14:31:52.65
SQLインジェクションとコネクションプール用途で使うには重すぎるだろ
そんなのcommonsあたりで簡単に対応できるしな

361:デフォルトの名無しさん
13/03/25 15:17:03.51
>>360
え、そんなことないよ。軽いものなんていくらでも。例えばS2JDBCとか。
マップする用途からしない用途までわざわざ書いたのはそういうことですよ。
CommonsだとCommons使わない人が出てくるのでSQLインジェクション対策としては
片手落ちだと思っています。
あえて言っておきますがORマッパを使わない選択肢は否定していませんからね。

362:デフォルトの名無しさん
13/03/25 15:36:33.34
>>359
＞生SQLで検索したものをオブジェクトにマップもできる。
ここが気になるって話じゃないの？
マップできるのはいいとして、SQLに対応するクラスをSQLの数だけ作るのか、
またはList<Map<String, Object>>とかで済ませてるのか

うちは後者で統一されてて、生SQLのSELECT句に対応するDTOは作成が禁止されてる
Mapのキー管理がかなり面倒だけどクラスの数を増やしたくないらしい

363:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/25 17:45:17.21
>>354-355
俺はある程度割り切ってクラスを共有するよ。
ざっくりとした例なので批判されるかもしれないけど
会員名、店舗名、都道府県名を格納できるDTOを用意して
会員→店舗までしかJOINしない場合もそのDTOを使用する。
都道府県名はnullなので都道府県名が欲しい場合は別のSQL使ってねと。

365:デフォルトの名無しさん
13/03/25 17:50:01.38
ありだな

366:デフォルトの名無しさん
13/03/25 18:22:48.02
ありだと思うよ
ただその場合だと複数機能で共有するだろうからパッケージに悩みそうかな
SQL書くときって機能でパッケージ分けてると共有しづらいよなー
ドメインモデリングは理解できる奴少なかったりするし

367:デフォルトの名無しさん
13/03/25 18:59:18.05
>>363
マッピングせずにResultSet(風)を触らせるのもありか
SQL発行した側はカラム名も型もわかってるはずだしな

この前久しぶりにMyBatis採用案件見たけど
これくらいシンプルな方が設計者も実装者もわかりやすくていいのかもしれないな

368:デフォルトの名無しさん
13/03/25 19:05:13.70
ようするにO/Rマッピングは現段階では不要だな

369:デフォルトの名無しさん
13/03/25 19:26:38.33
>>368
それはさすがに極論すぎて、ORマッパ以前にバグやセキュリティホールの温床になりそうです。

現状Webアプリなどの場合はORマッパがボトルネックになるより、
RDBMSの処理の方がボトルネックになることが多くて、
ORマッパの意義はむしろ昔より重みが増しているように感じられます。
＃つまりCommons DbUtils使ってやれはちょっと...ということです。
＃そして最近のORマッパは結構薄いラッパであることが多く、
＃そんなに重たくありません。

ただ素のSQLやPLSQL/pgSQLなどの手続き言語を併用するのを
否定することではなく、バッチ処理のようなデータベースで処理だと
ORマッパ以前にフロントエンドの処理がボトルネックになることが
あると思います。その場合はそれを選択すればいいだけです。

370:デフォルトの名無しさん
13/03/25 19:37:43.30
>>369
O/Rマッパーを使わないとバグやセキュリティホールの温床になるってのは
技術職、開発会社としてどうなんだ？
俺は条件によってはO/Rマッパーが有効なプロジェクトもあると思ってるが
上記のことは本質とはだいぶ違うと思うのだが。

371:デフォルトの名無しさん
13/03/25 19:40:36.78
SQL生成用クラスを一個つくればいいよね

372:デフォルトの名無しさん
13/03/25 19:45:11.79
>>370
本質じゃないというか言いたいのは「直接JDBC触らせるな」(DbUtils含む)ということですよ。
ORマッパはDAOみたいな機構も持っていることがあるので、
それなら最初からORマッパを使えば?ということです。
そういう汎用性をちゃんと持っているという認識が必要です。

>>371
そうですね。
でもそのサポートもDAOやORマッパがやってくれますけどね。

373:デフォルトの名無しさん
13/03/25 19:48:36.82
あと聞きたいのですが、JDBCなどを使っている場合、
java.sql.PreparedStatementをちゃんと使ってますか?

374:デフォルトの名無しさん
13/03/25 20:04:13.30
SQL生成用クラスでPreparedStatementを使ってバインドしてるよ。

375:デフォルトの名無しさん
13/03/26 01:20:56.00
Javaソースの中で文字列連結しながらSQL作るようなのはダメ絶対

376:デフォルトの名無しさん
13/03/26 01:40:04.61
別にダメじゃないだろ
O/RマッパーやPreparedStatementがないと
基本的なセキュリティ対策すらできないことのほうが問題
Javaじゃないと作れない人になってしまうよ

377:デフォルトの名無しさん
13/03/26 02:09:42.74
JavaスレだからJavaソースと書いたがどの言語でも同じ
ただしSQLを組み立てるライブラリは除く、を書き忘れた
アプリで文字列連結しながらSQL作るようなのはダメ絶対

378:デフォルトの名無しさん
13/03/26 05:36:16.05
>>376
PreparedStatementを積極的に使わない理由が思いつかない。
動的SQLなんて大抵の言語とRDBMSで使えるでしょ。
Javaじゃないと作れない人になってしまう理由がない。

379:デフォルトの名無しさん
13/03/26 07:38:05.65
>>376
他の言語もJDBCに相当する機能では、今はPreparedStatement的な手法が主流だし問題ないと思う

380:デフォルトの名無しさん
13/03/26 11:20:44.10
昔は、文字列と、変数の配列(リスト)の2つを受け取って、
SQLをStringBuffer(StringBuilder)で連結しつつ、 ? を埋め込んで、
PreparedStatement 発行したもんだ。

381:デフォルトの名無しさん
13/03/26 12:31:12.72
オープンソースJava O/Rマッピングソフト一覧（2013年1月版） | Unofficial DB2 BLOG
URLﾘﾝｸ(db2.jugem.cc)

382:デフォルトの名無しさん
13/03/26 22:37:34.34
PreparedStatementってDBサーバ側の機能だからな
>>376の発想がおかしい

383:デフォルトの名無しさん
13/03/27 05:23:30.46
>>382
「Javaじゃないと作れない人になってしまうよ」と言っている当人がJavaでしか作ったことがないパターンでは。

384:デフォルトの名無しさん
13/03/27 08:43:10.56
DBとのやり取りにDAOパターンを採用するとき何をどこに入れるかってどうすることが多い？

(1) Aテーブルに対する主キーでの1件取得、全件取得、挿入、更新、削除などの基本的な操作
(2) Aテーブルに対する業務に特化した操作(他業務で使うことはない)
(3) 複数テーブルを結合する複数業務で利用する操作

うちの周りだと下記のようにすることが多いんだけど、保守フェイズに入ると(3)が問題になりがちなんだよね
(1)は全テーブル分用意して共通パッケージに突っ込んでる
(2)は業務ごとにパッケージとDaoクラスを作成してそこに突っ込む
(3)は代表的なテーブルのDao(上記1に該当するもの)に突っ込んで他の業務でも使う

385:デフォルトの名無しさん
13/03/27 08:52:59.87
開発の規模によるがうちなら⑴と⑶だけかな
⑵は他の業務から使えないのが微妙

386:デフォルトの名無しさん
13/03/27 08:54:46.69
問題の内容忘れてたわ…

問題1. どの業務が使っているかわかりにくいから触るのが怖い
問題2. 最初は(2)のパターンだったけど改修の結果(3)のパターンになった時に共通パッケージに移動しづらい
(移動すると共通Daoを触る全業務の再テストが必要になる)

個人的には問題1はお前保守なんだから調査しろよ、
問題2はそこの客の方針がそうなら移動諦めて各業務Daoで重複させるか再テスト頑張れよ
って思ってて、実際そう伝えたんだけど納得されなくてなあ…

銀の弾丸はなかなかないんだよ

387:デフォルトの名無しさん
13/03/27 09:12:01.84
結局生SQLが一番いいという結果になるな

388:デフォルトの名無しさん
13/03/27 11:55:44.21
>>382
その上「基本的なパフォチューすらできない」っていうねw
SQLがどうやって実行されるか気にしたこともないんだろうな

389:デフォルトの名無しさん
13/03/27 11:58:16.26
結局SQLがどうやって実行されるか気にしなければならない
O/Rマッパは使わないほうがいい。

390:デフォルトの名無しさん
13/03/27 12:49:51.63
>>388
なんでセキュリティ対策のこと書くとパフォーマンスチューニングについて
わかってないことになるの？議論がめちゃくちゃ

391:デフォルトの名無しさん
13/03/27 13:35:29.45
前から言ってるけどO/RマッパやDAO、DSLか生SQL、どれを選択するのかは使う用途によると思う。
その前提がなくただO/Rマッパは使わないほうがいいというのは、少なくとも今のトレンドに
あっていないことも自覚すべきじゃないかと思う。
#特に国内と国外との違いにいつも愕然とするんですよね。

SQLやその実行過程を理解しガリガリにチューニングしなければならないというのも間違っていないし、
そしてO/Rマッパを使って抽象化・簡略化するのも間違っていないと思う。
何が目的でどういう手段を使うべきかをもうちょっと考察して議論したほうがいいと思う。

PreparedStatementを例に出したのはちょっとしたトラップで、
* PreparedStatementの利点を理解しているか?
* そもそも(たいていの場合)PreparedStatementを直接書くのが間違っているのを認識しているか?
を知りたかったからです(すみません)。

392:デフォルトの名無しさん
13/03/27 14:38:38.18
でもJavaの用途はWebがほとんどだからパフォーマンス重視なのは
仕方ない。だから生SQLが一番いい。

393:デフォルトの名無しさん
13/03/27 14:49:37.60
>>392
興味本位で聞くのですけど、O/Rマップってどのくらい遅いのですか?
具体的にベンチマークしましたでしょうか?
＃「あおり」じゃないので興味あったらで。

十分選択肢に入るくらい軽くなってますよ。
＃さらにいうと生SQLも書けるのですが(例えばMyBatis)。

394:デフォルトの名無しさん
13/03/27 15:02:22.39
O/Rマッピングはアンチパターン？ | スラッシュドット・ジャパンデベロッパー
URLﾘﾝｸ(developers.slashdot.jp)

395:デフォルトの名無しさん
13/03/27 15:14:44.15
>>393
びっくりするほど遅い。んで生SQLに書き直さないといけなくなる。
せめて生SQLにしないといけない割合が全体の1割未満なら使ってもいいけど
実際のプロジェクトではマスタメンテのような機能以外は
生SQLになってしまうので使い物にならない。

396:デフォルトの名無しさん
13/03/27 15:29:57.81
どういうケースでどんな理由で遅くなるのか具体例が欲しいな。

397:デフォルトの名無しさん
13/03/27 15:40:04.67
>>395
(また言いますけど煽りじゃないです。O/Rマッパ開発者としては現状認識を知りたい。)
生SQLをO/Rマッパに使ってもですか?

私の思う生SQLやストアドプロシージャを使う場面は、
* 長大で複雑ななクエリ(検索)
* バッチ処理など、検索以外にも挿入や更新が多い処理
だと思うのですけど、そういうケースですか?
あとO/Rマッパ(名前およびバージョン)に何使ったのかも気になりますね。

一般的なケースだとあまりボトルネックにならないのですが...。特にWebアプリだと。

>>395
そうそう気になりますよね。参考になりますし。

398:デフォルトの名無しさん
13/03/27 16:47:15.90
RailsみたいにORマッパに適したテーブル設計ができていれば、
結構不都合無いパフォーマンスになるんですけどね。
IOの激しいWeb系とかゲームだと設計的に厳しいし、
がちがちの業務系だとそういう設計のできないアホなSEばっかだし、
そもそも設計をフレームワークに合わせるのか、とか不毛な議論が始まるので。。。
小規模なアプリをサクッと作る場合には便利なんですけどねぇ。

399:デフォルトの名無しさん
13/03/27 17:42:51.07
社内システムならDBの負荷はたかがしれてるから
ORM使っても性能上の問題ないよ
開発スピードも上がる。

パフォーマンスが大きく変わるのはメモリ上にDBのデータが
のっているかどうかだろう

WebサービスであってもほとんどORM使って問題ないと思うし
本当に性能が必要な場面はストアドプロシージャ使えばSQLより速くなる。

必死にORM否定してる人は使い方が分からないか、
使いどころがわからないだけ

400:デフォルトの名無しさん
13/03/27 17:50:31.65
ストアドプロシージャは使いたくないです。

401:デフォルトの名無しさん
13/03/27 18:09:34.30
まぁ2:8の法則だわな。
8割の処理はORMで十分だし、利用頻度が高かったり負荷の高い2割の処理は生SQL。
ってのが常道だと思う。
俺がよく使ってるのはHibernateJPAだけど、速度的には不満は無いね。
むしろDBにきちんと索引張ったり外部キー設計する方が大事だと思う。

402:デフォルトの名無しさん
13/03/27 21:02:46.76
ORMいらない、と言っている人間ははよくわからんな。
Micro-ORMで十分、なら理解できるが。

403:デフォルトの名無しさん
13/03/27 21:14:49.27
ORMと一括りにして議論している時点で程度が知れてる、というべきだな。

404:デフォルトの名無しさん
13/03/28 00:33:47.55
同じSQLでO/Rマッパーだけ遅いなら外すしかないね。
内部のリフレクションとかが遅いんじゃないの？

405:デフォルトの名無しさん
13/03/28 01:24:46.14
問題になる遅さなのそれ。

406:デフォルトの名無しさん
13/03/28 01:29:38.75
生SQLとかORMいらないとか連投してるのは荒らしだろ
現実的にはこのどっちか

・SQLを暗黙的に発行することがあるHibernate含むJPA系のORM
・プログラムで指定したとおりのSQLを発行するMyBatisやSeasar系などのORM

407:デフォルトの名無しさん
13/03/28 14:06:46.51
生SQLの定義がわからんね
SQL*Plusなんかで直接実行できるSeasarの2way SQLは生SQLなのかどうか

408:デフォルトの名無しさん
13/03/28 14:32:20.33
フレームワークが勝手に作ったSQLを発行するんじゃなくて、
開発者が書いたSQLを流すのが生SQLでいいと思う

MyBatisとかDOMAとかの生SQLベースのマッピングはめんどくさいところもあるけど入門編にはいいと思うわ

409:デフォルトの名無しさん
13/03/28 14:41:14.77
だとするとJPA系を除く多くのORMは生SQLが主なんだが
生SQL君が言いたいのはORMイラネじゃなくJPAイラネなのか？
ORMイラネ君と同一人物かと思ってたんだが

410:デフォルトの名無しさん
13/03/28 14:49:50.56
>>407 >>409
ORMはSQLを生成して、SQLを投げるだけだよ
複雑なJOINしない限り、ほとんど性能は落ちない。

生SQLってのは自分でSQL文を書くってことだろう
JPAもORMの一種

ORM要らないって連呼してるひとは、
上のほうでフレームワークも要らないと必死に主張していたひとと同一人物だと思う。

411:デフォルトの名無しさん
13/03/28 15:07:49.10
>>410
自分で書いたSQLをORMで実行した場合も生SQLだとしたら、
生SQLが必要だからORMイラネってのはおかしいという話
生SQLが主のORMもたくさんあるわけだから
生SQL君とORMイラネ君が同一人物かどうかはしらんけど

412:デフォルトの名無しさん
13/03/28 18:43:58.87
俺は生SQL書きやすいORMならOK派かな。
Hibernateみたいなのは勘弁。
フレームワークも不要。

413:デフォルトの名無しさん
13/03/28 20:20:44.35
MyBatis+標準SQL(SQL92あたり)でいいわ

414:デフォルトの名無しさん
13/03/28 22:50:54.10
まぁ日本の開発現場ではNIH症候群が蔓延してるからな。
車輪の再発明大好きだし。

415:デフォルトの名無しさん
13/03/29 00:30:58.37
おれもMyBATIS＋SQLだな
学習コスト少なめだし、バグがあっても追いやすいし
裏で動的にSQL生成してるようなフレームワークで
いい思いをしたことがない

416:デフォルトの名無しさん
13/03/29 05:58:23.38
ＳＱＬ方言だけ吸収してくれれば

417:デフォルトの名無しさん
13/03/29 07:20:01.88
Hibernateかなぁ。
幸い個々のエンティティに関して比較的単純なCRUDしか必要が無いのでMyBatisでSQL書いた
ところでHibernateが生成するSQLとあまり大差無いものを書くことになったり。

個人的にはエンティティ引っぱってくるときに射影相当の演算や、関連を引っぱってくるのを
LazyにするのかEagerにするのか、固定ではなく場面に応じて簡単に指定出来ると有り難い。
HibernateだとCriteriaに頼ることになるので面倒。

418:デフォルトの名無しさん
13/03/30 09:24:08.73
>>415
どれでも発行SQLだけ確認やログ出しも出来るし
2WAYならチェックした上でマズいの手書きできる
フレームワークで統一性のない動的生成ルールが面倒だけどな

それよりもDTO周りの議論に戻ってくれ
俺も今DTO増殖中で疲れてる

419:デフォルトの名無しさん
13/03/30 10:34:49.59
DTOはある程度割り切って共有で結論出てなかったっけ
割り切り共有＋継承＋テーブル定義とにらめっこ、
すればそこまで増殖しないと思うが。

420:デフォルトの名無しさん
13/03/30 13:05:35.15
DTOのクラスが増えるのが嫌なら、全部Mapに突っ込んでしまえば？ｗ

421:デフォルトの名無しさん
13/03/30 13:07:19.28
Mapでええやろ

422:デフォルトの名無しさん
13/03/30 13:37:01.55
mapでいいならJavaじゃなくていいだろ
getterがあるからキーの文字列を意識しないで済んでるのに

423:デフォルトの名無しさん
13/03/30 19:32:32.72
MapとDTOは使い分ければ良いと思うけどなぁ。

424:デフォルトの名無しさん
13/03/31 10:16:31.71
Java系のフレームワーク、海外ではGrailsがすごい人気高くて驚いた
Java系だとGrailsはトップ3に入ってる

Java系でサクサク開発できるのはGrailsとPlayみたいだ
Javaの方言のGroovyだからといってGrailsを敬遠しないほうがよさそう

425:デフォルトの名無しさん
13/03/31 11:10:40.80
GroovyはJavaの資産は使えるなら積極的に使おうって姿勢かな

426:デフォルトの名無しさん
13/03/31 22:08:24.97
GroovyはJavaの方言というかJavaプラスアルファぐらいに考えた方が良いと思う。
Javaの文法にRuby風の文法やメソッドも付け加えた感じで、両方を混ぜて書ける。
JavaとRuby両方の素養がある人だとすごく便利だと思うよ。

Grailsだと根っこのドメインロジックはJava風にカッチリ書いたりそれこそJavaとして書いて、
逆にGSP(Grails版JSPみたいなもの)に埋め込むコードとか簡単なコントローラーはGroovyの
文法駆使して簡単に書く。

427:デフォルトの名無しさん
13/04/01 00:51:09.20
Groovy、Rubyほどギークでもない人でもゆるく書けるし、scalaより難しくないので、もっと流行ってもいいと思うんだけどな。
といいつつ周りではやっとこさ少しずつ広がってきて、以下のようなことをやるような人が増えてきた。
→納品物(webアプリケーション本体)はJavaだが、UTコード、内部ツールはGroovy、など。
　ビルドはgradle、とか。

といいつつRubyに素養がある人はRubyでやっちゃうんだよな。

428:デフォルトの名無しさん
13/04/01 02:41:51.01
JavaのView層はいつまでも安定しないね
似たようなコードの書き方、次から次に覚えないといけないのはきつい
他の言語はほとんど安定してるのになあ

429:デフォルトの名無しさん
13/04/01 03:21:29.18
Grailsは確かにもっと流行っても良い気はする。
会社でやっているプロジェクトも最近ようやくGrails2.2.1にバージョンアップして依存性管理を
Mavenに移行出来たので他のプロジェクトとの連携がよりやりやすくなった。

430:デフォルトの名無しさん
13/04/01 07:00:39.53
フレームワーク使わない人ってURLマッピングはどうやっているのだろう。

例えばクエリーを使ったレガシーなURLﾘﾝｸ(aaa)みたいな
URLではなく、よりRESTfulなURLﾘﾝｸ(aaa)みたいなURLを使う場合。

フレームワーク無しの生Servertだと毎度自前でpathをパースしたりサブリソース毎に条件分岐したりと
手作りできるにせよ無駄に面倒だと思う。

431:デフォルトの名無しさん
13/04/01 11:03:54.12
>>430
mod_rewrite

432:デフォルトの名無しさん
13/04/01 11:09:20.88
自前でパースしないと遅いしな

433:デフォルトの名無しさん
13/04/01 17:14:29.59
面倒を厭わない人たちなのはよく解った。

434:デフォルトの名無しさん
13/04/01 17:20:23.50
>>433
面倒を避けようとしてさらに面倒なことになってる印象。

435:デフォルトの名無しさん
13/04/01 22:00:58.98
でもSEO対策が入ってくるとできあいのフレームワークじゃ難しいんだよな
みんなどうしてるか、そっちのが気になるわ

436:デフォルトの名無しさん
13/04/01 22:09:02.05
JSFだのASP.NETだのはイントラじゃなきゃ難しいな

437:デフォルトの名無しさん
13/04/01 22:22:26.68
>>435
どうやってタグを吐くかだから
フレームワークは無関係

438:デフォルトの名無しさん
13/04/01 22:48:03.67
JSP&Servletだけで十分フレームワーク

439:デフォルトの名無しさん
13/04/01 22:50:16.68
URLについては、Struts時代はRouter自作。
Spring MVCでは無問題。

440:デフォルトの名無しさん
13/04/01 23:19:13.95
jspの文字コードがshift_jisで、サーブレットの文字コードがutf-8で書かれている場合、
jsp → サーブレット →　jsp でformパラメータの受け渡しで日本語が文字化けしないようにするには
どうしたらいいでしょうか？

サーブレット側で
変数 = new String(request.getParameter("パラメータ名").getBytes("Shift_JIS"), "UTF-8"));

としてPOSTパラメータを受け取ってUTF-8として処理し終わった後、

変数 = new String(変数.getBytes("UTF-8"), "Shift_JIS");

としてShift_JISに戻して

request.setAttribute("jspで受け取るパラメータ名", 変数);

としたのですが文字化けしてしまいます。

441:デフォルトの名無しさん
13/04/01 23:30:22.30
>>440
JSPの先頭
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="Windows-31J" %>

Servlet
req.setCharacterEncoding("UTF-8");

こうだったかな。JSPファイルもUTF-8にしちゃえば管理も楽だと思うのだけどねぇ

442:デフォルトの名無しさん
13/04/01 23:33:39.56
>>441
すいません。jspは文字コードを使い分けたいので、そのやり方はダメなんです・・・。
あくまで違う文字コードでの受け渡しでやりたいんです。

443:デフォルトの名無しさん
13/04/01 23:41:07.31
Java内部の文字列処理はUTF-16だよ
サーブレットの文字コードって表現が既におかしいんじゃない？

JSPのcharsetもSJISにしたいなら
req.setCharacterEncoding("Windows-31J");
とサーブレット側で受ければいい

444:デフォルトの名無しさん
13/04/02 00:05:07.91
>>443
サーブレットのソースコードのテキスト文字コードがUTF-8ってことです。

サーブレット側では冒頭で
request.setCharacterEncoding("Shift_JIS");
response.setCharacterEncoding("Shift_JIS");

と書いています

445:デフォルトの名無しさん
13/04/02 00:29:51.55
>>443
ああ、サーブレット側でsetCharacterEncodingやsetConentTypeで
Shift_JISを指定するだけで行けました。
サーブレット内での余計な変換処理は要らなかったんですね。
どうもです。

446:デフォルトの名無しさん
13/04/02 02:15:06.83
>>438
>JSP&Servletだけで十分フレームワーク

これはマジでそう思う。

ただ他方で機能不足なフレームワークはその上にオレオレフレームワークが育つ格好の培地でもある。

447:デフォルトの名無しさん
13/04/02 04:23:34.10
JSPはServletのフレームワークだな。
JSP嫌いだから引っこ抜いちゃうｗ

448:デフォルトの名無しさん
13/04/02 04:40:47.74
>JSP&Servletだけで十分フレームワーク

ただしServlet3以降に限る

449:デフォルトの名無しさん
13/04/02 10:51:31.04
Servlet2.5 と Servlet3 で大きな違いってあるの？
Servlet3はほとんど追いかけてないのですが、
HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
ぐらいのことしか知らん。

450:デフォルトの名無しさん
13/04/03 08:10:55.48
ないと思うなー。
＞HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
フレームワーク自体を作る側の人にとって嬉しいくらいじゃね？

451:デフォルトの名無しさん
13/04/03 08:15:23.37
そもそもアノテーションとか要らない

452:デフォルトの名無しさん
13/04/03 08:21:53.88
なにいってるんだか
xml地獄を解決するために生まれたのがアノテーションでしょ

453:デフォルトの名無しさん
13/04/03 08:24:32.09
フレームワークさえなければXML地獄もなかったのに

454:デフォルトの名無しさん
13/04/03 08:29:46.34
>>453
GrailsはXML地獄なかったよ

XML地獄のフレームワークはほんと時代遅れ
コードが見づらくなるし、コンパイラで検出できないエラーがでる。
なるべくコードで設定するってのが流行りだし、アノテーションは必須の機能

455:デフォルトの名無しさん
13/04/03 08:31:41.31
じゃあなんでSQLをXMLに外出しするような糞ORマッパを
勧めたりするんだ？

456:デフォルトの名無しさん
13/04/03 08:38:17.94
>>455
アンカーくらいつけてまともな日本語で書けよ
何が言いたいんだ

457:デフォルトの名無しさん
13/04/03 08:43:30.16
フレームワークとかORマッパが嫌い

458:デフォルトの名無しさん
13/04/03 08:47:54.30
>>457
だったらこのスレを見るなよ

459:デフォルトの名無しさん
13/04/03 08:53:54.35
いやさすがにわかるだろw
XML地獄を敬遠するくせにSQLはXMLいいのかってことだろ？
Javaの中でしか使わない設定はアノテーションとかでJavaの中に取り込んでいいと思うんだけど、
SQLについてはDBに流して確認とかよくやるから中に入り込まない方がいいな
今の所はSeaser系の2-way SQLが一番その辺り楽にできる
パラメータをSQLコメントに追い出すことで文法エラーにしないのは秀逸だと思った

460:デフォルトの名無しさん
13/04/03 09:04:33.36
海外だとHibernateが第一選択肢でそれ以外は比較的測定限界以下なのに、日本だとMyBatisとか
ガラパゴスフレームワークの類が幅をきかせているのは何か特殊事情があるのかな。

461:デフォルトの名無しさん
13/04/03 09:20:17.93
外出しすれば綺麗だと思うのは間違い
C++になっても変数宣言を関数の先頭でやるくらい汚い

462:デフォルトの名無しさん
13/04/03 09:21:15.39
全部のORMがXML使うわけじゃないし
TypesafeなORMが良ければそういうORMと組み合わせて
使えばいいだけだろ
入れ替えて使えるようにDIとかがあるわけで

うんこフレームワークを体験したからといって
フレームワーク全体を否定するのはアホ

うんこORMを体験したからといって
ORM全体を否定するのは馬鹿

463:デフォルトの名無しさん
13/04/03 09:23:53.81
いろいろなフレームワークがあること自体間違い

464:デフォルトの名無しさん
13/04/03 10:28:49.35
SQL外出しなオレオレフレームワークは色んな現場で見てきたけど、大体良い思い出が無いなぁ…。
大体SQLだけメンテしようとして、SELECT項目やバインド変数の数間違えてトラブるのが定番だった気がする。
事前にコンパイラみたいなのでチェックできるならいいんだけどね。

465:デフォルトの名無しさん
13/04/03 11:36:08.03
とりあえずSeasar信者の受け売りが嫌だ

466:デフォルトの名無しさん
13/04/03 11:47:15.81
色んなフレームワークがあるのは構わんけど、色んな実装があるのは嫌だ。
JAX-RSとかJSF、JPAとか。

つーか、WebやORMのフレームワークで、わざわざ仕様と実装をわける意味がわからん。
結局、実装固有の拡張機能を使わないと使い物にならなかったりするし。

467:デフォルトの名無しさん
13/04/03 12:02:47.87
>>466
その無駄な複雑性はJavaの悪いところだし
ORACLEが無能だからだろうな

468:デフォルトの名無しさん
13/04/03 13:39:18.89
継承や委譲を使うべきところまでPOJOがどうのこうのとアノテーションだらけにする
無能な糞フレームワークがあるな。S2なんとかーだけど。

469:デフォルトの名無しさん
13/04/03 13:55:01.70
自分も Hibernate より MyBatis のほうが好きなタイプだが、
Hibernate は嫌われるのに、Rails の ActiveRecord がみんなに受け入れられているのはなぜだろう？

両方とも似たようなタイプなのに

470:デフォルトの名無しさん
13/04/03 14:58:00.57
規約やアノテーションを活用する今のHibernateではなく、XML地獄時代のHibernateのイメージ
があるからじゃないのかな。

471:デフォルトの名無しさん
13/04/03 16:26:08.57
ActiveRecordが受け入れられている理由
-> RoRを使用するような用途/データモデルではそれで困らないから

Hibernateが受け入れられない理由
-> Javaがおそらく最も使用されているユースケース/データモデルではそのAPIモデルでは困るから

ソーシャルなWebアプリっぽいもの、DOA世界な帳票とかのLOBアプリでは、APIに求められるインターフェースも違うだろうし。

472:デフォルトの名無しさん
13/04/03 19:43:14.80
そういやhibernate entity manager経由でしか触ってないな
今って生hibernateどうなってんだろ
後で試してみるか…

473:デフォルトの名無しさん
13/04/03 20:06:18.41
>>471
でもそれだけだと内外差の説明はつかないなぁ。

474:デフォルトの名無しさん
13/04/03 20:33:32.91
>>469
RailsのようにConvention over Configurationが徹底した
フレームワークだと、ほとんどORMの設定することなく使える。

Javaの場合、RailsほどCoC重視したフレームワークがまだ少ないから
Hibernateのめんどうなマッピング設定が必要になって、嫌われるのでは

>>470 のいうように、昔のXML地獄のHibernateしか知らない人もいる
のも原因かもしれない。

475:デフォルトの名無しさん
13/04/03 21:17:53.29
>>473

ニホンジンはガイコクジンに比べて帳票ダイスキー、っという説はどうだろう？

- 帳票の出力内容はSQLレベルで複雑な処理を書くのが一番効率的
- その場合、求められるAPIは文字列としてのSQLをそのまま実行できるようなもの
- 日本において、Javaはもっぱらそういうアプリを作る用途で使われている(土方的な)
- そういう現場にHibernateを持って行っても(ﾟДﾟ)ﾊｧ?

国内では受け入れられていない理由が、昔のXML地獄のイメージがあるからとかっていうのは、
自分としては枝葉の話な気がするが。

476:デフォルトの名無しさん
13/04/03 21:21:36.90
>>472
そういやHibernate4はEntityManager/Annotationsがネイティブになって
旧APIとXMLマッピングがその上のラッパーになるってどっかで見たけど
実現してないんだな。今もドキュメントはXMLマッピングから始まる

477:デフォルトの名無しさん
13/04/03 21:44:55.39
>>473
日本のIT業界が世界に取り残される一番大きな理由は
大半が英語ができないからだよ
英語のドキュメントが満足に読めない人ばかり。

日本語の書籍がでて日本語情報が充実してこないと普及しない。

478:デフォルトの名無しさん
13/04/03 21:51:43.05
iBatis/MyBatisなんて日本語の情報が充実してなくても結構使われてるだろ
Springだって使われてる度合いに比べたら日本語の情報は少ないし
Hibernateは使われてない割に情報多い
たいして相関してる気がせんな

479:デフォルトの名無しさん
13/04/03 21:55:28.57
ぶっちゃけStringの連結なんてしたくないわ
テキストに書けるならそっちの方がチューニングもしやすいでな

480:デフォルトの名無しさん
13/04/03 22:02:27.77
>>478
Batis系はHibernateよりも単純だから英語のドキュメント
読めなくてもなんとかなるからだろう

Hibernateのほうがはるかに高機能な分、覚える概念が多い。
Hibernateの本、日本語のもあるけど今のと違いすぎて役経たないと思う
英語弱者にとって厳しいのがHibernate

ORMにしてもEntityベースでやるのが主流になってるし
SQLに近いBatis系はもう海外では流行ってない。
疑うならwebフレームワークの採用ORM見てみなよ

481:デフォルトの名無しさん
13/04/03 22:04:26.47
内外差以前に海外の実情がわからんのだよな
いつまでもTomcat使ってるのは日本だけと某エバンジェリストが言ってたけど
URLﾘﾝｸ(www.javacodegeeks.com)
を見ると海外でもTomcat強いしJetty含めてJavaEEじゃない方が主流だよな
海外じゃJSFやJPAが普及してるってのもどこまで本当か…
マーケティングに釣られてるんじゃないかと思うことがある

482:デフォルトの名無しさん
13/04/03 22:07:31.15
>>480
> 疑うならwebフレームワークの採用ORM見てみなよ

Playじゃebeanやnormも採用されてる件

483:デフォルトの名無しさん
13/04/03 22:36:07.96
英語・日本語にかかわらず、ドキュメント読まなくても使えるシンプルなのがいいのは確かだな

484:デフォルトの名無しさん
13/04/04 00:51:54.82
Struts1のEOLが決定しました
URLﾘﾝｸ(www.h3.dion.ne.jp)

潮流が変わるきっかけになるかね？

485:デフォルトの名無しさん
13/04/04 02:02:52.91
RailsとHibernateが同じようなものというのはない
JavaのフレームワークはXML地獄かアノテーション地獄
Railsなんて学習コストやハマりコストめちゃ低いぞ

486:デフォルトの名無しさん
13/04/04 02:21:25.71
こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん
URLﾘﾝｸ(qa.atmarkit.co.jp)

487:デフォルトの名無しさん
13/04/04 04:49:50.13
う～ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと
おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。

488:デフォルトの名無しさん
13/04/04 07:30:48.85
>>485
名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ
Javaを知っている人ならGrailsのが学習コストは低いとおもう。

>>484
日本の遅れたIT業界のことだから、ダメなのわかっててStruts2
に移行したりするんだろうなぁ

489:デフォルトの名無しさん
13/04/04 07:35:07.70
>>484
フレームワークなんか使うからこうなる。

490:デフォルトの名無しさん
13/04/04 07:44:26.43
>>489
お前自身がEOLってことに気づこうな

491:デフォルトの名無しさん
13/04/04 07:49:20.30
Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では
アレになっている部分も少なくないと思う。

例えばmappingsやtransientといったORMの定義、staticフィールドにRails風に記述できる
ようになっているけれども、型安全じゃないし正直JPA風のアノテーションの方がシンプルで
良かった。まあHibernateで定義したドメインクラスをインポートすれば良いのだけど。

あとビミョーに謎な振る舞いに悩むこともある。先日もドメインクラスにコンストラクタを定義
して使っただけでDIが動かなくなって暫し悩んだ。

492:デフォルトの名無しさん
13/04/04 07:49:35.61
>>489
まだこのスレにいたのか
必死にフレームワーク否定してるけど何つかったことあるんだよ

493:デフォルトの名無しさん
13/04/04 07:56:46.99
>>488
Javaのフレームワークにはいつも期待を裏切られてるけど
最後の最後ということでやってみるよ。アドバイスありがとう

494:デフォルトの名無しさん
13/04/04 08:05:53.42
作っては捨て作っては捨て
こんなのシステム開発では使えないよ。
趣味のプログラミングなら好きにやってくれていいけどさ。

495:デフォルトの名無しさん
13/04/04 08:52:46.84
>>494
毎回作り直してる俺々フレームワークのことですね、わかります

496:デフォルトの名無しさん
13/04/04 08:58:09.84
WicketライクなFW普及してくれ～

497:デフォルトの名無しさん
13/04/04 08:59:04.31
>>495
受託や派遣ばかりやってるからそういう発想になるんですね。わかります。

498:デフォルトの名無しさん
13/04/04 09:18:37.61
>>496
Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ

499:デフォルトの名無しさん
13/04/04 11:52:00.96
>>493
まだGrailsのチュートリアルやってるレベルだけど
最新の2.2.1はエラー出たから、2.2.0で試すのがいいかもしれない。
v2.2.1だと、controller作成時に下のようなエラー出る
2.2.0なら大丈夫。

grails> create-controller hello
| Error Error running script create-controller hello: _GrailsCompile_groovy$_run_closure1
(Use --stacktrace to see the full trace)
grails>

指示通り、--stacktraceしてみると、

grails> --stacktrace
| Error Error running script --stacktrace: Cannot invoke method findAll() on null object (NOTE: Stack trace has been fil
tered. Use --verbose to see entire trace.)
java.lang.NullPointerException: Cannot invoke method findAll() on null object
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243)
| Error Error running script --stacktrace: Cannot invoke method findAll() on null object

500:デフォルトの名無しさん
13/04/04 20:48:10.99
JSFってFacelets+CDIだけやれるっけ？
バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる

501:デフォルトの名無しさん
13/04/04 22:33:20.22
javascriptの時代が来る気がする
最近のjavascriptのライブラリは凄まじすぎるわ
jqueryuiとか、datatablesとか、jquery.sheetとか
マジでなんでもできるんだな
サーバーサイドもNode.jsになるんじゃないかな
ブラウザの開発ツールやらcloud9やらと、開発環境も整いつつあるし
Javaは下火になりそう

502:デフォルトの名無しさん
13/04/04 22:35:35.96
フレームワーク乱立のせいだな

503:デフォルトの名無しさん
13/04/04 22:41:00.19
>>501
その3つどれもただのjQueryのプレゼンテーション層よりの機能じゃないか
jQueryは他の言語のフレームワークでも連携させて使えるし、
サーバサイドが強いJavaとは強みのあるエリアがちがうよ

本格的なオブジェクト指向言語にすらなれてないJavascriptで
開発なんてしたくない

504:デフォルトの名無しさん
13/04/04 22:54:27.01
>>501
phpと争って削ってくれたらそれで十分な感じかな
あいつらだけはマ名乗ったらいかんレベル

505:デフォルトの名無しさん
13/04/04 22:59:26.63
apache cgi javaとかあればなー

506:デフォルトの名無しさん
13/04/04 23:23:40.46
>>503
それがさ、今single page applicationとかってのが流行ってるらしくて
サーバーサイドのコントローラの機能をクライアント側が吸収し始めてるんだよ
ライブラリさえあれば普通に本格的なオブジェクト指向言語だし
backbone.jsとかember.js見て驚愕した
requirejsやらcommonjsやらでモジュールもできるし、ビルドツールもある
qunitとかphantom.jsとかでテストも完備
サーバーサイドでormっぽいことも出来るみたいだし
URLﾘﾝｸ(nodejsdb.org)
ちょっと首を突っ込みはじめたんだが、マジで最強かも
ものすごいコミュニティができつつある

507:デフォルトの名無しさん
13/04/05 00:10:40.11
Javaのフレームワーク関連で
こんなにもたくさんの名前が出て来ること自体が異常
他の言語はここまで乱立してないから入りやすい

508:デフォルトの名無しさん
13/04/05 00:24:26.24
>>507
javaはまだマシだと思う
ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい
ぶっちゃけjeeだけってのもありだし
この点ではjavascriptのライブラリの乱立が一番ひどい

509:デフォルトの名無しさん
13/04/05 00:51:39.39
springjs
hibernatejs
なんかつよそう
jsf も js が付いていることに気がついた。でもうんこ

510:デフォルトの名無しさん
13/04/05 01:11:50.38
選択肢が無い方が幸せって人もいるけど俺はいやだな

511:デフォルトの名無しさん
13/04/05 06:32:32.04
趣味の自分プロダクトならそれでいいけど
フレームワークがコロコロ変わると
チームメンバーが大変だろう

512:デフォルトの名無しさん
13/04/05 06:47:37.60
そこまでころころは変わらない。

513:デフォルトの名無しさん
13/04/05 07:02:04.46
オレオレフレームワークで検索するとPHP率が結構高いのね。

514:デフォルトの名無しさん
13/04/05 08:05:54.47
Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな

515:デフォルトの名無しさん
13/04/05 09:36:15.65
>>508
DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね
GrailsもSpringをベースにして、HibernateやGroovyや
独自テンプレートエンジンなどを組み合わせたものだった。
VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。

>>510
選択肢は多いほうがいいね
ドキュメントが整備されているという条件つきだけど。

JSはドキュメントも十分にないようなライブラリが1万以上あってカオスだわ

516:デフォルトの名無しさん
13/04/05 11:15:07.30
2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ

たんにデコレーションする JQueryとprototype js と ext js しか知らなくて、
Backbone JS みたいにクライアントサイドでロジックまで制御するようなフレームワークが
出てくるなんて思わなかった(自分のスキルが低いのだろうが)

次ページ