12/06/03 16:19:16.45
【関連スレッド】
【DI】Java Spring Frameworkを語るスレ 5.0
ｽﾚﾘﾝｸ(tech板)
△△もっとStruts2の良さを教えてくださいSsssion6
ｽﾚﾘﾝｸ(tech板)
3:デフォルトの名無しさん
12/06/03 16:28:33.17
【Java】Play framework【Scala】
ｽﾚﾘﾝｸ(php板)
Tapestryについて語ろうよ！
ｽﾚﾘﾝｸ(tech板)
テンプレ以上です
4:デフォルトの名無しさん
12/06/03 21:39:45.16
まぁPlayだけはねーわ
なにしろセッションすら実装されてないんだからな
5:デフォルトの名無しさん
12/06/03 22:40:07.29
FWが発達するとコーディングは不要になる
6:デフォルトの名無しさん
12/06/03 23:42:57.00
今主流なのってSpringMVC Struts2 Grails JSFとかか？
7:デフォルトの名無しさん
12/06/04 01:02:19.92
SAStrutsを使ってるところが多いと思うんだけど。
Struts2なんか使ってるところ見たこと無い。
8:デフォルトの名無しさん
12/06/04 02:19:48.18
スレたてる前に、世界でのFramework人気度を調べるにはどうしたらいいか考えてた。
Google Trendsだと、カテゴリ指定できないから、Springみたいな一般名詞が
含まれていると、一般名詞での検索数も含めてしまうので比較できなくなる。
Stackoverflowでタグ検索してヒット件数見ればいいことに気がついた。
このサイトは、プログラミングの話題しかないし、タグがついてるから検索ワードの違いで悩む事もない。
Java系の検索結果（一部）
[xxx]は検索のタグを表す。
後ろの数字は、stackoverflow.comの質問件数。
[タグ] 質問件数
[spring] 16210件
[jsf] 9125
[grails] 7307
[struts2] 3129
[struts] 1775
[playframework] 2387
[playframework-2.0] 424
[Tapestry] 294
9:デフォルトの名無しさん
12/06/04 04:42:00.98
>>8の続き
ASP.net編 (C#.net , VB.net)
[タグ] 質問件数
[asp.net-mvc] 35119
[asp.net] 125448
ASP.net MVCは2010年登場の後発だけど海外では既にかなり人気
Python, Ruby編
[django] 33335 (Python)
[ruby-on-rails] 75705 (Ruby)
PHP編
[codeigniter] 10587
[cakephp] 8988
[symfony] 4050
10:デフォルトの名無しさん
12/06/04 05:44:35.39
今も国内はStruts1とかSeasar系なのか
11:デフォルトの名無しさん
12/06/05 17:46:52.50
>>8,9
これいいね。自分の実感に非常に近くて納得してしまう。
JavaとPythonにgoogle app engineがあるともっといいね。
12:デフォルトの名無しさん
12/06/05 20:17:36.46
Struts3開発中らしいね
13:デフォルトの名無しさん
12/06/06 18:52:06.42
>>8
springとjsf/struts2とは比較にならなくね？
[spring-mvc] 5,827
14:デフォルトの名無しさん
12/06/06 19:33:29.63
この手のスレでは何でJerseyやApache CXF、JBoss RESTEasyは名前さえ出てこないんだろう？
15:デフォルトの名無しさん
12/06/06 20:05:02.28
>>14
あり程度メジャーなのは>>1の英語wikiに載っているんでは？
>>13
Springの範囲が広すぎるから、[spring-mvc]に限ったほうがいいってこと？
Spring使ったことないから、その辺は読み替えてくださいな
あと、Stackoverflowで調べたのはこのスレで名前があがっていたやつだけ。
英語wikiの全部やろうと思ったが、なにしろ数が多すぎた。
16:デフォルトの名無しさん
12/06/06 20:19:00.52
JAX-RSは良いけど、現状だとまだ実装系固有の機能や自前での拡張が必要だったり、クライアント用には別のFW(GWTとか)が必要だよね。
JAX-RSにMVC的な機能も含まれてきたら、Spring MVC捨ててJAX-RSオンリーにしても良いんだけどな。
17:デフォルトの名無しさん
12/06/06 21:05:54.31
>>16
テンプレートエンジンとしてJSPやVelocityなどが自由に使えるらしいから、特に困ることも無いんじゃないかと思う
まぁ機会が無くて使えてないんだけど、JAX-RSを知ってしまったらもうStrutsやSpringMVCを使う気にはなれないな
18:デフォルトの名無しさん
12/06/06 21:20:35.88
>> 16
現時点で、使える、と簡単に使える、は別で。
例えばViewableはJersey固有のクラスだし。
jspならモデルと関連づいたタグライブラリをどうするかの話とか。
JSR-339でも、拡張ポイント的とかはまだ不満。
これらの点を考慮すると、ビューまで全てをまかなうには現状ではまだSpring MVCを使っていた方がマシという認識で。
こういった部分まで標準化されて、Jerseyといった固有実装ではなく、JavaEEのJAX-RSとして使えるような未来には期待しているが。
＃JAX-RS 2.xとか？
19:デフォルトの名無しさん
12/06/07 00:52:13.10
stackoverflowでタグ検索おもしろいな
AP鯖を調べてみた
[tomcat] 7,911
[jboss] 3,555
[glassfish] 2,215
[websphere] 1,473
[jetty] 1,414
[weblogic] 1,369
[geronimo] 64
20:デフォルトの名無しさん
12/06/07 13:14:14.96
フレームワークより何を作るかに困ってます
21:デフォルトの名無しさん
12/06/08 18:02:58.48
作りたいモノが作れればフレームワークなんてなんでもいいんだよね。楽したいだけ。
22:デフォルトの名無しさん
12/06/16 16:55:38.94
今使えるだけじゃなくて、１０年後も使えそうな載ってないかな。
結局ヲレフレームワーク作って自分で１０年メンテと言う泥沼走るしか無い？
面倒になったら転職じゃ定年まで生き残れないと思うんだよね。
23:デフォルトの名無しさん
12/06/16 17:55:38.20
オレオレフレームワークというかオレオレAPIの蓄積と
自分で会社とサービス作っちゃうって感じかな
転職繰り返すのに疲れて、今は細々と自分が食えるだけの金の一部を
オレオレwebサービスが稼いでくれる。
あとはちっこい案件をボチボチこなす。
贅沢はできないけど、なんといっても精神的に楽。
労働時間はすごく長くなったけど、自分のペースでやれるから苦痛がない。
と、スレチだな、失礼
24:デフォルトの名無しさん
12/07/22 16:34:04.57
JAX-RSって、やっぱりまだまだだなー。
良い感じの所はたくさんあるけど、詰めが甘い。
25:デフォルトの名無しさん
12/08/11 10:21:12.24
結局Struts 1.x系が最強だよね、攻守ともに。
26:デフォルトの名無しさん
12/08/11 10:48:26.41
いや、それだけは無い。
27:デフォルトの名無しさん
12/08/11 11:42:45.68
>>26
何で？
攻：利用実績が多数、開発環境が無償→上層部を説得するのに有利
守：経験者が多く、人員補充が容易。工数見積も安定しており先読みしやすい。
ほら最強
28:デフォルトの名無しさん
12/08/11 13:29:14.91
えっ…。
すまん、マジ意見だったんだな。
なら、特に言うことは無い。
29:デフォルトの名無しさん
12/08/11 17:14:36.39
>>28
ごめん、うちの会社の上司がこんな感じでご迷惑お掛けしております。
30:デフォルトの名無しさん
12/08/11 18:28:17.08
そろそろStruts1.x経験者も少なくなってきていると思う。
・現役の頃に Struts1.x をバリバリ学んできた人
→スキルが身について、別の言語や、もっといい仕事ができるところに転職している
・最近の若い子
→Struts 1.x すら知らない
・未だに Struts 1.x の人員補充で候補に挙がる人
→何年も Struts 1.x しかやらず、スキルアップしてこなかった凡人しか候補リストにあがってこない
31:デフォルトの名無しさん
12/08/12 02:21:50.34
実際のところ今は何がメジャーなん？
SpringはAOP以外の所を使ってるって話は聞かないし
Struts 2.xは空気だし、WicketやTapestryやClickもみないしで
やっぱStruts 1.xかフレームワーク無しが二大巨頭なんじゃないの？
32:デフォルトの名無しさん
12/08/12 04:29:58.10
クラウドに向かうエンタープライズJava
─しかしその前にまずJava EE 6対応を！
URLﾘﾝｸ(codezine.jp)
これを見ると日本ではいまだにStrutsが主流らしい
33:デフォルトの名無しさん
12/08/12 09:52:13.66
フレームワーク乱立しすぎだから、Java EE だけで開発できるようにしてほしいわ。
34:デフォルトの名無しさん
12/08/12 10:07:57.07
SpringMVCはそこそこ多いんじゃないの？ その次でStruts2 かな。おれの周りでは。
5年以上保守が続いている案件で Struts 1.3 をまだいじっているところはあるけど、
新規で Struts 1.3 はもう聞かないな。
JSFはもっと空気だ。あれはうんこだろ。
play framework は、先鋭的な人たちの間には広まってきているだろうけど、
土方ばかりの業務系には降りてこない気がする。
35:デフォルトの名無しさん
12/08/12 15:23:24.47
>>32
「日本オラクルイベントのアンケート結果調べ」でそれじゃ
実際のJava EEのシェアはその半分以下だろ
Java EE 7のクラウド対応も出たときには周回遅れだろうよ
36:デフォルトの名無しさん
12/08/12 19:35:31.03
遊びなら新しいのにもホイホイ手を出すけど、仕事だとやっぱりなあ
37:デフォルトの名無しさん
12/08/12 20:05:58.64
俺の周りではSpringMVCしか聞かないけどな。
Struts 1系は何年も前に新規から消えたし、Struts2やJSFは誰が選択するんだよという感じ。
playとかにも惹かれるけど、細かいところを見ていくとSI屋用途ではちょっとという部分もあり。
結果、別に最高というわけではないけど、モダンな考えも少しずつ取り入れられているSpringという選択になっている感じ。
こういうのは、働いている環境によっても結構違うもんかな？
38:デフォルトの名無しさん
12/08/12 21:04:30.34
昨年開発したシステムで、JDK1.4にtomcat3.2.x、servlet＋JSP
って言う案件やりましたよ。
何でも、現行の顧客社内で動いてるJavaAPサーバ環境がそれしか無いため、
それに限定してるんだとか…。
39:デフォルトの名無しさん
12/08/12 22:10:14.94
Webフレームワークはどうしてるん？
40:デフォルトの名無しさん
12/08/12 22:36:55.99
38だけどフレームワークっぽいものは無かったな。
全部JSPとServletでゴリゴリ書いてましたよ。
オープンソースで使われてるのはCommonsがいくつかくらい。
JDBC APIも直接使ってるっぽかった。
ちなみにここ2～3年内にあった本当の話です。
41:デフォルトの名無しさん
12/08/16 02:39:18.82
フレームワークの中のコードにまで手を入れたいということを聞くことがあるんですけど
そういう必要ってかなりあるものですか
42:デフォルトの名無しさん
12/08/16 02:52:27.66
既存のフレームワークに手を入れる需要は結構ある。
大抵そのフレームワークへの理解不足か、
設計思想にそぐわない事をやろうとしてる場合なので、
きな臭い方向に進み易いけど。
43:デフォルトの名無しさん
12/08/16 03:05:02.33
POHPはなぜ死滅したのか・・・あれ超楽なのに
44:デフォルトの名無しさん
12/08/16 14:30:39.44
ふう
45:デフォルトの名無しさん
12/08/16 15:50:37.25
ふぉおおお
46:デフォルトの名無しさん
12/08/16 18:44:13.97
web上でサーチエンジン？みたいな物を作りたいのですが、java applet などで出きるでしょうか？
amazonとかにある商品を検索するときに、ダイアログで家電なら家電を選んで検索結果出るようなやつを作りたいです。
47:デフォルトの名無しさん
12/08/16 18:49:04.72
なんでAppletなんか知らん（学生さんしか使わない）がスクリーニングはなんででも出来るよ
48:デフォルトの名無しさん
12/08/16 21:00:57.02
>>47
学校のプロジェクトで必要になったので。javaとxml、もしくはjavascriptで作りたいと思っています。
49:デフォルトの名無しさん
12/08/17 18:38:26.77
>31
シェアは知らないが、JBoss Seamとかはどうなんだろう？
>32の分類だとJava EEに入っていそうだが。
50:デフォルトの名無しさん
12/09/10 19:07:31.93
Javaでフレームワーク、Strutsという言葉を聞くがわかりやすくいうとなんでしょうか
Javaについて書かれている本というのはJavaの文法、Servlet,Jspがおおいのですけど
フレームワーク、Strutsについて書かれている本が少ないような気がします。
難しすぎて書く人がいないでしょうか。
51:デフォルトの名無しさん
12/09/10 22:46:28.79
予想
・本を買うよりWebで調べた方が早い
・技術書だとすぐに情報が古くなってしまう
・技術書を書く暇のある技術者がいない
52:デフォルトの名無しさん
12/09/11 18:41:33.81
>>50
多くはWebアプリ開発とか目的に応じて
それ以外の手間を省かせてくれるライブラリ群だ
まず自分で検索していくつか試せばわかる事だからそうしなさい
本が読みたければAmazonで"struts"で検索すれば書籍だってたくさんある
53:デフォルトの名無しさん
12/09/16 10:37:12.62
Java系フレームワークの2トップ？
Struts2とSpring MVC、
それぞれの良いところ、悪いところを教えて下さい
54:デフォルトの名無しさん
12/09/24 14:15:52.72
Struts2は止めた方がいいとおもうよ。外部からOSコマンドが実行できちゃう致命的な
セキュリティホールが２．３．１とかでも多数見つかるぐらいだから
（これと同じようなのを何回か緊急リリースで見たような。。。)
55:デフォルトの名無しさん
12/09/24 20:05:22.20
Play!とか選択する理由あるかな。
56:デフォルトの名無しさん
12/09/25 00:42:40.80
念入りに評価して自信持って結論出したならそんな質問不要
じゃなけりゃそんな質問無駄
57:53
12/09/25 19:12:52.59
>>54
レスありがとう
どこかのサイトにも、Strutsは2.xより1.x利用者が多いと書いてあったけど
移行が終わっていないだけじゃなくて、2.xの出来が悪いってことか。
新規ならSpring MVCのが無難かな
ORACLEが使いやすいFramework作らないからJavaの
Web frameworkは混沌としてるな
>>55
Play!スレに欠点が書いてあったよ
58:デフォルトの名無しさん
12/09/25 19:18:45.87
Apache Wicket 6がリリースされた
URLﾘﾝｸ(www.infoq.com)
URLﾘﾝｸ(wicket.apache.org)
59:デフォルトの名無しさん
12/09/26 03:28:52.72
>>57
Oracleが使いやすいFrameworkなんか作るわけないだろう
Oracle(旧Sun)は、使いにくい JSF、JPA を推してくるだけだ。
60:デフォルトの名無しさん
12/09/26 05:15:01.95
セミナーでハゲと外人にJSF2.0とJPA2.0は過去のバージョンと違って楽々開発だと洗脳され、金魚本買おうとした俺バカですか
61:59
12/09/26 09:55:47.77
>>60
それって今年5月の JavaUsersGroup CCC とか Java One かな？
おれもいたぞw
JSFはもううんざりだが、JPAは Hibernate とかもあるしいじってみようという気にはなる。
GlassFish は嫌いではない。
(WebLogic、WebSphere は重すぎる)
62:デフォルトの名無しさん
12/09/27 20:34:16.63
禿の煽りを鵜呑みにする情弱はEE使って苦労していれば良いんじゃ無いかな。
63:デフォルトの名無しさん
12/09/27 23:03:42.25
Playスレなんかどこに有んだよ。落ちたのか？
と思ったら、PHP板に有った。
64:デフォルトの名無しさん
12/09/28 01:26:56.63
>>60
過去のバージョンとは違うから！
って力説されても前のバージョンが酷かっただけだからなあ
65:デフォルトの名無しさん
12/10/03 23:21:23.33
今ならSAStrutsとDB周りはS2JDBC
もしくはSpringMVCにDB周りHibernateかなあ。
もしくはOracle一押しのJSF+JPA？
なんかこの前OracleがやってたJSFの講座行ったけど
標準じゃないフレームワークはオワコンレベルでやたらプッシュしてたなあ。
ただ、JSF＋JPAはTomcatだとどうも合わないんだよなあ…。
OracleなんざGlassFish使えで終わってるっぽいし。
今んとこ自分はSAStruts押しかなあ使いやすいし。
…まあ実際は保守案件でStruts1触ってる時間が一番長いんだけどさ。
66:デフォルトの名無しさん
12/10/03 23:34:58.97
>>61
8月後半にOracle社であったJavaのJSFセミナーだと思う。
まさにハゲとオランダ人（だったと思う）がセッションしていたので。
JSF1.0はありゃ悲劇でしたねとか言って笑いを取ってた。
JSF2は良くなりましたとは言ってたけどさ。
ちなみに俺もその時は乗って金魚本を買おうとした。
結局まだ買ってないけど（笑）。
67:デフォルトの名無しさん
12/10/09 18:51:47.06
Wicket+JDOがいいです。JPA2.0とか未だにインデックスも張れないだろ
68:デフォルトの名無しさん
12/10/09 20:09:31.22
インデックス？選定ポイントそこ！？w
69:デフォルトの名無しさん
12/10/10 02:45:38.49
じゃあJPA否定してどうすんだよ。
S2JDBCとかメソッドチェーンでクエリ書く様なのはJavaの構文じゃ無理。
C#のLINQみたいのが言語仕様で出てくるまではHibernate系のORMしかない。
70:デフォルトの名無しさん
12/10/10 20:32:21.74
Java EE7やJava 8リリースでFrameworkの進化は期待できそう？
これみたけどC#使ってるのでよくわからない
URLﾘﾝｸ(www.publickey1.jp)
URLﾘﾝｸ(www.publickey1.jp)
>>69
LINQいいね
LINQ + Entity Framework最強
C#のHibernateは設定がめんどくさくて挫折したｗ
71:デフォルトの名無しさん
12/10/14 16:32:52.50
最近のJavaはどんどん進化してるな。
72:デフォルトの名無しさん
12/10/15 13:01:59.73
型推論 var array = new ArrayList<HashMap<String, Integer>>();
プロパティ setter getter
ほしいな。
Servlet API 3.0 と ラムダ式で多少変わるぐらいだろう。
もう言語やフレームワークの進化は頭打ちだと思う。
73:デフォルトの名無しさん
12/10/15 19:11:41.68
varな型推論、プロパティ、ラムダ、AST操作、トレイト、パターンマッチング、非同期とか、その変が入った版がリリースされれば、とりあえずは満足してやんよ。
74:デフォルトの名無しさん
12/10/15 19:21:46.96
最近のJavaって進化してるのか？
とりあえず、Xtendで出来るような事を標準でもできるようにしてほしい。
75:デフォルトの名無しさん
12/10/16 10:02:16.75
>>73
でもScalaは結局はやらなかった。
76:デフォルトの名無しさん
12/10/16 10:27:38.54
Sunの時代にJavaは進化が止まっていた。
ORACLEのJavaになって多少は進歩するんじゃないか
propertyは、C#やってる人間なら便利さがわかるが、
Javaの世界では「可読性がおちる」といって反対意見があった。
他のドットの意味と区別がつかないんだとさｗ
C#は開発生産性重視で、柔軟にいろいろと取り入れているが
Javaは厳格すぎるために生産性が悪くなってるな
77:デフォルトの名無しさん
12/10/17 00:56:46.21
>>75
スカラはジャヴァ子の同人誌みたいなもんだからな。
本家が進化することに意味があるのだよ。
78:デフォルトの名無しさん
12/11/09 09:30:12.50
最新Java
Windows8に入れてもおｋ
79:デフォルトの名無しさん
12/11/23 23:04:32.71
SpringMVCだと、まだ日本では使ってるところ少ないのかな？
80:デフォルトの名無しさん
12/12/03 08:30:51.72
この前Javaのセミナーに行ったが、
ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。
前々からStrutsならDisってたけど。
>>79
見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。
81:デフォルトの名無しさん
12/12/03 11:21:09.89
>>80
> ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。
あの人はそれが仕事だから・・・(笑)
聴衆は、それを笑ってあげるのが仕事(話の内容が合っているかどうかに関わらず)
ちなみにおれもその場にいた。
> 見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。
おれの周りでは SpringMVC のほうがかなり多い。Seasar2はだいぶいなくなった。
>>80 さんのレスを否定するわけではないが、日本全体でちゃんとした調査をしないと、そこら辺は何とも言えんのでは。
82:デフォルトの名無しさん
12/12/03 12:53:34.35
俺の周りもSpring MVCが多いよ。
Seasarはもう役目を終えた感じだし。
ついでにJAX-RSは良いねという意見を聞くこともあるけど、Spring MVCの完全置き換えが出来るようになるのはJ2EE8とか9の頃じゃね、とも思う。
あと、良いのはJAX-RSではなくJerseyだろ、っという話もあるけど。
83:デフォルトの名無しさん
12/12/03 13:56:20.03
>>80
寺田氏？ならTomcatは前々からおおっぴらにdisってたな
とはいえGlassfishを運用する勇気はねぇっす
84:デフォルトの名無しさん
12/12/03 13:58:18.68
>>82
Seasarは中の人がJavaからいなくなったしな
85:デフォルトの名無しさん
12/12/03 17:49:10.59
TomcatをdisったりGlassfishをステマするのはまだわかるよ。
でも、開発にJ2EEを使え、っというのは笑うところ。
86:デフォルトの名無しさん
12/12/04 00:55:45.19
>>85
J2EEじゃなくてJavaEEだろ！ と笑えって意味？
87:80
12/12/04 01:27:58.76
>>81
自分の周りがそうだってのはあるけど、
やっぱり他の会社が何使ってるかってのは参考になるよ。
Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。
SpringMVCは使ってみたいんだけどなんか昔やった時やたらとっつきが悪かったイメージがあって…。
最近大分あれから使いやすくなってるとは聞いてるんだけどね。
ネットで調べろって言われるんだろうけど、いい解説書があればいいんだけどなー。
・・・もっとも、今やってる仕事デフォのStrutsアプリの改良案件だから
それ以前の問題がうちの会社にはあるけどね。
あんな馬鹿デカいアプリSeasarにせよSpringにせよ移行できないよー(涙）。
88:デフォルトの名無しさん
12/12/04 08:43:26.29
>>85
JavaEEのツールですべてまかなえ、ということだろう
やさしいな、おれ
89:デフォルトの名無しさん
12/12/04 09:03:53.58
ごくごく小規模ならJSF2.1にEJB3.1orCDI、裏はJPA2.0とかで組めなくもないけど…
小規模でやるには仕組みが大げさすぎるし、逆に大規模になると今度は大雑把すぎて扱いにくいんだよなぁ。
足りないところを色々と足して俺俺F/W作って教育するくらいなら、技術者集めやすい他の選択肢を探してしまう
90:81
12/12/04 10:34:09.96
> >>81
> 自分の周りがそうだってのはあるけど、
> やっぱり他の会社が何使ってるかってのは参考になるよ。
あ、それは私もそう思うので、正しいかどうかは置いといて、
「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね
(そういう意味では >>81 の自分のレスは書き方が良くなかった)
ただですらJavaの開発現場は衰退してきているので。
> Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。
たしかにSeasar2は発展性はないだろうけど、安定はしているし、Springよりは簡単で軽くていいと思う。
使い捨てとか、あまり大規模にならない開発だったら選んでもいいと思うけどね。
Springはアノテーション地獄になって読みづらいし、追いかけづらくなった。
XML地獄の方がまだマシだと思う(あとからメンテする側としては、追いかけやすい)
91:81
12/12/04 10:35:30.46
あ、 >>90 は >>87 へのレスです。
あと、誤記：
誤：
「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね
正：
「自分の周りだこうだよ」っていうレスは、うれしいし参考になりますね
92:デフォルトの名無しさん
12/12/04 12:48:08.37
>>89
まさにそれが使われない理由だよな。
>>90
うちもSpringだよ。
アノテーションが追いかけづらいという話をする人はいるけど、自分はそうかな～？、と思う。
アノテーションを使うところってある意味明示的な記述をするところだし。
まあ、依存関係の設計でおかしな事をしていたり、独自のアノテーションとかを使って
アノテーションやAOPではなくFWの拡張ポイントやスコープでの処理で解決すべきところまで
乱用してわかりにくい設計をしていたりとかは見たことあるけど。
そこはあまり優劣を比較するポイントにはならないかな、っというのが自分の感想。
Seasarも、個々のプロダクトではまだまだ良いな、っと思うものも多いんだけど、
色々考慮した結果うちではSpringを全面採用しているよ。
もっとも、Spring最高だと思っているわけでは無くて、消去法で消していくと現時点ではSpringが残るというだけだけど。
93:デフォルトの名無しさん
12/12/04 20:06:05.56
S2JDBCと対するSpringプロダクトって何？
S2JDBCがあるから、なかなかSpringへ踏み切れない。
94:デフォルトの名無しさん
12/12/04 20:53:08.58
>>93
専用のO/Rマッパーはないはず。
親和性の高さだとHibernateが一番だと思う。
あと、有名どころのプロダクトならSpringとつなぐための仕組みが提供されてるからその辺りの選択肢は広いよ。
95:デフォルトの名無しさん
12/12/04 21:13:48.85
>>93
そうそう、SeasarはS2JDBCは良いんだけどね－。
他のFWでデータアクセスする時は、APTでマッピング用のDTOから条件式用のクラスを作ったり、
多少賢いSQLビルダーを自作して、実行とマッピング自体はFW付属やその他データアクセスFWの
エンジンを使うことで、S2JDBCに近いことができるようにしているかな。
逆に言うと、S2JDBCに近いことをやりたいなら、SQLビルダーの自作やメタデータ系クラスの
操作なんかは必須。
96:デフォルトの名無しさん
12/12/05 01:27:48.84
>>93
S2JDBCをSpringで使うってネタは豊富にあったはず
2way SQLがよければDBFlute, Doma, MirageなんかはSeasar2に依存してない
97:デフォルトの名無しさん
12/12/05 20:31:55.99
関連して聞いてよい？
HibernateとかJPAって本当に使われているの？
結局、Criteriaとかこねくりまわしたり、SQLの代わりにxQL使ったりが必要になるので、
それならSQL書く(2way SQL)っていう選択しているところしか見たことないんだけど。
98:デフォルトの名無しさん
12/12/05 20:54:09.65
直近2年で6システムに絡んだけど採用0だったな。
2システムは客の親会社が作ったF/W(JDBCラッパーレベル)、
残りはMyBatis2, DOMA1, S2JDBC1。
客視点で見た時にもSQLはわかりやすいんだろうなぁと思う。
99:デフォルトの名無しさん
12/12/05 22:33:15.22
Hibernateなんかが想定しているオブジェクトモデルと、
Javaが多く利用されているであろう業務システムのデータ設計、クエリパターンは異なるので、
採用が少ないというのもまあ当然なんだろう。
100:80
12/12/05 23:03:29.36
>>97
Hibernateは使ったことがある。まあ悪くない。
JPAは・・・ごめんよくわからない。
仕事は今のところS2JDBCか、
そうでなかったら直にSQL書いてせいぜいCommonDBUtilかます程度。
101:デフォルトの名無しさん
12/12/05 23:43:06.07
仕事で今までSpringもSeasarも使ったことがないんだけど、
最近はSpringが多いのでしょうか
102:デフォルトの名無しさん
12/12/06 06:20:39.96
何が使われるのか？なんてのは F/W 選定できる権限持ってる担当者の
コダワリとか、会社の文化やらでだいぶ変わるんじゃないかな？
ゴールを取れる事が本質だとは思うけど。周りが使っているのは気になるね。
ということで、私の環境も晒しておくよ。自分たちで選定できる案件なら、ここ数年は
Tapestry5系と MyBatis3 が中心。あとは分散時に Spring の Remote を使うかな？
他では類を見ない変態的構成かもしれんｗ
103:デフォルトの名無しさん
12/12/06 07:07:48.52
Struts1.3だけ使ってるけど時代遅れ？
104:デフォルトの名無しさん
12/12/06 09:24:23.71
国内に限定するとStruts1.3もまだまだ現役だと思う。それしか使わないのは珍しいと思うけど。
特に銀行、証券みたいなお堅いところの独自F/Wのベースになってるのも多いね。
日本企業は自社の過去実績にかなりうるさいし、
選定する側も新しいものをなかなか勧めようとしないから仕方ないんじゃないかなー
例えば今のうちの顧客の場合、顧客内の採用事例がないF/Wを選定する際は
通常の見積り資料に加えて顧客指定フォーマットの新技術検討資料なるものが必要で、
検討資料を作ると小規模案件1個分くらいのコストがかかる。
しかもそれでダメと言われたらその案件は失注確定(見積りのやり直しが許されてない)ってリスクがあるからまずやらないわな。
105:デフォルトの名無しさん
12/12/06 10:59:02.32
Hibernate バリバリ使ってるけどなー。複雑な業務ドメインでドメイン指向なら普通じゃない？
SQL 直接書くとか有る程度の規模のプロジェクトだと無いわーって思う。
それはそうと、今 Java で Web アプリって何が良く使われてるのか確かに不思議ですね・・・。
Rails みたいに決め手になるようなものが無いし、わざわざ Java で作らなくても・・・って思う（とはいえ会社では Java を使わざるを得ないところはあるんだけど）。
Project Avatar はいつリリースなんですかね？
106:デフォルトの名無しさん
12/12/06 11:13:53.50
複雑な業務ドメインの場合、パーシステントの実装とモデルはむしろ分離しているからなぁ。
リポジトリを境界にして、その内部はSQL書くでもかまわない感じで。
大規模というか大量になったときにSQLを書きたくないのはそうだけど、
基本的な処理の自動生成なんかはどのFWにもあるし。
業務系といっても、レポートが大半、DB設計もそれを想定みたいな所が多いから、結局SQLというケースになるんじゃないかな。
107:デフォルトの名無しさん
12/12/06 11:24:07.78
個人的にはJSP&Servletが最強
108:デフォルトの名無しさん
12/12/06 13:34:47.17
5年前ならともかく, いま皆さんが Web アプリ作るのにわざわざ Java を使う理由って何ですか？Ruby とか Python で十分な気がするんだけど・・・。
109:デフォルトの名無しさん
12/12/06 14:42:34.80
業務系アプリ作るならやっぱり静的言語のほうが安全なもんで
110:デフォルトの名無しさん
12/12/06 15:28:34.02
>>108
運用側が(彼等にとって)新しいのを入れたがらないから常にJava前提
111:デフォルトの名無しさん
12/12/06 23:21:33.64
>>108
RubyとかPHPならありかもしれんけど、
日本でWebにpythonはないと思うよ。
何故と聞かれたら情報がない。
Java、Ruby、PHPはいろいろ探せばwebアプリ作成のための情報ソースが
その辺にいくらでも転がってるからね。
ちなみにあえてJavaである理由って言えば既存の資産が既にJavaだからだね。
今のの保守と新規の開発を両立するのならぶっちゃけ言語変える必要がないので。
別の環境作んないといけないじゃん。
別にEclipseとか使って開発する分にはそんなPHPとかに比べて開発しにくいとも思わないし。
困った時にはライブラリ探せば結構どうにかなるくらい既存の資産が大量にある。
もちろん慣れてるってのも大きいけど。
それにもいろいろ変えるにはお金がかかるし、なんで今動いてるやり方じゃダメなのって意識が
顧客にあるので意外にOKしてくれないのよ。
>>104さんみたいな事例はいっぱいあるからねえ・・・。
112:デフォルトの名無しさん
12/12/07 00:55:35.11
新規開発は一瞬で終わりだけど、その後の長く続くメンテは
お客さんのシステム部門(子会社が多い)が既存システムと
掛け持ちでやるから、既存システムと同じ技術ベースが
求められるケースが多いな
部分最適(案件毎に最適な技術を選択)の総和が全体最適に
なるとは限らないってやつだわ
113:デフォルトの名無しさん
12/12/07 10:38:55.48
Javaは、いい意味でも悪い意味でも、これからのCOBOL、VB6 になっていくと思う。
先鋭的な技術系の会社、ベンチャーと違い、SIerやヘボいソフトウェア開発会社は、Javaしかできないやつが多すぎるから。
逆に言うとJava要員は集めやすい。
バージョンの下位互換もかなり取られているし。
114:108
12/12/07 11:26:07.76
なるほどやっぱり運用考えるとそうなっちゃうんですねぇ・・・。
今までずっとリッチクライアント作ってたんですが、今度 Web アプリ作ることになったんですがどうやって作ろうか悩み中です・・・。
スクリプト言語使えるなら Ruby で十分かなーって思ってたんですが、色々しがらみがあるんでしょうね。
Web アプリって結局文字列処理になっちゃうので、静的型付け言語であるメリットがかなり薄れちゃうなーという印象があるんですよね・・・。
Play! framework みたいにタイプセーフに HTML テンプレートを書ける仕組みを持つフレームワークとかあれば良いんですが。
このスレを見ていると今 Java で作るなら何が良いんだろうって悩んじゃいますね・・・やっぱり Spring MVC なのかな・・・。
115:デフォルトの名無しさん
12/12/08 02:17:18.08
Javaは良いWebのフレームワークとORMがないのは事実
ASP.net MVCとC#でやるのが開発生産性が最強だよ
言語の開発生産性
C# ＞ Java
フレームワークの生産性
ASP.net MVC ＞ Java系フレームワーク（定番といえるものがない）
ORMの開発生産性
Entity Framework ＞ Java系ORM
情報量
ASP.net MVC、Entity Frameworkの圧勝
>>114
リッチクライアントは何の言語でやってたの？
Rubyは言語仕様がころころ変わってすぐ動かなくなるクソ言語だよ
動的言語だし、保守考えたら、開発生産性は最低レベル
あとWebアプリでも、Type Safeは重要だと思う
116:デフォルトの名無しさん
12/12/08 08:51:32.87
MS狂と議論してもしょうがない
117:デフォルトの名無しさん
12/12/08 10:03:33.47
>>113
Javaでビジネスロジック程度のプログラムを書くことしかできない技術者は多い。
フレームワークを自力で設計・構築できる程度のスキルを持つ技術者とか
アプリケーションサーバやJavaVMの内部を熟知している技術者はほとんどいないね。
118:デフォルトの名無しさん
12/12/08 10:17:57.48
アンチMSもちょっとなぁ。
どっちの信者でもなければ>>115の言ってることは正しいもん。
119:デフォルトの名無しさん
12/12/08 10:54:04.22
>>118
俺もJavaよりC#の方が…とは思うが、このスレでそれを言っても荒れるだけだと思うので控えておく。
120:デフォルトの名無しさん
12/12/08 11:07:03.44
>>118
こんにちはMS信者
121:デフォルトの名無しさん
12/12/08 11:25:00.20
うちも今はSpringMVC使ってる。
O/RマッパーはMyBATIS。mybatis-springっていうlibがあって
親和性も悪くない。
SpringMVCで通常は、ControllerクラスのメソッドはModelAndViewクラスを
返すと思うんだけど、画面とサーバー側は疎結合にしたかったんで
StringでJSONのみをやりとりするような構造にしてる。
画面側はよくある一覧詳細型なもんで、jQueryベースのjqGridで構築。
この構造だと、画面側もサーバ側も、互いの進捗にはほとんど影響され
ないから分業体制が作りやすい。
SpringMVC+MyBATISの構成で基盤部分作っちゃうと、あとは
ビジネスロジックとSQLと、その間をつなぐService,Mapperあたりを
作ることに専念できてなおかつ他のプロジェクトにも使い回ししやすいんで
ASP.netでC#とかにも手を出したいと思いつつ、なかなか踏ん切りがつかない。
122:113
12/12/08 13:20:30.50
>>114
サーバサイドがJavaで、リッチクライアントとしてクライアント側が
・VB.NETネイティブ(会計システム。データはXMLでやりとり)
・BizBrowser(会計システム。データはXMLでやりとり)
・CURL(物流系システム。データはCSVでやりとり)
という組み合わせをやったことがある。
サーバサイドはSpring。別にリッチクライアントだったらSpringというわけでは
ないけど、そのプロジェクトで選定をしている時点で
「JavaだったらSpringでいいんじゃない(あと、経験者が結構いた)」
という感じで決めた。
アーキテクチャとしては >>121 みたいな感じで、SpringMVCにしておけば、
View層がHTMLだろうとリッチクライアントだろうと、
ModelAndViewのところでXMLなりCSVなりJSONを返すように変えればいいだけだし、
コントローラ層より先は、普通の案件と何ら変わりはない。
それに、そもそもこの考え方であれば SpringMVC が必須であるというわけでもない。
10年ぐらい前、似たようなことをStrutsのみでやったことがある。
(jspにforwardする代わりにXMLを返すようなところを自作した)
123:デフォルトの名無しさん
12/12/08 13:50:25.31
BizBrowser とか懐かしいな。8年ほど前にそれ用のリクエスト処理と
JSON 返す Java 製のシンプルな枠組みとクライアント側のライブラリを
セットで書いたことがあるわ。それ以来使ったこと無いけど。
リッチクライアントとかと連携するサーバシステムって、結局 HTML の代わりに
クライアントが欲しいデータとのやり取りができればいいだけだから、
HTTP ベースなりの API を整備すれば大概事足りるよね。
124:デフォルトの名無しさん
12/12/08 21:32:47.36
RIA用途だとJAX-RSとかが使われるようになっていくのかねぇ？
今のところ、拡張ポイントやヴァリデーションとかを考えた場合に、SpringMVCを使った方が良い気がするけど。
125:デフォルトの名無しさん
12/12/08 21:37:10.77
普通にStrutsとJSPで今もシステム作ってるが、
最近Ajax的なの当たり前に要求されるようになったから
JSONか下手すれば直にHTML書いて送って
Jqueryでぼんみたいなことばかりやってるから正直既存機能とのかい離が激しい。
出来るものなら全部作り変えたいがもちろんそんな余力はない。
126:デフォルトの名無しさん
12/12/08 23:37:41.63
バリデーションはむしろ、JavaScript側でやっちゃいたい。
JAX-RSってRESTFulなことやるんだっけ。実装は別？
SpringMVCのコントローラでもアノテーションでRESTFulなこと
できるけど、どっちが軽量なんだろ？
127:108
12/12/09 00:34:34.19
大分亀レスですが・・・
リッチクライアントは Swing でゴリゴリ。RMI でつなぐことが多かったですねー。
非同期分散処理・サーバーからの push によるクライアントのリアルタイム更新とかもあったのでサーバーとクライアントは割と密結合でした。
今度から担当する Web の方はそれほどリッチな機能を求められていないようなので、もっと疎結合にした方が良いんでしょうね。
Rails + Backbone.js みたいに RESTful サーバで JSON 返してクライアント側で MVC って感じでしょうか。
それぐらいなら JAX-RS 使えば良いのかなーと何となく想像しました・・・（といっても Java で Web 開発って何が普通なのかサッパリ知らないのですが）
しかしそれなりの人数で JavaScript 書くとかあんまり考えたくないなー。チーム開発なら皆さん JS でも IDE とか使ってるんですかね？
128:108
12/12/09 00:36:21.77
あ、レスが別になっちゃった・・・。
>>115
C# で Web 開発ってあんまり聞いたことないですけど（当然だけど）普通にあるんですね。会社的には C# より Java が基本なので採用はちょっと難しいですが・・・。
>>113
なんか色々やってますね・・・。今度のプロジェクトはクライアントが HTML だったり Excel だったりするみたいです。
Excel を使った EUC クライアントみたいな感じの機能を沢山作る必要があるとか。Excel と上手くつなぐ方法があんまり無さそうなんですが・・・。
129:デフォルトの名無しさん
12/12/09 09:46:56.19
Visual StudioでExcelブックなアプリケーション作成ってあんま情報無いよな。
Excelも2013だとWEBSERVICEなんてものもあるけどなｗ
130:デフォルトの名無しさん
12/12/09 09:48:29.53
JAX-RSって、実務経験の足りない優等生、っていうイメージがあるんだよなー。
131:113
12/12/09 15:09:36.86
JAX-RSを使う場合(自分は使ったこともなく、webで斜め読みした程度の知識しかないですが),
どのプロダクトを使うのがいいのかな？
やっぱり Tomcat + Jersey が一番ポピュラーなんだろうか。
あとは Glassfish は標準で JAX-RS に対応しているみたい。
というかJavaEE6 に準拠しているコンテナは標準で対応しているのか。
さっき見つけたページ
JAX-RS(Jersey)を使ってみる - azuki note
URLﾘﾝｸ(d.hatena.ne.jp)
あと、最近このスレが活気づいていてうれしい。
自分はRailsも好きだしPlay!も気になるけど、なんだかんだでJava歴が一番長いので。
132:デフォルトの名無しさん
12/12/09 18:11:32.73
デファクトはJerseyじゃないの
Glassfishが組み込んでるのもJerseyじゃなかったけ？
JAX-RS、前に採用しようとして評価したんだけどさ。
そのときの感想として思ったのは、結局、実装固有の機能とかを使わないと、
JAX-RSで定義されている仕様だけだとちょっと(´・ω・`)だな～という点。
それはJAX-RS 2.0の仕様を見る限りも微妙な感じで。
まあ、将来には期待しているけどね。
133:108
12/12/10 10:58:04.97
Dropwizard というものを発見しましたがどうでしょう。
これは JAX-RS を使ってるみたいですね。
URLﾘﾝｸ(dropwizard.codahale.com)
Jetty を内包していてスタンドアローンで動くようです。
134:デフォルトの名無しさん
12/12/10 15:20:26.80
xsltを使用したフレームワークってないのかな
135:113
12/12/10 15:52:41.00
>>134
大昔から cocoon や Xalan があるではないか
Xala は XML 出連携されてきた内容を HTML に変換して表示、とかやったな。
136:デフォルトの名無しさん
12/12/14 00:38:24.74
xsltとかタグライブラリとか、マークアップ言語大嫌い
137:デフォルトの名無しさん
12/12/15 09:23:47.44
JavaScriptでゴリゴリDOM操作して
CSSでスタイル当てる方が好きだな
138:デフォルトの名無しさん
12/12/15 22:25:08.69
ちょっとでかい会計系のWebアプリ立ち上げる計画があるそうだが、
フレームワーク何にするかなー。
今ならSpringMVCですかねー。個人的にはSeasar2にしたいけど、
これからの大規模プロジェクトで採用するのはつらいかもなあ。
小規模なら遠慮なくSeasar2にするんだけど。
でも上司の思うが儘にやらせてたらStrutsとかになってしまいかねんし
早いうちから口酸っぱく違うフレームワークにしよう運動しとかないと。
JSFとかは・・・うーんよく知らないので判断がつきませんわ。
139:113
12/12/16 01:30:49.93
JSFは、細かいところで身動きが取れないので止めた方がいい。
Strutsは、悪く言えばごりごり書けば、汚くなるけどいくらでも逃げ道はある。
会計系というか業務系だと、顧客のいうことを聞いて実現しようとすると、
かならずフレームワークの流儀に合わない画面制御のところとかが出てくる。
多少汚くなってもいいから、逃げ道があるフレームワークを選んだ方がよい。
140:デフォルトの名無しさん
12/12/16 03:06:02.73
Struts使うなら、v2よりv1だな
Seasar2もいいけど、Tomcat7あたりは大規模でも十分使えるよ
141:デフォルトの名無しさん
12/12/16 08:58:23.46
自分はSeasar2が良いと思っていて、プロジェクトをコントロールできる自信があるならSeasar2で良いんじゃ無いの？
今後の発展に期待が出来ないだけで、悪いものな訳じゃないし。
多少の生産性より柔軟性の方が重要なのは139の言うとおりで、JSFはまず無いし、Springはありで。
142:デフォルトの名無しさん
12/12/16 09:29:56.11
「アーキは予測できないことを予測しろ」って誰かエロい人が言ってたけど、
想定外の状況が生まれた時に一番対処できる自信のあるのを選ぶのがいいかなー。
こと仕事においてはあまり冒険をしないで堅実にやれるのがいいと思う
143:デフォルトの名無しさん
12/12/16 09:35:44.44
だよな。やっぱりStruts1が最高
144:138です。
12/12/16 11:39:49.96
いろいろ意見もらえてうれしいです。
>>139
JSF・・・叩かれてること自体は知ってますが、そんな使いにくいんだ。選択肢から外します。
>>142の意見は確かにその通りだなーと思います。
Struts（もちろん1）もそう考えるとうち開発者Strutsが多いんで考え方的にはありなのかなあ。
Struts2は一回検討してなんじゃこりゃとなったのでもう選択肢にはないですね。
とすると・・・
Seasar2（使いやすい）
Struts1(経験者多し）
Spring(使ったことはあるけど上二つほど自信ないっす、
慣れるといろいろ便利なプロダクトがあるけども・・・）
この3択（今のところ上二つのどっちかにってことになるのかな）。
うちの会社で堅実な選択肢となるとやっぱり上二つのどっちかになりますね。
まだもうちょっと先の話なんでいろいろ相談しながら決めていきます。
145:デフォルトの名無しさん
12/12/17 17:26:53.84
RESThub ってのを見つけた。
URLﾘﾝｸ(resthub.org)
146:新しいSpringでたぞ
12/12/20 10:07:25.62
SpringSource Spruce Up Spring MVC as Spring Framework 3.2 Goes GA
URLﾘﾝｸ(www.infoq.com)
VMware's SpringSource team has released the GA version of Spring Framework 3.2
147:デフォルトの名無しさん
12/12/24 09:08:10.96
Play! は選択支にはいらないですか。
148:デフォルトの名無しさん
12/12/24 10:27:40.04
>>147
昔Play検討したときにDB周りに問題ありそうだったので選択肢から外したことあるけど今どうなんだろうな。
・・・でも今の日本でPlayとかここでの評判劇悪のJavaEE6より敷居が高そうだ。
あえてPlayにする理由がないと思う。
149:デフォルトの名無しさん
12/12/24 12:28:21.18
自分の感覚だと、Play は seaser 使うなら Play（２系） の方がコード量が少なく作れるなあ、という感じ。
DB は RoR な設計を出来るシステムだと ejb とか jpa で綺麗に作れる。
複雑なSQLが必要なシステムだと、Play にする旨味はない。
と思ってます。
150:デフォルトの名無しさん
13/01/23 00:01:00.50
業務系のWeb層ならApache Wicket最強だな！と思うんですが、なかなか賛同されないんですよねぇ。
最近はちょっとした社内向けWebアプリを作るのにGrailsにハマってます。
151:デフォルトの名無しさん
13/01/23 11:14:06.31
>>150
使ったことないんだけど、Wicketがどの辺がいいの？
何々のフレームワークと比べてXXだからいい、と具体的な理由が聞いてみたい。
152:デフォルトの名無しさん
13/01/23 13:31:31.50
他のフレームワークはコード量を減らすおまじないに終始したり、
ホットデプロイとか小さいアプリ向けに特化している。
Wicketは大きなアプリになっても長所を失わない。
Wicketで小さなアプリから大きなアプリまで堅実に作れる。
あと地味にテスト環境が秀逸。
153:デフォルトの名無しさん
13/01/23 13:38:36.55
Wicketの欠点はIDEにスケルトンを自動生成してもらわないと疲れるぐらい
スケルトンコードにあたる定型コードが多いことだな。
HTMLから生成するツールなりプラグインなりあればいいんだが
なぜ誰も作らんのやら。
154:デフォルトの名無しさん
13/01/23 13:40:44.05
Wicket見てるとどことなくASP.NETを思い出す
155:デフォルトの名無しさん
13/01/23 15:03:36.62
ASP.NETはJSFとWicketの中間っぽいような。
156:デフォルトの名無しさん
13/01/23 15:09:40.52
struts3どうなったんだろう
157:デフォルトの名無しさん
13/01/23 17:11:39.00
ついでに Click との比較もあればコメントしてくれ。
何年か前に矢野さんの Wicket の本が出たとき、流行るかなと思ってたけど
日本のSierでは浸透しなかったな。
Struts とか SpringMVC の要員しか見つからず、Wicket 経験者がいないとか、そういうのが問題なんだろうか。
あと、同僚が >>153 みたいなこともネック、って言っていた。
>>154-155
今度、初めて ASP.NET (ASP.NET WebForm なのか、ASP.NET MVCなのかはわからない)の仕事に
入るかもしれないんだけど、このふたつは SpringMVC や Struts などとくらべて、どっちが洗練されているんだろう？
158:デフォルトの名無しさん
13/01/23 17:42:30.19
ASP.NETは前世代思想のSpringMVCやStrutsより勝ると思うが、
新世代系FWは学習コストが高いから、実際には苦労する。
159:デフォルトの名無しさん
13/01/23 17:45:50.00
ASP.NET MVCは使ったこと無いけど、ASP.NET WebFormは、
昔のVBライクにポトペタで作れたりするので結構楽ですよ。
作法に則ったアプリ作る分にはStrutsとかより全然楽かと。
Wicketも同様(?)に、html+javaでコードが散逸しないし可読性高いのが良い。
ボタン押下時のイベントは～みたいな書き方で作れる。
欠点も裏返しで、ボタン押下時のイベントに1000行くらいの業務処理を書いたりするような
プログラマに使わせたときに手に負えなくなったりする。
160:157
13/01/23 18:38:58.51
>>158-159
レスどうもありがとうございます。
いままでJavaがほとんどで(Railsは多少経験があるが)、
そもそも web開発 だろうがデスクトップアプリ開発だろうが、.NET による開発が初めてなんだけど、
がんばってみようと思います。
JavaとC#の両方に精通している同僚が、ASP.NET MVC + Entity Framework はおもしろいよって言ってた。
ひまなときに wicket やってみるか。
161:デフォルトの名無しさん
13/01/23 21:47:36.20
>>160
C#erだけど、ASP.net MVCとWebFormは開発方法がかなり違う。
WebFormはポトペタで一見楽そうに見えるけれど、HTMLを
細かく制御したい場合には一気にハードルが高くなる。
「細かいデザインなどどうでもいい」、という用途以外では使いづらい。
例えばモバイルだとデバイスごとに出力html変えたりするけどそういうのも難しい。
あとは、WebFormは無駄な通信が発生しやすいアーキテクチャで
パフォーマンス上もよろしくない。
大量のhiddenフィールドと無駄なラウンドトリップ、ポストバック処理が原因。
インターネットサービスなどには向かない。
一方、asp.net MVCはアウトプットHTML、CSSを完全に制御できる。
パフォーマンスも高速
ASP.net MVCのほうが圧倒的にものがいい
ASP.net MVC覚えたらMVCだけを使う人のが多い感じ
WebFormは古くなりつつある。
ASP.NET MVC + Entity Frameworkがいいっていう同僚の意見には同意する。
Javaで同等レベルのものを探してるが見当たらない。
162:157
13/01/24 08:00:23.06
>>161
レスどうもありがとうございます。とても参考になります。
今度行くかもしれないチームは、すでにWebForm ですでにつくっていて、
これから ASP.NET MVC に作り替えるって言ってました。
(自分がどこから作業するのかはわからない)
>ASP.NET MVC + Entity Frameworkがいいっていう同僚の意見には同意する。
いまは喰らうどの人になってしまったが、以前、Seasarプロジェクトのshotタソも、勉強会で同じことも言っていた。
163:デフォルトの名無しさん
13/01/24 10:20:17.98
なぜかDBがOracleでEntityFrameworkが使えないというオチに100000ペリカ
164:デフォルトの名無しさん
13/01/24 10:29:03.20
>>163
Microsoftが作った、というだけでそういう誤解を受けるんだよな
Entity FrameworkはMySQLでもPostgreSQLでも
ORACLEでもSQLiteでも使える。
SQL Server限定のORMではない。
今はEFは、Linuxの.net(Mono)上でも動く。
しかもオープンソース
URLﾘﾝｸ(entityframework.codeplex.com)
ASP.net (asp.net MVC含む)もオープンソースになっていて、Linux上で動く
165:デフォルトの名無しさん
13/01/24 10:37:28.47
ん？今は使えるようになったのか？
誤解というか普通にOracleが対応してなかったはずなんだがな。MSじゃなくOracleのODP.NETが対応してない。
ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。
166:デフォルトの名無しさん
13/01/24 10:37:38.11
ASP.net のオープンソースのリポジトリって、 URLﾘﾝｸ(aspnetwebstack.codeplex.com) かな。
codeplex って MS がやっているオープンソースのサイトだよね。
167:デフォルトの名無しさん
13/01/24 10:52:40.24
>>165
EF側ではなくORACLE側が対応してなかったって話？
ぐぐったらすぐ出てきたけど
URLﾘﾝｸ(www.infoq.com)
URLﾘﾝｸ(www.oracle.com)
MySQLは最新のConnector/netでEF4.3対応した、とリリースされていた。
168:デフォルトの名無しさん
13/01/24 11:03:06.80
>>167
> ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。
> EF5
URLﾘﾝｸ(www.infoq.com)
> support for Entity Framework 4.1 and 4.2.
169:デフォルトの名無しさん
13/01/24 11:26:06.15
>>168
163ではEF5とはいってないじゃないかw
ORACLEで使えるとレスあったとたんにEF version5限定にハードルあげるなよｗ
最新のEF5使えれば最高だろうけど、EF4.xでも他のORMよりましだと思う。
Java世界のORMはよく知らないけど、JavaのORMでEFみたいにTypeSafeなORMってあるの？
HybernateとかはXMLマッピング地獄なんでしょう？
170:デフォルトの名無しさん
13/01/24 13:59:36.96
JPAとかS2JDBCとかあるし、今更XML地獄は古いよ。
だけどアノテーションやメソッドチェインも万能じゃない。
LINQがあるだけC#の方が短くかけるだろうけど、思想面では同じようなもん。
171:デフォルトの名無しさん
13/01/24 14:26:01.47
用途は限られるがslim3ならメタクラス使ってTypeSafeなORM実現できるよ
（GAEのDatastoreのみ）
172:デフォルトの名無しさん
13/01/24 19:52:13.04
APTで作ったメタクラスを使うのと式木では、式木の方が表現力や柔軟性はある気がする。
あと、ちょっとしたものならEFで良いかもしれないけど、用途によってはMicro-ORMとかを使うし。
そういえばサイボウズの社内システムで、Oracleの商用プロバイダを使っているとかいう話もあったね。
URLﾘﾝｸ(developer.cybozu.co.jp)
173:デフォルトの名無しさん
13/01/26 17:24:41.22
JAX-RS 人気ないですねぇ。
Jersey がデファクトなのかなと思いつつ、ドキュメントのしょぼさを見るとつい RESTEasy の方が良いんじゃないかと思ってしまう・・・。
174:デフォルトの名無しさん
13/01/26 19:41:28.01
人気ないか？
他のFWに比べれば評価は高い気がするけど。
ただ、本当の実用を考えるなら、現状の各種実装系固有の良いとこどりしたレベルのものが出ないと厳しい気がするけど。
175:デフォルトの名無しさん
13/01/26 22:38:07.97
評価は高いけど実用してる人が少ないなーという印象。
自社運用の Web サービスとかで使ってるところはあるみたいだけど、エンタープライズでは使ってるって聞いたことない。
正直表面的なところだけ見ると他の FW より断然良いなと思うんだけど、やっぱり機能面で何か不足があるんですかねぇ。
それとも経験値の問題で、わざわざ他から移るほどの価値を見出せていないだけなのかどっちなんだろう？
エンタープライズ向けの Web アプリを JAX-RS + Backbone.js とかで作るのはやっぱり危険ですかね？
176:デフォルトの名無しさん
13/01/27 14:14:22.26
JAX-RSは2.0出てからかなぁという印象、いつになるか知らんが
177:デフォルトの名無しさん
13/01/27 15:24:47.38
JAX-RSってSpring MVCに比べてメリットってあるの？
煽るわけじゃないんだけど、アノテーション使った書き方はそう違わないし、
実用度の点からは細かいところにまで手が届いているSpring MVCで良い気がするんだけど。
178:デフォルトの名無しさん
13/01/27 18:00:33.00
Spring MVC って思いっきり Framework って感じで重すぎる印象があってあんまり好きじゃないなー。
まぁそれはともかく Spring MVC は REST 対応が後付け感じがあるんですがどうなんでしょう？
RESTful なサービスを作りたい場合は JAX-RS の方に優位性があるのではと思ったりするんだけど。
例えばサブリソースの表現とかは Spring MVC だとベタに書かないといけない気がする（調べたわけではないけど）。
179:169
13/01/27 18:20:33.70
>>170-172
サンクス。
JavaのORM = Hibernate = XMLマッピング地獄だと思ってた。
GoogleやSeasaaは使ってないからS2JDBCとかはむりっぽ
JPAとやらを少し調べたけど良さそうだな
POJOを使うORMで、POCOを使うEntityFrameworkに少し似てる感じがする。
下ページでは、JPAの主要な実装は、TopLink Essentialsおよび
Hibernate EntityManagerと書いてあった。2006年の記事だけど。
URLﾘﾝｸ(news.mynavi.jp)
Javaで使用率高いORMは、JPAとTopLink Essentialsの組み合わせかな？
両方オラクル純正だし
Web Framework(for Java)の海外トップシェアはSpring MVCみたいだ。
ソースは俺の検索結果（主に海外サイト）
180:デフォルトの名無しさん
13/01/27 18:21:36.77
つ URLﾘﾝｸ(www.infoq.com)
181:デフォルトの名無しさん
13/01/27 21:55:42.86
>>180
読んでみたけど全体的に JAX-RS の方が美しく感じる。
・レスポンス
・Conneg
・例外ハンドリング
あたりは JAX-RS の方が良いと思った。けど実用性は多分 Spring MVC なんだろうな・・・。
各 JAX-RS 実装の拡張が色々あるから実際にアプリつくるときにあまり困ることはそんなに無いと思うんだけど、やってみないと分からないなー。
でもまぁ flush スコープとか validation とかあるからやっぱり Spring MVC なのかな・・・。
182:デフォルトの名無しさん
13/01/28 02:37:48.31
>>179
JPAについてコメントします。
JPAは規格の名前で、Toplink Essentialsは、JPAの実装の一種です。
いちおう、TopLinkが JPA のリファレンス実装となっています。
JPAの実装のオープンソースは、ほかに
OpenJPA、Hibernate(Hibernate EntityManager) などがあります。
あと、
> Javaで使用率高いORMは、JPAとTopLink Essentialsの組み合わせかな？
> 両方オラクル純正だし
Javaの世界でオラクル純正は、あまりアテになりません。
Oracle(Sun)純正でクソなプロダクトは、これまでにもいくらでもありました。
おまけ：
このプログラム板に以下のスレがあります。
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
ｽﾚﾘﾝｸ(tech板)
その昔は、Javaの各ORマッパーについての議論が活発で、
とても勉強になるスレだったのですが、ここ数年は
全然関係ないアニメのコピペが貼られるだけになってしまいました。
残念です(まぁJavaのORマッパーの話題は、一通り行き着くところまで行ってしまったのかもしれないが)
183:デフォルトの名無しさん
13/01/28 02:41:01.19
>>179
もう少しだけ補足。ご存じだったらすみません。
> JavaのORM = Hibernate = XMLマッピング地獄だと思ってた。
初期のHibernateは、そのとおりXMLマッピング地獄だったけど、
Hibernate Annotations というのができて、Enittyクラスにアノテーションでカラム名とか付けられるようになった
(XMLに書かなくても良くなった)
さらに Hibernate EntityManager というのができて、Hibernate が JPA をサポートするようになった。
184:>>20
13/01/28 21:39:34.15
かなり古いバージョンの記事が検索の上位にかかりやすいよね。
ちなみにJPAと同じ要領でXMLをマッピングするJAXBなんてのもあるぞ。
185:デフォルトの名無しさん
13/01/31 14:25:30.71
URLﾘﾝｸ(www.infoq.com)
Plans for Spring Framework 4.0 Announced
- Includes Support for Java SE 8 and Groovy 2
186:デフォルトの名無しさん
13/02/02 17:40:16.89
もうダメだわｗ
Twitterサイバーテロ事件の原因は話題のJavaの脆弱性ｗｗｗｗｗ 今すぐアンインストールしろｗｗｗｗｗ
ｽﾚﾘﾝｸ(poverty板)
187:デフォルトの名無しさん
13/02/02 22:30:37.53
昔Jerseyを使ったときにJAXBでアノテーションつけたbeanをJSONにシリアライズして
レスポンスとして返す場合に、プロパティに配列やコレクションがあるとその要素数に
よってそのプロパティのシリアライズの結果がArrayになったり裸単騎の値になったりして
頭を抱えたのだけれども今は大丈夫なんだろうか。
188:デフォルトの名無しさん
13/02/02 23:13:34.40
XML地獄の次はアノテーション地獄か
昔のJavaが一番作りやすかったな
いまは新入社員が入ってくる余地がないな
189:デフォルトの名無しさん
13/02/03 17:15:48.97
裸単騎ｗ
190:デフォルトの名無しさん
13/02/06 14:28:49.36
>>187
MessageBodyWriter使ってjsonicあたりに処理させればいいんじゃないの
191:デフォルトの名無しさん
13/02/07 00:34:05.94
アノテーションが増えてソースコードがXMLみたいになるな。
言語やＦＷを変化させても冗長性と簡略化のトレードオフになるだけで
優れたものに前進しないな。
192:デフォルトの名無しさん
13/02/07 13:38:09.81
そこで設定より規約ですよ
193:デフォルトの名無しさん
13/02/07 13:43:15.61
rubyやphpのほうが作りやすいということ
Javaは方向性間違ったな
194:デフォルトの名無しさん
13/02/07 14:48:22.64
COCはフレームワークの話だろ。
Playとかあるじゃん。
ArrayList, HashMapは構文に組み込んで欲しい。
あとアノテーションプロセッサを使いやすくできれば
COC方面で著しい変化がある。
var array = new Integer[];
var hash = new [String, Integer];
195:デフォルトの名無しさん
13/02/07 16:37:04.64
JAXBやJPAのアノテーションの話であれば十分にCoCしていると思うけれどもね。
普通のBenasであれば冒頭にただ@Entityとか@XMLRootElementとか書いておけばあとは何も
せずとも規約に従って大体よろしくマッピングしてくれる。
ただ規約に外れて手作りししたい部分が出てくるとその程度によってアノテーションだとかえって
見通しが悪くなることがあるのも事実。
196:デフォルトの名無しさん
13/02/07 20:26:49.56
「規約と完全一致ならBeanクラス自体がなくてもいい。」
アノテーションプロセッサでここまでできればRailsに勝てるだろう。
IDEにスケルトンプログラムのジェネレータプラグイン入れて
クラスファイルの山を作ってるのが現状。
今度はコンパイルが重くて仕方ないか。
197:デフォルトの名無しさん
13/02/08 01:48:59.44
Rails(というかActiveRecord)の便利なところは、
モデルクラスにメソッドを定義してなくても、呼び出し側が適当なメソッド名を
呼んでしまえば、Method Missing により、規約に沿って自動的に解釈されてSQLを実行してくれるところだと思う。
コンパイル言語でのJavaでは、これは絶対に無理。
S2Daoなど、Interfaceだけ定義すれば proxy オブジェクトを作ってくれるフレームワークはいくつかあるけど、
かならず Interface にメソッドだけは定義しないと行けないし。
198:デフォルトの名無しさん
13/02/08 02:18:23.89
本当に無理なんかなあ。Javaって回り道ばかりしてるじゃん
生活費1000万くれて1年それだけに集中していいって言われたら
開発者みんなが楽できる最強のフレームワーク作れる自信あるわ
199:デフォルトの名無しさん
13/02/08 05:10:55.98
最強のフレームワークなら１０００万円以上で売れるんじゃね？
200:デフォルトの名無しさん
13/02/08 07:11:01.57
Beans無しでしかも型安全なフレームワークが実現可能ならまだ存在意義もあるだろうけれども
Beans無しというだけでは全く流行らないだろうね。
201:デフォルトの名無しさん
13/02/08 14:27:57.43
>>198
コンセプトだけプレゼンしてみ？
よさげならうちの職場に紹介するよ
1年1千万なら余裕で出せるはず
202:デフォルトの名無しさん
13/02/08 15:22:57.86
Beans無しがそんなに嬉しいかねぇ。
203:デフォルトの名無しさん
13/02/08 16:00:08.22
>>200 >>202
Beansってなんのこと？
Entityクラスを作るってこと？
(SpringMVCにおける、Form の Modelクラスでもいいけど)
204:デフォルトの名無しさん
13/02/08 16:19:47.38
そういうことじゃね?
厳密にはEntityクラスは作るにしても、ActiveRecordだけ継承すればあとはフィールドや
アクセサの類を定義しない空のクラスのままでもよろしく動くということだと思う。
205:198です。
13/02/08 21:19:31.37
star-123@yahoo.co.jp
メール下さい。
206:198
13/02/08 23:00:45.38
早くメール下さい。
207:デフォルトの名無しさん
13/02/08 23:38:25.89
１０００万の仕事を捨てメアドで募集してるときいて
208:196
13/02/09 01:13:47.47
アノテーションプロセッサができるのはコンパイル時クラスの自動生成だよ。
Javassistとかは実行時生成だからインターフェースとか必要になるけど、
アノテーションプロセッサだとソース上では全く定義されていないクラスを
new HelloBean();とかしても型安全に操作できる。
今のアノテーションプロセッサでＦＷはかなり作りづらいし、見向きもされていない。
209:デフォルトの名無しさん
13/02/09 02:08:32.22
>>208
型安全… だと？
HelloBeanじゃなくHalloBeanと書いた場合にどうやって間違いを見つけるんだ？w
210:デフォルトの名無しさん
13/02/09 03:06:41.17
コンパイル時にターゲットのDBに接続してスキーマ引っ張ってくる必要があるな。
211:デフォルトの名無しさん
13/02/09 03:13:38.12
アノテーションプロセッサを使うというのは、(webフレームワークではなくORMだけど)Domaも似たようなものかな。
Interfaceクラスだけつくって、アノテーションプロセッサを一度実行しないといけないけど、Entityクラスが自動生成されるのはいいかも。
でも、それって Excel などでつくったプロジェクト内自動生成ツールを事前に実行するのと、手間的には変わらない気もする。
212:デフォルトの名無しさん
13/02/09 03:23:31.64
DBから生成できるEntityのプロパティはアノテーションプロセッサで作る必要ないな
>>197が言ってるのはSQL生成するメソッドだから、O/Rマッピングパターンだと
存在しないDAOを呼び出すとアノテーションプロセッサが作ってくれるイメージだろ
213:デフォルトの名無しさん
13/02/09 09:38:16.20
自動生成してくれるのは結構なんだがきっちりドメインオブジェクトを書き起こさずに
メソッドの自動生成に任せていて開発規模的にどの程度スケールするのかは気になる。
214:196
13/02/09 12:41:01.52
railsみたいにcocでもりもり削ろうぜって話だったはず
215:デフォルトの名無しさん
13/02/09 16:45:23.43
マイグレーションや関連、検証を書き始めるとあまり変わらん気もする。
JPA等を使うにしても結局面倒なのはそこで、Beansの定義自体は機械的作業でIDE使えば
面倒でも何でもないし、むしろBeansが無かったり動的生成されるほうが静的検証もやり
にくいしむしろ色々面倒臭い。
216:デフォルトの名無しさん
13/02/09 17:55:05.13
Eclipseが標準でSQLJを手厚くサポートしていればいろいろ違ったかもな
217:デフォルトの名無しさん
13/02/09 22:10:06.33
ORMの話だしSQLJ等の埋め込みクエリはあまり関係ないかなぁ。でもJPQLは好き。
ORMを使っていても集約計算などするときは変にエンティティオブジェクトや
フレームワークが提供する無駄に独自性溢れるクエリーAPIと格闘するよりSQL一本
書いた方が速いよね、という場面はそこそこあるし、そういった場合にはJPQLは
DBMSの方言を気にせずハードコード出来てかつどんなSQLが吐かれるか大体見当が
つくので個人的には時々便利に使う。
218:デフォルトの名無しさん
13/02/09 22:37:44.53
ORMったってマッピングの部分はほぼ完成していて問題にならない。
問題なのは相変わらずクエリを作るところだろ。
JPQLもクライテリアAPIもそこじゃん。
そこの標準が早期(JDK1.1)からあったんだからIDEがしっかりサポートしていれば
もっといろいろな発展があったと思うね。
OracleのSQL Developer使ったことあればわかるだろうけど、エディタ上でSQL書くと
その場で文法に加えて名前や型までチェックされて、即実行して結果も見える。
あれがJavaとシームレスにつながって関係するDAOやJavaBeansが自動生成されれば
相当便利なものになったんじゃないか。少なくとも、その基礎にはなり得たんじゃないか。
219:デフォルトの名無しさん
13/02/09 22:51:10.17
JSQLとJPQLライクの間みたいのが素敵だと思う。
jpql {
..Result<Entity> result = query {
....Entity e,
....From e,
....Bool isA = e.price > 0 && e.price < 100,
....Bool isB = e.price > 1000 && e.price < 2000,
....Where isA || isB,
....Order e.name,
....fetch lazy
..};
..List<Entity> list = result.range(first, last);
};
220:デフォルトの名無しさん
13/02/09 23:14:58.74
っていうか、こういう話を↓のスレで続けたかったな。
最初の頃はとても勉強になるスレだったのに、いまは変なアニメの人が居着いちゃってとても残念。
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
ｽﾚﾘﾝｸ(tech板)
221:デフォルトの名無しさん
13/02/09 23:26:28.54
そのスレまだ蹂躙されてたのかw
222:デフォルトの名無しさん
13/02/11 17:04:04.35
アニメの話はアニメ板でやった方が
反応もあって楽しいだろうに何であそこなんだろうな。
223:デフォルトの名無しさん
13/03/02 14:27:18.78
アニメ好きのJavaでDB開発担当してたやつが
仕事で下手こいてクビになったとか、メンタル壊して鬱病ヒキコモリに
なってしまったとか、哀れな末路に驀進中なんじゃね？
別スレ立ててもいいかもね。
そういえば、そのスレの１スレ目立てたの俺だった。。
最近、鯖側でスクリプト環境使うことが増えてきて、今までは
スクリプトは遅いとかバカにしてたけど、即時修正とか
運用のしやすさとかを感じて見直している。
Javaにもこういう扱いやすさが欲しいな。。。
ホットデプロイ使えばいいのか。
224:デフォルトの名無しさん
13/03/02 18:21:24.23
>>223
おお、あなたが Java⇔RDBのMapping-Frameworkを語るｽﾚ vol.1 スレを立てたのか。
乙です。
> 最近、鯖側でスクリプト環境使うことが増えてきて、今までは
> スクリプトは遅いとかバカにしてたけど、即時修正とか
> 運用のしやすさとかを感じて見直している。
今は何を使っているの?
JavaじゃなくてRailsとかPHPとか?
225:デフォルトの名無しさん
13/03/02 18:50:32.40
ポール・グレハム
URLﾘﾝｸ(ja.wikipedia.org)
は lisp でフレームワークを書いていたというのだから、それもいいかもしれない
226:デフォルトの名無しさん
13/03/04 19:46:02.90
Eclipse統合M34【Java/C++/Ruby/Python/Scala】
ｽﾚﾘﾝｸ(tech板:103-106番)n
↑のスレに質問したところ、こちらのスレが適切ということで、
こちらで質問させて頂きたいです
どなたかよろしくお願い致します
227:デフォルトの名無しさん
13/03/04 22:52:15.49
Javaの入門書を卒業して、サーブレット、JSP、jdbcでのDB操作もできるようになりました。
Webフレームワークを使って、勉強用に簡素なショッピングサイトでも作ってみようかと思ってるのですが、
いま、初めてやるとしたら、どのフレームワークを使うのがいいでしょうか。
228:デフォルトの名無しさん
13/03/04 23:58:37.09
play framework 2.1 がいいと思う
229:デフォルトの名無しさん
13/03/05 04:23:08.94
Grails
230:デフォルトの名無しさん
13/03/06 20:31:46.32
フレームワークなんかなくても、
サーブレットとJSPで作るのが一番正解だよ
231:デフォルトの名無しさん
13/03/06 20:49:59.21
一番迷惑。
規模が大きくなると結局オレオレフレームワークの類を作り始めるので、そうなる前に
ちゃんとしたフレームワークを使って欲しい。
232:デフォルトの名無しさん
13/03/06 21:15:41.74
>>231
ちゃんとしたフレームワークないじゃん
ちょっと特殊なことしようとするとクソハマり
だから>>230が正解
もしくはJavaを捨てる
233:デフォルトの名無しさん
13/03/06 21:27:58.57
>>232
とくしゅなことってどんなw
234:デフォルトの名無しさん
13/03/06 21:35:06.25
それは本当に特殊なのか？
本当に特殊だとして、それは本当に必要なのか？
本当に必要だとして、それは本当に特殊なことをしないと実現できないのか？
235:デフォルトの名無しさん
13/03/06 21:43:27.90
ハマる回数が多すぎていちいち覚えてないよ
フレームワークのサンプルまんまで業務が回るならいいけどそうじゃないだろ
236:デフォルトの名無しさん
13/03/06 21:47:18.97
世の中にあるフレームワークは全てオレオレだからな。
いくつかのシステムと他の言語も経験すれば、「ぼくのかんがえたさいきょうのフレームワーク」を作る能力もつく。
結局それが一番正解に近いのさ。
車輪の再発明こそがプログラマーの醍醐味。
もちろん今あるフレームワークの長所短所も研究するべきだけどね。
237:デフォルトの名無しさん
13/03/06 22:09:52.61
>>229
デモ見るとGrailsはかんたんに扱えそうな感じだね
URLﾘﾝｸ(grails.org)
JavaじゃなくてGroovyになってるから性能が心配なところだけど
実行前にはすべてJavaのバイトコードに事前コンパイルされるのかな？
>>230
ゴリゴリJSPでやるのは生産性が悪いと思う
>>232
例えば今まで何のフレームワークを試したの？
238:デフォルトの名無しさん
13/03/06 22:24:12.80
単にフレームワークを使うだけの力もなかったんだろ
239:デフォルトの名無しさん
13/03/06 22:29:33.88
サンプルからちょっと外れるとクソハマリなんてフレームワークの流儀や
コンセプトを知らずに使ってる証
240:デフォルトの名無しさん
13/03/06 22:53:35.30
フレームワークってその流儀やコンセプトの押し付けがましいのが嫌。
241:デフォルトの名無しさん
13/03/06 22:57:37.87
>>238
力がないと使えないならいらない
servletやjspなら力なんて一切必要ないぞ
242:デフォルトの名無しさん
13/03/06 23:21:15.89
３次元配列が扱えるフレームワーク無いもんなー
使えないよな
243:デフォルトの名無しさん
13/03/06 23:28:15.29
>>241
効率よく作るにはむしろ相当な力が必要じゃね？
それこそ小さな画面一つ作って終わりじゃないだろ
244:デフォルトの名無しさん
13/03/06 23:31:37.49
>>243
そりゃライブラリの類はたくさん必要だよ
でも外から自由を奪いにくるフレームワークは不要
245:デフォルトの名無しさん
13/03/06 23:32:09.71
力ないやつが生servlet/jspで作ったらメンテ不可能なものしかできなそう
246:デフォルトの名無しさん
13/03/07 00:25:47.22
>>244
規模が大きくなってくるとそのうちそのライブラリの中にフレームワークが入ってくるんじゃないのかw
247:デフォルトの名無しさん
13/03/07 00:32:52.10
>>246
入らないよ。ライブラリは実装から呼び出される側、
フレームワークは実装を呼び出す側、役割が全然違う
248:デフォルトの名無しさん
13/03/07 00:42:19.97
匿名で使えるgistでもあればそのライブラリ使ったコード貼ってみろよで終わりなんだけどな
お互い相手を下に見てるどうしが1、2行の文章だけでやりあっても不毛
249:デフォルトの名無しさん
13/03/07 06:14:07.70
>>236
誰も「さいきょうフレームワーク」の醍醐味なんか求めていない。趣味かよ。
オレオレにせよ商用にせよOSSにせよ、今すぐに使えてどれだけ継続的にアップデートが
続くかが問題。
どこかの天才が気まぐれで作ったさいきょうフレームワークよりも沢山のユーザに使われて
ある程度の期間バグを叩かれまくっているそこそこのフレームワークを使うね自分は。
250:デフォルトの名無しさん
13/03/07 08:43:31.29
画面が多いだけの大規模システム（いわゆる業務系）なら
フレームワークも有効だろうねぇ
251:デフォルトの名無しさん
13/03/07 15:56:03.63
「画面が多いだけ」ってよくわからん。
画面が多い「から」、フロントエンドの規模が大きいからウェブアプリのフレームワークを
使うのであって、その後ろに画面の多さ以外の何があろうが別問題だと思うのだが。
上から下まで全部一つのフレームワークで作ることしか頭にないのか。
252:デフォルトの名無しさん
13/03/07 16:10:25.88
でもおまいらの言ってるのは何が何でもフレームワークなんだろ？
とにかくまずフレームワークを使うことが第一であとは
どうでもいいって感じ。
253:デフォルトの名無しさん
13/03/07 16:20:28.86
じゃなくて、Java使ってWAF使って開発すると決めた後の話題が主なのがこのスレ
違う決断した後の話は別スレでする
254:デフォルトの名無しさん
13/03/07 16:24:17.70
JavaとWAF使うってことは型にはめやすい、型にはめるメリットがある(似た画面多い、人が多い)案件って事
そうじゃないこともあるが、それをここで話す意味がわからない
255:デフォルトの名無しさん
13/03/07 16:36:01.22
>>254の「そうじゃないこと」は「そうじゃない案件」です
256:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/07 18:23:53.38
>>256
Grailsって、ORMはHibernateを同梱しているんだよね？
Hibernateあまり使いたくないんだよなぁ。
MyBatisなどに差し替えられないの？
258:デフォルトの名無しさん
13/03/07 18:36:40.23
>>257
Mを構成するGORMというORマッパーはJPAどころかがっつりHibernateに依存しているので
無理っぽい。WAR等からHibernateだけ切り離すのも無理じゃないのかな。
ただ別のORMで書かれたMをVCから叩くのは普通に出来ると思う。たぶん。
259:デフォルトの名無しさん
13/03/07 18:39:36.67
>>256
ありがとう。
CoCが魅力的だったけど、速度も重視したいからSpring MVCも見てみる。
GrailsはJavaでも書けるようになってほしいな
260:デフォルトの名無しさん
13/03/07 18:46:34.27
やっぱり不自由が発生してるじゃん
Aだけを使いたいのに使いたくないBまで使わなきゃいけないとかw
技術力が普通にあるのなら使う必要ないんだよ
261:デフォルトの名無しさん
13/03/07 18:57:29.88
>>260
ORMは好きなの使えるっていうフレームワークもある。
JPA使えるやつなら大半の人は文句ないんじゃないの
JPAデファクトスタンダードだろうし
262:デフォルトの名無しさん
13/03/07 19:04:53.41
JPAｗ
263:デフォルトの名無しさん
13/03/07 19:05:31.48
デファクトｗｗ
264:デフォルトの名無しさん
13/03/07 19:16:01.10
なに草はやしてるんだ？
JPAはJavaでは一番メジャーなORMだろう
265:デフォルトの名無しさん
13/03/07 22:06:26.45
>>260
フレームワークの実装が特定のライブラリにがっつり依存しているか交換可能なように
設計されているかの違いだろうなぁ。
そしてそれはフレームワークの開発の速さや使い勝手とのトレードオフでもある。
GrailsはHibernate似のcriteriaも提供していたりとHibernate以外に交換するのは
しんどそう。
266:デフォルトの名無しさん
13/03/08 02:05:35.35
>>260
「やっぱり」って、不自由が発生するのを否定してるやついたか？
制約する・型にはめることによるメリットが不自由というデメリットより大きいってだけだろ
267:デフォルトの名無しさん
13/03/08 02:16:55.15
「特殊なこと」ってのが曖昧だから話にならんのだよな
ビューに関してはJSP使ってるフレームワークだったら不自由もないだろ
コントローラにしたって所詮HTTPの範疇じゃたいして特殊なことなんかできんだろ？
268:デフォルトの名無しさん
13/03/08 07:21:32.53
listの中にlistが入ってて、さらにlistが入ってるような
データが受け渡しできないから糞
そんなフレームワークばっかり。フレームワーク作ってる奴は
単純なサンプル画面しか作ったことないやつばっかり。
269:デフォルトの名無しさん
13/03/08 07:45:04.59
>>268
どのフレームワークのことを言っているのか皆目不明なのでざっくりMVCを使って尋ねるけど、
「受け渡しが出来ない」ってM・V・Cのどれからどれの間で受け渡しが出来なかったのさ。
フレームワークが使えない理由としてなにか高尚なものが来るかと思いきや、いきなり脱力な
例が飛び出してぐんにゃりですよ。
270:デフォルトの名無しさん
13/03/08 08:05:17.79
どこで受け渡しできないかも知らない程度の知識なんだとわかった
271: 忍法帖【Lv=40,xxxPT】(2+0：5)
13/03/08 08:14:16.37
>>268
批判するならどのフレームワークを使ったかくらい書くべきだね
すべてのフレームワークが同じわけではない
272:デフォルトの名無しさん
13/03/08 09:52:29.11
仕事以外の時間もプログラム板に来るような勤勉でスキルも高いであろうおまえらは
不便なフレームワークでハマる必要ないんだよ
流行りに流されてるのに気づいたほうがいい
チームに新人やスキルが低い人間がたくさんいてそいつらに大部分を任せないといけないから
スパゲッティを避けるため仕方なく使ってるという話ならわかるけど
273:デフォルトの名無しさん
13/03/08 11:04:32.79
そこでPlay! Frameworkですよ
Play! は Scala が話題になっているが、Javaでもかける。
274:デフォルトの名無しさん
13/03/08 11:58:37.45
wicketってのがXML書かなくていいらしいんだけど、うらやましい。
275:デフォルトの名無しさん
13/03/08 15:19:03.90
Playは独自感が半端なく強かったり、1.0=>2.0を見る限り不安定感が否めない。
wicketは素直な設計だし、1.5=>1.6を見る限り安定していて実用的な時期に思える。
用途に合わせて様々なフレームワークを使うぐらいなら、
wicketみたいな大規模向けフレームワークをベースに、
小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？
276:デフォルトの名無しさん
13/03/08 15:57:00.15
フレームワークいらんという人はORMやDIは使うのかな。
今時手組のSQLに生のJDBCとか勘弁。
277:デフォルトの名無しさん
13/03/08 16:06:37.78
ORMなんか使わないよ。パフォーマンス悪いし。
278:デフォルトの名無しさん
13/03/08 16:12:45.10
>>276
ibatisはたまに使う。
一番いらないと思うのはDIかな。
newぐらい自分でしたい。
279:デフォルトの名無しさん
13/03/08 16:24:05.63
とはいえweb.xmlにサーブレット登録した時点でサーブレットクラスのnewに関しては既に
サーブレットコンテナに委譲しているわけだからなぁ。
その先、各サーブレットクラスが必要とする依存性を自前でnewするかこれも委譲するかで
自前ファクトリをゴリゴリ書くかapplicationContext.xmlを書くかの違いが出てくる。
インスタンス生成の委譲の程度問題だと思うんだよね。個人的にはサーブレット使うことと
DIを使うことの間にはあまり断絶はない。
280:デフォルトの名無しさん
13/03/08 16:33:16.09
とくにWebアプリでORMとかアホかと思う。
Webアプリなんてサーバー集中型なのになるべく負荷を減らさないでどうする。
ORMはクラサバアプリ向けだろ。少しは考えて欲しい。
281:デフォルトの名無しさん
13/03/08 16:55:04.22
DB知らない素人が手組みしたDBスキーマとクエリ。
DB知らない素人が定義したORマッピングとそれから自動生成されたDBスキーマ。
どちらを使えと問われれば自分は絶対に後者を使う。前者は墓穴の宝庫だが後者は
一応それなりに定石を外さないスキーマやクエリを吐く。
DBの素養のある人が手組みしたDBスキーマとクエリ。
DBの素養ある人が定義したORマッピングとDBスキーマ。
どちらを使えと問われれば、まあ使い勝手次第であって基本的にはどちらでも良い。
結局スキーマもマッパーが吐くクエリも手組と大差無いものに大抵は落ち着くから。
ただし成果物のAPIレベルでの使い勝手は当然ORMを使った方が初めから機能豊富。
結局DB理解している人間が担当しているか否かが重要なのであって、その上の上物
はプロジェクト毎に好きに決めれば良い。ただし手組みさせるとそのDB理解している
人間の手作業がバカにならん。許させる範囲でORMで楽させてあげても。
282:デフォルトの名無しさん
13/03/08 16:58:19.38
そうやって、もっさりアプリ量産してくれ。
俺の超サクサクアプリが高評価なのはおまいらのおかげだ。
283:デフォルトの名無しさん
13/03/08 17:56:34.47
どうやらただの釣りだったようだな
284:デフォルトの名無しさん
13/03/08 19:25:26.20
ORMの必要性はわかるけど後でJDBCに差し替えにくい
Hibernateとかはバッドノウハウだなと思ったり。
285:デフォルトの名無しさん
13/03/08 19:39:04.75
最近のHibernateはJPA準拠してるんでしょ
JPAならそのままSQLも扱えるとおもうけど
286:デフォルトの名無しさん
13/03/08 20:00:01.24
ORMから外れたことをするにしても外れ具合の程度によってJPQLから生SQLまで
それなりに逃げ口は用意されているよね。
普通にORMを使って、困ったときにピンポイントでそういう逃げを利用するだけでも
大概のシナリオはカバーできると思う。
287:デフォルトの名無しさん
13/03/08 21:11:52.51
ORMを使うなら範囲検索にJPQL使うのは避けられないだろ。
プロトタイプだとしても主キーと全検索だけで作るわけにはいくまい。
288:デフォルトの名無しさん
13/03/08 21:29:37.43
その辺りはクライテリアとかフレームワークごとのDSLとか。
でもJPQLは良いものだ。サクッと使うのにちょうど良い。
289:デフォルトの名無しさん
13/03/09 01:00:06.57
>>281
DB知らない素人の件は俺なら前者かな。
ORMを理解してないやつが定義したものに
ORM適用するとか足かせにしかならん。
もちろんベストはそれなりにわかってるやつにDB定義をさせることだが
知らないやつが定義した場合は昔ながらのSQLで対応する他ないと思う。
290:デフォルトの名無しさん
13/03/09 01:03:09.87
>>282
俺もフレームワークとかDIとかORMとか否定派なので主張には賛成なのだけど
スマホアプリでもないただのWebアプリで
評価が高いとか低いとかどうやってわかるの？
291:デフォルトの名無しさん
13/03/09 01:29:45.60
DIを使うのって、短期的に楽をしたりするためより、変更に耐えやすいように作るためだと思うけど・・・・
(これも、スパゲッティなコードをメンテするより、長期的に楽になる)
Springスレだったかにも書いたけど、最初は Dao の実装を1つしか作らなかったけど
(Implが１つしかないのに、わざわざインターフェースを作っていた)、
途中で、一部のテーブルだけKVSに移行したので、MyBatisImplから別のDaoImplを作って移行した。
このとき、Daoのメソッドのインターフェースを変えないようにできたので、
修正はapplicationContext.xml だけ。コントローラやサービスクラスは変更無しで済んだ。
あとUT時は、サービスクラスにDaoをDIするときにモックにするとか。
こういうことを経験すると、よほど小さかったり使い捨て以外では、DIを使った方がいいと思っている。
DIをつかうための面倒なコストは、2回ぐらい変更があったら、回収できていると思う。
292:デフォルトの名無しさん
13/03/09 01:49:16.30
JavaEEが複雑すぎたために、DIが生まれたという解説をある本で読んだ。
293:デフォルトの名無しさん
13/03/09 03:27:23.17
>>291
レイヤごとにインターフェイス統一するのは
それなりのエンジニアなら誰でもやるし
そのケースでDIコンテナを使う必然性は感じられないが…
294:デフォルトの名無しさん
13/03/09 06:22:09.43
こまめにインターフェイスを定義することとDIコンテナを使うことは別に考えるべきだと思う。
インターフェイスを定義して抽象度を上げると実装の差し替えなど融通が効くのは別にDIを
使わずとも得られる恩恵だし、DIコンテナを使うにしても別にインターフェイスの定義は
必須ではない。注入される口の型が実クラス名で決め打ちでもDIコンテナは使える。
それならDIコンテナの利点は一体なにかというと、う～ん、DIコンテナを使っているフレーム
ワークを使うときは自分もDIコンテナを使った方が楽という点が正直一番でかいかなw
例えばSpringを使ったフレームワークを使うときは基本的にコンポーネントもDI前提で開発
するのが殆ど作法になっている。コンポーネントはDIコンテナのコンテキストに登録すること
でアプリ上にデプロイするという手順が大抵のフレームワークでほぼ共通なので、DI使えば
どのフレームワークでも簡単に似た手順でデプロイ出来るのに対して他の方法だと途端に
苦労することになる。
295:デフォルトの名無しさん
13/03/09 06:38:14.57
DIコンテナの作者が後年DIコンテナはいらないと言ってた件
296:デフォルトの名無しさん
13/03/09 10:57:51.80
当人がいらんと思ってても他の人が必要なら別にいいんじゃないの
297:デフォルトの名無しさん
13/03/09 11:04:21.79
>>296
いらないと思ってるやつが
いると思ってるリーダーの下についたときは悲惨だぞ←俺の今の状況
だからもっといらない流れができてほしいわ
298:デフォルトの名無しさん
13/03/09 11:13:19.54
>>295
ひがやすお？
299:デフォルトの名無しさん
13/03/09 12:11:10.88
>>298
YES
テストがしやすければDIコンテナは必要ないってSlim3の時に
300:デフォルトの名無しさん
13/03/09 15:35:31.76
DIの目的はテストじゃないと思うけどな。
301:デフォルトの名無しさん
13/03/09 15:50:02.45
ソースコード資産を別のフレームワークにそのまま移行する例って実は少ないだろ
302:デフォルトの名無しさん
13/03/09 16:34:51.64
wicket は Play! と同じくらい独自色がある気がする。 Play! で Java の時は、 DB のテーブル定義は ebean で、sql は 生 sql がいい気がする。
303:デフォルトの名無しさん
13/03/09 16:39:17.86
iBATISがやはり最強だな。
今まで使わないで来て今じゃMyBatisになってるようだがやはり最強。
304:デフォルトの名無しさん
13/03/09 16:42:53.41
HibernateやJPA実装の類がダメな理由はなんだろう?
305:デフォルトの名無しさん
13/03/09 16:54:23.60
RDBMSとの対応を把握する必要があるなら
最初からSQLに書けばいいじゃない。
306:デフォルトの名無しさん
13/03/09 17:07:23.68
Entityオブジェクトのクラスが決まっているのならそちらに必要最小限の
マッピング情報を書き足せば良いじゃない。
変なスキーマ相手だと苦労するけどJPA。
307:デフォルトの名無しさん
13/03/09 18:17:55.52
>>301
少ないっていうかほとんどない
著作権が客に移るからそのまま再利用できないし
308:デフォルトの名無しさん
13/03/09 18:45:15.19
>>300
DIの目的はオブジェクト(コンポーネント)を疎結合にすること、
DIコンテナによってそれが交換しやすくなる、
それが最大のメリットになるのが単体テスト。
だが単体テスト以外じゃ交換性は実は必要ない、
だったらテストがしやすけりゃDIコンテナはいらん、と読んだ。
309:デフォルトの名無しさん
13/03/09 18:52:55.16
「DBスキーマが何も無い状態から」素直なスキーマを使う小規模Webアプリをサクッと開発する
のであればMyBatisでも生JDBCでもなくJPA系が一番楽だと思う。要するにアノテーションからの
スキーマの自動生成で事足りる範囲であればこれが一番コード量が少ない。
開発序盤はデフォルトのマッピングでORMにどんどん生成させて、ある程度エンティティクラスが
出そろったり怪しげなスキーマ吐くようになった時点で一旦止めてマッピングに手を入れる。
そっから先の苦労は、結局扱うドメインモデルの複雑さそのものなのでどのフレームワーク使っても
あまり大差はないようにも思う。
310:デフォルトの名無しさん
13/03/09 19:08:28.23
>>304
JPA1.0の頃だが、一覧とかエンティティ以外の形で取るのが絶望的にダメだったところ
今はどうよ？
311:デフォルトの名無しさん
13/03/09 20:42:00.68
>>310
1.0にも、それ以前のHibernateにも、一覧結果をEntity以外の形（普通のBeanやMap）で取得する方法はあったぞ
JPQL使う必要があったけど
どうしてもSQLで書かなければいけない場合でも、HibernateネイティヴのAPI使えば普通にEntity以外の形で取れていたし
その手法を実際に適用して開発したこともある
312:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/10 21:32:05.66
ほんのちょっと前にJPA推しレスしてるやつ数人いるのに、
具体的な話になったらレス付かないとかwww
314:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/11 21:24:30.49
>>311 >>314
「一覧」という言葉を多用してるけど何のこと？
多数のテーブルをJOINするようなクエリを意味してる？
一覧とは何を指しているのかわからなかったからレスのつけようがなかった。
業務系では使えないという主張もよくわからない
JPAに限らず、ORMはマッピングさえ終えてしまえば使えるでしょう
316:デフォルトの名無しさん
13/03/11 21:52:26.07
JPAが良いって言っている人達は、どんな用途にでもJPA最高って主張しているのか？
JPAで簡単に出来る範囲のことをやる分には、JPA最高っていう主張なのかと思っていたけど。
317:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/11 22:13:39.98
>>316
>>286は「それなりに逃げ口は用意されている」から「大概のシナリオはカバーできる」
と主張してるな。「大概のシナリオ」だ、意味はわかるよな？
319:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/03/12 00:29:13.67
JPA とか吐き出されるSQLが微妙なときがあるから、変なSQL吐いてたら普通のSQLにするとか、速度的に気にしなくて良いならJPAで通すとか。各DBの方言を吸収してくれるのは便利だと思う。
321:デフォルトの名無しさん
13/03/12 01:55:03.35
hibernateから10年以上経ってて
いまだにこんなややこしい議論が必要なら
もうSQL書いたほうが早いってことだろ
322:デフォルトの名無しさん
13/03/12 09:13:52.20
でもこの差は何なんだろうね。
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(www.google.co.jp)
日本ではHibernateを使いにくい特殊事情でもあるのかな。
こんなのも。
URLﾘﾝｸ(www.google.co.jp)
URLﾘﾝｸ(www.google.co.jp)
323:デフォルトの名無しさん
13/03/12 09:42:51.79
俺の考えを述べさせてもらうと
O/Rマッピングだけでも生SQLと速度差がほとんどなくなるか
そもそもオブジェクトをそのまま扱えるDBが一般的になるまで
生SQLのほうがいいと思う。
324:デフォルトの名無しさん
13/03/12 21:47:36.02
>>319
Hibernate3.6以降の話かな
URLﾘﾝｸ(hibernate.onjira.com)
SSHから使ってた連中は別として、今JPA使うとしたらGlassFish(EclipseLink)が多いだろ
「Hibernateならできるし(震え声)」じゃダメなんだよ
あえて標準技術を選ぶ意味がない
俺はJPA(JavaEE)への移行を却下したんで「止めておいた方がいい 」のは最初からわかってる
そんなのよりJPA推し連中からのポジティブな反論を期待してたんだがな
325:デフォルトの名無しさん
13/03/12 23:22:04.17
余談だけど、JPAと言いつつHibernate前提の話をしたり、JAX-RSと言いつつ特定実装系前提の話をするJava EE推称派は、そこんとこキッチリしてくれ。
326:デフォルトの名無しさん
13/03/12 23:34:07.08
MyBatis触ってみたがこれで十分だわ
EJBに組み込む方法も割と簡単だし
327:デフォルトの名無しさん
13/03/13 00:27:43.05
>>325
標準ですむ範囲の要件であれば標準ですませた方がよい、それだけの話では？
328:デフォルトの名無しさん
13/03/13 01:04:42.17
>>327
文盲乙
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マッピングは悪だと思う。