【Java】 Java Web Application Framework 総合

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 12/05 14:16 / Filesize : 201 KB / Number-of Response : 676
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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
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使うべき場面です
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

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef