【Java】 Java Web Application Framework 総合

1 ：デフォルトの名無しさん：2012/06/03(日) 16:18:39.74

Java用のWeb Application Frameworkについて語るスレッド

海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド

Web Application Framework　のリスト
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features

2 ：デフォルトの名無しさん：2012/06/03(日) 16:19:16.45

【関連スレッド】
【DI】Java Spring Frameworkを語るスレ 5.0
http://toro.2ch.net/test/read.cgi/tech/1322414231/

△△もっとStruts2の良さを教えてくださいSsssion6
http://toro.2ch.net/test/read.cgi/tech/1217536023/

3 ：デフォルトの名無しさん：2012/06/03(日) 16:28:33.17

【Java】Play framework【Scala】
http://kohada.2ch.net/test/read.cgi/php/1304277057/

Tapestryについて語ろうよ！
http://toro.2ch.net/test/read.cgi/tech/1067531714/

テンプレ以上です

4 ：デフォルトの名無しさん：2012/06/03(日) 21:39:45.16

まぁPlayだけはねーわ
なにしろセッションすら実装されてないんだからな

5 ：デフォルトの名無しさん：2012/06/03(日) 22:40:07.29

FWが発達するとコーディングは不要になる

6 ：デフォルトの名無しさん：2012/06/03(日) 23:42:57.00

今主流なのってSpringMVC Struts2 Grails JSFとかか？

7 ：デフォルトの名無しさん：2012/06/04(月) 01:02:19.92

SAStrutsを使ってるところが多いと思うんだけど。
Struts2なんか使ってるところ見たこと無い。

8 ：デフォルトの名無しさん：2012/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 ：デフォルトの名無しさん：2012/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 ：デフォルトの名無しさん：2012/06/04(月) 05:44:35.39

今も国内はStruts1とかSeasar系なのか

11 ：デフォルトの名無しさん：2012/06/05(火) 17:46:52.50

>>8,9
これいいね。自分の実感に非常に近くて納得してしまう。
JavaとPythonにgoogle app engineがあるともっといいね。

12 ：デフォルトの名無しさん：2012/06/05(火) 20:17:36.46

Struts3開発中らしいね

13 ：デフォルトの名無しさん：2012/06/06(水) 18:52:06.42

>>8
springとjsf/struts2とは比較にならなくね？

[spring-mvc] 5,827

14 ：デフォルトの名無しさん：2012/06/06(水) 19:33:29.63

この手のスレでは何でJerseyやApache CXF、JBoss RESTEasyは名前さえ出てこないんだろう？

15 ：デフォルトの名無しさん：2012/06/06(水) 20:05:02.28

>>14
あり程度メジャーなのは>>1の英語wikiに載っているんでは？

>>13
Springの範囲が広すぎるから、[spring-mvc]に限ったほうがいいってこと？
Spring使ったことないから、その辺は読み替えてくださいな

あと、Stackoverflowで調べたのはこのスレで名前があがっていたやつだけ。
英語wikiの全部やろうと思ったが、なにしろ数が多すぎた。

16 ：デフォルトの名無しさん：2012/06/06(水) 20:19:00.52

JAX-RSは良いけど、現状だとまだ実装系固有の機能や自前での拡張が必要だったり、クライアント用には別のFW(GWTとか)が必要だよね。
JAX-RSにMVC的な機能も含まれてきたら、Spring MVC捨ててJAX-RSオンリーにしても良いんだけどな。

17 ：デフォルトの名無しさん：2012/06/06(水) 21:05:54.31

>>16
テンプレートエンジンとしてJSPやVelocityなどが自由に使えるらしいから、特に困ることも無いんじゃないかと思う

まぁ機会が無くて使えてないんだけど、JAX-RSを知ってしまったらもうStrutsやSpringMVCを使う気にはなれないな

18 ：デフォルトの名無しさん：2012/06/06(水) 21:20:35.88

>> 16
現時点で、使える、と簡単に使える、は別で。

例えばViewableはJersey固有のクラスだし。
jspならモデルと関連づいたタグライブラリをどうするかの話とか。
JSR-339でも、拡張ポイント的とかはまだ不満。

これらの点を考慮すると、ビューまで全てをまかなうには現状ではまだSpring MVCを使っていた方がマシという認識で。
こういった部分まで標準化されて、Jerseyといった固有実装ではなく、JavaEEのJAX-RSとして使えるような未来には期待しているが。
＃JAX-RS 2.xとか？

19 ：デフォルトの名無しさん：2012/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 ：デフォルトの名無しさん：2012/06/07(木) 13:14:14.96

フレームワークより何を作るかに困ってます

21 ：デフォルトの名無しさん：2012/06/08(金) 18:02:58.48

作りたいモノが作れればフレームワークなんてなんでもいいんだよね。楽したいだけ。

22 ：デフォルトの名無しさん：2012/06/16(土) 16:55:38.94

今使えるだけじゃなくて、１０年後も使えそうな載ってないかな。

結局ヲレフレームワーク作って自分で１０年メンテと言う泥沼走るしか無い？
面倒になったら転職じゃ定年まで生き残れないと思うんだよね。

23 ：デフォルトの名無しさん：2012/06/16(土) 17:55:38.20

オレオレフレームワークというかオレオレAPIの蓄積と
自分で会社とサービス作っちゃうって感じかな
転職繰り返すのに疲れて、今は細々と自分が食えるだけの金の一部を
オレオレwebサービスが稼いでくれる。
あとはちっこい案件をボチボチこなす。
贅沢はできないけど、なんといっても精神的に楽。
労働時間はすごく長くなったけど、自分のペースでやれるから苦痛がない。

と、スレチだな、失礼

24 ：デフォルトの名無しさん：2012/07/22(日) 16:34:04.57

JAX-RSって、やっぱりまだまだだなー。
良い感じの所はたくさんあるけど、詰めが甘い。

25 ：デフォルトの名無しさん：2012/08/11(土) 10:21:12.24

結局Struts 1.x系が最強だよね、攻守ともに。

26 ：デフォルトの名無しさん：2012/08/11(土) 10:48:26.41

いや、それだけは無い。

27 ：デフォルトの名無しさん：2012/08/11(土) 11:42:45.68

>>26
何で？
攻：利用実績が多数、開発環境が無償→上層部を説得するのに有利
守：経験者が多く、人員補充が容易。工数見積も安定しており先読みしやすい。
ほら最強

28 ：デフォルトの名無しさん：2012/08/11(土) 13:29:14.91

えっ…。
すまん、マジ意見だったんだな。

なら、特に言うことは無い。

29 ：デフォルトの名無しさん：2012/08/11(土) 17:14:36.39

>>28
ごめん、うちの会社の上司がこんな感じでご迷惑お掛けしております。

30 ：デフォルトの名無しさん：2012/08/11(土) 18:28:17.08

そろそろStruts1.x経験者も少なくなってきていると思う。

・現役の頃に Struts1.x をバリバリ学んできた人
　→スキルが身について、別の言語や、もっといい仕事ができるところに転職している
・最近の若い子
　→Struts 1.x すら知らない
・未だに Struts 1.x の人員補充で候補に挙がる人
　→何年も Struts 1.x しかやらず、スキルアップしてこなかった凡人しか候補リストにあがってこない

31 ：デフォルトの名無しさん：2012/08/12(日) 02:21:50.34

実際のところ今は何がメジャーなん？
SpringはAOP以外の所を使ってるって話は聞かないし
Struts 2.xは空気だし、WicketやTapestryやClickもみないしで
やっぱStruts 1.xかフレームワーク無しが二大巨頭なんじゃないの？

32 ：デフォルトの名無しさん：2012/08/12(日) 04:29:58.10

クラウドに向かうエンタープライズJava
──しかしその前にまずJava EE 6対応を！
http://codezine.jp/article/detail/6659?p=2

これを見ると日本ではいまだにStrutsが主流らしい

33 ：デフォルトの名無しさん：2012/08/12(日) 09:52:13.66

フレームワーク乱立しすぎだから、Java EE だけで開発できるようにしてほしいわ。

34 ：デフォルトの名無しさん：2012/08/12(日) 10:07:57.07

SpringMVCはそこそこ多いんじゃないの？その次でStruts2 かな。おれの周りでは。
5年以上保守が続いている案件で Struts 1.3 をまだいじっているところはあるけど、
新規で Struts 1.3 はもう聞かないな。

JSFはもっと空気だ。あれはうんこだろ。

play framework は、先鋭的な人たちの間には広まってきているだろうけど、
土方ばかりの業務系には降りてこない気がする。

35 ：デフォルトの名無しさん：2012/08/12(日) 15:23:24.47

>>32
「日本オラクルイベントのアンケート結果調べ」でそれじゃ
実際のJava EEのシェアはその半分以下だろ
Java EE 7のクラウド対応も出たときには周回遅れだろうよ

36 ：デフォルトの名無しさん：2012/08/12(日) 19:35:31.03

遊びなら新しいのにもホイホイ手を出すけど、仕事だとやっぱりなあ

37 ：デフォルトの名無しさん：2012/08/12(日) 20:05:58.64

俺の周りではSpringMVCしか聞かないけどな。
Struts 1系は何年も前に新規から消えたし、Struts2やJSFは誰が選択するんだよという感じ。

playとかにも惹かれるけど、細かいところを見ていくとSI屋用途ではちょっとという部分もあり。
結果、別に最高というわけではないけど、モダンな考えも少しずつ取り入れられているSpringという選択になっている感じ。

こういうのは、働いている環境によっても結構違うもんかな？

38 ：デフォルトの名無しさん：2012/08/12(日) 21:04:30.34

昨年開発したシステムで、JDK1.4にtomcat3.2.x、servlet＋JSP
って言う案件やりましたよ。
何でも、現行の顧客社内で動いてるJavaAPサーバ環境がそれしか無いため、
それに限定してるんだとか…。

39 ：デフォルトの名無しさん：2012/08/12(日) 22:10:14.94

Webフレームワークはどうしてるん？

40 ：デフォルトの名無しさん：2012/08/12(日) 22:36:55.99

38だけどフレームワークっぽいものは無かったな。
全部JSPとServletでゴリゴリ書いてましたよ。
オープンソースで使われてるのはCommonsがいくつかくらい。
JDBC APIも直接使ってるっぽかった。
ちなみにここ2～3年内にあった本当の話です。

41 ：デフォルトの名無しさん：2012/08/16(木) 02:39:18.82

フレームワークの中のコードにまで手を入れたいということを聞くことがあるんですけど
そういう必要ってかなりあるものですか

42 ：デフォルトの名無しさん：2012/08/16(木) 02:52:27.66

既存のフレームワークに手を入れる需要は結構ある。
大抵そのフレームワークへの理解不足か、
設計思想にそぐわない事をやろうとしてる場合なので、
きな臭い方向に進み易いけど。

43 ：デフォルトの名無しさん：2012/08/16(木) 03:05:02.33

POHPはなぜ死滅したのか・・・あれ超楽なのに

44 ：デフォルトの名無しさん：2012/08/16(木) 14:30:39.44

ふう

45 ：デフォルトの名無しさん：2012/08/16(木) 15:50:37.25

ふぉおおお

46 ：デフォルトの名無しさん：2012/08/16(木) 18:44:13.97

web上でサーチエンジン？みたいな物を作りたいのですが、java applet などで出きるでしょうか？
amazonとかにある商品を検索するときに、ダイアログで家電なら家電を選んで検索結果出るようなやつを作りたいです。

47 ：デフォルトの名無しさん：2012/08/16(木) 18:49:04.72

なんでAppletなんか知らん（学生さんしか使わない）がスクリーニングはなんででも出来るよ

48 ：デフォルトの名無しさん：2012/08/16(木) 21:00:57.02

>>47
学校のプロジェクトで必要になったので。javaとxml、もしくはjavascriptで作りたいと思っています。

49 ：デフォルトの名無しさん：2012/08/17(金) 18:38:26.77

>31
シェアは知らないが、JBoss Seamとかはどうなんだろう？
>32の分類だとJava EEに入っていそうだが。

50 ：デフォルトの名無しさん：2012/09/10(月) 19:07:31.93

Javaでフレームワーク、Strutsという言葉を聞くがわかりやすくいうとなんでしょうか
Javaについて書かれている本というのはJavaの文法、Servlet,Jspがおおいのですけど
フレームワーク、Strutsについて書かれている本が少ないような気がします。
難しすぎて書く人がいないでしょうか。

51 ：デフォルトの名無しさん：2012/09/10(月) 22:46:28.79

予想
・本を買うよりWebで調べた方が早い
・技術書だとすぐに情報が古くなってしまう
・技術書を書く暇のある技術者がいない

52 ：デフォルトの名無しさん：2012/09/11(火) 18:41:33.81

>>50
多くはWebアプリ開発とか目的に応じて
それ以外の手間を省かせてくれるライブラリ群だ

まず自分で検索していくつか試せばわかる事だからそうしなさい
本が読みたければAmazonで"struts"で検索すれば書籍だってたくさんある

53 ：デフォルトの名無しさん：2012/09/16(日) 10:37:12.62

Java系フレームワークの2トップ？
Struts2とSpring MVC、
それぞれの良いところ、悪いところを教えて下さい

54 ：デフォルトの名無しさん：2012/09/24(月) 14:15:52.72

Struts2は止めた方がいいとおもうよ。外部からOSコマンドが実行できちゃう致命的な
セキュリティホールが２．３．１とかでも多数見つかるぐらいだから
（これと同じようなのを何回か緊急リリースで見たような。。。)

55 ：デフォルトの名無しさん：2012/09/24(月) 20:05:22.20

Play!とか選択する理由あるかな。

56 ：デフォルトの名無しさん：2012/09/25(火) 00:42:40.80

念入りに評価して自信持って結論出したならそんな質問不要
じゃなけりゃそんな質問無駄

57 ：53：2012/09/25(火) 19:12:52.59

>>54
レスありがとう
どこかのサイトにも、Strutsは2.xより1.x利用者が多いと書いてあったけど
移行が終わっていないだけじゃなくて、2.xの出来が悪いってことか。

新規ならSpring MVCのが無難かな
ORACLEが使いやすいFramework作らないからJavaの
Web frameworkは混沌としてるな

>>55
Play!スレに欠点が書いてあったよ

58 ：デフォルトの名無しさん：2012/09/25(火) 19:18:45.87

Apache Wicket 6がリリースされた
http://www.infoq.com/news/2012/09/wicket_6

http://wicket.apache.org/

59 ：デフォルトの名無しさん：2012/09/26(水) 03:28:52.72

>>57
Oracleが使いやすいFrameworkなんか作るわけないだろう
Oracle(旧Sun)は、使いにくい JSF、JPA を推してくるだけだ。

60 ：デフォルトの名無しさん：2012/09/26(水) 05:15:01.95

セミナーでハゲと外人にJSF2.0とJPA2.0は過去のバージョンと違って楽々開発だと洗脳され、金魚本買おうとした俺バカですか

61 ：59：2012/09/26(水) 09:55:47.77

>>60
それって今年5月の JavaUsersGroup CCC とか Java One かな？
おれもいたぞw

JSFはもううんざりだが、JPAは Hibernate とかもあるしいじってみようという気にはなる。
GlassFish は嫌いではない。
(WebLogic、WebSphere は重すぎる)

62 ：デフォルトの名無しさん：2012/09/27(木) 20:34:16.63

禿の煽りを鵜呑みにする情弱はEE使って苦労していれば良いんじゃ無いかな。

63 ：デフォルトの名無しさん：2012/09/27(木) 23:03:42.25

Playスレなんかどこに有んだよ。落ちたのか？

と思ったら、PHP板に有った。

64 ：デフォルトの名無しさん：2012/09/28(金) 01:26:56.63

>>60
過去のバージョンとは違うから！
って力説されても前のバージョンが酷かっただけだからなあ

65 ：デフォルトの名無しさん：2012/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 ：デフォルトの名無しさん：2012/10/03(水) 23:34:58.97

>>61
8月後半にOracle社であったJavaのJSFセミナーだと思う。
まさにハゲとオランダ人（だったと思う）がセッションしていたので。
JSF1.0はありゃ悲劇でしたねとか言って笑いを取ってた。
JSF2は良くなりましたとは言ってたけどさ。

ちなみに俺もその時は乗って金魚本を買おうとした。
結局まだ買ってないけど（笑）。

67 ：デフォルトの名無しさん：2012/10/09(火) 18:51:47.06

Wicket+JDOがいいです。JPA2.0とか未だにインデックスも張れないだろ

68 ：デフォルトの名無しさん：2012/10/09(火) 20:09:31.22

インデックス？選定ポイントそこ！？w

69 ：デフォルトの名無しさん：2012/10/10(水) 02:45:38.49

じゃあJPA否定してどうすんだよ。
S2JDBCとかメソッドチェーンでクエリ書く様なのはJavaの構文じゃ無理。
C#のLINQみたいのが言語仕様で出てくるまではHibernate系のORMしかない。

70 ：デフォルトの名無しさん：2012/10/10(水) 20:32:21.74

Java EE7やJava 8リリースでFrameworkの進化は期待できそう？
これみたけどC#使ってるのでよくわからない
http://www.publickey1.jp/blog/12/javajavascriptnashornopenjdkjavaone_2012.html
http://www.publickey1.jp/blog/12/java_ee_7websocketsjpanosqljavaone_2012.html

>>69
LINQいいね
LINQ + Entity Framework最強
C#のHibernateは設定がめんどくさくて挫折したｗ

71 ：デフォルトの名無しさん：2012/10/14(日) 16:32:52.50

最近のJavaはどんどん進化してるな。

72 ：デフォルトの名無しさん：2012/10/15(月) 13:01:59.73

型推論 var array = new ArrayList<HashMap<String, Integer>>();
プロパティ setter getter
ほしいな。

Servlet API 3.0 とラムダ式で多少変わるぐらいだろう。
もう言語やフレームワークの進化は頭打ちだと思う。

73 ：デフォルトの名無しさん：2012/10/15(月) 19:11:41.68

varな型推論、プロパティ、ラムダ、AST操作、トレイト、パターンマッチング、非同期とか、その変が入った版がリリースされれば、とりあえずは満足してやんよ。

74 ：デフォルトの名無しさん：2012/10/15(月) 19:21:46.96

最近のJavaって進化してるのか？

とりあえず、Xtendで出来るような事を標準でもできるようにしてほしい。

75 ：デフォルトの名無しさん：2012/10/16(火) 10:02:16.75

>>73
でもScalaは結局はやらなかった。

76 ：デフォルトの名無しさん：2012/10/16(火) 10:27:38.54

Sunの時代にJavaは進化が止まっていた。
ORACLEのJavaになって多少は進歩するんじゃないか

propertyは、C#やってる人間なら便利さがわかるが、
Javaの世界では「可読性がおちる」といって反対意見があった。
他のドットの意味と区別がつかないんだとさｗ

C#は開発生産性重視で、柔軟にいろいろと取り入れているが
Javaは厳格すぎるために生産性が悪くなってるな

77 ：デフォルトの名無しさん：2012/10/17(水) 00:56:46.21

>>75
スカラはジャヴァ子の同人誌みたいなもんだからな。
本家が進化することに意味があるのだよ。

78 ：デフォルトの名無しさん：2012/11/09(金) 09:30:12.50

最新Java
Windows8に入れてもおｋ

79 ：デフォルトの名無しさん：2012/11/23(金) 23:04:32.71

SpringMVCだと、まだ日本では使ってるところ少ないのかな？

80 ：デフォルトの名無しさん：2012/12/03(月) 08:30:51.72

この前Javaのセミナーに行ったが、
ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。
前々からStrutsならDisってたけど。

>>79
見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。

81 ：デフォルトの名無しさん：2012/12/03(月) 11:21:09.89

>>80
> ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。

あの人はそれが仕事だから・・・(笑)
聴衆は、それを笑ってあげるのが仕事(話の内容が合っているかどうかに関わらず)
ちなみにおれもその場にいた。

> 見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。

おれの周りでは SpringMVC のほうがかなり多い。Seasar2はだいぶいなくなった。
>>80 さんのレスを否定するわけではないが、日本全体でちゃんとした調査をしないと、そこら辺は何とも言えんのでは。

82 ：デフォルトの名無しさん：2012/12/03(月) 12:53:34.35

俺の周りもSpring MVCが多いよ。
Seasarはもう役目を終えた感じだし。

ついでにJAX-RSは良いねという意見を聞くこともあるけど、Spring MVCの完全置き換えが出来るようになるのはJ2EE8とか9の頃じゃね、とも思う。
あと、良いのはJAX-RSではなくJerseyだろ、っという話もあるけど。

83 ：デフォルトの名無しさん：2012/12/03(月) 13:56:20.03

>>80
寺田氏？ならTomcatは前々からおおっぴらにdisってたな
とはいえGlassfishを運用する勇気はねぇっす

84 ：デフォルトの名無しさん：2012/12/03(月) 13:58:18.68

>>82
Seasarは中の人がJavaからいなくなったしな

85 ：デフォルトの名無しさん：2012/12/03(月) 17:49:10.59

TomcatをdisったりGlassfishをステマするのはまだわかるよ。
でも、開発にJ2EEを使え、っというのは笑うところ。

86 ：デフォルトの名無しさん：2012/12/04(火) 00:55:45.19

>>85
J2EEじゃなくてJavaEEだろ！と笑えって意味？

87 ：80：2012/12/04(火) 01:27:58.76

>>81
自分の周りがそうだってのはあるけど、
やっぱり他の会社が何使ってるかってのは参考になるよ。
Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。

SpringMVCは使ってみたいんだけどなんか昔やった時やたらとっつきが悪かったイメージがあって…。
最近大分あれから使いやすくなってるとは聞いてるんだけどね。
ネットで調べろって言われるんだろうけど、いい解説書があればいいんだけどなー。

・・・もっとも、今やってる仕事デフォのStrutsアプリの改良案件だから
それ以前の問題がうちの会社にはあるけどね。
あんな馬鹿デカいアプリSeasarにせよSpringにせよ移行できないよー(涙）。

88 ：デフォルトの名無しさん：2012/12/04(火) 08:43:26.29

>>85
JavaEEのツールですべてまかなえ、ということだろう

やさしいな、おれ

89 ：デフォルトの名無しさん：2012/12/04(火) 09:03:53.58

ごくごく小規模ならJSF2.1にEJB3.1orCDI、裏はJPA2.0とかで組めなくもないけど…
小規模でやるには仕組みが大げさすぎるし、逆に大規模になると今度は大雑把すぎて扱いにくいんだよなぁ。
足りないところを色々と足して俺俺F/W作って教育するくらいなら、技術者集めやすい他の選択肢を探してしまう

90 ：81：2012/12/04(火) 10:34:09.96

> >>81
> 自分の周りがそうだってのはあるけど、
> やっぱり他の会社が何使ってるかってのは参考になるよ。

あ、それは私もそう思うので、正しいかどうかは置いといて、
「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね
(そういう意味では >>81 の自分のレスは書き方が良くなかった)

ただですらJavaの開発現場は衰退してきているので。

> Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。

たしかにSeasar2は発展性はないだろうけど、安定はしているし、Springよりは簡単で軽くていいと思う。
使い捨てとか、あまり大規模にならない開発だったら選んでもいいと思うけどね。

Springはアノテーション地獄になって読みづらいし、追いかけづらくなった。
XML地獄の方がまだマシだと思う(あとからメンテする側としては、追いかけやすい)

91 ：81：2012/12/04(火) 10:35:30.46

あ、 >>90 は >>87 へのレスです。

あと、誤記：

誤：
「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね

正：
「自分の周りだこうだよ」っていうレスは、うれしいし参考になりますね

92 ：デフォルトの名無しさん：2012/12/04(火) 12:48:08.37

>>89
まさにそれが使われない理由だよな。

>>90
うちもSpringだよ。

アノテーションが追いかけづらいという話をする人はいるけど、自分はそうかな～？、と思う。
アノテーションを使うところってある意味明示的な記述をするところだし。

まあ、依存関係の設計でおかしな事をしていたり、独自のアノテーションとかを使って
アノテーションやAOPではなくFWの拡張ポイントやスコープでの処理で解決すべきところまで
乱用してわかりにくい設計をしていたりとかは見たことあるけど。

そこはあまり優劣を比較するポイントにはならないかな、っというのが自分の感想。

Seasarも、個々のプロダクトではまだまだ良いな、っと思うものも多いんだけど、
色々考慮した結果うちではSpringを全面採用しているよ。

もっとも、Spring最高だと思っているわけでは無くて、消去法で消していくと現時点ではSpringが残るというだけだけど。

93 ：デフォルトの名無しさん：2012/12/04(火) 20:06:05.56

S2JDBCと対するSpringプロダクトって何？
S2JDBCがあるから、なかなかSpringへ踏み切れない。

94 ：デフォルトの名無しさん：2012/12/04(火) 20:53:08.58

>>93
専用のO/Rマッパーはないはず。
親和性の高さだとHibernateが一番だと思う。
あと、有名どころのプロダクトならSpringとつなぐための仕組みが提供されてるからその辺りの選択肢は広いよ。

95 ：デフォルトの名無しさん：2012/12/04(火) 21:13:48.85

>>93
そうそう、SeasarはS2JDBCは良いんだけどね－。

他のFWでデータアクセスする時は、APTでマッピング用のDTOから条件式用のクラスを作ったり、
多少賢いSQLビルダーを自作して、実行とマッピング自体はFW付属やその他データアクセスFWの
エンジンを使うことで、S2JDBCに近いことができるようにしているかな。

逆に言うと、S2JDBCに近いことをやりたいなら、SQLビルダーの自作やメタデータ系クラスの
操作なんかは必須。

96 ：デフォルトの名無しさん：2012/12/05(水) 01:27:48.84

>>93
S2JDBCをSpringで使うってネタは豊富にあったはず
2way SQLがよければDBFlute, Doma, MirageなんかはSeasar2に依存してない

97 ：デフォルトの名無しさん：2012/12/05(水) 20:31:55.99

関連して聞いてよい？
HibernateとかJPAって本当に使われているの？

結局、Criteriaとかこねくりまわしたり、SQLの代わりにxQL使ったりが必要になるので、
それならSQL書く(2way SQL)っていう選択しているところしか見たことないんだけど。

98 ：デフォルトの名無しさん：2012/12/05(水) 20:54:09.65

直近2年で6システムに絡んだけど採用0だったな。
2システムは客の親会社が作ったF/W(JDBCラッパーレベル)、
残りはMyBatis2, DOMA1, S2JDBC1。
客視点で見た時にもSQLはわかりやすいんだろうなぁと思う。

99 ：デフォルトの名無しさん：2012/12/05(水) 22:33:15.22

Hibernateなんかが想定しているオブジェクトモデルと、
Javaが多く利用されているであろう業務システムのデータ設計、クエリパターンは異なるので、
採用が少ないというのもまあ当然なんだろう。

100 ：80：2012/12/05(水) 23:03:29.36

>>97
Hibernateは使ったことがある。まあ悪くない。
JPAは・・・ごめんよくわからない。

仕事は今のところS2JDBCか、
そうでなかったら直にSQL書いてせいぜいCommonDBUtilかます程度。

101 ：デフォルトの名無しさん：2012/12/05(水) 23:43:06.07

仕事で今までSpringもSeasarも使ったことがないんだけど、
最近はSpringが多いのでしょうか

102 ：デフォルトの名無しさん：2012/12/06(木) 06:20:39.96

何が使われるのか？なんてのは F/W 選定できる権限持ってる担当者の
コダワリとか、会社の文化やらでだいぶ変わるんじゃないかな？

ゴールを取れる事が本質だとは思うけど。周りが使っているのは気になるね。
ということで、私の環境も晒しておくよ。自分たちで選定できる案件なら、ここ数年は
Tapestry5系と MyBatis3 が中心。あとは分散時に Spring の Remote を使うかな？
他では類を見ない変態的構成かもしれんｗ

103 ：デフォルトの名無しさん：2012/12/06(木) 07:07:48.52

Struts1.3だけ使ってるけど時代遅れ？

104 ：デフォルトの名無しさん：2012/12/06(木) 09:24:23.71

国内に限定するとStruts1.3もまだまだ現役だと思う。それしか使わないのは珍しいと思うけど。
特に銀行、証券みたいなお堅いところの独自F/Wのベースになってるのも多いね。
日本企業は自社の過去実績にかなりうるさいし、
選定する側も新しいものをなかなか勧めようとしないから仕方ないんじゃないかなー

例えば今のうちの顧客の場合、顧客内の採用事例がないF/Wを選定する際は
通常の見積り資料に加えて顧客指定フォーマットの新技術検討資料なるものが必要で、
検討資料を作ると小規模案件1個分くらいのコストがかかる。
しかもそれでダメと言われたらその案件は失注確定(見積りのやり直しが許されてない)ってリスクがあるからまずやらないわな。

105 ：デフォルトの名無しさん：2012/12/06(木) 10:59:02.32

Hibernate バリバリ使ってるけどなー。複雑な業務ドメインでドメイン指向なら普通じゃない？
SQL 直接書くとか有る程度の規模のプロジェクトだと無いわーって思う。

それはそうと、今 Java で Web アプリって何が良く使われてるのか確かに不思議ですね・・・。
Rails みたいに決め手になるようなものが無いし、わざわざ Java で作らなくても・・・って思う（とはいえ会社では Java を使わざるを得ないところはあるんだけど）。
Project Avatar はいつリリースなんですかね？

106 ：デフォルトの名無しさん：2012/12/06(木) 11:13:53.50

複雑な業務ドメインの場合、パーシステントの実装とモデルはむしろ分離しているからなぁ。
リポジトリを境界にして、その内部はSQL書くでもかまわない感じで。

大規模というか大量になったときにSQLを書きたくないのはそうだけど、
基本的な処理の自動生成なんかはどのFWにもあるし。

業務系といっても、レポートが大半、DB設計もそれを想定みたいな所が多いから、結局SQLというケースになるんじゃないかな。

107 ：デフォルトの名無しさん：2012/12/06(木) 11:24:07.78

個人的にはJSP&Servletが最強

108 ：デフォルトの名無しさん：2012/12/06(木) 13:34:47.17

5年前ならともかく, いま皆さんが Web アプリ作るのにわざわざ Java を使う理由って何ですか？Ruby とか Python で十分な気がするんだけど・・・。

109 ：デフォルトの名無しさん：2012/12/06(木) 14:42:34.80

業務系アプリ作るならやっぱり静的言語のほうが安全なもんで

110 ：デフォルトの名無しさん：2012/12/06(木) 15:28:34.02

>>108
運用側が(彼等にとって)新しいのを入れたがらないから常にJava前提

111 ：デフォルトの名無しさん：2012/12/06(木) 23:21:33.64

>>108
RubyとかPHPならありかもしれんけど、
日本でWebにpythonはないと思うよ。
何故と聞かれたら情報がない。
Java、Ruby、PHPはいろいろ探せばwebアプリ作成のための情報ソースが
その辺にいくらでも転がってるからね。

ちなみにあえてJavaである理由って言えば既存の資産が既にJavaだからだね。
今のの保守と新規の開発を両立するのならぶっちゃけ言語変える必要がないので。
別の環境作んないといけないじゃん。
別にEclipseとか使って開発する分にはそんなPHPとかに比べて開発しにくいとも思わないし。
困った時にはライブラリ探せば結構どうにかなるくらい既存の資産が大量にある。
もちろん慣れてるってのも大きいけど。

それにもいろいろ変えるにはお金がかかるし、なんで今動いてるやり方じゃダメなのって意識が
顧客にあるので意外にOKしてくれないのよ。
>>104さんみたいな事例はいっぱいあるからねえ・・・。

112 ：デフォルトの名無しさん：2012/12/07(金) 00:55:35.11

新規開発は一瞬で終わりだけど、その後の長く続くメンテは
お客さんのシステム部門(子会社が多い)が既存システムと
掛け持ちでやるから、既存システムと同じ技術ベースが
求められるケースが多いな
部分最適(案件毎に最適な技術を選択)の総和が全体最適に
なるとは限らないってやつだわ

113 ：デフォルトの名無しさん：2012/12/07(金) 10:38:55.48

Javaは、いい意味でも悪い意味でも、これからのCOBOL、VB6 になっていくと思う。
先鋭的な技術系の会社、ベンチャーと違い、SIerやヘボいソフトウェア開発会社は、Javaしかできないやつが多すぎるから。
逆に言うとJava要員は集めやすい。

バージョンの下位互換もかなり取られているし。

114 ：108：2012/12/07(金) 11:26:07.76

なるほどやっぱり運用考えるとそうなっちゃうんですねぇ・・・。
今までずっとリッチクライアント作ってたんですが、今度 Web アプリ作ることになったんですがどうやって作ろうか悩み中です・・・。
スクリプト言語使えるなら Ruby で十分かなーって思ってたんですが、色々しがらみがあるんでしょうね。

Web アプリって結局文字列処理になっちゃうので、静的型付け言語であるメリットがかなり薄れちゃうなーという印象があるんですよね・・・。
Play! framework みたいにタイプセーフに HTML テンプレートを書ける仕組みを持つフレームワークとかあれば良いんですが。
このスレを見ていると今 Java で作るなら何が良いんだろうって悩んじゃいますね・・・やっぱり Spring MVC なのかな・・・。

115 ：デフォルトの名無しさん：2012/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 ：デフォルトの名無しさん：2012/12/08(土) 08:51:32.87

MS狂と議論してもしょうがない

117 ：デフォルトの名無しさん：2012/12/08(土) 10:03:33.47

>>113
Javaでビジネスロジック程度のプログラムを書くことしかできない技術者は多い。
フレームワークを自力で設計・構築できる程度のスキルを持つ技術者とか
アプリケーションサーバやJavaVMの内部を熟知している技術者はほとんどいないね。

118 ：デフォルトの名無しさん：2012/12/08(土) 10:17:57.48

アンチMSもちょっとなぁ。
どっちの信者でもなければ>>115の言ってることは正しいもん。

119 ：デフォルトの名無しさん：2012/12/08(土) 10:54:04.22

>>118
俺もJavaよりC#の方が…とは思うが、このスレでそれを言っても荒れるだけだと思うので控えておく。

120 ：デフォルトの名無しさん：2012/12/08(土) 11:07:03.44

>>118
こんにちはMS信者

121 ：デフォルトの名無しさん：2012/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：2012/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 ：デフォルトの名無しさん：2012/12/08(土) 13:50:25.31

BizBrowser とか懐かしいな。8年ほど前にそれ用のリクエスト処理と
JSON 返す Java 製のシンプルな枠組みとクライアント側のライブラリを
セットで書いたことがあるわ。それ以来使ったこと無いけど。

リッチクライアントとかと連携するサーバシステムって、結局 HTML の代わりに
クライアントが欲しいデータとのやり取りができればいいだけだから、
HTTP ベースなりの API を整備すれば大概事足りるよね。

124 ：デフォルトの名無しさん：2012/12/08(土) 21:32:47.36

RIA用途だとJAX-RSとかが使われるようになっていくのかねぇ？
今のところ、拡張ポイントやヴァリデーションとかを考えた場合に、SpringMVCを使った方が良い気がするけど。

125 ：デフォルトの名無しさん：2012/12/08(土) 21:37:10.77

普通にStrutsとJSPで今もシステム作ってるが、
最近Ajax的なの当たり前に要求されるようになったから
JSONか下手すれば直にHTML書いて送って
Jqueryでぼんみたいなことばかりやってるから正直既存機能とのかい離が激しい。
出来るものなら全部作り変えたいがもちろんそんな余力はない。

126 ：デフォルトの名無しさん：2012/12/08(土) 23:37:41.63

バリデーションはむしろ、JavaScript側でやっちゃいたい。
JAX-RSってRESTFulなことやるんだっけ。実装は別？
SpringMVCのコントローラでもアノテーションでRESTFulなこと
できるけど、どっちが軽量なんだろ？

127 ：108：2012/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：2012/12/09(日) 00:36:21.77

あ、レスが別になっちゃった・・・。

>>115
C# で Web 開発ってあんまり聞いたことないですけど（当然だけど）普通にあるんですね。会社的には C# より Java が基本なので採用はちょっと難しいですが・・・。

>>113
なんか色々やってますね・・・。今度のプロジェクトはクライアントが HTML だったり Excel だったりするみたいです。
Excel を使った EUC クライアントみたいな感じの機能を沢山作る必要があるとか。Excel と上手くつなぐ方法があんまり無さそうなんですが・・・。

129 ：デフォルトの名無しさん：2012/12/09(日) 09:46:56.19

Visual StudioでExcelブックなアプリケーション作成ってあんま情報無いよな。
Excelも2013だとWEBSERVICEなんてものもあるけどなｗ

130 ：デフォルトの名無しさん：2012/12/09(日) 09:48:29.53

JAX-RSって、実務経験の足りない優等生、っていうイメージがあるんだよなー。

131 ：113：2012/12/09(日) 15:09:36.86

JAX-RSを使う場合(自分は使ったこともなく、webで斜め読みした程度の知識しかないですが),
どのプロダクトを使うのがいいのかな？
やっぱり Tomcat + Jersey が一番ポピュラーなんだろうか。
あとは Glassfish は標準で JAX-RS に対応しているみたい。
というかJavaEE6 に準拠しているコンテナは標準で対応しているのか。

さっき見つけたページ
JAX-RS(Jersey)を使ってみる - azuki note
http://d.hatena.ne.jp/w650/20110119/1295411262

あと、最近このスレが活気づいていてうれしい。
自分はRailsも好きだしPlay!も気になるけど、なんだかんだでJava歴が一番長いので。

132 ：デフォルトの名無しさん：2012/12/09(日) 18:11:32.73

デファクトはJerseyじゃないの
Glassfishが組み込んでるのもJerseyじゃなかったけ？

JAX-RS、前に採用しようとして評価したんだけどさ。
そのときの感想として思ったのは、結局、実装固有の機能とかを使わないと、
JAX-RSで定義されている仕様だけだとちょっと(´・ω・`)だな～という点。
それはJAX-RS 2.0の仕様を見る限りも微妙な感じで。

まあ、将来には期待しているけどね。

133 ：108：2012/12/10(月) 10:58:04.97

Dropwizard というものを発見しましたがどうでしょう。
これは JAX-RS を使ってるみたいですね。
http://dropwizard.codahale.com/

Jetty を内包していてスタンドアローンで動くようです。

134 ：デフォルトの名無しさん：2012/12/10(月) 15:20:26.80

xsltを使用したフレームワークってないのかな

135 ：113：2012/12/10(月) 15:52:41.00

>>134
大昔から cocoon や Xalan があるではないか
Xala は XML 出連携されてきた内容を HTML に変換して表示、とかやったな。

136 ：デフォルトの名無しさん：2012/12/14(金) 00:38:24.74

xsltとかタグライブラリとか、マークアップ言語大嫌い

137 ：デフォルトの名無しさん：2012/12/15(土) 09:23:47.44

JavaScriptでゴリゴリDOM操作して
CSSでスタイル当てる方が好きだな

138 ：デフォルトの名無しさん：2012/12/15(土) 22:25:08.69

ちょっとでかい会計系のWebアプリ立ち上げる計画があるそうだが、
フレームワーク何にするかなー。
今ならSpringMVCですかねー。個人的にはSeasar2にしたいけど、
これからの大規模プロジェクトで採用するのはつらいかもなあ。
小規模なら遠慮なくSeasar2にするんだけど。
でも上司の思うが儘にやらせてたらStrutsとかになってしまいかねんし
早いうちから口酸っぱく違うフレームワークにしよう運動しとかないと。

JSFとかは・・・うーんよく知らないので判断がつきませんわ。

139 ：113：2012/12/16(日) 01:30:49.93

JSFは、細かいところで身動きが取れないので止めた方がいい。
Strutsは、悪く言えばごりごり書けば、汚くなるけどいくらでも逃げ道はある。

会計系というか業務系だと、顧客のいうことを聞いて実現しようとすると、
かならずフレームワークの流儀に合わない画面制御のところとかが出てくる。

多少汚くなってもいいから、逃げ道があるフレームワークを選んだ方がよい。

140 ：デフォルトの名無しさん：2012/12/16(日) 03:06:02.73

Struts使うなら、v2よりv1だな
Seasar2もいいけど、Tomcat7あたりは大規模でも十分使えるよ

141 ：デフォルトの名無しさん：2012/12/16(日) 08:58:23.46

自分はSeasar2が良いと思っていて、プロジェクトをコントロールできる自信があるならSeasar2で良いんじゃ無いの？
今後の発展に期待が出来ないだけで、悪いものな訳じゃないし。

多少の生産性より柔軟性の方が重要なのは139の言うとおりで、JSFはまず無いし、Springはありで。

142 ：デフォルトの名無しさん：2012/12/16(日) 09:29:56.11

「アーキは予測できないことを予測しろ」って誰かエロい人が言ってたけど、
想定外の状況が生まれた時に一番対処できる自信のあるのを選ぶのがいいかなー。
こと仕事においてはあまり冒険をしないで堅実にやれるのがいいと思う

143 ：デフォルトの名無しさん：2012/12/16(日) 09:35:44.44

だよな。やっぱりStruts1が最高

144 ：138です。：2012/12/16(日) 11:39:49.96

いろいろ意見もらえてうれしいです。
>>139
JSF・・・叩かれてること自体は知ってますが、そんな使いにくいんだ。選択肢から外します。

>>142の意見は確かにその通りだなーと思います。
Struts（もちろん1）もそう考えるとうち開発者Strutsが多いんで考え方的にはありなのかなあ。
Struts2は一回検討してなんじゃこりゃとなったのでもう選択肢にはないですね。

とすると・・・
Seasar2（使いやすい）
Struts1(経験者多し）
Spring(使ったことはあるけど上二つほど自信ないっす、
慣れるといろいろ便利なプロダクトがあるけども・・・）

この3択（今のところ上二つのどっちかにってことになるのかな）。
うちの会社で堅実な選択肢となるとやっぱり上二つのどっちかになりますね。
まだもうちょっと先の話なんでいろいろ相談しながら決めていきます。

145 ：デフォルトの名無しさん：2012/12/17(月) 17:26:53.84

RESThub ってのを見つけた。
http://resthub.org/index.html

146 ：新しいSpringでたぞ：2012/12/20(木) 10:07:25.62

SpringSource Spruce Up Spring MVC as Spring Framework 3.2 Goes GA
http://www.infoq.com/news/2012/12/spring-32

VMware's SpringSource team has released the GA version of Spring Framework 3.2

147 ：デフォルトの名無しさん：2012/12/24(月) 09:08:10.96

Play! は選択支にはいらないですか。

148 ：デフォルトの名無しさん：2012/12/24(月) 10:27:40.04

>>147
昔Play検討したときにDB周りに問題ありそうだったので選択肢から外したことあるけど今どうなんだろうな。
・・・でも今の日本でPlayとかここでの評判劇悪のJavaEE6より敷居が高そうだ。
あえてPlayにする理由がないと思う。

149 ：デフォルトの名無しさん：2012/12/24(月) 12:28:21.18

自分の感覚だと、Play は seaser 使うなら Play（２系）の方がコード量が少なく作れるなあ、という感じ。
DB は RoR な設計を出来るシステムだと ejb とか jpa で綺麗に作れる。
複雑なSQLが必要なシステムだと、Play にする旨味はない。
と思ってます。

150 ：デフォルトの名無しさん：2013/01/23(水) 00:01:00.50

業務系のWeb層ならApache Wicket最強だな！と思うんですが、なかなか賛同されないんですよねぇ。
最近はちょっとした社内向けWebアプリを作るのにGrailsにハマってます。

151 ：デフォルトの名無しさん：2013/01/23(水) 11:14:06.31

>>150
使ったことないんだけど、Wicketがどの辺がいいの？
何々のフレームワークと比べてXXだからいい、と具体的な理由が聞いてみたい。

152 ：デフォルトの名無しさん：2013/01/23(水) 13:31:31.50

他のフレームワークはコード量を減らすおまじないに終始したり、
ホットデプロイとか小さいアプリ向けに特化している。

Wicketは大きなアプリになっても長所を失わない。
Wicketで小さなアプリから大きなアプリまで堅実に作れる。
あと地味にテスト環境が秀逸。

153 ：デフォルトの名無しさん：2013/01/23(水) 13:38:36.55

Wicketの欠点はIDEにスケルトンを自動生成してもらわないと疲れるぐらい
スケルトンコードにあたる定型コードが多いことだな。

HTMLから生成するツールなりプラグインなりあればいいんだが
なぜ誰も作らんのやら。

154 ：デフォルトの名無しさん：2013/01/23(水) 13:40:44.05

Wicket見てるとどことなくASP.NETを思い出す

155 ：デフォルトの名無しさん：2013/01/23(水) 15:03:36.62

ASP.NETはJSFとWicketの中間っぽいような。

156 ：デフォルトの名無しさん：2013/01/23(水) 15:09:40.52

struts3どうなったんだろう

157 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/01/23(水) 17:42:30.19

ASP.NETは前世代思想のSpringMVCやStrutsより勝ると思うが、
新世代系FWは学習コストが高いから、実際には苦労する。

159 ：デフォルトの名無しさん：2013/01/23(水) 17:45:50.00

ASP.NET MVCは使ったこと無いけど、ASP.NET WebFormは、
昔のVBライクにポトペタで作れたりするので結構楽ですよ。
作法に則ったアプリ作る分にはStrutsとかより全然楽かと。

Wicketも同様(?)に、html+javaでコードが散逸しないし可読性高いのが良い。
ボタン押下時のイベントは～みたいな書き方で作れる。
欠点も裏返しで、ボタン押下時のイベントに1000行くらいの業務処理を書いたりするような
プログラマに使わせたときに手に負えなくなったりする。

160 ：157：2013/01/23(水) 18:38:58.51

>>158-159
レスどうもありがとうございます。
いままでJavaがほとんどで(Railsは多少経験があるが)、
そもそも web開発だろうがデスクトップアプリ開発だろうが、.NET による開発が初めてなんだけど、
がんばってみようと思います。

JavaとC#の両方に精通している同僚が、ASP.NET MVC + Entity Framework はおもしろいよって言ってた。

ひまなときに wicket やってみるか。

161 ：デフォルトの名無しさん：2013/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：2013/01/24(木) 08:00:23.06

>>161
レスどうもありがとうございます。とても参考になります。
今度行くかもしれないチームは、すでにWebForm ですでにつくっていて、
これから ASP.NET MVC に作り替えるって言ってました。
(自分がどこから作業するのかはわからない)

>ASP.NET MVC + Entity Frameworkがいいっていう同僚の意見には同意する。

いまは喰らうどの人になってしまったが、以前、Seasarプロジェクトのshotタソも、勉強会で同じことも言っていた。

163 ：デフォルトの名無しさん：2013/01/24(木) 10:20:17.98

なぜかDBがOracleでEntityFrameworkが使えないというオチに100000ペリカ

164 ：デフォルトの名無しさん：2013/01/24(木) 10:29:03.20

>>163
Microsoftが作った、というだけでそういう誤解を受けるんだよな

Entity FrameworkはMySQLでもPostgreSQLでも
ORACLEでもSQLiteでも使える。
SQL Server限定のORMではない。

今はEFは、Linuxの.net(Mono)上でも動く。

しかもオープンソース
http://entityframework.codeplex.com/

ASP.net (asp.net MVC含む)もオープンソースになっていて、Linux上で動く

165 ：デフォルトの名無しさん：2013/01/24(木) 10:37:28.47

ん？今は使えるようになったのか？
誤解というか普通にOracleが対応してなかったはずなんだがな。MSじゃなくOracleのODP.NETが対応してない。
ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。

166 ：デフォルトの名無しさん：2013/01/24(木) 10:37:38.11

ASP.net のオープンソースのリポジトリって、 http://aspnetwebstack.codeplex.com/ かな。
codeplex って MS がやっているオープンソースのサイトだよね。

167 ：デフォルトの名無しさん：2013/01/24(木) 10:52:40.24

>>165
EF側ではなくORACLE側が対応してなかったって話？
ぐぐったらすぐ出てきたけど
http://www.infoq.com/news/2012/01/oracle-ef
http://www.oracle.com/technetwork/jp/topics/dotnet/downloads/oracleefbeta-302521-ja.html

MySQLは最新のConnector/netでEF4.3対応した、とリリースされていた。

168 ：デフォルトの名無しさん：2013/01/24(木) 11:03:06.80

>>167
> ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。
> EF5

http://www.infoq.com/news/2012/01/oracle-ef
> support for Entity Framework 4.1 and 4.2.

169 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/01/24(木) 13:59:36.96

JPAとかS2JDBCとかあるし、今更XML地獄は古いよ。
だけどアノテーションやメソッドチェインも万能じゃない。

LINQがあるだけC#の方が短くかけるだろうけど、思想面では同じようなもん。

171 ：デフォルトの名無しさん：2013/01/24(木) 14:26:01.47

用途は限られるがslim3ならメタクラス使ってTypeSafeなORM実現できるよ
（GAEのDatastoreのみ）

172 ：デフォルトの名無しさん：2013/01/24(木) 19:52:13.04

APTで作ったメタクラスを使うのと式木では、式木の方が表現力や柔軟性はある気がする。

あと、ちょっとしたものならEFで良いかもしれないけど、用途によってはMicro-ORMとかを使うし。

そういえばサイボウズの社内システムで、Oracleの商用プロバイダを使っているとかいう話もあったね。
ttp://developer.cybozu.co.jp/tech/?p=2071

173 ：デフォルトの名無しさん：2013/01/26(土) 17:24:41.22

JAX-RS 人気ないですねぇ。

Jersey がデファクトなのかなと思いつつ、ドキュメントのしょぼさを見るとつい RESTEasy の方が良いんじゃないかと思ってしまう・・・。

174 ：デフォルトの名無しさん：2013/01/26(土) 19:41:28.01

人気ないか？
他のFWに比べれば評価は高い気がするけど。

ただ、本当の実用を考えるなら、現状の各種実装系固有の良いとこどりしたレベルのものが出ないと厳しい気がするけど。

175 ：デフォルトの名無しさん：2013/01/26(土) 22:38:07.97

評価は高いけど実用してる人が少ないなーという印象。
自社運用の Web サービスとかで使ってるところはあるみたいだけど、エンタープライズでは使ってるって聞いたことない。
正直表面的なところだけ見ると他の FW より断然良いなと思うんだけど、やっぱり機能面で何か不足があるんですかねぇ。
それとも経験値の問題で、わざわざ他から移るほどの価値を見出せていないだけなのかどっちなんだろう？
エンタープライズ向けの Web アプリを JAX-RS + Backbone.js とかで作るのはやっぱり危険ですかね？

176 ：デフォルトの名無しさん：2013/01/27(日) 14:14:22.26

JAX-RSは2.0出てからかなぁという印象、いつになるか知らんが

177 ：デフォルトの名無しさん：2013/01/27(日) 15:24:47.38

JAX-RSってSpring MVCに比べてメリットってあるの？

煽るわけじゃないんだけど、アノテーション使った書き方はそう違わないし、
実用度の点からは細かいところにまで手が届いているSpring MVCで良い気がするんだけど。

178 ：デフォルトの名無しさん：2013/01/27(日) 18:00:33.00

Spring MVC って思いっきり Framework って感じで重すぎる印象があってあんまり好きじゃないなー。

まぁそれはともかく Spring MVC は REST 対応が後付け感じがあるんですがどうなんでしょう？
RESTful なサービスを作りたい場合は JAX-RS の方に優位性があるのではと思ったりするんだけど。
例えばサブリソースの表現とかは Spring MVC だとベタに書かないといけない気がする（調べたわけではないけど）。

179 ：169：2013/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年の記事だけど。
http://news.mynavi.jp/special/2006/jpa/index.html

Javaで使用率高いORMは、JPAとTopLink Essentialsの組み合わせかな？
両方オラクル純正だし

Web Framework(for Java)の海外トップシェアはSpring MVCみたいだ。
ソースは俺の検索結果（主に海外サイト）

180 ：デフォルトの名無しさん：2013/01/27(日) 18:21:36.77

つ ttp://www.infoq.com/articles/springmvc_jsx-rs

181 ：デフォルトの名無しさん：2013/01/27(日) 21:55:42.86

>>180

読んでみたけど全体的に JAX-RS の方が美しく感じる。
・レスポンス
・Conneg
・例外ハンドリング
あたりは JAX-RS の方が良いと思った。けど実用性は多分 Spring MVC なんだろうな・・・。
各 JAX-RS 実装の拡張が色々あるから実際にアプリつくるときにあまり困ることはそんなに無いと思うんだけど、やってみないと分からないなー。
でもまぁ flush スコープとか validation とかあるからやっぱり Spring MVC なのかな・・・。

182 ：デフォルトの名無しさん：2013/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
http://toro.2ch.net/test/read.cgi/tech/1220671877/

その昔は、Javaの各ORマッパーについての議論が活発で、
とても勉強になるスレだったのですが、ここ数年は
全然関係ないアニメのコピペが貼られるだけになってしまいました。
残念です(まぁJavaのORマッパーの話題は、一通り行き着くところまで行ってしまったのかもしれないが)

183 ：デフォルトの名無しさん：2013/01/28(月) 02:41:01.19

>>179
もう少しだけ補足。ご存じだったらすみません。

> JavaのORM = Hibernate = XMLマッピング地獄だと思ってた。

初期のHibernateは、そのとおりXMLマッピング地獄だったけど、
Hibernate Annotations というのができて、Enittyクラスにアノテーションでカラム名とか付けられるようになった
(XMLに書かなくても良くなった)

さらに Hibernate EntityManager というのができて、Hibernate が JPA をサポートするようになった。

184 ：>>20：2013/01/28(月) 21:39:34.15

かなり古いバージョンの記事が検索の上位にかかりやすいよね。
ちなみにJPAと同じ要領でXMLをマッピングするJAXBなんてのもあるぞ。

185 ：デフォルトの名無しさん：2013/01/31(木) 14:25:30.71

http://www.infoq.com/news/2013/01/spring4
Plans for Spring Framework 4.0 Announced
- Includes Support for Java SE 8 and Groovy 2

186 ：デフォルトの名無しさん：2013/02/02(土) 17:40:16.89

もうダメだわｗ

Twitterサイバーテロ事件の原因は話題のJavaの脆弱性ｗｗｗｗｗ今すぐアンインストールしろｗｗｗｗｗ
http://engawa.2ch.net/test/read.cgi/poverty/1359787786/

187 ：デフォルトの名無しさん：2013/02/02(土) 22:30:37.53

昔Jerseyを使ったときにJAXBでアノテーションつけたbeanをJSONにシリアライズして
レスポンスとして返す場合に、プロパティに配列やコレクションがあるとその要素数に
よってそのプロパティのシリアライズの結果がArrayになったり裸単騎の値になったりして
頭を抱えたのだけれども今は大丈夫なんだろうか。

188 ：デフォルトの名無しさん：2013/02/02(土) 23:13:34.40

XML地獄の次はアノテーション地獄か
昔のJavaが一番作りやすかったな
いまは新入社員が入ってくる余地がないな

189 ：デフォルトの名無しさん：2013/02/03(日) 17:15:48.97

裸単騎ｗ

190 ：デフォルトの名無しさん：2013/02/06(水) 14:28:49.36

>>187
MessageBodyWriter使ってjsonicあたりに処理させればいいんじゃないの

191 ：デフォルトの名無しさん：2013/02/07(木) 00:34:05.94

アノテーションが増えてソースコードがXMLみたいになるな。
言語やＦＷを変化させても冗長性と簡略化のトレードオフになるだけで
優れたものに前進しないな。

192 ：デフォルトの名無しさん：2013/02/07(木) 13:38:09.81

そこで設定より規約ですよ

193 ：デフォルトの名無しさん：2013/02/07(木) 13:43:15.61

rubyやphpのほうが作りやすいということ
Javaは方向性間違ったな

194 ：デフォルトの名無しさん：2013/02/07(木) 14:48:22.64

COCはフレームワークの話だろ。
Playとかあるじゃん。

ArrayList, HashMapは構文に組み込んで欲しい。
あとアノテーションプロセッサを使いやすくできれば
COC方面で著しい変化がある。

var array = new Integer[];
var hash = new [String, Integer];

195 ：デフォルトの名無しさん：2013/02/07(木) 16:37:04.64

JAXBやJPAのアノテーションの話であれば十分にCoCしていると思うけれどもね。
普通のBenasであれば冒頭にただ@Entityとか@XMLRootElementとか書いておけばあとは何も
せずとも規約に従って大体よろしくマッピングしてくれる。

ただ規約に外れて手作りししたい部分が出てくるとその程度によってアノテーションだとかえって
見通しが悪くなることがあるのも事実。

196 ：デフォルトの名無しさん：2013/02/07(木) 20:26:49.56

「規約と完全一致ならBeanクラス自体がなくてもいい。」
アノテーションプロセッサでここまでできればRailsに勝てるだろう。

IDEにスケルトンプログラムのジェネレータプラグイン入れて
クラスファイルの山を作ってるのが現状。

今度はコンパイルが重くて仕方ないか。

197 ：デフォルトの名無しさん：2013/02/08(金) 01:48:59.44

Rails(というかActiveRecord)の便利なところは、
モデルクラスにメソッドを定義してなくても、呼び出し側が適当なメソッド名を
呼んでしまえば、Method Missing により、規約に沿って自動的に解釈されてSQLを実行してくれるところだと思う。

コンパイル言語でのJavaでは、これは絶対に無理。
S2Daoなど、Interfaceだけ定義すれば proxy オブジェクトを作ってくれるフレームワークはいくつかあるけど、
かならず Interface にメソッドだけは定義しないと行けないし。

198 ：デフォルトの名無しさん：2013/02/08(金) 02:18:23.89

本当に無理なんかなあ。Javaって回り道ばかりしてるじゃん
生活費1000万くれて1年それだけに集中していいって言われたら
開発者みんなが楽できる最強のフレームワーク作れる自信あるわ

199 ：デフォルトの名無しさん：2013/02/08(金) 05:10:55.98

最強のフレームワークなら１０００万円以上で売れるんじゃね？

200 ：デフォルトの名無しさん：2013/02/08(金) 07:11:01.57

Beans無しでしかも型安全なフレームワークが実現可能ならまだ存在意義もあるだろうけれども
Beans無しというだけでは全く流行らないだろうね。

201 ：デフォルトの名無しさん：2013/02/08(金) 14:27:57.43

>>198
コンセプトだけプレゼンしてみ？
よさげならうちの職場に紹介するよ
1年1千万なら余裕で出せるはず

202 ：デフォルトの名無しさん：2013/02/08(金) 15:22:57.86

Beans無しがそんなに嬉しいかねぇ。

203 ：デフォルトの名無しさん：2013/02/08(金) 16:00:08.22

>>200 >>202
Beansってなんのこと？
Entityクラスを作るってこと？
(SpringMVCにおける、Form の Modelクラスでもいいけど)

204 ：デフォルトの名無しさん：2013/02/08(金) 16:19:47.38

そういうことじゃね?
厳密にはEntityクラスは作るにしても、ActiveRecordだけ継承すればあとはフィールドや
アクセサの類を定義しない空のクラスのままでもよろしく動くということだと思う。

205 ：198です。：2013/02/08(金) 21:19:31.37

[email protected]
メール下さい。

206 ：198：2013/02/08(金) 23:00:45.38

早くメール下さい。

207 ：デフォルトの名無しさん：2013/02/08(金) 23:38:25.89

１０００万の仕事を捨てメアドで募集してるときいて

208 ：196：2013/02/09(土) 01:13:47.47

アノテーションプロセッサができるのはコンパイル時クラスの自動生成だよ。
Javassistとかは実行時生成だからインターフェースとか必要になるけど、
アノテーションプロセッサだとソース上では全く定義されていないクラスを
new HelloBean();とかしても型安全に操作できる。

今のアノテーションプロセッサでＦＷはかなり作りづらいし、見向きもされていない。

209 ：デフォルトの名無しさん：2013/02/09(土) 02:08:32.22

>>208
型安全… だと？
HelloBeanじゃなくHalloBeanと書いた場合にどうやって間違いを見つけるんだ？w

210 ：デフォルトの名無しさん：2013/02/09(土) 03:06:41.17

コンパイル時にターゲットのDBに接続してスキーマ引っ張ってくる必要があるな。

211 ：デフォルトの名無しさん：2013/02/09(土) 03:13:38.12

アノテーションプロセッサを使うというのは、(webフレームワークではなくORMだけど)Domaも似たようなものかな。

Interfaceクラスだけつくって、アノテーションプロセッサを一度実行しないといけないけど、Entityクラスが自動生成されるのはいいかも。
でも、それって Excel などでつくったプロジェクト内自動生成ツールを事前に実行するのと、手間的には変わらない気もする。

212 ：デフォルトの名無しさん：2013/02/09(土) 03:23:31.64

DBから生成できるEntityのプロパティはアノテーションプロセッサで作る必要ないな
>>197が言ってるのはSQL生成するメソッドだから、O/Rマッピングパターンだと
存在しないDAOを呼び出すとアノテーションプロセッサが作ってくれるイメージだろ

213 ：デフォルトの名無しさん：2013/02/09(土) 09:38:16.20

自動生成してくれるのは結構なんだがきっちりドメインオブジェクトを書き起こさずに
メソッドの自動生成に任せていて開発規模的にどの程度スケールするのかは気になる。

214 ：196：2013/02/09(土) 12:41:01.52

railsみたいにcocでもりもり削ろうぜって話だったはず

215 ：デフォルトの名無しさん：2013/02/09(土) 16:45:23.43

マイグレーションや関連、検証を書き始めるとあまり変わらん気もする。
JPA等を使うにしても結局面倒なのはそこで、Beansの定義自体は機械的作業でIDE使えば
面倒でも何でもないし、むしろBeansが無かったり動的生成されるほうが静的検証もやり
にくいしむしろ色々面倒臭い。

216 ：デフォルトの名無しさん：2013/02/09(土) 17:55:05.13

Eclipseが標準でSQLJを手厚くサポートしていればいろいろ違ったかもな

217 ：デフォルトの名無しさん：2013/02/09(土) 22:10:06.33

ORMの話だしSQLJ等の埋め込みクエリはあまり関係ないかなぁ。でもJPQLは好き。

ORMを使っていても集約計算などするときは変にエンティティオブジェクトや
フレームワークが提供する無駄に独自性溢れるクエリーAPIと格闘するよりSQL一本
書いた方が速いよね、という場面はそこそこあるし、そういった場合にはJPQLは
DBMSの方言を気にせずハードコード出来てかつどんなSQLが吐かれるか大体見当が
つくので個人的には時々便利に使う。

218 ：デフォルトの名無しさん：2013/02/09(土) 22:37:44.53

ORMったってマッピングの部分はほぼ完成していて問題にならない。
問題なのは相変わらずクエリを作るところだろ。
JPQLもクライテリアAPIもそこじゃん。
そこの標準が早期(JDK1.1)からあったんだからIDEがしっかりサポートしていれば
もっといろいろな発展があったと思うね。
OracleのSQL Developer使ったことあればわかるだろうけど、エディタ上でSQL書くと
その場で文法に加えて名前や型までチェックされて、即実行して結果も見える。
あれがJavaとシームレスにつながって関係するDAOやJavaBeansが自動生成されれば
相当便利なものになったんじゃないか。少なくとも、その基礎にはなり得たんじゃないか。

219 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/02/09(土) 23:14:58.74

っていうか、こういう話を↓のスレで続けたかったな。
最初の頃はとても勉強になるスレだったのに、いまは変なアニメの人が居着いちゃってとても残念。

Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
http://toro.2ch.net/test/read.cgi/tech/1220671877/

221 ：デフォルトの名無しさん：2013/02/09(土) 23:26:28.54

そのスレまだ蹂躙されてたのかw

222 ：デフォルトの名無しさん：2013/02/11(月) 17:04:04.35

アニメの話はアニメ板でやった方が
反応もあって楽しいだろうに何であそこなんだろうな。

223 ：デフォルトの名無しさん：2013/03/02(土) 14:27:18.78

アニメ好きのJavaでDB開発担当してたやつが
仕事で下手こいてクビになったとか、メンタル壊して鬱病ヒキコモリに
なってしまったとか、哀れな末路に驀進中なんじゃね？
別スレ立ててもいいかもね。
そういえば、そのスレの１スレ目立てたの俺だった。。

最近、鯖側でスクリプト環境使うことが増えてきて、今までは
スクリプトは遅いとかバカにしてたけど、即時修正とか
運用のしやすさとかを感じて見直している。
Javaにもこういう扱いやすさが欲しいな。。。
ホットデプロイ使えばいいのか。

224 ：デフォルトの名無しさん：2013/03/02(土) 18:21:24.23

>>223
おお、あなたが Java⇔RDBのMapping-Frameworkを語るｽﾚ vol.1 スレを立てたのか。
乙です。

> 最近、鯖側でスクリプト環境使うことが増えてきて、今までは
> スクリプトは遅いとかバカにしてたけど、即時修正とか
> 運用のしやすさとかを感じて見直している。

今は何を使っているの?
JavaじゃなくてRailsとかPHPとか?

225 ：デフォルトの名無しさん：2013/03/02(土) 18:50:32.40

ポール・グレハム
http://ja.wikipedia.org/wiki/%E3%83%9D%E3%83%BC%E3%83%AB%E3%83%BB%E3%82%B0%E3%83%AC%E3%82%A2%E3%83%A0
は lisp でフレームワークを書いていたというのだから、それもいいかもしれない

226 ：デフォルトの名無しさん：2013/03/04(月) 19:46:02.90

Eclipse統合M34【Java/C++/Ruby/Python/Scala】
http://toro.2ch.net/test/read.cgi/tech/1361510049/103-106n

↑のスレに質問したところ、こちらのスレが適切ということで、
こちらで質問させて頂きたいです

どなたかよろしくお願い致します

227 ：デフォルトの名無しさん：2013/03/04(月) 22:52:15.49

Javaの入門書を卒業して、サーブレット、JSP、jdbcでのDB操作もできるようになりました。
Webフレームワークを使って、勉強用に簡素なショッピングサイトでも作ってみようかと思ってるのですが、
いま、初めてやるとしたら、どのフレームワークを使うのがいいでしょうか。

228 ：デフォルトの名無しさん：2013/03/04(月) 23:58:37.09

play framework 2.1 がいいと思う

229 ：デフォルトの名無しさん：2013/03/05(火) 04:23:08.94

Grails

230 ：デフォルトの名無しさん：2013/03/06(水) 20:31:46.32

フレームワークなんかなくても、
サーブレットとJSPで作るのが一番正解だよ

231 ：デフォルトの名無しさん：2013/03/06(水) 20:49:59.21

一番迷惑。

規模が大きくなると結局オレオレフレームワークの類を作り始めるので、そうなる前に
ちゃんとしたフレームワークを使って欲しい。

232 ：デフォルトの名無しさん：2013/03/06(水) 21:15:41.74

>>231
ちゃんとしたフレームワークないじゃん
ちょっと特殊なことしようとするとクソハマり
だから>>230が正解
もしくはJavaを捨てる

233 ：デフォルトの名無しさん：2013/03/06(水) 21:27:58.57

>>232
とくしゅなことってどんなw

234 ：デフォルトの名無しさん：2013/03/06(水) 21:35:06.25

それは本当に特殊なのか？
本当に特殊だとして、それは本当に必要なのか？
本当に必要だとして、それは本当に特殊なことをしないと実現できないのか？

235 ：デフォルトの名無しさん：2013/03/06(水) 21:43:27.90

ハマる回数が多すぎていちいち覚えてないよ
フレームワークのサンプルまんまで業務が回るならいいけどそうじゃないだろ

236 ：デフォルトの名無しさん：2013/03/06(水) 21:47:18.97

世の中にあるフレームワークは全てオレオレだからな。
いくつかのシステムと他の言語も経験すれば、「ぼくのかんがえたさいきょうのフレームワーク」を作る能力もつく。
結局それが一番正解に近いのさ。
車輪の再発明こそがプログラマーの醍醐味。
もちろん今あるフレームワークの長所短所も研究するべきだけどね。

237 ：デフォルトの名無しさん：2013/03/06(水) 22:09:52.61

>>229
デモ見るとGrailsはかんたんに扱えそうな感じだね
http://grails.org/learn

JavaじゃなくてGroovyになってるから性能が心配なところだけど
実行前にはすべてJavaのバイトコードに事前コンパイルされるのかな？

>>230
ゴリゴリJSPでやるのは生産性が悪いと思う

>>232
例えば今まで何のフレームワークを試したの？

238 ：デフォルトの名無しさん：2013/03/06(水) 22:24:12.80

単にフレームワークを使うだけの力もなかったんだろ

239 ：デフォルトの名無しさん：2013/03/06(水) 22:29:33.88

サンプルからちょっと外れるとクソハマリなんてフレームワークの流儀や
コンセプトを知らずに使ってる証

240 ：デフォルトの名無しさん：2013/03/06(水) 22:53:35.30

フレームワークってその流儀やコンセプトの押し付けがましいのが嫌。

241 ：デフォルトの名無しさん：2013/03/06(水) 22:57:37.87

>>238
力がないと使えないならいらない
servletやjspなら力なんて一切必要ないぞ

242 ：デフォルトの名無しさん：2013/03/06(水) 23:21:15.89

３次元配列が扱えるフレームワーク無いもんなー
使えないよな

243 ：デフォルトの名無しさん：2013/03/06(水) 23:28:15.29

>>241
効率よく作るにはむしろ相当な力が必要じゃね？
それこそ小さな画面一つ作って終わりじゃないだろ

244 ：デフォルトの名無しさん：2013/03/06(水) 23:31:37.49

>>243
そりゃライブラリの類はたくさん必要だよ
でも外から自由を奪いにくるフレームワークは不要

245 ：デフォルトの名無しさん：2013/03/06(水) 23:32:09.71

力ないやつが生servlet/jspで作ったらメンテ不可能なものしかできなそう

246 ：デフォルトの名無しさん：2013/03/07(木) 00:25:47.22

>>244
規模が大きくなってくるとそのうちそのライブラリの中にフレームワークが入ってくるんじゃないのかw

247 ：デフォルトの名無しさん：2013/03/07(木) 00:32:52.10

>>246
入らないよ。ライブラリは実装から呼び出される側、
フレームワークは実装を呼び出す側、役割が全然違う

248 ：デフォルトの名無しさん：2013/03/07(木) 00:42:19.97

匿名で使えるgistでもあればそのライブラリ使ったコード貼ってみろよで終わりなんだけどな
お互い相手を下に見てるどうしが1、2行の文章だけでやりあっても不毛

249 ：デフォルトの名無しさん：2013/03/07(木) 06:14:07.70

>>236
誰も「さいきょうフレームワーク」の醍醐味なんか求めていない。趣味かよ。

オレオレにせよ商用にせよOSSにせよ、今すぐに使えてどれだけ継続的にアップデートが
続くかが問題。

どこかの天才が気まぐれで作ったさいきょうフレームワークよりも沢山のユーザに使われて
ある程度の期間バグを叩かれまくっているそこそこのフレームワークを使うね自分は。

250 ：デフォルトの名無しさん：2013/03/07(木) 08:43:31.29

画面が多いだけの大規模システム（いわゆる業務系）なら
フレームワークも有効だろうねぇ

251 ：デフォルトの名無しさん：2013/03/07(木) 15:56:03.63

「画面が多いだけ」ってよくわからん。
画面が多い「から」、フロントエンドの規模が大きいからウェブアプリのフレームワークを
使うのであって、その後ろに画面の多さ以外の何があろうが別問題だと思うのだが。
上から下まで全部一つのフレームワークで作ることしか頭にないのか。

252 ：デフォルトの名無しさん：2013/03/07(木) 16:10:25.88

でもおまいらの言ってるのは何が何でもフレームワークなんだろ？
とにかくまずフレームワークを使うことが第一であとは
どうでもいいって感じ。

253 ：デフォルトの名無しさん：2013/03/07(木) 16:20:28.86

じゃなくて、Java使ってWAF使って開発すると決めた後の話題が主なのがこのスレ
違う決断した後の話は別スレでする

254 ：デフォルトの名無しさん：2013/03/07(木) 16:24:17.70

JavaとWAF使うってことは型にはめやすい、型にはめるメリットがある(似た画面多い、人が多い)案件って事
そうじゃないこともあるが、それをここで話す意味がわからない

255 ：デフォルトの名無しさん：2013/03/07(木) 16:36:01.22

>>254の「そうじゃないこと」は「そうじゃない案件」です

256 ：デフォルトの名無しさん：2013/03/07(木) 16:43:44.27

>>237
Grailsは実質Spring MVCで、その上に動的言語と名前ベースのCoCの薄皮をかぶせた物だから。
なのでドメインクラスとかサービス層など内側の大事なところはJavaでカッチリ型安全に書いて
おいて、それをGrailsアプリの上にデプロイするのは案外自然に出来る。
そうしておけば重さが気になるのはVCのウェブ層だけの部分になるけれども、ここは開発も実行
も重いよw GroovyもJSPのGroovy版であるGSPも事前コンパイルされるけれども、Groovy
自体が遅い。ただ生産性は高いと思う。GroovyやRubyの経験があればVCは本当に書きやすい。

意外にはまったのが依存性の解決かな。Mavenでなくてivyベースで、Mavenリポジトリから
依存性を引っぱってくることも出来るのだけれども、Mavenとは微妙に振る舞いが違うことも
あってMavenベースのプロジェクトと連携するさいに妙にはまったことがある。
Maven統合プラグインもあるのだけれども評価時にはイマイチで以後使っていない。

257 ：デフォルトの名無しさん：2013/03/07(木) 18:23:53.38

>>256
Grailsって、ORMはHibernateを同梱しているんだよね？
Hibernateあまり使いたくないんだよなぁ。
MyBatisなどに差し替えられないの？

258 ：デフォルトの名無しさん：2013/03/07(木) 18:36:40.23

>>257
Mを構成するGORMというORマッパーはJPAどころかがっつりHibernateに依存しているので
無理っぽい。WAR等からHibernateだけ切り離すのも無理じゃないのかな。
ただ別のORMで書かれたMをVCから叩くのは普通に出来ると思う。たぶん。

259 ：デフォルトの名無しさん：2013/03/07(木) 18:39:36.67

>>256
ありがとう。
CoCが魅力的だったけど、速度も重視したいからSpring MVCも見てみる。
GrailsはJavaでも書けるようになってほしいな

260 ：デフォルトの名無しさん：2013/03/07(木) 18:46:34.27

やっぱり不自由が発生してるじゃん
Aだけを使いたいのに使いたくないBまで使わなきゃいけないとかw
技術力が普通にあるのなら使う必要ないんだよ

261 ：デフォルトの名無しさん：2013/03/07(木) 18:57:29.88

>>260
ORMは好きなの使えるっていうフレームワークもある。

JPA使えるやつなら大半の人は文句ないんじゃないの
JPAデファクトスタンダードだろうし

262 ：デフォルトの名無しさん：2013/03/07(木) 19:04:53.41

JPAｗ

263 ：デフォルトの名無しさん：2013/03/07(木) 19:05:31.48

デファクトｗｗ

264 ：デフォルトの名無しさん：2013/03/07(木) 19:16:01.10

なに草はやしてるんだ？
JPAはJavaでは一番メジャーなORMだろう

265 ：デフォルトの名無しさん：2013/03/07(木) 22:06:26.45

>>260
フレームワークの実装が特定のライブラリにがっつり依存しているか交換可能なように
設計されているかの違いだろうなぁ。
そしてそれはフレームワークの開発の速さや使い勝手とのトレードオフでもある。

GrailsはHibernate似のcriteriaも提供していたりとHibernate以外に交換するのは
しんどそう。

266 ：デフォルトの名無しさん：2013/03/08(金) 02:05:35.35

>>260
「やっぱり」って、不自由が発生するのを否定してるやついたか？
制約する・型にはめることによるメリットが不自由というデメリットより大きいってだけだろ

267 ：デフォルトの名無しさん：2013/03/08(金) 02:16:55.15

「特殊なこと」ってのが曖昧だから話にならんのだよな
ビューに関してはJSP使ってるフレームワークだったら不自由もないだろ
コントローラにしたって所詮HTTPの範疇じゃたいして特殊なことなんかできんだろ？

268 ：デフォルトの名無しさん：2013/03/08(金) 07:21:32.53

listの中にlistが入ってて、さらにlistが入ってるような
データが受け渡しできないから糞
そんなフレームワークばっかり。フレームワーク作ってる奴は
単純なサンプル画面しか作ったことないやつばっかり。

269 ：デフォルトの名無しさん：2013/03/08(金) 07:45:04.59

>>268
どのフレームワークのことを言っているのか皆目不明なのでざっくりMVCを使って尋ねるけど、
「受け渡しが出来ない」ってM・V・Cのどれからどれの間で受け渡しが出来なかったのさ。

フレームワークが使えない理由としてなにか高尚なものが来るかと思いきや、いきなり脱力な
例が飛び出してぐんにゃりですよ。

270 ：デフォルトの名無しさん：2013/03/08(金) 08:05:17.79

どこで受け渡しできないかも知らない程度の知識なんだとわかった

271 ：忍法帖【Lv=40,xxxPT】(2+0：5) ：2013/03/08(金) 08:14:16.37

>>268
批判するならどのフレームワークを使ったかくらい書くべきだね
すべてのフレームワークが同じわけではない

272 ：デフォルトの名無しさん：2013/03/08(金) 09:52:29.11

仕事以外の時間もプログラム板に来るような勤勉でスキルも高いであろうおまえらは
不便なフレームワークでハマる必要ないんだよ
流行りに流されてるのに気づいたほうがいい
チームに新人やスキルが低い人間がたくさんいてそいつらに大部分を任せないといけないから
スパゲッティを避けるため仕方なく使ってるという話ならわかるけど

273 ：デフォルトの名無しさん：2013/03/08(金) 11:04:32.79

そこでPlay! Frameworkですよ
Play! は Scala が話題になっているが、Javaでもかける。

274 ：デフォルトの名無しさん：2013/03/08(金) 11:58:37.45

wicketってのがXML書かなくていいらしいんだけど、うらやましい。

275 ：デフォルトの名無しさん：2013/03/08(金) 15:19:03.90

Playは独自感が半端なく強かったり、1.0=>2.0を見る限り不安定感が否めない。
wicketは素直な設計だし、1.5=>1.6を見る限り安定していて実用的な時期に思える。

用途に合わせて様々なフレームワークを使うぐらいなら、
wicketみたいな大規模向けフレームワークをベースに、
小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？

276 ：デフォルトの名無しさん：2013/03/08(金) 15:57:00.15

フレームワークいらんという人はORMやDIは使うのかな。
今時手組のSQLに生のJDBCとか勘弁。

277 ：デフォルトの名無しさん：2013/03/08(金) 16:06:37.78

ORMなんか使わないよ。パフォーマンス悪いし。

278 ：デフォルトの名無しさん：2013/03/08(金) 16:12:45.10

>>276
ibatisはたまに使う。
一番いらないと思うのはDIかな。
newぐらい自分でしたい。

279 ：デフォルトの名無しさん：2013/03/08(金) 16:24:05.63

とはいえweb.xmlにサーブレット登録した時点でサーブレットクラスのnewに関しては既に
サーブレットコンテナに委譲しているわけだからなぁ。
その先、各サーブレットクラスが必要とする依存性を自前でnewするかこれも委譲するかで
自前ファクトリをゴリゴリ書くかapplicationContext.xmlを書くかの違いが出てくる。
インスタンス生成の委譲の程度問題だと思うんだよね。個人的にはサーブレット使うことと
DIを使うことの間にはあまり断絶はない。

280 ：デフォルトの名無しさん：2013/03/08(金) 16:33:16.09

とくにWebアプリでORMとかアホかと思う。
Webアプリなんてサーバー集中型なのになるべく負荷を減らさないでどうする。
ORMはクラサバアプリ向けだろ。少しは考えて欲しい。

281 ：デフォルトの名無しさん：2013/03/08(金) 16:55:04.22

DB知らない素人が手組みしたDBスキーマとクエリ。
DB知らない素人が定義したORマッピングとそれから自動生成されたDBスキーマ。
どちらを使えと問われれば自分は絶対に後者を使う。前者は墓穴の宝庫だが後者は
一応それなりに定石を外さないスキーマやクエリを吐く。

DBの素養のある人が手組みしたDBスキーマとクエリ。
DBの素養ある人が定義したORマッピングとDBスキーマ。
どちらを使えと問われれば、まあ使い勝手次第であって基本的にはどちらでも良い。
結局スキーマもマッパーが吐くクエリも手組と大差無いものに大抵は落ち着くから。
ただし成果物のAPIレベルでの使い勝手は当然ORMを使った方が初めから機能豊富。

結局DB理解している人間が担当しているか否かが重要なのであって、その上の上物
はプロジェクト毎に好きに決めれば良い。ただし手組みさせるとそのDB理解している
人間の手作業がバカにならん。許させる範囲でORMで楽させてあげても。

282 ：デフォルトの名無しさん：2013/03/08(金) 16:58:19.38

そうやって、もっさりアプリ量産してくれ。
俺の超サクサクアプリが高評価なのはおまいらのおかげだ。

283 ：デフォルトの名無しさん：2013/03/08(金) 17:56:34.47

どうやらただの釣りだったようだな

284 ：デフォルトの名無しさん：2013/03/08(金) 19:25:26.20

ORMの必要性はわかるけど後でJDBCに差し替えにくい
Hibernateとかはバッドノウハウだなと思ったり。

285 ：デフォルトの名無しさん：2013/03/08(金) 19:39:04.75

最近のHibernateはJPA準拠してるんでしょ
JPAならそのままSQLも扱えるとおもうけど

286 ：デフォルトの名無しさん：2013/03/08(金) 20:00:01.24

ORMから外れたことをするにしても外れ具合の程度によってJPQLから生SQLまで
それなりに逃げ口は用意されているよね。
普通にORMを使って、困ったときにピンポイントでそういう逃げを利用するだけでも
大概のシナリオはカバーできると思う。

287 ：デフォルトの名無しさん：2013/03/08(金) 21:11:52.51

ORMを使うなら範囲検索にJPQL使うのは避けられないだろ。
プロトタイプだとしても主キーと全検索だけで作るわけにはいくまい。

288 ：デフォルトの名無しさん：2013/03/08(金) 21:29:37.43

その辺りはクライテリアとかフレームワークごとのDSLとか。
でもJPQLは良いものだ。サクッと使うのにちょうど良い。

289 ：デフォルトの名無しさん：2013/03/09(土) 01:00:06.57

>>281
DB知らない素人の件は俺なら前者かな。
ORMを理解してないやつが定義したものに
ORM適用するとか足かせにしかならん。
もちろんベストはそれなりにわかってるやつにDB定義をさせることだが
知らないやつが定義した場合は昔ながらのSQLで対応する他ないと思う。

290 ：デフォルトの名無しさん：2013/03/09(土) 01:03:09.87

>>282
俺もフレームワークとかDIとかORMとか否定派なので主張には賛成なのだけど
スマホアプリでもないただのWebアプリで
評価が高いとか低いとかどうやってわかるの？

291 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/09(土) 01:49:16.30

JavaEEが複雑すぎたために、DIが生まれたという解説をある本で読んだ。

293 ：デフォルトの名無しさん：2013/03/09(土) 03:27:23.17

>>291
レイヤごとにインターフェイス統一するのは
それなりのエンジニアなら誰でもやるし
そのケースでDIコンテナを使う必然性は感じられないが…

294 ：デフォルトの名無しさん：2013/03/09(土) 06:22:09.43

こまめにインターフェイスを定義することとDIコンテナを使うことは別に考えるべきだと思う。

インターフェイスを定義して抽象度を上げると実装の差し替えなど融通が効くのは別にDIを
使わずとも得られる恩恵だし、DIコンテナを使うにしても別にインターフェイスの定義は
必須ではない。注入される口の型が実クラス名で決め打ちでもDIコンテナは使える。

それならDIコンテナの利点は一体なにかというと、う～ん、DIコンテナを使っているフレーム
ワークを使うときは自分もDIコンテナを使った方が楽という点が正直一番でかいかなw

例えばSpringを使ったフレームワークを使うときは基本的にコンポーネントもDI前提で開発
するのが殆ど作法になっている。コンポーネントはDIコンテナのコンテキストに登録すること
でアプリ上にデプロイするという手順が大抵のフレームワークでほぼ共通なので、DI使えば
どのフレームワークでも簡単に似た手順でデプロイ出来るのに対して他の方法だと途端に
苦労することになる。

295 ：デフォルトの名無しさん：2013/03/09(土) 06:38:14.57

DIコンテナの作者が後年DIコンテナはいらないと言ってた件

296 ：デフォルトの名無しさん：2013/03/09(土) 10:57:51.80

当人がいらんと思ってても他の人が必要なら別にいいんじゃないの

297 ：デフォルトの名無しさん：2013/03/09(土) 11:04:21.79

>>296
いらないと思ってるやつが
いると思ってるリーダーの下についたときは悲惨だぞ←俺の今の状況
だからもっといらない流れができてほしいわ

298 ：デフォルトの名無しさん：2013/03/09(土) 11:13:19.54

>>295
ひがやすお？

299 ：デフォルトの名無しさん：2013/03/09(土) 12:11:10.88

>>298
YES
テストがしやすければDIコンテナは必要ないってSlim3の時に

300 ：デフォルトの名無しさん：2013/03/09(土) 15:35:31.76

DIの目的はテストじゃないと思うけどな。

301 ：デフォルトの名無しさん：2013/03/09(土) 15:50:02.45

ソースコード資産を別のフレームワークにそのまま移行する例って実は少ないだろ

302 ：デフォルトの名無しさん：2013/03/09(土) 16:34:51.64

wicket は Play! と同じくらい独自色がある気がする。 Play! で Java の時は、 DB のテーブル定義は ebean で、sql は生 sql がいい気がする。

303 ：デフォルトの名無しさん：2013/03/09(土) 16:39:17.86

iBATISがやはり最強だな。
今まで使わないで来て今じゃMyBatisになってるようだがやはり最強。

304 ：デフォルトの名無しさん：2013/03/09(土) 16:42:53.41

HibernateやJPA実装の類がダメな理由はなんだろう?

305 ：デフォルトの名無しさん：2013/03/09(土) 16:54:23.60

RDBMSとの対応を把握する必要があるなら
最初からSQLに書けばいいじゃない。

306 ：デフォルトの名無しさん：2013/03/09(土) 17:07:23.68

Entityオブジェクトのクラスが決まっているのならそちらに必要最小限の
マッピング情報を書き足せば良いじゃない。

変なスキーマ相手だと苦労するけどJPA。

307 ：デフォルトの名無しさん：2013/03/09(土) 18:17:55.52

>>301
少ないっていうかほとんどない
著作権が客に移るからそのまま再利用できないし

308 ：デフォルトの名無しさん：2013/03/09(土) 18:45:15.19

>>300
DIの目的はオブジェクト(コンポーネント)を疎結合にすること、
DIコンテナによってそれが交換しやすくなる、
それが最大のメリットになるのが単体テスト。
だが単体テスト以外じゃ交換性は実は必要ない、
だったらテストがしやすけりゃDIコンテナはいらん、と読んだ。

309 ：デフォルトの名無しさん：2013/03/09(土) 18:52:55.16

「DBスキーマが何も無い状態から」素直なスキーマを使う小規模Webアプリをサクッと開発する
のであればMyBatisでも生JDBCでもなくJPA系が一番楽だと思う。要するにアノテーションからの
スキーマの自動生成で事足りる範囲であればこれが一番コード量が少ない。

開発序盤はデフォルトのマッピングでORMにどんどん生成させて、ある程度エンティティクラスが
出そろったり怪しげなスキーマ吐くようになった時点で一旦止めてマッピングに手を入れる。
そっから先の苦労は、結局扱うドメインモデルの複雑さそのものなのでどのフレームワーク使っても
あまり大差はないようにも思う。

310 ：デフォルトの名無しさん：2013/03/09(土) 19:08:28.23

>>304
JPA1.0の頃だが、一覧とかエンティティ以外の形で取るのが絶望的にダメだったところ
今はどうよ？

311 ：デフォルトの名無しさん：2013/03/09(土) 20:42:00.68

>>310
1.0にも、それ以前のHibernateにも、一覧結果をEntity以外の形（普通のBeanやMap）で取得する方法はあったぞ
JPQL使う必要があったけど
どうしてもSQLで書かなければいけない場合でも、HibernateネイティヴのAPI使えば普通にEntity以外の形で取れていたし
その手法を実際に適用して開発したこともある

312 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/10(日) 21:32:05.66

ほんのちょっと前にJPA推しレスしてるやつ数人いるのに、
具体的な話になったらレス付かないとかwww

314 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/11(月) 21:24:30.49

>>311 >>314
「一覧」という言葉を多用してるけど何のこと？
多数のテーブルをJOINするようなクエリを意味してる？
一覧とは何を指しているのかわからなかったからレスのつけようがなかった。

業務系では使えないという主張もよくわからない
JPAに限らず、ORMはマッピングさえ終えてしまえば使えるでしょう

316 ：デフォルトの名無しさん：2013/03/11(月) 21:52:26.07

JPAが良いって言っている人達は、どんな用途にでもJPA最高って主張しているのか？
JPAで簡単に出来る範囲のことをやる分には、JPA最高っていう主張なのかと思っていたけど。

317 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/11(月) 22:13:39.98

>>316
>>286は「それなりに逃げ口は用意されている」から「大概のシナリオはカバーできる」
と主張してるな。「大概のシナリオ」だ、意味はわかるよな？

319 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/12(火) 00:29:13.67

JPA とか吐き出されるSQLが微妙なときがあるから、変なSQL吐いてたら普通のSQLにするとか、速度的に気にしなくて良いならJPAで通すとか。各DBの方言を吸収してくれるのは便利だと思う。

321 ：デフォルトの名無しさん：2013/03/12(火) 01:55:03.35

hibernateから10年以上経ってて
いまだにこんなややこしい議論が必要なら
もうSQL書いたほうが早いってことだろ

322 ：デフォルトの名無しさん：2013/03/12(火) 09:13:52.20

でもこの差は何なんだろうね。
http://www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&geo=JP&date=today%2012-m&cmpt=q
http://www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&date=today%2012-m&cmpt=q

日本ではHibernateを使いにくい特殊事情でもあるのかな。

こんなのも。
http://www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&geo=JP&date=today%2012-m&cmpt=q
http://www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&date=today%2012-m&cmpt=q

323 ：デフォルトの名無しさん：2013/03/12(火) 09:42:51.79

俺の考えを述べさせてもらうと
O/Rマッピングだけでも生SQLと速度差がほとんどなくなるか
そもそもオブジェクトをそのまま扱えるDBが一般的になるまで
生SQLのほうがいいと思う。

324 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/12(火) 23:22:04.17

余談だけど、JPAと言いつつHibernate前提の話をしたり、JAX-RSと言いつつ特定実装系前提の話をするJava EE推称派は、そこんとこキッチリしてくれ。

326 ：デフォルトの名無しさん：2013/03/12(火) 23:34:07.08

MyBatis触ってみたがこれで十分だわ
EJBに組み込む方法も割と簡単だし

327 ：デフォルトの名無しさん：2013/03/13(水) 00:27:43.05

>>325
標準ですむ範囲の要件であれば標準ですませた方がよい、それだけの話では？

328 ：デフォルトの名無しさん：2013/03/13(水) 01:04:42.17

>>327
文盲乙

329 ：デフォルトの名無しさん：2013/03/13(水) 01:10:39.93

hibernateって昔、1000件DELETEするときに
1000回DELETE文が走るとかでこれは使えないと断念したことがあるのだけど
いまのhibernateとかJPAとやらはそのへんは改良されてるの？

330 ：デフォルトの名無しさん：2013/03/13(水) 01:13:34.55

横断的な処理をする場合はJPQLを使って処理するんだろ
JPAはSELECTがJava側から見て綺麗になるくらいで後は方言吸収くらいが利点か

331 ：デフォルトの名無しさん：2013/03/13(水) 11:42:57.54

Linuxサーバーって一回設定したら以後放置だよね。Windows Update + Windows Serverの方がよいよね
http://engawa.2ch.net/test/read.cgi/poverty/1363142026/

332 ：デフォルトの名無しさん：2013/03/13(水) 15:53:58.68

>>329
調査不足つか調査力不足
Hibernate2.xの頃ですらできてた

333 ：デフォルトの名無しさん：2013/03/13(水) 16:53:32.09

>>332
昔って書いたのに何でそういう否定の仕方するんかね。
俺が見たのは2003年ごろだよ。バージョンは忘れた。

334 ：デフォルトの名無しさん：2013/03/13(水) 17:18:16.36

別に1000回DELETEすることは問題じゃないと思う。
それが1回のSQLでDELETEするのと同じ速度なら。
でもまだそういう時代じゃないからO/Rマッピングは悪だと思う。

335 ：デフォルトの名無しさん：2013/03/13(水) 18:07:27.21

>>333
事実だから
2002年1月リリースの0.9.2からできてたことに気づけず断念とか調査力不足だろ

336 ：デフォルトの名無しさん：2013/03/13(水) 18:34:57.15

>>335
まさかHQLのことじゃないよね？

337 ：デフォルトの名無しさん：2013/03/13(水) 18:50:25.71

すり替えｷﾀwww
少なくとも10年選手なんだろ？情けねぇ・・・
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
「hibernateって昔、1000件DELETEするときに」
どう見てもHQL使うべき場面です

338 ：デフォルトの名無しさん：2013/03/13(水) 19:00:25.43

できるできるってHQLのことかよ
HQL書かないといかんのなら使わんよそんなもん
隠蔽されて実行されるSQLを最適化してくれるよう
進化してるかが質問の意図だったんだが

339 ：デフォルトの名無しさん：2013/03/13(水) 19:09:20.82

>>338
だよな
それをわかってないんだよ
ここの奴らは

340 ：デフォルトの名無しさん：2013/03/13(水) 19:11:33.54

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

341 ：デフォルトの名無しさん：2013/03/13(水) 19:14:31.73

ファビョるなw

342 ：デフォルトの名無しさん：2013/03/13(水) 19:16:26.44

一応書いておくが、俺(340他)はHibernate使えるとは思ってない
↓がバカだと思っただけだ

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

343 ：デフォルトの名無しさん：2013/03/13(水) 19:16:53.38

そもそもオブジェクトを操作するだけでSQLと遜色ない速度で
動いてくれないと意味ないんだよ。

344 ：デフォルトの名無しさん：2013/03/15(金) 01:16:45.46

亀レス＆スレチですまん。

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

345 ：デフォルトの名無しさん：2013/03/15(金) 14:12:49.96

タイプセーフは重要

346 ：デフォルトの名無しさん：2013/03/16(土) 00:31:32.17

>>344-345
同じ言語を使えるってのは楽でいいね

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

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

347 ：デフォルトの名無しさん：2013/03/16(土) 00:47:09.87

Expressが必要なところでNode.jsを使ったら負けだと思ってる

348 ：224：2013/03/16(土) 22:53:33.58

>>344
node.jsか。レスありがとう!

349 ：デフォルトの名無しさん：2013/03/18(月) 20:10:52.78

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

350 ：デフォルトの名無しさん：2013/03/18(月) 20:49:09.28

ああreadonlyに設定してないと読み取りの度にシリアライズが走るのか
イミュータブルにすると周囲にやや不評だろうけど安全だしそうするか

351 ：デフォルトの名無しさん：2013/03/20(水) 00:08:40.52

mapper XMLでinsertをする時、useGeneratedKeysを指定すれば自動採番されたIDが取得できるのは
わかってるんだけど、これって単発insertのときだけじゃないですか。
insert selectで複数行をinsertしたとき、全部の自動採番IDを取ることって出来るんですか？

352 ：デフォルトの名無しさん：2013/03/20(水) 01:00:57.18

生JDBCのgetGeneratedKeys()はResultSetを返すんだからできるんじゃねーの？

353 ：351：2013/03/20(水) 01:13:31.36

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

354 ：デフォルトの名無しさん：2013/03/25(月) 11:00:30.07

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

355 ：デフォルトの名無しさん：2013/03/25(月) 11:10:09.19

あと、Tableに対応するクラスはEntityでいいとして、SQLに対応するクラスは何と定義してどのパッケージに突っ込んでる？
前者をDomainEntity, 後者をCustomizeEntityと呼んで同じパッケージに突っ込んでるプロダクトもあるみたいだけど.

356 ：デフォルトの名無しさん：2013/03/25(月) 11:31:00.42

だからまったくSQLを意識しなくてすむレベルまでオブジェクトにしても
パフォーマンスがぜんぜん問題にならないくらいになるまで
使うべきじゃない。時期尚早。

357 ：デフォルトの名無しさん：2013/03/25(月) 11:52:33.44

>>356
使わないのも選択肢としてありだと思うけど>>354-355の課題は使用有無に関わらず発生するよね
これみんなどうしてるのかねぇ

358 ：デフォルトの名無しさん：2013/03/25(月) 12:15:04.22

>>354
適材適所でいいんじゃないの
SQL使うほうが楽な場所はSQLで直接やればいい。
お決まりの処理で性能を満たす場合はORMで。

359 ：デフォルトの名無しさん：2013/03/25(月) 14:06:30.14

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

360 ：デフォルトの名無しさん：2013/03/25(月) 14:31:52.65

SQLインジェクションとコネクションプール用途で使うには重すぎるだろ
そんなのcommonsあたりで簡単に対応できるしな

361 ：デフォルトの名無しさん：2013/03/25(月) 15:17:03.51

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

362 ：デフォルトの名無しさん：2013/03/25(月) 15:36:33.34

>>359
＞生SQLで検索したものをオブジェクトにマップもできる。
ここが気になるって話じゃないの？
マップできるのはいいとして、SQLに対応するクラスをSQLの数だけ作るのか、
またはList<Map<String, Object>>とかで済ませてるのか

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

363 ：デフォルトの名無しさん：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 ：デフォルトの名無しさん：2013/03/25(月) 17:45:17.21

>>354-355
俺はある程度割り切ってクラスを共有するよ。
ざっくりとした例なので批判されるかもしれないけど
会員名、店舗名、都道府県名を格納できるDTOを用意して
会員→店舗までしかJOINしない場合もそのDTOを使用する。
都道府県名はnullなので都道府県名が欲しい場合は別のSQL使ってねと。

365 ：デフォルトの名無しさん：2013/03/25(月) 17:50:01.38

ありだな

366 ：デフォルトの名無しさん：2013/03/25(月) 18:22:48.02

ありだと思うよ
ただその場合だと複数機能で共有するだろうからパッケージに悩みそうかな
SQL書くときって機能でパッケージ分けてると共有しづらいよなー
ドメインモデリングは理解できる奴少なかったりするし

367 ：デフォルトの名無しさん：2013/03/25(月) 18:59:18.05

>>363
マッピングせずにResultSet(風)を触らせるのもありか
SQL発行した側はカラム名も型もわかってるはずだしな

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

368 ：デフォルトの名無しさん：2013/03/25(月) 19:05:13.70

ようするにO/Rマッピングは現段階では不要だな

369 ：デフォルトの名無しさん：2013/03/25(月) 19:26:38.33

>>368
それはさすがに極論すぎて、ORマッパ以前にバグやセキュリティホールの温床になりそうです。

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

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

370 ：デフォルトの名無しさん：2013/03/25(月) 19:37:43.30

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

371 ：デフォルトの名無しさん：2013/03/25(月) 19:40:36.78

SQL生成用クラスを一個つくればいいよね

372 ：デフォルトの名無しさん：2013/03/25(月) 19:45:11.79

>>370
本質じゃないというか言いたいのは「直接JDBC触らせるな」(DbUtils含む)ということですよ。
ORマッパはDAOみたいな機構も持っていることがあるので、
それなら最初からORマッパを使えば?ということです。
そういう汎用性をちゃんと持っているという認識が必要です。

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

373 ：デフォルトの名無しさん：2013/03/25(月) 19:48:36.82

あと聞きたいのですが、JDBCなどを使っている場合、
java.sql.PreparedStatementをちゃんと使ってますか?

374 ：デフォルトの名無しさん：2013/03/25(月) 20:04:13.30

SQL生成用クラスでPreparedStatementを使ってバインドしてるよ。

375 ：デフォルトの名無しさん：2013/03/26(火) 01:20:56.00

Javaソースの中で文字列連結しながらSQL作るようなのはダメ絶対

376 ：デフォルトの名無しさん：2013/03/26(火) 01:40:04.61

別にダメじゃないだろ
O/RマッパーやPreparedStatementがないと
基本的なセキュリティ対策すらできないことのほうが問題
Javaじゃないと作れない人になってしまうよ

377 ：デフォルトの名無しさん：2013/03/26(火) 02:09:42.74

JavaスレだからJavaソースと書いたがどの言語でも同じ
ただしSQLを組み立てるライブラリは除く、を書き忘れた
アプリで文字列連結しながらSQL作るようなのはダメ絶対

378 ：デフォルトの名無しさん：2013/03/26(火) 05:36:16.05

>>376
PreparedStatementを積極的に使わない理由が思いつかない。
動的SQLなんて大抵の言語とRDBMSで使えるでしょ。
Javaじゃないと作れない人になってしまう理由がない。

379 ：デフォルトの名無しさん：2013/03/26(火) 07:38:05.65

>>376
他の言語もJDBCに相当する機能では、今はPreparedStatement的な手法が主流だし問題ないと思う

380 ：デフォルトの名無しさん：2013/03/26(火) 11:20:44.10

昔は、文字列と、変数の配列(リスト)の2つを受け取って、
SQLをStringBuffer(StringBuilder)で連結しつつ、 ? を埋め込んで、
PreparedStatement 発行したもんだ。

381 ：デフォルトの名無しさん：2013/03/26(火) 12:31:12.72

オープンソースJava O/Rマッピングソフト一覧（2013年1月版） | Unofficial DB2 BLOG
ttp://db2.jugem.cc/?eid=2540

382 ：デフォルトの名無しさん：2013/03/26(火) 22:37:34.34

PreparedStatementってDBサーバ側の機能だからな
>>376の発想がおかしい

383 ：デフォルトの名無しさん：2013/03/27(水) 05:23:30.46

>>382
「Javaじゃないと作れない人になってしまうよ」と言っている当人がJavaでしか作ったことがないパターンでは。

384 ：デフォルトの名無しさん：2013/03/27(水) 08:43:10.56

DBとのやり取りにDAOパターンを採用するとき何をどこに入れるかってどうすることが多い？

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

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

385 ：デフォルトの名無しさん：2013/03/27(水) 08:52:59.87

開発の規模によるがうちなら⑴と⑶だけかな
⑵は他の業務から使えないのが微妙

386 ：デフォルトの名無しさん：2013/03/27(水) 08:54:46.69

問題の内容忘れてたわ…

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

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

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

387 ：デフォルトの名無しさん：2013/03/27(水) 09:12:01.84

結局生SQLが一番いいという結果になるな

388 ：デフォルトの名無しさん：2013/03/27(水) 11:55:44.21

>>382
その上「基本的なパフォチューすらできない」っていうねw
SQLがどうやって実行されるか気にしたこともないんだろうな

389 ：デフォルトの名無しさん：2013/03/27(水) 11:58:16.26

結局SQLがどうやって実行されるか気にしなければならない
O/Rマッパは使わないほうがいい。

390 ：デフォルトの名無しさん：2013/03/27(水) 12:49:51.63

>>388
なんでセキュリティ対策のこと書くとパフォーマンスチューニングについて
わかってないことになるの？議論がめちゃくちゃ

391 ：デフォルトの名無しさん：2013/03/27(水) 13:35:29.45

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

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

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

392 ：デフォルトの名無しさん：2013/03/27(水) 14:38:38.18

でもJavaの用途はWebがほとんどだからパフォーマンス重視なのは
仕方ない。だから生SQLが一番いい。

393 ：デフォルトの名無しさん：2013/03/27(水) 14:49:37.60

>>392
興味本位で聞くのですけど、O/Rマップってどのくらい遅いのですか?
具体的にベンチマークしましたでしょうか?
＃「あおり」じゃないので興味あったらで。

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

394 ：デフォルトの名無しさん：2013/03/27(水) 15:02:22.39

O/Rマッピングはアンチパターン？ | スラッシュドット・ジャパンデベロッパー
ttp://developers.slashdot.jp/submission/42933/

395 ：デフォルトの名無しさん：2013/03/27(水) 15:14:44.15

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

396 ：デフォルトの名無しさん：2013/03/27(水) 15:29:57.81

どういうケースでどんな理由で遅くなるのか具体例が欲しいな。

397 ：デフォルトの名無しさん：2013/03/27(水) 15:40:04.67

>>395
(また言いますけど煽りじゃないです。O/Rマッパ開発者としては現状認識を知りたい。)
生SQLをO/Rマッパに使ってもですか?

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

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

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

398 ：デフォルトの名無しさん：2013/03/27(水) 16:47:15.90

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

399 ：デフォルトの名無しさん：2013/03/27(水) 17:42:51.07

社内システムならDBの負荷はたかがしれてるから
ORM使っても性能上の問題ないよ
開発スピードも上がる。

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

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

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

400 ：デフォルトの名無しさん：2013/03/27(水) 17:50:31.65

ストアドプロシージャは使いたくないです。

401 ：デフォルトの名無しさん：2013/03/27(水) 18:09:34.30

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

402 ：デフォルトの名無しさん：2013/03/27(水) 21:02:46.76

ORMいらない、と言っている人間ははよくわからんな。
Micro-ORMで十分、なら理解できるが。

403 ：デフォルトの名無しさん：2013/03/27(水) 21:14:49.27

ORMと一括りにして議論している時点で程度が知れてる、というべきだな。

404 ：デフォルトの名無しさん：2013/03/28(木) 00:33:47.55

同じSQLでO/Rマッパーだけ遅いなら外すしかないね。
内部のリフレクションとかが遅いんじゃないの？

405 ：デフォルトの名無しさん：2013/03/28(木) 01:24:46.14

問題になる遅さなのそれ。

406 ：デフォルトの名無しさん：2013/03/28(木) 01:29:38.75

生SQLとかORMいらないとか連投してるのは荒らしだろ
現実的にはこのどっちか

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

407 ：デフォルトの名無しさん：2013/03/28(木) 14:06:46.51

生SQLの定義がわからんね
SQL*Plusなんかで直接実行できるSeasarの2way SQLは生SQLなのかどうか

408 ：デフォルトの名無しさん：2013/03/28(木) 14:32:20.33

フレームワークが勝手に作ったSQLを発行するんじゃなくて、
開発者が書いたSQLを流すのが生SQLでいいと思う

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

409 ：デフォルトの名無しさん：2013/03/28(木) 14:41:14.77

だとするとJPA系を除く多くのORMは生SQLが主なんだが
生SQL君が言いたいのはORMイラネじゃなくJPAイラネなのか？
ORMイラネ君と同一人物かと思ってたんだが

410 ：デフォルトの名無しさん：2013/03/28(木) 14:49:50.56

>>407 >>409
ORMはSQLを生成して、SQLを投げるだけだよ
複雑なJOINしない限り、ほとんど性能は落ちない。

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

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

411 ：デフォルトの名無しさん：2013/03/28(木) 15:07:49.10

>>410
自分で書いたSQLをORMで実行した場合も生SQLだとしたら、
生SQLが必要だからORMイラネってのはおかしいという話
生SQLが主のORMもたくさんあるわけだから
生SQL君とORMイラネ君が同一人物かどうかはしらんけど

412 ：デフォルトの名無しさん：2013/03/28(木) 18:43:58.87

俺は生SQL書きやすいORMならOK派かな。
Hibernateみたいなのは勘弁。
フレームワークも不要。

413 ：デフォルトの名無しさん：2013/03/28(木) 20:20:44.35

MyBatis+標準SQL(SQL92あたり)でいいわ

414 ：デフォルトの名無しさん：2013/03/28(木) 22:50:54.10

まぁ日本の開発現場ではNIH症候群が蔓延してるからな。
車輪の再発明大好きだし。

415 ：デフォルトの名無しさん：2013/03/29(金) 00:30:58.37

おれもMyBATIS＋SQLだな
学習コスト少なめだし、バグがあっても追いやすいし
裏で動的にSQL生成してるようなフレームワークで
いい思いをしたことがない

416 ：デフォルトの名無しさん：2013/03/29(金) 05:58:23.38

ＳＱＬ方言だけ吸収してくれれば

417 ：デフォルトの名無しさん：2013/03/29(金) 07:20:01.88

Hibernateかなぁ。
幸い個々のエンティティに関して比較的単純なCRUDしか必要が無いのでMyBatisでSQL書いた
ところでHibernateが生成するSQLとあまり大差無いものを書くことになったり。

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

418 ：デフォルトの名無しさん：2013/03/30(土) 09:24:08.73

>>415
どれでも発行SQLだけ確認やログ出しも出来るし
2WAYならチェックした上でマズいの手書きできる
フレームワークで統一性のない動的生成ルールが面倒だけどな

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

419 ：デフォルトの名無しさん：2013/03/30(土) 10:34:49.59

DTOはある程度割り切って共有で結論出てなかったっけ
割り切り共有＋継承＋テーブル定義とにらめっこ、
すればそこまで増殖しないと思うが。

420 ：デフォルトの名無しさん：2013/03/30(土) 13:05:35.15

DTOのクラスが増えるのが嫌なら、全部Mapに突っ込んでしまえば？ｗ

421 ：デフォルトの名無しさん：2013/03/30(土) 13:07:19.28

Mapでええやろ

422 ：デフォルトの名無しさん：2013/03/30(土) 13:37:01.55

mapでいいならJavaじゃなくていいだろ
getterがあるからキーの文字列を意識しないで済んでるのに

423 ：デフォルトの名無しさん：2013/03/30(土) 19:32:32.72

MapとDTOは使い分ければ良いと思うけどなぁ。

424 ：デフォルトの名無しさん：2013/03/31(日) 10:16:31.71

Java系のフレームワーク、海外ではGrailsがすごい人気高くて驚いた
Java系だとGrailsはトップ3に入ってる

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

425 ：デフォルトの名無しさん：2013/03/31(日) 11:10:40.80

GroovyはJavaの資産は使えるなら積極的に使おうって姿勢かな

426 ：デフォルトの名無しさん：2013/03/31(日) 22:08:24.97

GroovyはJavaの方言というかJavaプラスアルファぐらいに考えた方が良いと思う。
Javaの文法にRuby風の文法やメソッドも付け加えた感じで、両方を混ぜて書ける。
JavaとRuby両方の素養がある人だとすごく便利だと思うよ。

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

427 ：デフォルトの名無しさん：2013/04/01(月) 00:51:09.20

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

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

428 ：デフォルトの名無しさん：2013/04/01(月) 02:41:51.01

JavaのView層はいつまでも安定しないね
似たようなコードの書き方、次から次に覚えないといけないのはきつい
他の言語はほとんど安定してるのになあ

429 ：デフォルトの名無しさん：2013/04/01(月) 03:21:29.18

Grailsは確かにもっと流行っても良い気はする。
会社でやっているプロジェクトも最近ようやくGrails2.2.1にバージョンアップして依存性管理を
Mavenに移行出来たので他のプロジェクトとの連携がよりやりやすくなった。

430 ：デフォルトの名無しさん：2013/04/01(月) 07:00:39.53

フレームワーク使わない人ってURLマッピングはどうやっているのだろう。

例えばクエリーを使ったレガシーなhttp://aaa/product_comment?id=12345&comment=6789みたいな
URLではなく、よりRESTfulなhttp://aaa/product/12345/comment/6789みたいなURLを使う場合。

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

431 ：デフォルトの名無しさん：2013/04/01(月) 11:03:54.12

>>430
mod_rewrite

432 ：デフォルトの名無しさん：2013/04/01(月) 11:09:20.88

自前でパースしないと遅いしな

433 ：デフォルトの名無しさん：2013/04/01(月) 17:14:29.59

面倒を厭わない人たちなのはよく解った。

434 ：デフォルトの名無しさん：2013/04/01(月) 17:20:23.50

>>433
面倒を避けようとしてさらに面倒なことになってる印象。

435 ：デフォルトの名無しさん：2013/04/01(月) 22:00:58.98

でもSEO対策が入ってくるとできあいのフレームワークじゃ難しいんだよな
みんなどうしてるか、そっちのが気になるわ

436 ：デフォルトの名無しさん：2013/04/01(月) 22:09:02.05

JSFだのASP.NETだのはイントラじゃなきゃ難しいな

437 ：デフォルトの名無しさん：2013/04/01(月) 22:22:26.68

>>435
どうやってタグを吐くかだから
フレームワークは無関係

438 ：デフォルトの名無しさん：2013/04/01(月) 22:48:03.67

JSP&Servletだけで十分フレームワーク

439 ：デフォルトの名無しさん：2013/04/01(月) 22:50:16.68

URLについては、Struts時代はRouter自作。
Spring MVCでは無問題。

440 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/04/01(月) 23:33:39.56

>>441
すいません。jspは文字コードを使い分けたいので、そのやり方はダメなんです・・・。
あくまで違う文字コードでの受け渡しでやりたいんです。

443 ：デフォルトの名無しさん：2013/04/01(月) 23:41:07.31

Java内部の文字列処理はUTF-16だよ
サーブレットの文字コードって表現が既におかしいんじゃない？

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

444 ：デフォルトの名無しさん：2013/04/02(火) 00:05:07.91

>>443
サーブレットのソースコードのテキスト文字コードがUTF-8ってことです。

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

と書いています

445 ：デフォルトの名無しさん：2013/04/02(火) 00:29:51.55

>>443
ああ、サーブレット側でsetCharacterEncodingやsetConentTypeで
Shift_JISを指定するだけで行けました。
サーブレット内での余計な変換処理は要らなかったんですね。
どうもです。

446 ：デフォルトの名無しさん：2013/04/02(火) 02:15:06.83

>>438
>JSP&Servletだけで十分フレームワーク

これはマジでそう思う。

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

447 ：デフォルトの名無しさん：2013/04/02(火) 04:23:34.10

JSPはServletのフレームワークだな。
JSP嫌いだから引っこ抜いちゃうｗ

448 ：デフォルトの名無しさん：2013/04/02(火) 04:40:47.74

>JSP&Servletだけで十分フレームワーク

ただしServlet3以降に限る

449 ：デフォルトの名無しさん：2013/04/02(火) 10:51:31.04

Servlet2.5 と Servlet3 で大きな違いってあるの？
Servlet3はほとんど追いかけてないのですが、
HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
ぐらいのことしか知らん。

450 ：デフォルトの名無しさん：2013/04/03(水) 08:10:55.48

ないと思うなー。
＞HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
フレームワーク自体を作る側の人にとって嬉しいくらいじゃね？

451 ：デフォルトの名無しさん：2013/04/03(水) 08:15:23.37

そもそもアノテーションとか要らない

452 ：デフォルトの名無しさん：2013/04/03(水) 08:21:53.88

なにいってるんだか
xml地獄を解決するために生まれたのがアノテーションでしょ

453 ：デフォルトの名無しさん：2013/04/03(水) 08:24:32.09

フレームワークさえなければXML地獄もなかったのに

454 ：デフォルトの名無しさん：2013/04/03(水) 08:29:46.34

>>453
GrailsはXML地獄なかったよ

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

455 ：デフォルトの名無しさん：2013/04/03(水) 08:31:41.31

じゃあなんでSQLをXMLに外出しするような糞ORマッパを
勧めたりするんだ？

456 ：デフォルトの名無しさん：2013/04/03(水) 08:38:17.94

>>455
アンカーくらいつけてまともな日本語で書けよ
何が言いたいんだ

457 ：デフォルトの名無しさん：2013/04/03(水) 08:43:30.16

フレームワークとかORマッパが嫌い

458 ：デフォルトの名無しさん：2013/04/03(水) 08:47:54.30

>>457
だったらこのスレを見るなよ

459 ：デフォルトの名無しさん：2013/04/03(水) 08:53:54.35

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

460 ：デフォルトの名無しさん：2013/04/03(水) 09:04:33.36

海外だとHibernateが第一選択肢でそれ以外は比較的測定限界以下なのに、日本だとMyBatisとか
ガラパゴスフレームワークの類が幅をきかせているのは何か特殊事情があるのかな。

461 ：デフォルトの名無しさん：2013/04/03(水) 09:20:17.93

外出しすれば綺麗だと思うのは間違い
C++になっても変数宣言を関数の先頭でやるくらい汚い

462 ：デフォルトの名無しさん：2013/04/03(水) 09:21:15.39

全部のORMがXML使うわけじゃないし
TypesafeなORMが良ければそういうORMと組み合わせて
使えばいいだけだろ
入れ替えて使えるようにDIとかがあるわけで

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

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

463 ：デフォルトの名無しさん：2013/04/03(水) 09:23:53.81

いろいろなフレームワークがあること自体間違い

464 ：デフォルトの名無しさん：2013/04/03(水) 10:28:49.35

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

465 ：デフォルトの名無しさん：2013/04/03(水) 11:36:08.03

とりあえずSeasar信者の受け売りが嫌だ

466 ：デフォルトの名無しさん：2013/04/03(水) 11:47:15.81

色んなフレームワークがあるのは構わんけど、色んな実装があるのは嫌だ。
JAX-RSとかJSF、JPAとか。

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

467 ：デフォルトの名無しさん：2013/04/03(水) 12:02:47.87

>>466
その無駄な複雑性はJavaの悪いところだし
ORACLEが無能だからだろうな

468 ：デフォルトの名無しさん：2013/04/03(水) 13:39:18.89

継承や委譲を使うべきところまでPOJOがどうのこうのとアノテーションだらけにする
無能な糞フレームワークがあるな。S2なんとかーだけど。

469 ：デフォルトの名無しさん：2013/04/03(水) 13:55:01.70

自分も Hibernate より MyBatis のほうが好きなタイプだが、
Hibernate は嫌われるのに、Rails の ActiveRecord がみんなに受け入れられているのはなぜだろう？

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

470 ：デフォルトの名無しさん：2013/04/03(水) 14:58:00.57

規約やアノテーションを活用する今のHibernateではなく、XML地獄時代のHibernateのイメージ
があるからじゃないのかな。

471 ：デフォルトの名無しさん：2013/04/03(水) 16:26:08.57

ActiveRecordが受け入れられている理由
-> RoRを使用するような用途/データモデルではそれで困らないから

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

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

472 ：デフォルトの名無しさん：2013/04/03(水) 19:43:14.80

そういやhibernate entity manager経由でしか触ってないな
今って生hibernateどうなってんだろ
後で試してみるか…

473 ：デフォルトの名無しさん：2013/04/03(水) 20:06:18.41

>>471
でもそれだけだと内外差の説明はつかないなぁ。

474 ：デフォルトの名無しさん：2013/04/03(水) 20:33:32.91

>>469
RailsのようにConvention over Configurationが徹底した
フレームワークだと、ほとんどORMの設定することなく使える。

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

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

475 ：デフォルトの名無しさん：2013/04/03(水) 21:17:53.29

>>473

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

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

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

476 ：デフォルトの名無しさん：2013/04/03(水) 21:21:36.90

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

477 ：デフォルトの名無しさん：2013/04/03(水) 21:44:55.39

>>473
日本のIT業界が世界に取り残される一番大きな理由は
大半が英語ができないからだよ
英語のドキュメントが満足に読めない人ばかり。

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

478 ：デフォルトの名無しさん：2013/04/03(水) 21:51:43.05

iBatis/MyBatisなんて日本語の情報が充実してなくても結構使われてるだろ
Springだって使われてる度合いに比べたら日本語の情報は少ないし
Hibernateは使われてない割に情報多い
たいして相関してる気がせんな

479 ：デフォルトの名無しさん：2013/04/03(水) 21:55:28.57

ぶっちゃけStringの連結なんてしたくないわ
テキストに書けるならそっちの方がチューニングもしやすいでな

480 ：デフォルトの名無しさん：2013/04/03(水) 22:02:27.77

>>478
Batis系はHibernateよりも単純だから英語のドキュメント
読めなくてもなんとかなるからだろう

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

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

481 ：デフォルトの名無しさん：2013/04/03(水) 22:04:26.47

内外差以前に海外の実情がわからんのだよな
いつまでもTomcat使ってるのは日本だけと某エバンジェリストが言ってたけど
http://www.javacodegeeks.com/2013/03/most-popular-application-servers.html
を見ると海外でもTomcat強いしJetty含めてJavaEEじゃない方が主流だよな
海外じゃJSFやJPAが普及してるってのもどこまで本当か…
マーケティングに釣られてるんじゃないかと思うことがある

482 ：デフォルトの名無しさん：2013/04/03(水) 22:07:31.15

>>480
> 疑うならwebフレームワークの採用ORM見てみなよ

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

483 ：デフォルトの名無しさん：2013/04/03(水) 22:36:07.96

英語・日本語にかかわらず、ドキュメント読まなくても使えるシンプルなのがいいのは確かだな

484 ：デフォルトの名無しさん：2013/04/04(木) 00:51:54.82

Struts1のEOLが決定しました
http://www.h3.dion.ne.jp/~alpha-pz/misc2811.html

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

485 ：デフォルトの名無しさん：2013/04/04(木) 02:02:52.91

RailsとHibernateが同じようなものというのはない
JavaのフレームワークはXML地獄かアノテーション地獄
Railsなんて学習コストやハマりコストめちゃ低いぞ

486 ：デフォルトの名無しさん：2013/04/04(木) 02:21:25.71

こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん
http://qa.atmarkit.co.jp/q/2826

487 ：デフォルトの名無しさん：2013/04/04(木) 04:49:50.13

う～ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと
おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。

488 ：デフォルトの名無しさん：2013/04/04(木) 07:30:48.85

>>485
名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ
Javaを知っている人ならGrailsのが学習コストは低いとおもう。

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

489 ：デフォルトの名無しさん：2013/04/04(木) 07:35:07.70

>>484
フレームワークなんか使うからこうなる。

490 ：デフォルトの名無しさん：2013/04/04(木) 07:44:26.43

>>489
お前自身がEOLってことに気づこうな

491 ：デフォルトの名無しさん：2013/04/04(木) 07:49:20.30

Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では
アレになっている部分も少なくないと思う。

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

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

492 ：デフォルトの名無しさん：2013/04/04(木) 07:49:35.61

>>489
まだこのスレにいたのか
必死にフレームワーク否定してるけど何つかったことあるんだよ

493 ：デフォルトの名無しさん：2013/04/04(木) 07:56:46.99

>>488
Javaのフレームワークにはいつも期待を裏切られてるけど
最後の最後ということでやってみるよ。アドバイスありがとう

494 ：デフォルトの名無しさん：2013/04/04(木) 08:05:53.42

作っては捨て作っては捨て
こんなのシステム開発では使えないよ。
趣味のプログラミングなら好きにやってくれていいけどさ。

495 ：デフォルトの名無しさん：2013/04/04(木) 08:52:46.84

>>494
毎回作り直してる俺々フレームワークのことですね、わかります

496 ：デフォルトの名無しさん：2013/04/04(木) 08:58:09.84

WicketライクなFW普及してくれ～

497 ：デフォルトの名無しさん：2013/04/04(木) 08:59:04.31

>>495
受託や派遣ばかりやってるからそういう発想になるんですね。わかります。

498 ：デフォルトの名無しさん：2013/04/04(木) 09:18:37.61

>>496
Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ

499 ：デフォルトの名無しさん：2013/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 ：デフォルトの名無しさん：2013/04/04(木) 20:48:10.99

JSFってFacelets+CDIだけやれるっけ？
バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる

501 ：デフォルトの名無しさん：2013/04/04(木) 22:33:20.22

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

502 ：デフォルトの名無しさん：2013/04/04(木) 22:35:35.96

フレームワーク乱立のせいだな

503 ：デフォルトの名無しさん：2013/04/04(木) 22:41:00.19

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

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

504 ：デフォルトの名無しさん：2013/04/04(木) 22:54:27.01

>>501
phpと争って削ってくれたらそれで十分な感じかな
あいつらだけはマ名乗ったらいかんレベル

505 ：デフォルトの名無しさん：2013/04/04(木) 22:59:26.63

apache cgi javaとかあればなー

506 ：デフォルトの名無しさん：2013/04/04(木) 23:23:40.46

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

507 ：デフォルトの名無しさん：2013/04/05(金) 00:10:40.11

Javaのフレームワーク関連で
こんなにもたくさんの名前が出て来ること自体が異常
他の言語はここまで乱立してないから入りやすい

508 ：デフォルトの名無しさん：2013/04/05(金) 00:24:26.24

>>507
javaはまだマシだと思う
ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい
ぶっちゃけjeeだけってのもありだし
この点ではjavascriptのライブラリの乱立が一番ひどい

509 ：デフォルトの名無しさん：2013/04/05(金) 00:51:39.39

springjs
hibernatejs
なんかつよそう
jsf も js が付いていることに気がついた。でもうんこ

510 ：デフォルトの名無しさん：2013/04/05(金) 01:11:50.38

選択肢が無い方が幸せって人もいるけど俺はいやだな

511 ：デフォルトの名無しさん：2013/04/05(金) 06:32:32.04

趣味の自分プロダクトならそれでいいけど
フレームワークがコロコロ変わると
チームメンバーが大変だろう

512 ：デフォルトの名無しさん：2013/04/05(金) 06:47:37.60

そこまでころころは変わらない。

513 ：デフォルトの名無しさん：2013/04/05(金) 07:02:04.46

オレオレフレームワークで検索するとPHP率が結構高いのね。

514 ：デフォルトの名無しさん：2013/04/05(金) 08:05:54.47

Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな

515 ：デフォルトの名無しさん：2013/04/05(金) 09:36:15.65

>>508
DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね
GrailsもSpringをベースにして、HibernateやGroovyや
独自テンプレートエンジンなどを組み合わせたものだった。
VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。

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

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

516 ：デフォルトの名無しさん：2013/04/05(金) 11:15:07.30

2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ

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

517 ：デフォルトの名無しさん：2013/04/05(金) 11:17:44.83

俺はフレームワーク嫌いだからjQueryすら使わない

518 ：デフォルトの名無しさん：2013/04/05(金) 11:33:11.41

JSはただのライブラリであってフレームワークではないだろ

519 ：デフォルトの名無しさん：2013/04/05(金) 11:41:08.76

ネイティブが好き

520 ：デフォルトの名無しさん：2013/04/05(金) 13:47:27.52

Javaのフレームワークの乱立について指摘されてるのに
JSのほうがもっと酷いからJavaの乱立はOK、というのはいかがなものか

521 ：デフォルトの名無しさん：2013/04/05(金) 13:53:42.65

>>518
MVCフレームワークが乱立してるよ
http://todomvc.com/

522 ：デフォルトの名無しさん：2013/04/05(金) 14:46:14.82

Node.jsはCPUを使う処理には弱いと書いてあるね。
シングルスレッドでしか使えない弱点が痛い。

グリーの宣伝（人材募集）みたいになっててアレな記事だけど。
http://codezine.jp/article/detail/6461?p=2

メリットはリアルタイム処理が強いことくらいかな
でもソーシャルゲームとかチャットのようなリアルタイム性が
必要ないなら、Node.jsを使う意味は見当たらない。

JSは細かいライブラリが大量にあって情報追いかけるのがひたすらめんどくさいわ
現状は汎用的に使えるサーバサイドフレームワークって感じじゃなくて
リアルタイム処理が必要な場面で使うものに見える。

523 ：デフォルトの名無しさん：2013/04/05(金) 14:49:07.16

従来サーバ側のWebフレームワークが担ってきた役割、特にビューは
クライアント側（JSに限らずObjCやJava含む）への移動が始まってる
だからサーバ側もJAX-RS的なものでAPIだけ作る流れ
これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）

524 ：デフォルトの名無しさん：2013/04/05(金) 14:52:50.13

>>522
今はJavaでもNettyがあるし、その上に作られたNode.js風のVert.xもある
Netty上に作られたErlang風のAkkaもあり、Akka上に作られたPlay!もある
技術的にはNode.jsを選ぶ理由はない

525 ：デフォルトの名無しさん：2013/04/05(金) 14:56:37.52

JAX-RSは地味によいものだと思う。

526 ：デフォルトの名無しさん：2013/04/05(金) 14:59:55.89

シングルスレッドとかありえねー

527 ：デフォルトの名無しさん：2013/04/05(金) 15:18:49.66

逆だろ、単体ではシングルスレッドにしておき、
CPUコア数に応じてスケールさせたければ、プロセスを複数立ち上げておいて、
フロントのロードバランサーなりリバースプロクシで分散させればよい。

Nodeにしろ、こういったのは、パフォーマンスを上げるために、マルチスレッドではなく
RubyのEventMachineみたいにイベント駆動にすることでパフォーマンスを上げようとするアプローチなんじゃないの？

って書いてて自分でも理解してないのだが、
マルチスレッドにしつつ、各スレッドは EventMachine 形式にしたら、もっといいんじゃないの？
と思うんだけど、併用できないんですか？

528 ：デフォルトの名無しさん：2013/04/05(金) 15:35:47.71

逆とか意味不明。シングルスレッドとか糞

529 ：デフォルトの名無しさん：2013/04/05(金) 15:44:10.18

シングルスレッドにはシングルスレッドの良さがある
同時1万接続をすいすい捌いてもメモリ256MBでおつりが来る
これはマルチスレッドじゃ無理
クラウド（PaaS）ではこれがコスト面で効いてくる場合がある
要は適材適所の一つ

530 ：デフォルトの名無しさん：2013/04/05(金) 15:45:51.78

>>523
Viewがクライアント側に移動が始まっている、の意味がさっぱりわからんですわ。

例えばCRUDのうち、データ取得する(SELECT的)処理をするとして
AP serverは、DBから得た結果を、htmlとマージして最終的にブラウザに
渡す必要があるのは何ら変わってないでしょう？
要するにTemplateにデータを合成して、レスポンスを返す処理。

実際に、今の主流のMVCのフレームワークでも
そういったViewのテンプレート処理を持ってるし、使ってるでしょう。

Node.jsをプッシュしてたひとと同じだと思うけど、「使われている事例がある」
というだけなのに、すべてそうなっていくかのように主張しているように見える。

531 ：デフォルトの名無しさん：2013/04/05(金) 15:50:45.64

>>529
ないない。
DB絡んだら1万同時接続なんて1台じゃ無理だし
シングルスレッドならなおさら無理。
さらに256MBで足りるなんて妄想もいいところ

1万接続で256MBとか馬鹿な主張はいいかげんにしろといいたい

532 ：デフォルトの名無しさん：2013/04/05(金) 15:58:18.20

シングルスレッドはマルチスレッドになれないけど
マルチスレッドはシングルスレッドになれるんだから
シングルスレッドのほうがいいなんてありえない。

533 ：デフォルトの名無しさん：2013/04/05(金) 16:02:24.39

>>530
HTMLを返す必要がなくなってきてるってこと
JSONだけ返しておけばあとはクライアント側でレンダリングする
だからクライアント側のMVCフレームワークが注目なわけ
君だいぶ遅れてるみたいだから少しはキャッチアップしておいて損はないと思うよ

534 ：デフォルトの名無しさん：2013/04/05(金) 16:15:06.17

>>531
Node.jsじゃDB接続もノンブロッキングだし1スレッドで十分
DBとのやり取りってアプリ側はSQL投げて返ってくるまで待つだけじゃん？
だから影響はないよ
もちろんDB側がボトルネックじゃない前提で

>>532
用語の使い方の問題だな
シングルスレッド: イベントループで複数の接続を扱うアーキテクチャ
マルチスレッド:　接続毎にワーカースレッドを使うアーキテクチャ

まともな議論にならないなら用語変えた方がいいかもね
実際はNode.jsだってマルチスレッドだよ
イベントループ以外のスレッドは持ってる

別にNode.jsプッシュしてるつもりはないんで
必要に応じて使ってるだけ

535 ：デフォルトの名無しさん：2013/04/05(金) 16:19:45.99

>>533
遅れてるとか馬鹿にしてるだけで答えになってないよ。
最終的にブラウザで表示されるhtmlはどうするんだよ
HTMLを返す必要はなくなってきてなんてないから

536 ：デフォルトの名無しさん：2013/04/05(金) 16:21:03.02

bodyタグの中身は空でjsで全部書くってことでしょう。

537 ：デフォルトの名無しさん：2013/04/05(金) 16:24:45.46

>>536
それ非効率極まりないね

あとJS無効にされてたらなにもレンダリングされないじゃないの。

プライベートブラウジング機能が搭載されてきてるから
JS無効になってるなんてケースは増えてる。

538 ：デフォルトの名無しさん：2013/04/05(金) 16:27:03.82

フレームワークを使う人は開発効率のみ優先だから。

539 ：デフォルトの名無しさん：2013/04/05(金) 16:30:26.06

>>523 >>533
それはないと断言できる
プログラムの前にキミはWebがわかってない

540 ：デフォルトの名無しさん：2013/04/05(金) 16:31:51.49

>>530
ViewはもともとウェブアプリケーションフレームワークによるHTML生成とウェブブラウザにる
レンダリングの共同作業だったわけだけど、書かれるロジックがどんどんブラウザ側のJavaScript
に引っ越ししつつあるというのは自分も解る。

ただ個人的にはウェブアプリケーションフレームワークでViewと呼ばれている部分よりもController
と呼ばれている部分に書かれていたロジックがお引っ越ししている印象。

ウェブアプリのMVCは本来のMVCとは違うとかMVC2とか細かいツッコミは別として、大まかに
ウェブアプリのCはURLマッピングで振り分けられたHTTPリクエストに応じてアクションを起こす
役割と、Vで表示されるデータをお膳立てするビューロジックの一部を担ってきたように思う。

これが前者に関しては最近はブラウザ上でSubmitボタンを押しても直接POSTリクエストが飛ぶの
ではなく、ブラウザ上でJavaScriptがRESTリソース、言うなればMにアクセスするリクエストを
組み立ててAjaxでやりとりしてHTMLを書き換える。この場合ウェブアプリ側のCというのはURL
にRESTリソースをバインドする程度のすごく薄いものになる。

後者に関しても例えばMの中に1万件あるデータをある属性で並べ替えて20番目から29番目を表示、
といったページングのためのビューロジックは大抵Cの中に書かれていた。ただこのロジックも最近
ではJavaScriptで書いて、AJAXをつかって動的にサーバから表示に必要なデータを取得する場合
も多いと思う。これもサーバ上のCからブラウザ上のJavaScriptにお引っ越ししている例。

541 ：デフォルトの名無しさん：2013/04/05(金) 16:38:33.99

>>539
同意。
他人を遅れてると馬鹿にして上から目線で発言してるわりに
アーキテクチャと利点、欠点などがわかってないわ

542 ：デフォルトの名無しさん：2013/04/05(金) 16:39:43.33

フレームワーク厨はフレームワークさえ使えればなんでもいいんだよ。
君らもフレームワークをありがたがってないでネイティブに回帰すべき。

543 ：デフォルトの名無しさん：2013/04/05(金) 16:43:38.62

>>535
最初は静的なHTMLで始まる（Javaで返す必要はない）
そこからロードされたJSがサーバからJSONを取得する
JSONで得た情報をJSでレンダリングする
そのためのJSで書かれたテンプレートエンジンもたくさんある
うちはHandlebars使ってる

まだそこまで極端なケースは少ないけど方向はこっち
（Twitterみたいに後戻りするケースもあるし流動的かもしれんが）
スマホのネイティブアプリとサーバ側が共有しやすいメリットも大きい
つかうちはスマホアプリが先で後からブラウザ対応が増えてきてる

ちなみに業務系はオンプレのJavaでStrutsベースのオレオレ、
それとは別にAWSでPHP、RoR、Node.jsを使ったサービスを並行してやってる
わかってないといわれるならそうなんだろう

544 ：デフォルトの名無しさん：2013/04/05(金) 16:49:34.93

そうやって間違った方向に進んでしまうのがIT業界の悪いところだな。

545 ：デフォルトの名無しさん：2013/04/05(金) 17:16:33.84

>>540 >>543
Google mapとかの地図サイトのように
ページの一部分を頻繁に読み込むようなサイトなら
JSは使うだろうし、それくらいは当然知ってます。
ページ全部を毎回読み込むのは非効率だし

ただ、MVCのある機能がブラウザ側に移動したというより、サーバとクライアントが
協調して動作するようなシステムが出てきたってだけの話だと思う。
結局、サーバサイドのフレームワークがなくなることはありえない。

>>523は、「分散」とかではなく「移動」といったうえで
「これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）」
なんて結論づけたから噛みついたわけ。

Strutsがクソなのは知ってるけど、そこからサーバサイドのMVCフレームワークが
なくなっていくという話につなげられると
まったく同意しかねる、ということ。

Ajax, jQuery必須にしてしまえば、ブラウザでJS切ったら使い物にならないし
有効であってもバージョンの互換性でエラーが出る。
開発のコストも無駄にかかる。デメリットも大きい。
だから全般的に移行することはありえない。
デメリットを補ってあまりあるメリットがあれば使われる、というだけ

サーバだけでやるのか、サーバ＋クライアントでやるのか、
使い分けの問題であって、サーバのみでやるのが遅れているわけでもない。
セキュリティ上の理由でクライアントサイドで処理できないこともある。

546 ：デフォルトの名無しさん：2013/04/05(金) 17:20:06.75

まったくだ。ニコ動もクライアントでいろいろやりすぎて
糞使いにくくなってる。
つまり何事もネイティブで考えることが必要だ。

547 ：デフォルトの名無しさん：2013/04/05(金) 18:58:11.74

中の人にはソレが段々と見えんくなってくるのでしょう。

548 ：デフォルトの名無しさん：2013/04/05(金) 19:24:11.12

JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。

ちなみにうちは、jQueryの利用的なことから一歩進んで、JSフレームワークのLOBアプリへの適用もやりはじめた。
今までJSで個別に処理を記述していたところを、フレームワークを使って、
RESTなAPIの結果でObserverなVMのメンバを更新、バィンディングでHTMLの表示を更新というレベルだけど。

549 ：デフォルトの名無しさん：2013/04/05(金) 20:45:01.83

>>548
> JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。

どの辺がまだまだ?

550 ：デフォルトの名無しさん：2013/04/05(金) 21:28:07.76

>>545
もちろん、なかなか消えはしないだろうけど、
徐々にviewの部分が移行していく流れだと思う
下手すると、cの部分も
本当に最後まで残るのは、モデル層だけだろう

551 ：デフォルトの名無しさん：2013/04/05(金) 21:41:16.25

今後流れがjavascriptに来るだろうというのは
確実に分かる
現在のライブラリの乱立がその徴候
今はその動きの中にいる人だけが気がついてる状態だが
これがやがて、本流になる

552 ：デフォルトの名無しさん：2013/04/06(土) 00:15:09.70

サーバーサイドがhtmlではなくxmlでデータを返すに留まり
Ajaxで何でもやるなら既存のMVCフレームワークの延長でもできそうだな。
(ViewがXMLになり、XML/HTMLは互換性がある)
GWTとかPlayみたいなオレオレ色の強い独善的FWよりそっちがいいかもしれん。

だがサーバーにフレームワークが必要ないって意味不明。
クライアント側でjavascriptがJSONからHTML組み立てる言われても
誰がクライアントに渡すJSON/XMLを作るんだ？
まさかクライアント側のjavascriptがSQL発行してjson作るのだろうか？

553 ：デフォルトの名無しさん：2013/04/06(土) 00:35:34.78

今後はクセモノであるHTTPセッションを
クライアント側メモリに持ち込むのも増えていくだろうけど、
クライアントがスマフォとかだと大きいキャッシュデータとか無理だし
サーバー側でセッション作る必要がある。

554 ：デフォルトの名無しさん：2013/04/06(土) 01:04:28.16

インタラクティブな処理が必要な場合に、
クライアントサイドでのタスクを増やすってのがJSの使いどころ

このスレのJSやnode.js推してる人は、すべてクライアントサイドで
やる方向にいくと思ってるところが大間違い。
デメリットがわかってない。
必要のない場所でまでJSでやったら開発コストも増すし
ブラウザの互換性というやっかいな問題が現れる。

555 ：デフォルトの名無しさん：2013/04/06(土) 01:06:01.26

ダイナミックHTML時代のままで大いに結構
Ajaxまでは求めちゃいないよ

556 ：keisuken：2013/04/06(土) 01:24:33.06

ちょっと勘違いもあるかなと思うけど、今後は両方で進んでいくことはほぼ間違いないと思うけどな。
* ブラウザがFORMでPOSTしサーバがHTMLを返す
* ブラウザがAjaxでPOSTしサーバがJSON/HTMLを返す(JSONの場合はJavaScripotがDOMなどに適用する)
RESTful坊は後者に偏りがちで
* ブラウザの処理が重たくなる
* JavaScriptに対応していない端末で動かない
という欠点もあるんだけど
* サーバ側がかなりシンプルになる(Web APIの提供)
* 場合によってはレスポンスデータが小さくなる
などの利点もあって別に間違った方法でもないし、実際そういうサイトはいくらでもある。

JavaScriptでの開発が煩雑になり、開発しにくくなるというのも間違っていないのだが、
Wicketみたいにある程度フレームワークが解決してくれることもあるし、
今時のJavaScriptライブラリ/フレームワークは昔より良くできていることが
多いので案外どうにでもなっちゃう印象ですね。

特にスマートフォン対応だとむしろJavaScriptを使わないことが(主にレスポンシブや
アニメーション, レイテンシなどで)しょぼく感じてしまうケースもあるので
もう無視できなくなってると思う。

557 ：デフォルトの名無しさん：2013/04/06(土) 01:30:00.65

HTMLを返す処理はなくならないが
フレームワークの要不要はまた別問題だな
俺はいらんと思うけど

558 ：デフォルトの名無しさん：2013/04/06(土) 01:33:29.51

ブラウザで多くをやる方法は限界やデメリットがある以上、
サーバ側のフレームワークにとって代わることはない。

JavaのWebフレームワークのスレなのにスレ違いのレスばっかりになってる。

559 ：デフォルトの名無しさん：2013/04/06(土) 01:34:45.31

>>553
>今後はクセモノであるHTTPセッションを
>クライアント側メモリに持ち込むのも増えていくだろうけど、

セキュリティホール確定。
クライアント側は当然偽装し放題ですよ。

ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも）
なので、見えないページはムカつきつつ閉じてます。
わざわざ開く価値なんてないし。

560 ：デフォルトの名無しさん：2013/04/06(土) 01:36:37.41

>>558
JAX-RSだってJavaのWebフレームワークだからこの流れはスレ違いじゃない
自分の意見と違うからって排他的にならないでほしいね

561 ：デフォルトの名無しさん：2013/04/06(土) 02:12:52.30

>>559
いまどきJavaScriptをOFFとかありえないだろ。
商品リストのページングとかSession+Ajaxでやっていたようなものにも
クライアント側が操作しても問題ないようなデータは結構あるぞ。

562 ：デフォルトの名無しさん：2013/04/06(土) 02:19:09.71

>>559個人がどうするかは>>559の自由だから放っておいてやれw
ようはJS無効にしてるユーザを救うことによって得られる
利益とかかるコストをそれぞれのサイトがどう評価するかだ

563 ：デフォルトの名無しさん：2013/04/06(土) 02:24:58.73

クライアントJavaScriptでバリデーションをするとか嫌だな。
たとえば登録フォームだとパスワード半角英数8桁とか以外にも
同じ名前が既に登録されているのかとかチェックするときがありうる。
そうなるとデータベースとバリデーションが関連するわけで、
Ajaxを通すのは良いとしてもバリデーション自体は鯖側で行うべきだ。

564 ：デフォルトの名無しさん：2013/04/06(土) 02:51:01.86

クライアントから投げられる値なんて基本的に信頼できないからサーバ側でのバリデーションは
いつまでたっても必須だよ。ただsubmitする前にキー入力に応じてダイナミックにバリデーション
したい場合などはJavaScriptを使ってブラウザ上で「仮」バリデーションする場合もあるというだけ。

ただこれするには同じバリデーションロジックをJavaとJavaScriptでそれぞれ書くことになるので
二度手間になる。この点でGWTは地味に便利だった。Javaで書いたロジックをJavaScriptに変換して
ブラウザ上で使うから二度手間にならないし、Java上でロジックを書き換えるとそのままクライアント
側のロジックにも反映されるからロジックの同期も楽。

というわけでJavaからJavaScriptへのコード変換はそろそろjavaxとして仕様化すべきだと思う。
あるいはJava -> JavaScriptの変換を行う定番トランスレーターがデファクトで決まるのでも良い。

565 ：デフォルトの名無しさん：2013/04/06(土) 04:45:17.33

>>564
で、だったらはじめからサーバーもjavascriptで書けばいいじゃん
という流れになったりしてな
node人気が出てきたみたいだし

566 ：デフォルトの名無しさん：2013/04/06(土) 06:06:19.09

>>563-564
そうそう。
セキュリティ上の理由で、サーバ側でやらないといけないもの
があると書いたのはそういうValidationとか。

クライアントサイドのValidationは仮のチェックだね
レスポンスを高めるだけのものでしかない。

クライアントに渡した時点で汚染された（信頼できない）データに
なってしまうし、再度DBに入ってくるようなデータは渡したくない。

全部クライアントサイドでやる流れ、とか言ってる人は
セキュリティの観点が頭にない。

567 ：デフォルトの名無しさん：2013/04/06(土) 06:17:19.79

>>566
バッカだねぇ、「全部」クライアントでやる流れなんて誰が書いた？
サーバ側でバリデーションが必須なんて当たり前すぎて議論の余地無しだよ
JAX-RS使うとバリデーションできないとでも思ってる？
BeanValidatorはMVCフレームワークと密結合してるとでも思ってる？
レベル低すぎて相手にするのやめようと思ったけど想像以上の低さに驚いたよ

568 ：デフォルトの名無しさん：2013/04/06(土) 06:24:52.99

つーか「StrutsとJSPの時代が終わる」と書いた>>523でもJAX-RSのこと書いてるのに
なんで>>545みたく「サーバサイドのフレームワークがなくなることはありえない」
なんて的外れの反論しちゃうのかねぇ
あげくに「全部クライアントでやる流れ」とか誤読どころの話じゃないだろ
こんな文盲で仕事できるのかね？

569 ：デフォルトの名無しさん：2013/04/06(土) 06:26:42.29

>>567
自分の発言読み返してみろよ
そう読み取られてもおかしくない表現してる

>>523なんてアホ発言そのもの
他にもnode.jsの時代になってるだの妄想垂れ流しすぎ

570 ：デフォルトの名無しさん：2013/04/06(土) 06:27:53.82

>>568
おまえはJSスレに帰れよ
完全にスレ違い

571 ：デフォルトの名無しさん：2013/04/06(土) 06:29:14.15

一度スマホのネイティブアプリとだけつながるサービスの開発でもやってみると
（何が必要か考えるだけでも）知見も広がっていい経験になるんじゃないすかね？

572 ：デフォルトの名無しさん：2013/04/06(土) 06:32:39.84

>>569
具体的に指摘してみろよ
どこに「全部クライアントでやる流れ」と読み取られておかしくない発言がある？
Node.jsの時代になってるってのもどこにある？

573 ：デフォルトの名無しさん：2013/04/06(土) 06:43:39.54

>>572
誤解されてもおかしくない表現力だよ
他の人もそうとらえてる人がいる。

>>543もあんただろうけど滅茶苦茶

＞最初は静的なHTMLで始まる（Javaで返す必要はない）
それができない場面もあることはすでに書かれていたよな？

＞まだそこまで極端なケースは少ないけど方向はこっち
ほら、ここで自分でいってるだろう。
使えない場面がたくさんあるのに「方向はこっち」とか言ってる。

あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。
自分ではないいうのなら自分のレス番号全部書くなりトリップつけないとわからない。
この板はIDでないから

574 ：デフォルトの名無しさん：2013/04/06(土) 06:55:48.45

>>573
> 他の人もそうとらえてる人がいる。

他の人じゃなくてさ、君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ

> それができない場面もあることはすでに書かれていたよな？

できない場面「も」あるから何？

> 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。

「たくさん」っていうのは君の主観だね

> あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。

そもそもどのレスがNode.js推しなんだよ？
ちなみに>>524は俺だよ。Node.js推してるように読めるか？

575 ：デフォルトの名無しさん：2013/04/06(土) 07:03:44.94

>>574
>>524は別人だと思ったよ
俺とかいわれてもIDでないしわからない。

＞君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ

散々書いただろ。めんどくさいやつだな

あんたの発言がどのレスだか判別つかないことくらいわかってくれ。
俺のレスもすべてはわからないだろう。

576 ：デフォルトの名無しさん：2013/04/06(土) 07:25:47.54

>>575
「散々書いた」ってどこにあるんだよw
具体的に指摘する気はないみたいだからこれ以上は追求しないが、
勝手に拡大解釈して文句をつけるのはもうやめてくれ

577 ：デフォルトの名無しさん：2013/04/06(土) 07:33:12.04

>>576
散々書いたってわからないって？
俺もお前のレスがどれだかわかんないのよ
IDでないから
そういうしょうもない掲示板でまともな議論なんてできないの

578 ：デフォルトの名無しさん：2013/04/06(土) 07:37:32.20

>>577
あぁ、続ける気なんだ
別に「俺の」じゃなくていいからさ、君がどのレスのどの表現から
「全部クライアントでやる流れ」と読み取ったのか教えてよ
寝ぼけててもできる簡単なお仕事だろ？

579 ：デフォルトの名無しさん：2013/04/06(土) 07:42:19.34

>>572
「APIだけ作る流れ」
「HTMLを返す必要がなくなってきてる」

580 ：デフォルトの名無しさん：2013/04/06(土) 07:42:23.42

>>576
ちなみに俺は「君が」書いたレスかどうかは「気にしないで」読み返したけど
どこに「散々書いた」のか見つけられなかったよ
突然飛躍してるレスしか見あたらない

581 ：デフォルトの名無しさん：2013/04/06(土) 07:47:57.92

>>578 >580
しつこいなぁ、あんたも
「続ける気なんだ」どころか真逆だわ
IDでないしょうもない掲示板でまともな議論なんてできないってかいたろうに

IDでないんだから違う相手に反論してるなんてことあるだろ？
だからこれだけレスもついたし、検証作業なんてやりたくないの。
全員が正直に自分のレスを書いてトリップ書いたりしないと今となってはわからない。

582 ：デフォルトの名無しさん：2013/04/06(土) 07:49:57.54

>>579
それかよ（失笑）
Twitterが「API」も提供してのはもちろん知ってるだろ？
Twitter4Jとかあることくらいは知ってるだろ？
そのAPIはHTML返さないのも知ってるだろ？
じゃあTwitterのAPI叩くとTwitterのサーバじゃバリデーションも行わず、
「全部クライアントでやる」と思ってる？
違うだろ？冷静に考えてみてくれ

583 ：デフォルトの名無しさん：2013/04/06(土) 07:52:13.77

>>581
別に違う相手でも構わないよ
>>579にしたってさっきまでの誰かと同じかどうかはどうでもいい
それで議論できないなら半年ROMってろ

584 ：デフォルトの名無しさん：2013/04/06(土) 07:54:41.95

>>580
581 だけど>>579の人とは別人だぞｗ
ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ？
だれかJS押しの必死な人がいるように見えるわけ。
でも、IDでないから同一人物かすらもうわからないわけ。
くだらないだろ？

無意味なレスばっかりになってる上にスレ違いだから、
クライアントJSの話題はJSのスレでやってくれ

585 ：デフォルトの名無しさん：2013/04/06(土) 07:56:09.01

>>582
スレ違い。荒らしになってる。
冷静にスレタイを読めとしか言えない

586 ：デフォルトの名無しさん：2013/04/06(土) 07:59:59.38

>>582
喧嘩してるとこ横レスして混乱させてすまんかった

JSONを返す流れについていってないやつは遅れてるとか
HTMLを返す仕事してるやつを小馬鹿にする発言もあったしなあ

じゃあバリデーションやデータの受け渡し以外は
全部クライアント側でやる流れってことでいいの？

587 ：デフォルトの名無しさん：2013/04/06(土) 08:01:53.46

>>585
JAX-RSはWebフレームワークだからスレ違いじゃないだろ
それともここはHTMLを返すフレームワーク限定なのか？
スレタイにも>>1にもそんなこと書いてないのに？自治厨？

588 ：デフォルトの名無しさん：2013/04/06(土) 08:10:29.51

>>587
スレ違いといってるのはクライアントサイドのJS

フレームワークという言葉を拡大解釈して、
スレ違いではないと強弁するのはやめたほうがいい

589 ：デフォルトの名無しさん：2013/04/06(土) 08:25:56.10

>>588
俺のに限らずクライアントJSの話が主のレスなんてほとんどないだろ
どのレスがスレ違いなんだよ

「フレームワークって用語を拡大解釈」ってJAX-RSに対して言ってる？

590 ：デフォルトの名無しさん：2013/04/06(土) 08:26:15.04

サーバーサイドで書かれていたビューロジックやコントローラー内の一部のロジックがJavaScriptで
クライアントサイドに書かれるようになりつつあるのは誰も否定しないと思う。

ではそれがどこまで行くのか、と考えると、まずビジネスロジックを実装したモデルやサービス層は
当面はサーバーサイドに留まる。クライアントの正直さを保証する仕組みが無いので。

ではそれ以外はクライアントに移るのかと問われると、それもやや期待過剰かなと個人的には思う。

正直今のHTML5やモバイルアプリからガンガンREST云々を叩いてクライアント側で動的に表示を
更新する仕組みは一昔前のRIAの流行の再放送を見る感じなんだよね。Flashその他でUIを作って
サーバー側をRPCで叩きまくった時代の(当時はBlazeDSとかSOAPとかだったけど。SOAP好き)。
サーバーからはJSONだけ返してHTMLはクライアントで組み立てる、というのも死産に終わった
クライアントサイドXSLTの夢を思い出させる。

なので問題点も未だに概ね共通していて、一つは検索サイトにインデックスされない、もう一つは
ハイパーリンクが難しい(モバイルアプリなんかは特にそう)。画面状態をURLに対応づける仕組みは
RIAの時代からあったけれども、それには単にUI作る以外の一手間が必要なことは今も昔もそれほど
変わらないし、DOMをグリグリいじくるのに夢中でその辺無頓着な開発者も多いような。
REST API等々使ってインタラクティブなWeb UIを作るのは簡単。でもREST APIにどっぷり依存
しながらそれ自体は全然RESTではないウェブアプリも少なくない。
さらにクライアントサイドでのHTML変換よりサーバーサイドでやった方が安全確実しかも簡単
でしょ、というのXSLTでの教訓。

このあたりの過去の教訓をちゃんと意識しないと、流行はともかく定着はしないと思う。

591 ：デフォルトの名無しさん：2013/04/06(土) 08:30:14.26

丁度今、JS側で色々やろうとして結果として中途半端な構成になっているプロジェクトに入ったので
JS側のFWを調べているところなんだだけど、正直、まだ時期早々だと感じている

View構築に関してサーバサイドFWからの依存を排除したい理由は
どうもネイティブアプリ化を睨んでいるみたいで、その主旨は理解したんだけど
まだ、そういった要件に完璧に応えてくれるデファクトなFWが存在していない
backbone.jsでは機能が足りないし、jQuery mobileは逆にサーバサイドに依存して作った方がやりやすいし
JSによるView機能も色々触ったけど、国際化等まで考え始めたらサーバから色々情報を渡さないといけないし、
結局、クライアント側でやるのは不便としか感じなかった
「できる」んだけど、「仕事としてしっかりできる」レベルには、どのFWも至っていないという印象

他にも、もっと多機能なFWもあるんだろうけど、そういうのはjQuery以外の独自ライブラリ依存だったりして
まだまだ取り組むのにはリスクが大きい感が否めない

以前のプロジェクトでは、何もかもJSでやるのではなく、
Viewはサーバサイド任せにしてイベント関連のみJSでやっていたけど
今はそういう作り方の方が断然楽だと感じる。自分がサーバサイド暦が長いせいもあるだろうけど

592 ：デフォルトの名無しさん：2013/04/06(土) 08:33:44.14

>>589で「俺のに限らずクライアントJSの話が主のレスなんて
ほとんどないだろ」って書いた俺涙目w

593 ：デフォルトの名無しさん：2013/04/06(土) 08:37:56.40

いいんじゃないの？
今はクライアントJSまで考慮しないとどうしようもないんだから
どうせスレ違いに拘ってるのは一人だけだろうし

594 ：デフォルトの名無しさん：2013/04/06(土) 08:43:45.27

>>589
ずっと上から読み返してみ？
サーバサイドのフレームワーク不要論を唱えだした奴いるだろ
>>579 の引用がその一例

その不要論を言いだすと、Java不要論になるし
このスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定になる。

要するに、このスレもスレ住人の仕事もJavaも全否定になるから、
サーバサイドフレームワーク不要論は反論されるし、
スレ違いだと言われるわけ。

比較のためにRailsとか他の言語のフレームワークの話題でることも
あるけど荒れなかった。

違いはなにかというと、ここのスレと住人を全否定したかどうか、
だと思う。

595 ：デフォルトの名無しさん：2013/04/06(土) 08:57:23.38

>>594
>>572は>>523からの引用だが、それのどこが「サーバサイドの
フレームワーク不要論を唱えだした」？
JavaでJAX-RSでAPIを提供するサービスを作る流れっていうのが
「Java不要論になる」？「サーバサイド開発も全否定」？
頭おかしいんじゃね？

596 ：デフォルトの名無しさん：2013/04/06(土) 09:08:47.77

>>595
JSON返す流れになってるだのアホなこといってるのは
サーバサイドFW不要論そのものだろ

サーバサイド不要論唱えてる奴はいたわけ
このしつこさからしておまえの可能性高いけど

597 ：デフォルトの名無しさん：2013/04/06(土) 09:11:00.43

>>595
頭おかしいだの遅れてるだの口が悪い

598 ：デフォルトの名無しさん：2013/04/06(土) 09:15:15.54

>>596
JSON返すと「サーバサイドFW不要論」wwwwwwww
ダメだこいつw
俺とは「サーバサイドFW」の定義が違うようだが、
俺だけとじゃなくてこのスレ住人、Java開発者、Web開発者、
その他多くと違う定義だよそれ
負けたよ、さすがにもう相手にできないわwww

599 ：デフォルトの名無しさん：2013/04/06(土) 09:18:21.51

>>598
お前来てから荒れた。出てけ
このスレは遅れていて、相手にできないんだろ
はよでてけ

600 ：デフォルトの名無しさん：2013/04/06(土) 09:19:53.00

荒らしはLLスレにいたやつと同じにおいがする
これからはJavascriptの時代だってしつこいのなんの

601 ：デフォルトの名無しさん：2013/04/06(土) 09:22:13.99

このスレの連中は真面目に相手しすぎだわ

602 ：デフォルトの名無しさん：2013/04/06(土) 09:31:31.35

>>601
まったくだ
俺は>>563の時点で目眩がしたわｗ
CGI全盛時代のスレかと思ったよ

603 ：デフォルトの名無しさん：2013/04/06(土) 09:42:25.02

でも流行りに流されたほうが金になるというのもまた事実

604 ：デフォルトの名無しさん：2013/04/06(土) 09:53:37.29

Javascriptがもう少し機能的にもデザイン的にも優れものだったら、
プリミティブ型が使えて静的型・型推論・LINQ・JAXBとか持ち合わせていたら
「これからはJavascriptの時代だ」でも別にいいけどね。
ログ出力すらブラウザ互換性云々いってる糞言語は書きたくないし、
Dartとかも出力対象のJavascriptが糞すぎて未来が絶望的だろう。

WicketはJavaコンポーネントにJavascript自動生成させることで隠蔽し、
Javascriptを開発者から少しでも消し去ろうとした素晴らしいＦＷだった。
Javascriptフレームワークが乱立する現状とは逆の立場で流行らなかったが。

605 ：デフォルトの名無しさん：2013/04/06(土) 09:58:25.30

>>591
> どうもネイティブアプリ化を睨んでいるみたいで、

うちじゃ最初のターゲットがスマホアプリだけってケースが増えてる
先週ローンチしたサービスもそう（Webサイトはあるが静的コンテンツのみ）
だからブラウザ対応する場合も同じAPI叩くだけでやりたいって意見は強いね
SEO担当部署は抵抗してるが、検索サイトからの流入どころかブラウザで
アクセスする人が激減してるのが現実（もちろんサービスによるだろう）
LINEの成功もあってブラウザ対応はいらないってケースも増えそう

606 ：デフォルトの名無しさん：2013/04/06(土) 10:07:04.86

>>591
クライアントJSのMVCフレームワークが乱立してるわけだけど、
世界的には一番話題になってそうでリッチなAngularJSよりも、
日本じゃシンプルなBackbone.jsが人気あるように見えるのは、
JSFとStrutsを見てるようで興味深いw

607 ：デフォルトの名無しさん：2013/04/06(土) 10:22:53.57

>>606
apachcommons的なのなんて乱立なんてもんじゃない
手軽環境で誰でも書けるしハブとかあるからゴミが多くてフルパックじゃないとスタンダードになりえない
馬鹿でも書けるから調べて類似見つけて拡張依頼やコミッタ申請なんて事も少ない
アンドロマーケットと一緒

608 ：デフォルトの名無しさん：2013/04/06(土) 11:33:00.31

XML+XSLTが攻守最強だな
リッチクライアントでもブラウザでも行ける

609 ：デフォルトの名無しさん：2013/04/06(土) 11:34:57.01

もうそういうのやめてくれ
ネイティブが一番いい。

610 ：デフォルトの名無しさん：2013/04/06(土) 16:34:25.16

とりあえずJAX-RSに関してはあまり否定的な意見は出てこないな。

611 ：デフォルトの名無しさん：2013/04/06(土) 22:01:52.60

評価保留って感じじゃないの、2.0になってから本番な感じだし

612 ：デフォルトの名無しさん：2013/04/06(土) 22:08:36.83

JAX-RSの否定ではないが、各実装固有の機能を使わないと微妙、っという点は多々ある。

613 ：デフォルトの名無しさん：2013/04/06(土) 22:14:28.20

JAX-RSはシンプルでいい
標準だけじゃ足りないって意見はあるが重厚よりはいい
各実装の独自機能も自前で作るよりはいい

JAX-RS 2.0（JSR 399）見たけどフィルターや
インターセプターが標準に含まれてるね
Bean Validationとの連携も入ってた
JerseyのViewable的なものは見あたらない

JSONが相変わらずJAXBなのだけ残念だわ
Java API for JSON Processing（JSR 353）はどうしたと
思ったら、あれマッピングは含まれてないんだと
Jerseyのjson.POJOMappingFeatureを使い続けることになりそうだ

614 ：デフォルトの名無しさん：2013/04/06(土) 22:35:44.41

JAX-RSに限らないんだけど、JSRと実装とか馬鹿な事はさっさとやめて、今ある各実装の良いとこどりしたMVC機能も持った単一の実装を作ってよ。
そしたらSpring MVCから乗り換えるのに。

615 ：デフォルトの名無しさん：2013/04/07(日) 00:45:35.77

サーバーサイドはvalidation等のセキュリティ関連と、
データベースだけ残るだろ
あとは全部クライアントサイドに行く
それにサーバーサイドもjavaがやってる部分はnode.jsに置き換わるよ

616 ：デフォルトの名無しさん：2013/04/07(日) 00:48:56.77

ないない。Javaが持つ膨大なライブラリをカバーするのに何年かかんだよ

617 ：デフォルトの名無しさん：2013/04/07(日) 00:51:23.43

もう既にカバーしてるし、できないこともたくさんできてしまってる

618 ：デフォルトの名無しさん：2013/04/07(日) 00:53:08.10

釣る気満々のレスに速攻で釣られるなよ

619 ：デフォルトの名無しさん：2013/04/07(日) 00:55:43.89

>>615
またJS信者湧いてるのかよ

620 ：デフォルトの名無しさん：2013/04/07(日) 00:59:31.13

node.jsなんてlibuvだけだろ

621 ：デフォルトの名無しさん：2013/04/07(日) 01:08:38.35

ここ見てオシッコちびるなよ？
http://www.nodecloud.org/

622 ：デフォルトの名無しさん：2013/04/11(木) 07:24:36.04

Javascript云々のくだらない流れで過疎ったぞ

623 ：デフォルトの名無しさん：2013/04/11(木) 10:27:17.03

【超速報】 Java8、仮想マシンに.NET/Mono採用検討開始　－　プログラミング界に激震
http://engawa.2ch.net/test/read.cgi/poverty/1365643043/

624 ：デフォルトの名無しさん：2013/04/11(木) 10:43:32.25

Mono、のちのちMS.netランタイムでjarが動くようになるなら
Javaデスクトップアプリケーションにはありがたいなぁ。

625 ：デフォルトの名無しさん：2013/04/11(木) 10:49:37.28

でも .class → JVM → .NETランタイム(CLR)ということで、変換が二重になってパフォーマンスが悪い、
ということにはならないのかな。

626 ：デフォルトの名無しさん：2013/04/11(木) 10:52:56.26

何事もネイティブが一番

627 ：デフォルトの名無しさん：2013/04/11(木) 12:21:34.13

IKVMはありえんよ、最悪の選択肢

628 ：デフォルトの名無しさん：2013/04/11(木) 17:51:08.92

最良の選択肢はjavascript

629 ：デフォルトの名無しさん：2013/04/11(木) 19:46:00.52

マルチパラダイム対応が一番。
Java、Scala、Groovyを自在に混ぜて使えばよいし、それはさほど難しくない。

630 ：デフォルトの名無しさん：2013/04/12(金) 01:22:11.91

ScalaとかGroovyとかいらんよ
Java周辺は勉強してもすぐ消えていくから信用ならない

631 ：デフォルトの名無しさん：2013/04/12(金) 01:57:44.58

ScalaやGroovyをちょっと勉強してみたら
とてもそうは思えなくなる
やっぱり利便性が全然違う

632 ：デフォルトの名無しさん：2013/04/12(金) 07:12:38.76

>>622
JS推してたうざいやつのせいだな

>>623
Monoはまず品質をなんとかしてほしいわ
MS純正版との互換性がなさすぎてMono版のASP.net MVCは
使いものにならなかった。

633 ：デフォルトの名無しさん：2013/04/24(水) 21:18:24.48

Java8延期された
Java 8 Delayed to 2014 by Ongoing Security Woes
http://www.infoq.com/news/2013/04/Java_8_Delayed

634 ：デフォルトの名無しさん：2013/04/26(金) 23:42:43.59

>>632
どうやったらlinuxServer＋ASP,netとかアホな構成を選べるのかわからんけど実務で使ってるアホいるんだぜ？

635 ：デフォルトの名無しさん：2013/04/27(土) 23:37:45.83

EE7がそろそろ？

636 ：デフォルトの名無しさん：2013/04/28(日) 23:31:36.49

JavaEE使いづらいよママン…

637 ：デフォルトの名無しさん：2013/04/29(月) 08:26:27.28

使いづらいものをなんでわざわざ使おうとするの？、Mなの？

638 ：デフォルトの名無しさん：2013/04/29(月) 09:28:07.82

>>637
フレームワークの選択権限俺じゃないんだよ・・・。
そりゃ俺ならSpringMVCかSASｔrutsにするよ…。

639 ：デフォルトの名無しさん：2013/04/29(月) 11:26:27.70

上がアホだとどうしようもないよな

640 ：デフォルトの名無しさん：2013/04/29(月) 11:28:42.07

ﾌﾟｯ､バーカｗ

641 ：デフォルトの名無しさん：2013/04/29(月) 12:00:06.81

>>640
なんだこいつ

642 ：デフォルトの名無しさん：2013/04/29(月) 14:01:22.83

>>638
SpringもJavaEEつかってるんじゃないの？

643 ：デフォルトの名無しさん：2013/04/29(月) 17:22:34.76

なに言ってんだおまえは…。

644 ：デフォルトの名無しさん：2013/04/29(月) 20:09:51.80

>>642
・・・
開発をSpringMVCでやるかSAStrutsでやるか
標準のJavaEEでやるか？っていう話だと言えばいいのか？
SpringMVCの中身の話ではない。
単に何で開発したいかと言うことだ。

645 ：デフォルトの名無しさん：2013/04/29(月) 20:25:40.36

>>644
SAStrutsなんて日本でしか使われてないやつでしょ？
新規でそんなの使う意味がわからない

646 ：デフォルトの名無しさん：2013/04/29(月) 20:29:28.26

http://dev.worksap.co.jp/Members/inoue_se/archives/38

JavaOne参加者は、JavaEE利用者とSpring利用者が半々くらいだったらしい。

JavaEEはJavaEE5以降でSpringを取り入れてきているとも書かれてる。
純正JavaEEでやる人がまた増えてきてるということじゃないの

647 ：デフォルトの名無しさん：2013/05/01(水) 17:20:11.87

>>645
世界で戦ってるわけでもあるまいが…。

648 ：デフォルトの名無しさん：2013/05/01(水) 17:53:07.34

Authentication/Authorizationには皆さん何使ってる？

社内システム用にSpring Securityを使い始めたもののなんか微妙。

649 ：デフォルトの名無しさん：2013/05/01(水) 19:04:34.20

Spring使ってるけどSpring Securityは微妙。
認証・承認って、結局システム固有の要素が入ることがほとんどなので、自分はそこはいつも自前。

650 ：デフォルトの名無しさん：2013/05/01(水) 19:08:13.20

今更SAStrutsを奨めもしないけど、海外でどうだからという話は無視して良いと思う。
禿とかがそういうdisりをしたりもするけど。

自分のニーズにあったものを選択するのが基本。

それに海外ではどうこういうなら、海外の人は細かい部分にルーズだ、みたいな話だってあるし。
それでJSFやJPA実装の細かい部分が微妙だったりとか。

651 ：デフォルトの名無しさん：2013/05/01(水) 20:26:41.12

さてJavaEE7きましたよ。

652 ：デフォルトの名無しさん：2013/05/02(木) 13:40:33.64

>>651
どこにきたの？
http://www.oracle.com/technetwork/java/javaee/downloads/index.html

653 ：デフォルトの名無しさん：2013/05/02(木) 14:39:16.33

https://blogs.oracle.com/theaquarium/entry/java_ee_7_platform_completes

654 ：デフォルトの名無しさん：2013/05/10(金) 10:39:23.30

>>650
細かい部分にルーズにしては、国産FWが少ないし
Springに比べてS2Forumのアーティクルは少ねぇよなぁ

ほんとに海外について知ってるつもり?

655 ：デフォルトの名無しさん：2013/05/10(金) 11:33:01.75

良いものは海外でも流行る。
日本限定のマイナーなフレームワークなんかつかうと
すぐにメンテ終了になってしまう

656 ：650：2013/05/10(金) 12:38:17.38

俺は「世界ではJava EEが標準です(ｷﾘｯ」みたいな発言を真に受けたり引用したりするのはやめれというだけで。
別に国産FWが良いと思っているわけじゃないよん。

657 ：デフォルトの名無しさん：2013/05/10(金) 13:07:44.12

俺が作ったフレームワークがどう考えても最高

658 ：デフォルトの名無しさん：2013/05/11(土) 09:13:44.19

>>656
何でやめなくちゃいけないんだ？
事実は事実のまま捉えろよ

659 ：デフォルトの名無しさん：2013/05/11(土) 10:26:19.98

JavaEEは最高のフレームワークです(ｷﾘｯ
ほかのフレームワークを使っている奴らは無知なだけのｶｽ

660 ：デフォルトの名無しさん：2013/05/11(土) 10:35:01.25

フレームワークがないと作れないやつって不幸だな

661 ：デフォルトの名無しさん：2013/05/11(土) 15:17:14.27

標準って用語は多重定義されてるからな
JavaEEが標準仕様なのは事実だしデファクト標準じゃないことも事実

662 ：デフォルトの名無しさん：2013/05/11(土) 15:41:42.22

依存性管理はそろそろデジュール標準でいって欲しいな。
そんで依存性ツリーを持たないAntプロジェクトとか撲滅して欲しい。

現状リポジトリはほぼMavenリポジトリがデファクトで、依存性解決はMavenの他に
ivyやGradle等といった複数の実装があるわけだけど、実装毎に微妙に解決した結果
が異なったりとか依存性の記法が異なるとかちょい勘弁。

って何時だよProject Jigsaw使えるようになるの。

663 ：デフォルトの名無しさん：2013/05/17(金) 20:56:32.32

うちなんて未だにApache Ant + CVSだよ
今年の予定がSubversionの適用とか10年遅れてるわ

664 ：デフォルトの名無しさん：2013/05/17(金) 21:51:50.52

もうSubversionはスキップしていいでしょw
GitやMercurialにすればよいのに。

665 ：デフォルトの名無しさん：2013/05/18(土) 01:26:59.84

>>663
昨年までEclipseとファイルコピーで何とかしてた俺よりましだな。
さすがに最近Git入れたけど。

666 ：デフォルトの名無しさん：2013/05/20(月) 08:38:34.64

CVSと用語の使い方が似ているとか長く使われて実績があるって意味ではSubversionもありはありだけど、それ以外に取り柄が無いよなぁ
分散リポジトリは概念説明からスタートだからめんどくさいとかあるのかな
構成管理担当のスキル不足で使いこなせないなんて笑えない理由だったら笑うがw

667 ：デフォルトの名無しさん：2013/05/20(月) 22:57:38.89

トラブルが起こらないという意味ではsubversionで十分かもな
Mavenとかだと、やれプロキシの設定だの、レポジトリが無いだの、
新しく入ったメンバーが自分で設定できないだの、
依存性が解決できないだのと、問題がつきもの

668 ：デフォルトの名無しさん：2013/05/21(火) 02:38:48.74

とのVCS(Subversion, Git, Mercurial, etc.)を使うかと、どのビルドツール
(Ant, Maven etc.)を使うかは基本的には直交した問題じゃないかな。

経験上ビルドツールに関してはMavenを使った方が新人対応も楽。なにせ手動で
インストールする必要のあるものを圧倒的に減らせるので開発環境の立ち上げが
楽だしメンバー間でのバージョンの同期もし易い。
Mavenの設定と言ってもひな形のsettings.xmlをコピペして社内Artifactory使う
クレデンシャルの設定だけを個々人で書き換えてもらう定型作業なので、ちゃん
と話を聞かなかったり勝手に先走る新人を除いてははまった経験もあまりない。

新人対応の面でMavenを避ける理由はあまり思いつかないかなぁ。単純に社内の
プロジェクトがAntベースか既にMavenizeされているかの問題ではないかと。

新人対応に関してはむしろVCSが問題で、GitやMercurialを使った経験のない
新人は戸惑う事が多い。updateやcommitだけしてpullやpushを忘れるのは定番
として、ブランチを切って開発するスタイルに慣れていないことが多いので。
こちらはJira等を使ったチケットベースの開発のサイクルとセットにして最初
から丁寧に手順を伝える必要がある。

669 ：デフォルトの名無しさん：2013/05/21(火) 04:14:23.88

手動でインストールって何のことだ
eclipseのフォルダごとコピーして終わりだわw

670 ：デフォルトの名無しさん：2013/05/21(火) 05:31:35.94

>手動でインストールって何のことだ

まずはScalaコンパイラやGrailsといったビルド環境。
これらはMaven Pluginが勝手にビルド環境をダウンロードしてくれるのでScala等を
インストールしてEclipseに登録したりせずともプロジェクトのビルドはすぐ出来る。

実際にScalaやGroovyでの開発担当が回ってきた場合は結局Scala等をインストールして
Eclipseにプラグイン入れないと不便だけれども、その場合もMavenを使って実行する
ビルドやテストでは必ずpomに書かれたバージョンのビルド環境が使われるのは便利。
Jenkins等でビルドするのにもJenkinsにプラグイン入れるよりMaven任せが楽だと思う。

もう一つは複数のプロジェクトで横断的に使われるフレームワークやcommons、log4j
といったライブラリのJar。これらのJarをローカルにインストールしてクラスパスを
通しておく方式は手間だし開発者間でバージョンの同期がとれない。
プロジェクトのlibフォルダにJarを放り込んでVCSで同期する方式だとプロジェクト間
で違うバージョンのJarが使われているとやはり面倒で、そのチェックも大変。

というか膨大な数のJarに依存する昨今のJavaフレームワークを依存性解決ツール無し
で使うのは無駄に大変だと思う。

671 ：デフォルトの名無しさん：2013/05/21(火) 08:17:14.09

え、scalaやgradleなんて何から何までeclipseプラグインが用意してくれるし、
eclipseプラグインはローカルフォルダごとコピーすればついてくるがな

672 ：デフォルトの名無しさん：2013/05/21(火) 09:38:09.94

GradleじゃなくてGrailsね。
Scala IDEはともかくSpringToolSuiteは手動でGrailsを落としてきてEclipseに登録する必要が
あるし、何れにしても本格的に開発するときはコマンドラインツールやIDEの支援がないと何かと
不便なので結局これらやプラグインは手動でインストールすることにはなる。

ただEclipseプラグインに頼った場合は適切に設定されたEclipse環境が無いとビルド出来ないけど、
Mavenプロジェクトは基本的にはmavenが走れば概ね無難にmvn単体でビルド出来る。これ重要。
なので素のEclipseでもm2eclipseだけ入れてもらえればあとはプロジェクトをチェックアウトする
だけで無難にEclipse上でもビルド出来る。Eclipse等とは無関係にビルドに必要な情報は全部pom
に集約されているから環境の違いによるブレが少ない。便利だと思うけれどもなぁ。

Eclipseフォルダのコピーはやらないなぁ。人によって設定も必要なプラグインも異なるし。
プロジェクト内の.projectとか.settingsの類も基本的にはバージョン管理から外す。

673 ：デフォルトの名無しさん：2013/05/22(水) 01:17:21.75

複数人開発するならMavenで管理するがいいと思うけど、
1人身開発だとあんまり利便性がない気がする・・・。

まあ、一人で開発してる俺みたいなのは少数派なんだろうけど。
単に開発者いないだけだし。

674 ：デフォルトの名無しさん：2013/05/22(水) 04:34:46.93

一人で開発する場合も依存性管理は便利だけど。
ライブラリのパッケージを手動で落としてきて展開してJarをコピったり
プロジェクトのビルドパスに登録したりとかもう今更。

Eclipseプラグインをupdateサイトからではなく手動でzip落としてきて
インストールしたり、aptの類を使わずにtarballに固執する程度には
使わないのは勿体ないなぁと思う。

確かに凝ったビルドをし出すと俄然ややこしくなるしモジュールの切り分け
などに頭を使うけど、その他の大多数の定型的なビルドに関してはMavenは
すごく楽だと思う。

675 ：デフォルトの名無しさん：2013/06/04(火) 23:22:07.93

Mavenはリポジトリ整理してくれ、マジで

676 ：デフォルトの名無しさん：2013/06/11(火) 00:05:31.57

iBATISのTypeHandlerがどこでどう使われてるかわかんねえ
まあSqlMapConfigがどこで呼び出されてるか分からんだけかもしれんが

677 ：デフォルトの名無しさん：2013/06/11(火) 08:27:17.02 ID:1XCWfLQq!

JAX-RSは便利だと思うのだけど、JSONを使い始めた途端に使い始めた途端にJettisonとJacksonの
違いとか微妙な設定パラメータのさじ加減とかが影響してくるのが凄く残念だ。
JAXBを使ってrepresentationにXMLを使っている限りは入出力のフォーマットの揺らぎもなくカッチリ
しているのに。

678 ：デフォルトの名無しさん：2013/06/12(水) 02:00:37.01

所詮はJava標準ってことよ

679 ：デフォルトの名無しさん：2013/06/12(水) 04:25:05.76

各種ideが対応しだしたらee7も本番かねぇ

680 ：デフォルトの名無しさん：2013/06/12(水) 04:43:54.25

EE6から素晴らしく進化したわけでもないし空気のままだろ

681 ：デフォルトの名無しさん：2013/06/12(水) 07:28:44.96

正直SpringからEE7に移る元気がわかない。

682 ：デフォルトの名無しさん：2013/06/13(木) 23:56:53.35

Springはそれなりにとっつけるが
正直JavaEEはいまだに敷居が高い。

683 ：デフォルトの名無しさん：2013/06/14(金) 22:30:34.36

JavaでRESTならJAX-RSが一番かな？

684 ：デフォルトの名無しさん：2013/06/15(土) 06:09:59.79

無難にJAX-RSだろうね。解りやすいよ。
ただし上でも少し書いたけれども、representationにJSONを使う場合は要注意。

JerseyもCXFのデフォルトではJettison使ってJAXBアノテーション経由でJSONの
バインディングをする。大概のチュートリアルもJAXBを使っているのが多い。

これ、JAXBアノテーションをつけるだけでREST APIがXMLとJSONの両方を出力
するようになるので初めこそ凄く簡単便利なんだけど、少し複雑なJSONを出力
させようとすると「え、何でこんな出力になるの?」と、とにかく思い描いた
JSONを出力させるのにえらい苦労する。JAX-RSの問題では無いのだけれども、
カッチリしたXML Schemaを裏付けに持つJAXBと緩いJSONは相性が悪いと思う。

なのでrepresentationとしてJSONがメインなのであればJAXBはスパッと諦めて
Jacksonを使うよう強く強くお薦めしたい。
DropWizardなんかJarsey+Jackson+Jetty全部入りですぐ始められて便利だよ。

685 ：デフォルトの名無しさん：2013/06/17(月) 02:18:58.13

>>613にも出てるけどJSON-PがクソなのがJAX-RSの足引っ張ってるよな
JAX-RSってよりJersey使うって思えばいいだけだが

686 ：デフォルトの名無しさん：2013/06/17(月) 05:42:22.64

JAX-RSとSwaggerの組み合わせはマジ便利。

687 ：デフォルトの名無しさん：2013/06/17(月) 15:15:09.41

JSF1.2なんですけど、ビジネスロジック層とかDAO層からカスタム例外(RuntimeExceptionのサブクラス)を
投げられたときに、そのカスタム例外用のエラーページに遷移するにはどうすればよいのでしょうか。

web.xmlのerror-pageに
<exception-type>my.CustomException</exception-type>
って書けばいいのかなと思っていたのですが、例外はServletExceptionにラップされて
しまうのですね・・・
知恵をお貸しください。よろしくお願いします。

688 ：デフォルトの名無しさん：2013/06/17(月) 21:04:59.76

JAX-RS使ってるときのフォームベース認証ってどう実装してますか？HTTPSession使うのが普通？何かサンプルが欲しい・・・。

689 ：デフォルトの名無しさん：2013/06/18(火) 06:58:30.70

>>688
今関わっているシステムではJAX-RSアノテーションで定義したRESTリソースクラスを
一つはJetty+Jersey上に配置して、こちらはAmazon S3で使っているプロトコルと同じ
HMAC-SHA1を使った署名ヘッダで認証している。

ただこれはウェブブラウザ上からサクッとAPIのURLを叩いて結果を見たり出来ないなど
開発時にはやや不便なので、開発向けにログイン画面がついた別のウェブアプリ上にも
同じRESTリソースを配置して、こちらはウェブブラウザからウェブアプリにログインして
セッション確立したら以降は同じブラウザから署名無しでAPIを叩けるようにしている。

690 ：デフォルトの名無しさん：2013/06/18(火) 07:27:19.99

>>688
RESTの認証は例えばウェブアプリ内で動的なページ生成を生成するためにWebブラウザ
からJavaScriptを使って叩くか、システム間のRPCなどの用途でクライアントクラスを
書いて叩くかで適した方法が違うと思う。

前者の場合はログイン+セッションベースで親となるウェブアプリと認証を共用すると
認証のためのロジックをJavaScriptのコードに書く必要が無いので使いやすい。
他方でAPI Keyを用いた署名による認証にはセッションいらずのステートレスという
があって、クライアントの実装が単純になる。なので後者向けにはこちらが楽。

691 ：688：2013/06/18(火) 10:59:58.67

>>689
どもども。後者は普通にJerseyのFilter使ってセッション作ってる感じですか？

>>690
こちらもありがとう。前者の場合（WebアプリのJSクライアントからREST APIを叩く感じ）なんですけど、その場合は↑に書いたようにJerseyのFilterでセッション作るのが普通なのかな。

692 ：デフォルトの名無しさん：2013/06/18(火) 15:21:10.17

>>691
689, 690。どっちも自分なんだけれどもねw

まずJerseyのフィルタを使って「も」認証は実装できる、と思う。
カスタムのContainerRequestFilterを作って、そこに@Contextアノテーション
を使ってHttpServletRequestをインジェクト出来るので、あとはrequest
オブジェクト経由でセッション作成なりリダイレクトなりお好きなように。

ただし「も」「思う」と書いたのは、そのREST APIがJavaで書かれたウェブ
アプリの一部ならそのアプリの認証をそのまま流用出来るのでJAX-RS独自の
ContainerRequestFilter等々のフィルタを使う理由があまり無いため。
例えばweb.xmlに<filter>として登録されたフィルタを使ってアプリの認証を
しているのであれば、RESTリソースのURLパスに対しても<filter-mapping>を
登録することで同じフィルタがREST APIに対しても適用される。

689の後者の例は、ログイン等を実装したGrailsで書かれた開発者ポータルが
もともとあって、そのポータルアプリのSpringコンテキストにRESTリソースを
beanとして登録。あとはGrailsのJAX-RSプラグインまかせでなんとか。

REST API単体の開発で、web.xml等々と格闘せずにJAX-RSのアノテーションで
なるべく済ませるのであればJAX-RS独自のDIやフィルタを使うと良いけれども、
それ以外は親となるウェブアプリで使っている仕組みを使うのが良いと思う。

693 ：691：2013/06/19(水) 00:11:42.17

>>692
どもども。勉強になります。
今回はクライアント側を全部JSで作ってて、単にデータを提供するだけのサーバって位置づけなんですよね。なので特に親アプリとか無いのでひとまずJersey側で実装しちゃいました。

694 ：デフォルトの名無しさん：2013/06/20(木) 21:08:43.53

お前らほんとjs大好きだな

695 ：デフォルトの名無しさん：2013/06/20(木) 22:43:26.53

そりゃJoshiShougakuseiは大好きさ！

696 ：デフォルトの名無しさん：2013/06/21(金) 02:49:33.31

好き嫌いじゃなくて時代の趨勢だし

697 ：デフォルトの名無しさん：2013/06/28(金) 14:59:56.37

実際のところもっとJavaScriptとの連携が上手なフレームワークが欲しい。

表一つ書くにしてもサーバー側でHTML生成するのとJavaScriptクライアントサイドで
動的に書くのとでは記法が全く異なるのが面倒くさい。

698 ：デフォルトの名無しさん：2013/06/28(金) 16:15:04.96

>>697
ASP.NET MVCを使えば解決
SpringやJava EEのはるか先をいっている

時代遅れの言語(Java)とフレームワークに固執する理由はない

699 ：デフォルトの名無しさん：2013/06/28(金) 19:00:44.31

JavaEE7でやっと追いつくかな。

700 ：デフォルトの名無しさん：2013/06/28(金) 19:49:21.99

JavaEE7程度で喜んでるからお里が知れてるとか言われちゃうんだよな…。
JAX-RSにしても、3.0が出ることには満足できるものになるかもしれないけど。

701 ：デフォルトの名無しさん：2013/06/28(金) 20:02:18.47

ASP.NET MVCはすごく新しいという訳では無いけど、モダンなFWをよく研究して作ってあるので不満が少ない。
Springは時代にあわせてちゃんと変化していっているけど、実装の中身に微妙な部分が多かったり、Javaの言語仕様上の限界があるところが残念。
JavaEEは7になったと言っても、考え方が時代遅れな部分が多いし、JAX-RSとかは良いと思うけど、使いやすいレベルにまでこなれるには2.0ではまだ不十分。

702 ：デフォルトの名無しさん：2013/06/29(土) 08:06:28.59

Java EEって一口に括られるけど、
Java EEが糞って言う人達は、考え方が古い部分、考慮不足な部分を指して駄目っていうし、
Java EEが良いって言う人達は、生産性が高い部分、良い部分のみを持ち出して礼賛するので、
あんま参考にならんのよね。

703 ：デフォルトの名無しさん：2013/06/29(土) 10:35:50.94

ASP.NET MVCってJSON返すだけでも嬉しいことあんの？
て思ったけどその部分はJAX-RSが2.0でも糞だから黙る

704 ：デフォルトの名無しさん：2013/06/30(日) 13:52:53.77

長年Javaやってて ASP.NET MVC やりはじめたけど、何がすごいのかまだよくわからないよ
両方知っている人、説明求む

ただいろいろプラグイン入れるだけで、機能追加したいことが楽に書ける、というのは何となくわかってきた
(Railsで、いろいろプラグイン追加していくみたいな感じ)

705 ：デフォルトの名無しさん：2013/06/30(日) 17:52:25.19

ASP.NET MVCってASP.NETとは別物なのか
JSFはASP.NTEのパクリだったが、ASP.NET MVCはJAX-RS的なんだな
VSがknockout.js含んだテンプレート作ってくれることはわかったが、
>>697を解決できるようには見えんのう。どっか具体例ある？

706 ：デフォルトの名無しさん：2013/06/30(日) 18:00:05.37

つーか>>697を解決するのってGWTとかClojureScript、Scala.js的なやり方？
逆にJSで広まってるHandlebarsのJava版をサーバ側でも使うか？

707 ：デフォルトの名無しさん：2013/06/30(日) 22:52:41.30

そういうのはGWT的なやりかたでしか解決しないだろ。
あるいは、ASP.NETのUpdatePanelみたいなものとか、PrimeFacesとかで満足できるかどうかで。
どっちにしろ、主流にはならんと思うけどな。

708 ：デフォルトの名無しさん：2013/07/01(月) 02:08:50.85

>>704
ASP.NET MVCのコードはJavaよりかなり短くなる

CoCが重視されてるフレームワークだからありきたりな処理は
規約に従うことでコード量が大幅に減らせる。
もちろん、言語としてC#のほうが簡潔なコードがかけるという理由もある。

Scaffolding使うと、ViewとCRUD処理のコードのテンプレートを自動作成してくれる。
JavaでScaffolding使えるフレームワーク少ないんじゃない？

あとは生産性の高めるツールが揃ってる。
Visual Studioが使えること
LINQが使えること
Entity Frameworkが使えること

LINQとEFをお勉強すると、ASP.NET MVCはJavaよりだいぶ楽なのが分かると思う

709 ：デフォルトの名無しさん：2013/07/01(月) 02:17:32.11

>>705
＞ASP.NET MVCってASP.NETとは別物なのか

ASP.NET MVCはASP.NETの一部だから別物ではないんだけど、
開発のスタイルはぜんぜん違うから別物と思ってもいいかもしれない。

ちなみに、従来のASP.NETはWeb Formsと呼ばれる。
サーバコントロールをペタペタ貼ってイベントドリブンで作るスタイルね。

ASP.NET MVCではサーバコントロールとかは使わない。
だから出力されるHTMLはきれい。

MVCの場合はURLを完全にコントロールできる。
ViewStateも使わない。ポストバックなどもない。

Sessionの機能とかは共通でWeb FormsでもMVCでも使える。

710 ：デフォルトの名無しさん：2013/07/02(火) 18:20:13.46

>>708-709
それだけじゃ>>698がいうように>>697を解決できるように見えないな
VSとC#とLINQを除いたMVCフレームワーク単体としての優れた点が見えない

711 ：デフォルトの名無しさん：2013/07/02(火) 19:27:00.50

Web APIでIQueryableを返すとリクエストパラメータを処理してくれるとかあるけど、
ASP.NET MVCはあくまでMVCフレームワークだから、JSとの連携について聞きたい人に
どこかで聞いたような一般論を答えられてもな。

まあ、MVCフレームワークとしては、細かいところまで考えられていて良いものだけど。

クライアントサイドのJSを書く負荷を軽減したいという話ならば、>>706-707のように
根本的に違うアプローチじゃないと駄目じゃないかな？

712 ：デフォルトの名無しさん：2013/07/02(火) 20:01:09.71

>>711
ASP.NET MVCはクライアントサイドも楽になってるだろう

例えば、必須データのフィールドなら、データモデルに
[Required]

とAttributeをつけるだけで
サーバとクライアントサイドにValidationが付加される。
これは一例で他にもValidation用のAttributeはあるよ
ちなみに、[Required]つけるだけで、DB側のカラムも
自動的にNull不可になる。
Javaでここまで親切なのあるかね？

こういうのはJSとの連携と言っていいと思うけど

713 ：デフォルトの名無しさん：2013/07/02(火) 20:04:43.04

>>710
全体としてみたらASP.NETのが楽できるのは事実だからいいじゃないの。

VSとC#とLINQによるものは除け、というけど
そういう強みをひっくるめてMSの開発環境だよ
まとまったドキュメントとかもね

Javaだといろいろ組み合わせないといけないからほんと面倒。

714 ：デフォルトの名無しさん：2013/07/02(火) 21:04:00.58

>>712
俺もASP.NET MVC好きだし使ってるからわかるけどね。

ただ、今聞かれているのは、そういうレベルの話じゃ無くて、
サーバサイドはJSON返すだけ、クライアントサイドはJSでMVxな処理～
みたいなものを、JSを書かずに済むレベルのものってある？、
みたいな話だと思っているけど。

まあ、そんなのは誰もが一度は見る幻想、っというのが俺の意見なんだけど。

715 ：710：2013/07/03(水) 02:11:46.98

俺も幻想だと思ってるが>>698が「解決」って断言したからな

716 ：デフォルトの名無しさん：2013/07/03(水) 03:48:12.77

>>713
言いたいことは分かるがここはJavaの"Web Application Framework"を扱うスレ
.NETの話題もあっていいが比べるなら総力戦ではなくフレームワーク単体で頼む

717 ：704：2013/07/03(水) 17:10:10.52

Javaと.NET(C#)の両刀使いって結構いるんだな

おれはJava+Ruby (あとObjective-C)で、.NETは最近始めた

718 ：デフォルトの名無しさん：2013/07/07(日) 15:23:57.52

これから、Java Webアプリ開発予定なんだけど、今って何のフレームワーク使うのがお勧め？

719 ：デフォルトの名無しさん：2013/07/08(月) 01:31:58.94

>>718
お勧めできるような代物がない。
Javaを使わないのがお勧め
ASP.NET MVCのが開発生産性が高い

720 ：デフォルトの名無しさん：2013/07/08(月) 09:36:35.03

>>718
SpringかSAStrutsあたりが無難じゃないの

721 ：デフォルトの名無しさん：2013/07/08(月) 13:58:45.78

>>720
やっぱり、その辺になるか
ありがとう

722 ：デフォルトの名無しさん：2013/07/08(月) 20:00:11.34

C#推す人って受け売りコピペみたいで、本当はjavaもc#も経験ない学生さんか派遣でしょ？

723 ：デフォルトの名無しさん：2013/07/08(月) 20:03:59.68

イージーに始めるならGrailsお勧め。
お手軽SpringMVC入門編と捉えると良いかも。

724 ：デフォルトの名無しさん：2013/07/08(月) 20:26:35.96

Groovy なんて誰得…

725 ：デフォルトの名無しさん：2013/07/08(月) 20:32:30.46

ビルドにGradleは使ってるけどな。

726 ：デフォルトの名無しさん：2013/07/08(月) 21:48:23.70

groovy と Gradle と spock とかは好きだけど、
Grails はいまいち興味がわかん・・・

Grails やるくらいだったら Rails でやる(自分はRubyも書けるからだけど)

727 ：デフォルトの名無しさん：2013/07/08(月) 22:19:40.70

>>722
言語とフレームワークが区別できてないあんたのが知識ないな

C#でつかえるフレームワークはASP.NETだけではないし
ASP.NETで使える言語もC#だけではない

728 ：デフォルトの名無しさん：2013/07/08(月) 22:23:54.76

Springって英語の公式サイトみてもドキュメントが十分に
揃ってないのがいらつく。

公式ドキュメントがただのブログへのリンクで
中身が駄文だったりする。

729 ：デフォルトの名無しさん：2013/07/08(月) 22:57:12.41

マジレスすると、ここで空気を読まずにC# + ASP.NET MVCを推すのはMSシンパの気持ち悪い連中。

C#もJavaもやってるASP.NET MVC好きの人間から言わせてもらうと、
そういう人のせいでC#やASP.NET MVCにネガティブイメージを持たれるのは嫌なので、
適当なところで切り上げてほしい。

730 ：デフォルトの名無しさん：2013/07/08(月) 23:00:53.54

>>727
Javaで聞かれてるのにC#で答えてるんだからそもそも論外だろ

731 ：デフォルトの名無しさん：2013/07/09(火) 02:58:49.35

>>727
言語と統合開発環境とフレームワークが区別できてる知識ある人なら、
ASP.NET MVC単体でどこが優れてるか教えてもらえますか？
>>708じゃASP.NETとは系統が違うことしかわからないし、
>>713は区別してくれなかったし

732 ：デフォルトの名無しさん：2013/07/09(火) 05:30:21.19

Grails推したら総スカンで悲しいw

別にGroovyで全部書く必要は無くて、Javaでカッチリ書く部分とGroovyで簡潔に
書く部分を混ぜることが出来るのが魅力。
一皮むけば所詮Spring MVCなので、他のJavaプロジェクトからサービス等のBean
をコンテキストにデプロイしてVCを書けばとりあえずWebアプリが出来る。
ControllerとViewは本当に書きやすいよ。

うちはJavaで開発している資産があってそれに社内用や外向けのWeb UIをつける
のにGrails使っているけれども結構助かっている。

733 ：デフォルトの名無しさん：2013/07/09(火) 10:50:00.87

>>731
ひとことで言えば、ASP.NET系は「開発生産性が高い」
Javaよりはるかに進んでいることは使ってみればわかるよ

ここのチュートリアルでもやってみるといい
解説の動画もいっぱいおいてある。
http://www.ASP.NET/mvc
http://www.asp.net/mvc/tutorials

734 ：デフォルトの名無しさん：2013/07/09(火) 11:55:36.61

Windowsはソースを公開してないからやばい。
いつ止められてもおかしくない

735 ：デフォルトの名無しさん：2013/07/09(火) 12:38:38.85

>>734
ほんと時代遅れだな
ASP.NETはオープンソースになってる。
C#はISOで国際標準化されている。
だから突然使えなくなることはない。

Javaは、国際規格にすらなってない
Javaのがよっぽど危ない

736 ：デフォルトの名無しさん：2013/07/09(火) 12:48:32.32

Linux+ASP.NET+C#ってことか？
それは安定してるのか？

737 ：デフォルトの名無しさん：2013/07/09(火) 14:23:43.06

>>736
Mono(Linux版の.NET Framwork)のASP.NET MVC (C#)とMySQLで
実用レベルのソーシャルゲームを運用してる企業も出てきた。

連載：MonoでOSSなASP.NET MVCアプリ：
第1回　Mono×LinuxでASP.NET MVCを動かすまで (1/2)
http://www.atmarkit.co.jp/ait/articles/1303/15/news069.html

こっちのスレでも話題になってた

ASP.NET MVC
http://kohada.2ch.net/test/read.cgi/php/1331013877/

【消しゴム】MONOを使ってみるスレ4【じゃない】
http://toro.2ch.net/test/read.cgi/tech/1329023778/

738 ：デフォルトの名無しさん：2013/07/09(火) 14:47:03.20

ハローワールド程度のアプリをスクラッチから書くのに「さいきょうのふれーむわーく」を
語りたいのならともかく、Javaのフレームワークを使っているのにはバックエンドがJavaで
書かれているとかJavaが有利なアプリケーション領域での開発とかいう事情を抱えている
ことも多いわけで。

そこでASP.NETを宣伝されたところで単に「Javaとの連携に一手間かかるので却下」かな。
SOA云々とか反論するかもしれないけど、多言語プロジェクトは技術的な手間に始まって
ドキュメンテーションや開発部隊間の文化の違いなど人的要素まで含めてやはり手間。
そういう手間を上回る導入メリットがASP.NETにあるかというと、まあ大抵は無いね。

連携に一手間かかる点ではRailsその他の他言語のフレームワークも同様なので、それでも
ASP.NETを宣伝したいのであればこれら他言語のフレームワークもやっつけて最強の称号を
手にしてから出直してきて下さい。

739 ：デフォルトの名無しさん：2013/07/09(火) 14:57:39.21

>>738
言い訳してるけど結局Javaしかわかる人材がいなくて
古くさいフレームワークでやってるだけだろ

740 ：デフォルトの名無しさん：2013/07/09(火) 15:30:47.29

>>739
うちの会社の事例だと元々Pythonその他で書かれていたバックエンドの基盤を
HBaseに移行するためにJavaで書き直したんだよね。なので人材も新たにJavaで
Hadoopその他を扱える人を中心に集めたぐらい。
フロントエンドも専らDjangoだったのが社内向けのUIからGrailsを使い始めて、
社内外向けのRESTエンドポイントもDropWizardと新規システムはJavaベースが
増えている。GrailsもDWもあまり古臭いとは感じないよ。共に便利。

741 ：デフォルトの名無しさん：2013/07/09(火) 16:26:55.36

Windows に依存しない環境で実装するために Java 使ってる人や
業務システム組む時点で、原則 Java の顧客も居たりするから、
そもそも C# という選択肢が無い仕事もあるんだけどな。
必要に応じてどっちも使うから構わんけど。ここ Java のスレちゃうの？

742 ：デフォルトの名無しさん：2013/07/09(火) 17:05:50.29

>>733
ASP.NET MVCのどこが優れてるから「開発生産性が高い」とあなたは評価してるのですか？

>>739
煽るだけならお帰りください

743 ：デフォルトの名無しさん：2013/07/09(火) 17:12:02.28

THE EN

744 ：デフォルトの名無しさん：2013/07/09(火) 17:15:17.69

俺はちまちまと作るのが好きだから生産性とか要らないな
フレームワークも要らない

745 ：デフォルトの名無しさん：2013/07/09(火) 17:19:45.86

Javaを好むとこは手堅すぎて古くさい技術ばかりになってる面は確かにあるよね
実績・経験あるLinuxありきでWindowsサーバを選ぶことはない(Monoは選択肢に乗ることもない)
Javaの中でもTomcatありきでGlassFishを選ぶことはない(だからJava EE選べない)
もうちょっとトライしようよ(させてよ)と思うことは多い

746 ：デフォルトの名無しさん：2013/07/09(火) 17:26:31.90

>>744
なぜこのスレに来た？w

747 ：デフォルトの名無しさん：2013/07/09(火) 17:39:36.77

>>742
同じ処理を書いた場合にJavaでやるよりコード量が圧倒的に少なくなる。
もちろん開発に要する時間も短くなる。

Javaの冗長さは有名だけどそれすら認めたくないのかな
Railsが流行ったのもJavaの開発生産性が低すぎるからでしょ

>>745
よく言えば保守的ってことなんだろうけど、社員も新しい技術に
触れなくなるからエンジニアとしてはつまらないだろうな

748 ：デフォルトの名無しさん：2013/07/09(火) 17:47:44.18

>>746
フレームワークを否定するために来たのです

749 ：デフォルトの名無しさん：2013/07/09(火) 17:50:03.62

>>740
GrailsはRailsの影響受けてるからそんなに古くさくはないと思うよ
NoSQL使ってるなら新しめの技術にも積極的な企業なんじゃないか
日本でJava使ってる企業はStruts1.xとか化石を使おうとする。

カラム型NoSQLといえばHBaseとCassandraだけど
主要な言語ならどれもドライバのライブラリ用意されてるよね
全部Javaにそろえる必要性もよくわからんかった。
人材の都合で特定の言語に絞りたいというのは理解できなくもない。

750 ：デフォルトの名無しさん：2013/07/09(火) 18:05:26.53

>>747
もう一度>>731を読んでもらえます？(>>716も)
ここ、言語じゃなくてフレームワークが主題のスレなんで

>>749
Railsってもう10年近く前に登場した技術ですよ？
その影響を受けてるってだけでは古くささを否定する理由には…

751 ：デフォルトの名無しさん：2013/07/09(火) 18:19:09.35

>>750
10年はたってない、Railsは1.0が2005年だな
新しくはないが短いコードでかけるという意味では
Javaのレガシーなやつ(strutsとか）よりだいぶましだろう

752 ：デフォルトの名無しさん：2013/07/09(火) 18:21:40.66

>>750
比較するJavaのフレームワークも特定されていないのに
どこがどう違うかなんて誰も答えられっこないだろ
アホかいな

753 ：デフォルトの名無しさん：2013/07/09(火) 18:51:39.95

>>751
8年は10年「近く」に入りませんか？

>>752
言い出しっぺは>>698なので、Spring MVCやJava EE(JAX-RS)との比較でお願いします

754 ：デフォルトの名無しさん：2013/07/09(火) 20:27:32.33

>>749
HBaseに限って言えば他言語のクライアントで不満無くできるのは単発GetやPutを
投げる程度であって、コプロセッサやカスタムフィルタを書いてMapReduce走らせ
たりと大規模バッジを実行するにはごく普通にJavaが必要になる。
これはHBaseに限らずHadoopソフトウェアスタックにおいて大体共通する事情。
他言語は使えてもあくまでゲスト扱いでThrift等が間に噛むのが大半。
ある程度突っ込んだ開発や運用にはJavaの知識は欠かせないし、Javaで揃えた方が
何かと有利も多い。Javaに揃える必要性というか優位点は普通にあるよ。

755 ：デフォルトの名無しさん：2013/07/10(水) 00:29:46.27

VisualStudioは無料なのか？まずそこからつまずくだろ

756 ：デフォルトの名無しさん：2013/07/10(水) 01:15:35.60

>>755
Visual StudioはExpress editionは無料だよ。
あまり機能制限もないし職業プログラマーでもExpress使ってる人もけっこういる。
名前にExpressとつくのは無料

Visual Studio Express 2012
http://www.microsoft.com/visualstudio/jpn/downloads

Webアプリ開発なら、Visual Studio Express 2012 for Web
クライアントアプリなら、Visual Studio 2012 Express for Windows Desktop

2013はまだベータ版なので最初にいれるなら2012の安定版のがいい

757 ：デフォルトの名無しさん：2013/07/10(水) 01:27:36.98

>>754
なるほどね。HBase使用前提ならメリットありそうだね

Cassandraだとこんな感じにThrift以外のドライバが揃ってるけど
HBaseだといろいろプラットフォームを選ぶんだな
http://wiki.apache.org/cassandra/ClientOptions

CassandraでもHadoop連携できるらしい。やったことはないが
http://wiki.apache.org/cassandra/HadoopSupport

758 ：デフォルトの名無しさん：2013/07/10(水) 01:31:12.68

>>753
SpringはScaffoldingできないんじゃなかった？

GrailsはScaffoldingできるの知ってる。
JavaじゃなくてGroovyだけど

759 ：デフォルトの名無しさん：2013/07/10(水) 03:30:49.80

scaffoldあったらいいけど本質じゃないよ
Struts1にscaffoldがあったら今でもいいフレームワークといえるか？

760 ：デフォルトの名無しさん：2013/07/10(水) 05:37:01.55

なんかドライバがあるから大丈夫とかカタログスペックだけで解った気になっているのがいるな

必要性がよくわからんって、そりゃ単に実務で使った経験がないから思い浮かばんだけだろうて・・・

761 ：デフォルトの名無しさん：2013/07/10(水) 08:17:27.35

>>759
Scaffoldingすらないフレームワークの生産性高いという主張は無理がある
モダンなフレームワークと呼べるものじゃないな

762 ：デフォルトの名無しさん：2013/07/10(水) 13:46:02.39

期間内に求められた品質で作れりゃモダンじゃなくてもいいんじゃないですかね・・・

763 ：デフォルトの名無しさん：2013/07/10(水) 15:08:46.60

Click とかWicket とか、結構関心があったんだけど
いまでもメンテされてるのかな？

最近聞かなくなっちゃった気がする

764 ：デフォルトの名無しさん：2013/07/10(水) 15:34:21.52

ASP.NETのScaffoldingはVisualStudioの支援無しでもできるのかな。
例えばLinux上のMonoをターゲットにしてMacユーザがOSX版のEclipseを使ってASP.NET
の開発をする場合、どの程度ASP.NETの便利機能を使えるのだろう。

765 ：デフォルトの名無しさん：2013/07/10(水) 17:29:07.60

>>763
んなこと公式とかリポジトリ見りゃわかんだろクソが

766 ：デフォルトの名無しさん：2013/07/10(水) 17:33:59.81

結局、ASP.NET MVC単体の優れた点を語ってくれる方はいらっしゃらないのでしょうか？

767 ：デフォルトの名無しさん：2013/07/10(水) 17:37:52.53

百聞は一見にしかず

768 ：デフォルトの名無しさん：2013/07/10(水) 18:30:08.52

ここまでASP.NET推しの意見に具体論なし。

769 ：デフォルトの名無しさん：2013/07/10(水) 18:43:51.71

支持者らしき方からの書き込みが連日あるのに、誰一人として優れてる点を書かないのは変ですよねぇ
言語(C#)と開発環境(VS)が優れてるだけでフレームワーク(ASP.NET MVC)は平凡という結論でよろしいでしょうか？

770 ：デフォルトの名無しさん：2013/07/10(水) 19:12:14.57

>>769
うざいASP.NET推しの人とは違う無い両刀使いだけど、まあ、平凡と考えても良いよ。

Rails系FWとしてはもっともマシな実装として平凡という感じで、嬉しいのはC#とIDEと言っても良いし。

俺もASP.NET MVCが一番好きだけど、敢えてこのスレでそれをゴリ押しする人はうざいし、
それを相手にしている人も同レベルだと思うわ。

771 ：デフォルトの名無しさん：2013/07/10(水) 19:30:01.42

>>758
単なるscaffoldとは言い難いが、RooがSpring MVCのscaffold持ってる

772 ：デフォルトの名無しさん：2013/07/10(水) 19:39:11.13

>>770
「一番好き」ならあんたもASP.NET MVCが一番いいと思ってるんだろ
そう思うなら素直に褒めればいいじゃない

「マシ」「平凡」なんて言う必要はないし
住人や推してる人の人格まで否定する必要はない

773 ：デフォルトの名無しさん：2013/07/10(水) 20:06:49.20

俺はJAX-RSいいと思ってるが、優れてる点があるとは感じない
まさに「平凡」だけどJava系の有力どころでは「マシ」なフレームワーク
ASP.NET MVCもそんな感じなんじゃねーの？

774 ：770：2013/07/10(水) 20:31:18.90

>>773
そんな感じ。

まあ、JAX-RSと比較するなら、ASP.NET MVCはよっぽどかゆいところに手が届くものだけどね。
JAX-RSについて言えば、2.0でもまだまだ不満があって、まあ将来には期待、っというのが俺の意見。

ASP.NET MVCを引き合いに出すのも良いけど、どこかのページに書いてあるような上っ面や一般論ではなく、
実際に使った上での話をして欲しいなあとは思う。

ちな、Monoについては、ASP.NET MVCの実行環境よりも、俺ならServiceStackとかの方に行きたいかな～、
っというのが俺の意見。

そんな私は、JavaではSpring MVCを使っています(´・ω・`)
消去法的に。
JAX-RSは、ほんと将来には期待しているけどね。

775 ：デフォルトの名無しさん：2013/07/10(水) 23:52:47.04

自分もJAX-RSは好きだけど特定用途向けなのでSpring MVC等と比較するのは違うような。

776 ：デフォルトの名無しさん：2013/07/11(木) 06:14:48.07

JAX-RSにMVC的な仕様も取り込もう、取り込んでほしいという話もあるじゃん。

JerseyのViewableを使って、JAX-RSがあればもう他のFWなんていらねーわ、とか言っているEEよりの人もいるけどさあ。
俺としては、JAX-RSとJersey(とか固有実装の話)はちゃんと使い分けてほしいけど。

でも、将来的にビュー関係も標準仕様に取り込まれたら、JAX-RSでもいいよね。

777 ：デフォルトの名無しさん：2013/07/11(木) 06:54:33.04

JAX-RSは他の分野のフレームワークを喰う方向ではなくシンプルな貴方のまま
でいてというのが正直な願いだわ(笑)

それよかJAXBとの互換性は切って良いのでJSON用のデータバインディングと
JSON Schema対応、Beanバリデーションを標準仕様化してほしい。
特にJSON Schema validation形式でBeanのバリデーション定義を吐けると、
JavaScriptに読ませてブラウザ上でバリデーションしたりとか他の言語で
書かれたシステムとバリデーション定義を共有したりとかがやりやすい。
最近JSON Schema、特にvalidationは言語中立なバリデーションの記述形式
として結構お手軽で、しかも実装がかなり揃ってきたので期待している。

778 ：デフォルトの名無しさん：2013/07/11(木) 16:37:45.52

で、ASP.NET MVCで作られてる人気サイトは
MS関連以外であるの？どうせないだろ

779 ：デフォルトの名無しさん：2013/07/11(木) 17:07:58.34

コミケウェブカタログとかどうよｗ

780 ：デフォルトの名無しさん：2013/07/11(木) 17:34:43.94

>>778
無知すぎるな

ASP.NETが稼働してるサイトなんて無数にある
統計で世界のWebサイトの4割弱がIISで動いてる。
ASP.NETはフレームワークとしてもシェアはダントツでトップ

781 ：デフォルトの名無しさん：2013/07/11(木) 17:40:17.51

>>776
> JAX-RSにMVC的な仕様も取り込もう、取り込んでほしいという話もあるじゃん。

-1

>>777
> JAX-RSは他の分野のフレームワークを喰う方向ではなくシンプルな貴方のまま

+1

782 ：デフォルトの名無しさん：2013/07/11(木) 18:20:18.93

>>778
Stack Overflow (エンジニアなら知らないとは言わせないが)

あれは ASP.NET MVC だ。
http://blog.stackoverflow.com/2008/09/what-was-stack-overflow-built-with/

783 ：デフォルトの名無しさん：2013/07/11(木) 18:40:35.48

そういやstackoverflowで一番タグの多い言語はC#なんだよな。次がJava

784 ：デフォルトの名無しさん：2013/07/11(木) 18:43:40.38

>>774
コントローラーの部分で不満なところはどこ？
ビューの所は既出だから除いて

785 ：デフォルトの名無しさん：2013/07/11(木) 18:58:11.60

このスレ的には、JAX-RSはAPIに特化してシンプルなままでいるべきだっていう意見かな？
まあ、それが普通の感覚か。

いや、Java EEよりの人間が、これからはMVCしたい時にも他のFWではなくJAX-RSですよ、みたいにうざいので、
じゃあ、Spring MVCと同程度のことが標準化されたら完全に移行してやんよ、っと自分も言ってるだけなので。

786 ：デフォルトの名無しさん：2013/07/11(木) 19:04:20.68

あの人達はJava EEでやることが目的になってるからなw
JSFやJPAなんてあれが本当にいいと思って書いてるのか？と疑問なブログばっか

787 ：770：2013/07/11(木) 19:30:46.67

>>784
ビューを想定せず、API専用と考えれば、2.0になってコントローラー周りでもそんなに困らないかなあ。

拡張ポイントはもっと柔軟になって欲しいけど。
SpringやASP.NET MVCを引きあいに出して悪いけど、そいつらは色んなポイントに介入できるようになっているし。

あと、コントローラーの話じゃ無いけど、個別の実装が持ってるような便利機能はどの実装でも使えるようにして欲しいところ。

788 ：デフォルトの名無しさん：2013/07/12(金) 00:52:31.84

他の言語のフレームワークと比較するとスレッドが盛り上がるな

789 ：デフォルトの名無しさん：2013/07/12(金) 03:11:13.02

荒らしと釣られるやつがいるとスレが伸びるだけ

790 ：デフォルトの名無しさん：2013/07/12(金) 07:24:29.56

最近盛り上がっているのは良いけど、荒らしと釣られるやつの発言だけはつまらんしな。

791 ：デフォルトの名無しさん：2013/07/12(金) 09:23:46.08

ちゃんと議論になってるしこんなの荒れてるとは言わないわ

792 ：デフォルトの名無しさん：2013/07/12(金) 10:40:55.02

JDBCとか、プロバイダーモデルにする意味があるものを仕様化するのは良いとして、
JAX-RS、あとはJPAとかJSFみたいなフレームワークについてまで仕様と実装を分離するのは
正直よく意味がわからんのだけど。

固有機能の際が発生するとか、開発リソースが分散するとか、良いことない気がするんだけど。

793 ：デフォルトの名無しさん：2013/07/12(金) 12:36:00.46

なんというか、どのフレームワークも囲い込みに必死でJava言語の良さすらダメにしそうな勢い
eclipseという神器上で醜い広告や下品な情報収集を繰り広げていることに腹が立つ

794 ：デフォルトの名無しさん：2013/07/12(金) 14:38:38.26

囲い込みって、具体例を挙げないとどの辺りに憤っているのかもイマイチわからん。

795 ：デフォルトの名無しさん：2013/07/12(金) 14:47:04.74

String template = "なんというか、どの %s も囲い込みに必死で %s の良さすらダメにしそうな勢い
%s という神器上で醜い広告や下品な情報収集を繰り広げていることに腹が立つ";

796 ：デフォルトの名無しさん：2013/07/12(金) 15:05:02.79

795で思い出したけれども、Grailsではテンプレート内での式展開にELではなく
${users.collect{it.name}.join(" - ")}みたいにGroovyの文そのものを使える
のが素敵。

797 ：デフォルトの名無しさん：2013/07/12(金) 17:14:09.94

>>780
どこの統計？

798 ：デフォルトの名無しさん：2013/07/12(金) 18:16:09.03

netcraftの統計じゃIISはやや今は復調して20%、去年の今頃は14-5%しかない
40%を越えたことは一度もなく、2007-8年に30%台後半だったことがあるだけ
でもASP.NETがフレームワークのシェア一位でもおかしくはない
MS系は選択肢が少ないから

799 ：デフォルトの名無しさん：2013/07/13(土) 10:10:21.68

最近は、フロント側はHTML+JQuery+CSSで書くようになっちゃって、
Javaにやらせるのはモデル側処理とJSONをフロントとやりとりする
処理とかになってる。

JavaScriptとHTML5+CSS3でここまでデキるようになると、
もはやサーバサイドで処理するWebアプリケーションフレームワークの
出番が無いんだよな。。。

JavaScriptも、素で書くよりはHaxeかCoffeeScriptで書くと楽。
Haxeだったら、実装もJavaとよく似てるしJavaに変換できるという
変なメタ言語ではあるが、タイプセーフにできるんでいい。

800 ：デフォルトの名無しさん：2013/07/13(土) 10:14:09.91

まあ、サーバーサイドはJSONだけ返しておけばいいやと思って色々考慮した結果、
やっぱりHTMLのフラグメント返した方がいいわ、っという結論になるのもありがち。

801 ：デフォルトの名無しさん：2013/07/13(土) 11:26:49.95

ScaffoldingすらないJavaのフレームワーク使ってるから
View書くのがめんどくさくなって
JSONでやろうとする人が多くなってるんだろうな

ブラウザ向けはHTMLで返すのが基本で王道

802 ：デフォルトの名無しさん：2013/07/13(土) 11:46:10.15

＞JSONでやろうとする人が多くなってるんだろうな
これはもう本当にずっと前からそうだね

息を吹き返しただけあってjavascriptってやはり便利なんだよね
となると個人情報扱うだとかそういう時のセキュリティ関係さえ強いフレームワークであればいいと思うの
後はGWTみたいに必要に応じてピンポイントにモジュール組み込んでいけたら問題ない
多言語との共生

803 ：デフォルトの名無しさん：2013/07/13(土) 11:55:20.07

jquery+JSONは、ほんと楽だからなぁ。。。
HTMLはAP鯖じゃなくWeb鯖に置きたいし

804 ：デフォルトの名無しさん：2013/07/13(土) 12:50:16.74

>>799
それは昔からそうだろ
サーバーサイドでフロント側の挙動なんて動かせないんだから

805 ：デフォルトの名無しさん：2013/07/13(土) 12:51:01.42

てか、スマホがHTMLでなくアプリって流れが明確になっちゃったからな
うちじゃ新しいフレームワーク使えるような新規案件はスマホアプリ用ばっか
だからサーバはJSON返すだけでいい
少しはWebView向けのHTMLをサーバで作るけど

806 ：デフォルトの名無しさん：2013/07/13(土) 13:18:01.59

スマホ案件だとほんとそうだよね
JSONのやりとりだけ

807 ：デフォルトの名無しさん：2013/07/13(土) 13:29:45.06

>>801は、競争優位にあるせいで時代に取り残されるという、よくあるケースに見える

808 ：デフォルトの名無しさん：2013/07/13(土) 13:51:10.60

CAの藤田によるとスマホアプリよりスマホ向けサイトのほうが
圧倒的に儲かるらしいけどな

809 ：デフォルトの名無しさん：2013/07/13(土) 14:00:18.47

CAみたいなところはストアからの導線が無くても平気かもしらんけどさぁ
スマホユーザ特に若い世代はググってくれんから新規サイトは作らないって客が言ってた

810 ：デフォルトの名無しさん：2013/07/13(土) 14:13:35.06

JSON案件ばかりの人って、具体的に何を使って開発してます?
・サーブレットコンテナ。TomcatとかJetty組み込みにしてコンテナレスデプロイとか
・JAX-RS実装。JerseyとかCXFとかあるいはJAX-RS使わんとか
・その他、DIとかORMとか

811 ：デフォルトの名無しさん：2013/07/13(土) 14:17:15.26

じゃあ、俺も便乗して。
・JSのMVxなFWは何か使っている？ BackboneやKnockoutとか

812 ：デフォルトの名無しさん：2013/07/13(土) 14:23:59.72

さらに追加
・REST APIの認証どうしている? Basic認証とかCookie+jsessionidとかHMAC署名とか
・JSONの取り回しに何使っている? Jackson?

813 ：デフォルトの名無しさん：2013/07/13(土) 15:20:51.61

>>810
Tomcat、Jersey、Weld、Doma+オレオレ
Jersey+Weldは最初動かせなくて苦労したな。去年のことなんで詳しくは思い出せないがJNDIだったかな

>>811
うちはネイティブアプリが多いんでJS少ないけどTizen(笑)用でBackbone使ってるらしい
あとjQuery MobileとPhoneGapで作ったアプリが一つあるはずだがそれっきりだとか
別チームだから詳しくは知らない

>>812
アプリと独自のやり取りでセキュリティトークン発行してるが本当に安全なのか誰も知らない
JSONはJackson

814 ：デフォルトの名無しさん：2013/07/13(土) 15:59:12.98

>>813
なるほどね。参考になる。
うちはフロントエンドだけJerseyで共通しているけれども、動的なウェブアプリに
JSONデータ提供するのと、社内システム内やパートナーのシステムとの通信向けの
RPCでその下の実装が結構異なる。

(1) ウェブアプリ向けは(Jersey -> Grails -> Spring, Hibernate) -> Tomcatにデプロイ
(2) システム間RCP向けは(Jersey -> 色々) -> DropWizard(Jetty)でデプロイ

って感じ。初めは全部(1)だったのだけれどもGrailsアプリが肥大化してしまって、
今はGrailsアプリからAPIを一つずつ引きはがして(2)の方法で立ち上げたサービス
として細かく分けて走らせている。将来はウェブアプリ向けだけGrailsに残る予定。

815 ：デフォルトの名無しさん：2013/07/13(土) 16:17:53.07

JSON返す流れになってるだのアホなこといってるのは
サーバサイドFW不要論そのもの
その不要論を言いだすと、Java不要論になるし
このスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定になる。

816 ：デフォルトの名無しさん：2013/07/13(土) 16:31:51.92

( 'A`) …?

817 ：デフォルトの名無しさん：2013/07/13(土) 16:33:31.58

>>815
？
サーバサイドの開発はウェプアプリのフロントエンド周りだけなの？

818 ：デフォルトの名無しさん：2013/07/13(土) 16:38:55.51

なんか極論が多いね
JSON返すだけのプロジェクトもあれば
普通のWebアプリのプロジェクトもあるだろ
スマホアプリが普及したらWebブラウザは絶滅するのか？w

819 ：デフォルトの名無しさん：2013/07/13(土) 18:44:54.18

仕事の報告書じゃないからなｗ

820 ：デフォルトの名無しさん：2013/07/13(土) 22:37:27.08

>>799
そうなると、結局、サーバーサイドはフレームワーク使わずに、サーブレット中心の実装になりそうだなｗ

821 ：デフォルトの名無しさん：2013/07/14(日) 01:07:01.45

>>820
わけわからん。大抵はJAX-RS使うと思うけど。
JAX-RSはフレームワークじゃないとか内部的にはサーブレット使っているとでも
言いたいのだろうか。

822 ：デフォルトの名無しさん：2013/07/14(日) 03:54:12.30

>>821
このスレには昔から>>748のようなフレームワーク否定厨が粘着してるんだ
触っちゃダメ絶対

823 ：デフォルトの名無しさん：2013/07/14(日) 06:36:12.07

jQueryで思い出したけど
function $(element) {
return document.getElementById(element);
}
みたいな書き方ってどこ発祥なの？スレチだけど。

824 ：デフォルトの名無しさん：2013/07/14(日) 07:38:26.32

prototype.js かなあ

825 ：デフォルトの名無しさん：2013/07/14(日) 11:03:14.98

prototype.js 辺りがメジャーにした認識だとは思うけれど、どこが発祥かは知らないなぁ。
この手って、使いやすいから自分のところにも取り込んでみた。的なのもあるだろうし。

826 ：デフォルトの名無しさん：2013/07/14(日) 11:40:38.32

>>816-818
このスレには前から>>815のようなJSON否定厨が粘着してるんだ
触っちゃダメ絶対

827 ：デフォルトの名無しさん：2013/07/14(日) 15:07:53.76

>>826
JSONだけになる！って主張してるやつのほうがバランス欠いてるだろ

828 ：デフォルトの名無しさん：2013/07/14(日) 17:21:00.49

JSON否定もJSONだけも両方ともバランス欠いているので中間をとりなさいw

大抵のウェブアプリケーションフレームワークはレスポンスとしてJSONを返す
アクションもたいした苦労なく定義出来るし、基本HTMLベースで一部AJAXで
JSON引っぱってきて動的にDOM生成する、って場合はわざわざJAX-RS等を使う
より既存のウェブアプリケーション向けフレームワーク使ってコントローラー
上でゴニョゴニョする方が楽。

829 ：デフォルトの名無しさん：2013/07/14(日) 20:52:43.36

Struts1.xが社内パッケージの主流なんで、新人にも今教えてるんだけど正直苦痛だ。

830 ：デフォルトの名無しさん：2013/07/14(日) 21:27:43.19

もうサポート終わるんじゃなかったっけ？　Struts1

831 ：デフォルトの名無しさん：2013/07/14(日) 21:45:40.02

>>830
終わってるね

開発もメンテも終わってるような化石フレームワークを
まだ使い続けてる>>829のようなSIerが日本にはたくさんある。
欧米に比べ10年遅れているといわれるとおりだよ

832 ：デフォルトの名無しさん：2013/07/14(日) 21:58:38.25

昔はおまえらもStruts使ってただろ
客は同じシステムを使いつづけなきゃならんのに
時代遅れだから化石だからもう俺知らね、じゃ無責任すぎる
フレームワークごりごりに使うやつって後々のこと全然考えないよな

833 ：デフォルトの名無しさん：2013/07/14(日) 22:07:53.03

まったくだよ
だから俺はフレームワーク否定派

834 ：デフォルトの名無しさん：2013/07/14(日) 22:17:10.36

日本人は責任感が強すぎるんじゃね
時代遅れとか最先端とか謳って新しいフレームワークを客に勧めて
金をきっちり取ればいいんだよ

835 ：デフォルトの名無しさん：2013/07/14(日) 22:41:01.38

>>832
新規プロジェクトでもStruts1つかってるカス会社があるんだよ

古いフレームワークを使うとシステム稼働してる間に
メンテナンス期間が終了してしまう。
だから古いフレームワークで開発するのはやっちゃいけない。

>>830
メンテナンスだけならすでにStruts知ってる奴にやらせておけばいいだろ
新人には新しい技術をトレーニングしてやれよ
負の連鎖を続けてどうすんだ

836 ：デフォルトの名無しさん：2013/07/14(日) 22:47:23.52

>835内の>>830は間違い。>>829だったわ

837 ：デフォルトの名無しさん：2013/07/15(月) 08:20:25.54

フレームワークから入った新人は、大抵そのフレームワーク以外の開発ができなくなる
そこがフレームワークの欠点でもある

838 ：デフォルトの名無しさん：2013/07/15(月) 09:29:22.45

フレームワーク否定厨が否定してるフレームワークって？
第三者が作ったものという意味？それともオレオレも否定してるのか？
ある程度の規模でオレオレも含めてフレームワークを一切使わない開発って想像つかないな
その現場に行ってコード見たいもんだよ

839 ：830：2013/07/15(月) 09:38:45.53

>>835,837
俺も流石に一からStrutsに染めるのは罪悪感があったんで、
一週間JSPとServlet触らせた上でフレームワークの功罪について触れてから教えてるよ。
俺はStruts嫌いって前置きした上で。
ちなみに新人三人のうち二人は女で、俺が一押しのフレームワークはWicketだ。
開発スタイルにはまれば生産性高いよ。

840 ：デフォルトの名無しさん：2013/07/15(月) 09:42:26.66

フレームワーク否定厨はServletも使わないのか？
Servletって
・アプリはHttpServletを継承する(アプリを型にはめてる)
・コンテナがアプリ(Servlet実装クラス)を呼び出す
だから構造的には典型的なフレームワークなんだが

841 ：デフォルトの名無しさん：2013/07/15(月) 09:47:19.91

フレームワーク否定厨だけどJSP＆Servletで作るべき

842 ：デフォルトの名無しさん：2013/07/15(月) 09:52:08.93

>>841
それってURLごとに一つずつServletやJSP作るのか？
それともFront Controllerパターンは使うのか？

843 ：デフォルトの名無しさん：2013/07/15(月) 10:31:08.26

>>839
新人は最初にStrutsを教えるようなゴミ会社から逃げたいと思うだろうな
2年もしたら転職するんじゃないか

844 ：デフォルトの名無しさん：2013/07/15(月) 10:33:00.39

>>841
何のフレームワーク使ったことある？

良いフレームワークは生産性を劇的にあげるわけだが

845 ：デフォルトの名無しさん：2013/07/15(月) 10:40:30.50

どんなに生産性が高くても一瞬でサポートが終わるようなもの
使えないよ

846 ：デフォルトの名無しさん：2013/07/15(月) 10:43:06.13

>>843
二人の女にとってはStrutsどーこーより教えてくれる人の人間性だろ
>>830いい人そうじゃん
性格悪そうな>>843に教えられてたらすでに出社しなくなってるだろうけどw

847 ：デフォルトの名無しさん：2013/07/15(月) 10:45:47.26

>>845
フレームワークかどうかじゃなくて、他人の作ったものは使えないってことか？

848 ：デフォルトの名無しさん：2013/07/15(月) 10:55:03.71

>>846
新人には新しい技術、良い技術を覚えてほしいから
Strutsなんて教え込むな、と言ってる俺のが性格いいだろ
ゴミになった技術を教えて新人を潰しちゃいけない

849 ：デフォルトの名無しさん：2013/07/15(月) 10:55:33.19

>>847
圧倒的な普及率と圧倒的なサポート期間があるならいいけど。
思いつきで作ったオナニーフレームワークは使わない。

850 ：デフォルトの名無しさん：2013/07/15(月) 10:58:13.65

>>845
その理屈だと10年以上きっちりサポート
してくれる、ASP.NETが最高ってことだな
しかもフレームワークの出来が良い

851 ：デフォルトの名無しさん：2013/07/15(月) 11:00:55.69

>>849
なんだ、フレームワーク全否定じゃないのか
だったら思いつきで作られたオナニーライブラリだって当然使わないんだろ？
このスレ関係ないじゃんw
出て行け

852 ：デフォルトの名無しさん：2013/07/15(月) 11:11:41.95

>>850
うん。最高！

>>851
否定するために来てる。
そりゃあ遊びで作ってるならうほっこのフレームワーク生産性たけー
とか言ってればいいんだろうけどなｗ

853 ：デフォルトの名無しさん：2013/07/15(月) 11:12:17.51

>>839
お前、本当に>>830なのか？>>829じゃなくて？

854 ：デフォルトの名無しさん：2013/07/15(月) 11:16:49.57

>>852
いや、お前がしてるのはフレームワーク否定じゃなくて「他人の作ったもの」否定だろ
あるいは「遊びで作ってるもの」否定
フレームワークかどうかは関係ないだろ
さっからフレームワークそのものは全く否定できてないじゃん

855 ：デフォルトの名無しさん：2013/07/15(月) 11:18:30.59

つか>>842にも答えれ

856 ：デフォルトの名無しさん：2013/07/15(月) 11:23:35.88

あ、そうかも。JSP＆Servletに変わるものでも
圧倒的普及率と圧倒的サポート期間があればそれはOKだからね。
別にフレームワークを否定してるわけじゃないかも。

857 ：デフォルトの名無しさん：2013/07/15(月) 11:25:41.73

今頃気づいてんじゃねーよバカ

858 ：デフォルトの名無しさん：2013/07/15(月) 11:49:31.81

>>848
会社は趣味じゃねえんだよ
>>829読んだら会社の都合で教えざるを得ないのわかるだろ

859 ：デフォルトの名無しさん：2013/07/15(月) 12:47:59.02

Jerseyで実装したJAX-RSかSpring MVCでいいだろ。
Struts教えざるを得ないが。

scara-play2とかは、やりづらいのでできる限り避けてくれ。

860 ：デフォルトの名無しさん：2013/07/15(月) 15:03:04.89

>>844
> 良いフレームワークは生産性を劇的にあげるわけだが

フレームワークを使う理由は、生産性向上もあるけど、コードの均一化/保守性とかでは？
むしろ生産性向上性より保守性とか均一化のほうが重要視されていると思う(そうじゃない職場もあると思うけど)

使い捨て、保守しないことがわかっているんなら生産性向上でそっこうでリリースを目指す、でもいいけどね。

861 ：デフォルトの名無しさん：2013/07/15(月) 15:06:57.98

自分もSpring MVCに一票かな。
アノテーション付けたりjsp書いたりらとりあえずWebアプリが動くことをを体験させて
それから徐々にautowiredやcomponent-scanを使わずに幾つかbeanを手動登録させて
DIでアプリを組み立てる仕組みを理解させる。

862 ：デフォルトの名無しさん：2013/07/15(月) 15:10:30.85

保守性が大事なのにサポート期間の短いフレームワークを使うなんて
本末転倒だね

863 ：デフォルトの名無しさん：2013/07/15(月) 16:01:38.57

どんな工業製品だって古くなればなるほど保守運営に金がかかるようになる。
ソフトウェアだって例外じゃない。

829も解っていて言っているのだろうけれども829の例は開発会社が自社の開発フローの
技術更新にかかるコストをケチっている事例だし、Struts1ベースのシステムの延々と
使い続けるのもカスタマーがコストを払ってシステムを更新するのをケチっている事例。

自社オレオレFWにしても保守コストがかかるのは同様。
担当者も消えた古い社内FWのデバッグとか苦痛。

最悪なのはFW不要とか言いつつ実際はシステム毎にプチFWを作り込んでいる事例。
それこそservletやJSPから何でも手作り車輪の再発明しているやつ。これが一番厄介。

864 ：デフォルトの名無しさん：2013/07/15(月) 16:13:02.51

ライブラリとかならともかくフレームワークなんて根幹部分を
あんな短いサポート期間のもの使えない。
そういう理想論振りかざしても事実は変わらない。

865 ：デフォルトの名無しさん：2013/07/15(月) 16:21:07.95

結局顧客のためを考えたらASP.NETかJSP＆Servletで作るのが一番だな
もう使われないようなものを管理しつづけるのはきつい
放射性廃棄物問題と同じだな

866 ：デフォルトの名無しさん：2013/07/15(月) 16:41:24.67

>>814
GrailsのフロントエンドからRESTなAPIサーバを呼び出すのはLinkedInもやってるんだな
JAX-RSは使ってなくてRest.liって独自フレームワークのようだが

867 ：デフォルトの名無しさん：2013/07/15(月) 16:45:42.71

>>850 >>865
ASP.NET MVC はともかく、ASP.NET (WebForms) が最高なんてあり得ないww
MS自身だって切ろうとしているのに

868 ：デフォルトの名無しさん：2013/07/15(月) 16:49:34.97

そんな当たり前のこと言われても

869 ：デフォルトの名無しさん：2013/07/15(月) 16:54:25.50

>>823
jQueryに慣れてるとちょっと気持ち悪い書き方だけど
素JavaScriptでjQueryの $(element-ID) 的なことをやるための関数ってことかな？

870 ：デフォルトの名無しさん：2013/07/15(月) 17:02:05.74

うーむ。結局、話が循環せざるを得ないな。

871 ：デフォルトの名無しさん：2013/07/15(月) 17:52:35.65

>>867
ASP.NET MVCも広義のASP.NETに含まれるから
間違ってはいないだろ。
たんにASP.NETとかくと従来のASP(WebFormsやclassic asp)
と勘違いする人がいるから困る

MSがWeb Forms切ろうとしているというのも間違い。
MVCはWebFormsに変わる技術ではないとMSの開発責任者が言ってる。
Server control使いたければWebFormsで、HTMLを完全にコントロール
したければASP.NET MVCでやれ、と使い分けを勧めている。
MSは長期間サポートするからWebFormsがすぐに使えなくなることはない。

872 ：デフォルトの名無しさん：2013/07/15(月) 17:56:08.25

XNA勉強してたらあっという間に終了した。
こういうのほんと迷惑なんで

873 ：デフォルトの名無しさん：2013/07/15(月) 18:44:03.26

ASP.NET MVCはイイネ(・∀・)
C#も最高。

ただし、MSやMS界隈のコミュティにの言っていることをそのまま鵜呑みにするのは、
Java界隈で言えば禿の言っていることを真に受けるようなものなので、お勧めしない。

参考に話を聞くときは、どっかのページのコピペみたいな事を言っている人ではなく、
実際に使っている人達の話を聞くべきだね、っていう。

874 ：830：2013/07/15(月) 20:11:17.06

>>853
839だけど自分のレス番間違えた。。。

>>843,846
正直俺も転職何回か繰り返してるから2年以内に今教えてる新人が
転職できるだけのスキルを身につけてくれたら嬉しい、と思ってるよ。

たくさんの顧客にパッケージとして提供してるプロダクトのベースに
Struts1.x使ってるから今更、一開発者の趣味や趣向で変えるわけにはいかないんだよね。
移行のコストって言ったって導入顧客は裏が何で動いているかなんて知ったこっちゃないし、
うちの会社の経営層だってそんなコストおいそれと認めるわけにはいかないし。

新人にもStruts1.xは今年の4月でお亡くなりになったけど、
それでも使わざるを得ない背景は説明してるし、
他のフレームワークの事例も挟みながら、最初にJSP+Servletだけで
組んだ時の手間のうち、この辺が軽減される、みたいな説明はしてるつもり。
とりあえず今の現状で○○だけ覚えれば、みたいな思想は危険だよね。
自身のスキルセットやキャリアに対してのリスクヘッジとしても、
色んなフレームワーク触って長所短所を知っておくべきだと思う。

875 ：830じゃなくて829：2013/07/15(月) 20:21:39.25

↑829です、度々間違えて申し訳ない。。。
JSP+Servlet信者とかオプソは信用できない云々言う人と仕事する機会もあったけど、
大抵そう言う人って他のフレームワークやらパラダイムが理解できないだけなんだよね。
知らない技術を使うリスクとフレームワークを使うことで得られる生産性向上のリターンを
天秤にかけてリスクの方が大きいって判断してるだけだから、ある意味正論なんだけどさ。

876 ：デフォルトの名無しさん：2013/07/15(月) 20:28:35.15

待てよ
信用できないのは誰のせいだよ。
一瞬でサポート打ち切るやつらのせいだろ。
なんで信者扱いされないといけないんだよ。

877 ：デフォルトの名無しさん：2013/07/15(月) 20:30:45.49

つーか、最近の流れで、FW否定論者っていうのがどの程度のものかわかっただろ？
まあ、それでも相手にしたい人は相手にすればよいさ。

878 ：デフォルトの名無しさん：2013/07/15(月) 20:42:37.66

ところでStruts1.xがフレームワークとして美しくないのは、
HttpRequestやHttpResponseみたいなServletAPIに生でアクセスできてて、
低レベルAPIを隠蔽しきれてない、抽象化しきれてないあたりだと思うのだがどうか。
次にActionクラスとかの実装に継承を使う必要があって、POJOで単体テストがしづらい
とか、その辺が出てくるんだけど。

879 ：デフォルトの名無しさん：2013/07/15(月) 21:10:38.57

フレームワーク使いたがる奴って結局作り逃げできるやつらだろ
そんなのが作ってるもののレベルってたかが知れてるよ

880 ：デフォルトの名無しさん：2013/07/15(月) 22:11:15.62

普通に自社サービスの開発にフレームワーク使っているけど。

881 ：デフォルトの名無しさん：2013/07/15(月) 22:54:10.54

>>878
そもそも前世紀のFWだからしょうが無いべ
Jakarta(実験プロジェクト) を卒業して Apache(看板プロジェクト)
になった 2005 年から数えても 8 年前の FW

2013 年現在から見れば至らないところだらけだけど
いいフレームワーク「だった」と言えるのでは？

# これからの新規案件で Struts 1 とか言い出すやつは正気を疑う。
# 既存サイトなら、全面リプレースをオススメするけど、どうしても
# だめなら涙をのんで

882 ：デフォルトの名無しさん：2013/07/15(月) 23:35:53.36

>>881
確かに当時はPOJOとかDIみたいな考え方は無かったもんな。

883 ：デフォルトの名無しさん：2013/07/15(月) 23:52:51.72

>>881
動いてるものを全面リプレイスw
本当ここのFW厨はビジネスセンスゼロだな

884 ：デフォルトの名無しさん：2013/07/16(火) 00:05:20.67

>>881
Initial Releaseは2000年だから
基本的なデザインは13年前のフレームワークだぞ

885 ：デフォルトの名無しさん：2013/07/16(火) 01:34:08.10

自分は、いろんな意味で、Struts1.xを経験したから、それを基準にして今がある。
Struts1.x のリアルタイム世代でよかった。

>>874 が相手している新人も、 >>874 がちゃんと説明しているのなら、
Struts 1.x を経験した後にいまどきの FW を勉強したら、ちゃんとわかってくれるのでは。

>>878
> ところでStruts1.xがフレームワークとして美しくないのは、
> HttpRequestやHttpResponseみたいなServletAPIに生でアクセスできてて、

別にWebフレームワークなんだから、生ServletAPIにアクセスできてもいいんじゃない？
中途半端に無理に隠すより、直接触れる方法も残しておいたほうが、逃げ道があっていいと思う。
無理に隠して、融通の利かないFWを何度見てきたことか。

886 ：デフォルトの名無しさん：2013/07/16(火) 08:24:54.78

まあなんだ。
パッケージはJSP&Servletで作って、受託開発みたいな
使い捨てオーダーメイドはフレームワークを使うのがいいってこった。

887 ：デフォルトの名無しさん：2013/07/16(火) 14:56:24.13

YammerのMetricsライブラリって使っている? Jerseyアプリのレスポンスタイムとか
要所のランタイムメトリクスを監視するのにお手軽で便利。

http://metrics.codahale.com/

これ以外にもウェブアプリの状態監視をするのに何を使っていますか?

888 ：デフォルトの名無しさん：2013/07/16(火) 14:57:20.45

>>869
＞jQueryに慣れてるとちょっと気持ち悪い書き方だけど

えっ
jQueryも思いっきり採用してるよね・・・？

889 ：デフォルトの名無しさん：2013/07/16(火) 16:39:46.28

>>886
だね。自社プロダクトや長く続くお客さんにはServlet＆JSPで作り、
長く使われなさそうなシステムや
すぐ関係が切れそうな客にはFW使って作ればいい
値切ってくるような細い客は新しいFWの実験台にされて当然

890 ：デフォルトの名無しさん：2013/07/16(火) 22:28:51.63

>>888
jQueryを使う場合のことを言っただけ。
目的はIDで要素を指定するってことでしょ。
jQuery内部ではそれをやってるんだろうけど
jQueryを使って実装する人は
var value = $(element).val();
みたいに書くでしょ。

891 ：デフォルトの名無しさん：2013/07/17(水) 05:07:01.97

>>890
えっ、何故わざわざ変数に入れるの？何のための$関数なの？
使用者の勝手だけどそれがスタンダートな訳なかろうが。

892 ：デフォルトの名無しさん：2013/07/17(水) 05:31:47.12 ID:UntIoZtW!

jQueryの.val()の戻り値を変数に入れるのは普通によくあると思う。

893 ：デフォルトの名無しさん：2013/07/17(水) 19:44:26.66

val()の値を代入するのはわかるけど
それがなぜ>>823に違和感を覚えるのかが心底謎。
ここが欠如しているとval()の代入すらできないのだけれど・・・

894 ：デフォルトの名無しさん：2013/07/17(水) 19:48:24.41

上の方で話してる人が今教えてもらってる先輩そっくりで笑ったw
配属の事前学習でStruts1.Xの勉強中なんだけど、MVCでよくわからんところが2点あるので教えてください

(1) MVCでの画面遷移って、V -> C -> V'が普通なんでしょうか？
今やってる内容だとCがV'の初期表示用処理をやっててとても気持ちが悪い
V -> C -> C' -> V'とかにしてCは自分のVから来た入力の処理(Modelへの依頼)と
遷移先の制御だけにしたほうがキレイに思えるんだけど、変な考え？

(2) ModelはControllerから依頼された処理結果に伴う状態の変化をViewに伝達して、ViewはModelに情報の再取得を依頼するという説明があったんだけど、
その時点ではModelがViewのことを知ってるとは思えないし、ViewからModelに取りに行くのもJSPにロジックがちゃがちゃで微妙な感じ
実際にはControllerが間にいて色々とやってる？
それとも上にあったようなJavascriptとJSONとかでModelとがんがんやりとりしてる？

長文すみませんがよろしくお願いします

895 ：デフォルトの名無しさん：2013/07/17(水) 21:42:05.56

>>894
＞(1)
多くの場合コントローラはデータを渡して来たのがどのビューだろうと
自分の処理をすればいいだけで、「自分のビュー」という考え方で
遷移設計をするとすごく不自由なものが出来上がると思う
当然、複数のビューから呼び出されるコントローラがあるわけで

＞(2)
ビューからモデルにアクセスするというか
例えばモデルでDBから取り出した複数のレコードを
ビューが受け取ってどう表示するかまでが一つの処理で
再取得云々というのは次の別の処理を言ったのでは？その点は意図がよくわからんね

896 ：デフォルトの名無しさん：2013/07/17(水) 22:32:56.70

本当に今更Struts1.xやってるところなんてあるんだｗ
しかも7月に入ってもまだ配属決まらずに研修中とか色々不安な会社だな。
とりあえずフレームワーク覚えるのに血道上げるよりか、
JSPとServletの基本を覚えろよ。

897 ：デフォルトの名無しさん：2013/07/17(水) 22:48:23.42

あれだけ普及させといて簡単に切っちゃうんだもんなぁ
マジで信じられない

898 ：デフォルトの名無しさん：2013/07/17(水) 23:30:17.60

>>894
頼むから2chで聞かないで、普通にググるか会社の先輩に聞いてくれ、会社の恥だ。

V→C→Vが気持ち悪いってのは、StrutsのActionとJSPの関係を理解してない証拠だね。
MVCで言えばCはStrutsのActionServlet+strus-config.xml
Action+JSPがView担当ですよ。

まぁStruts1.xなんか教えるのは正直悪いと思ってるけど、
これもウチみたいな中小企業に来た運命と思って諦めてくれ。

899 ：デフォルトの名無しさん：2013/07/18(木) 00:41:39.96

894です
教えてくださったお二人ありがとうございました
先輩に聞けたらいいんですがトラブル発生だそうで1週間ほど放置真っ最中
次行くところがSAStrutsというのを使ってるので、SAStrutsやる前にStruts1.Xやってます

5月までJava？それコーヒー？とか言ってたんだけどなぁ…
先月OJC-P Silverとかいうの取らされて、今月中にOJC-P Gold取れと言われてる
なんか色々と間違ってるみたいだからもう一回参考書見直すます

900 ：デフォルトの名無しさん：2013/07/18(木) 00:45:39.90

一年目の最初からフレームワークというのはさすがにかわいそうだな
まず最初はJava、Linux、HTTP、DBとSQL、HTMLとJSとCSS、からだろ

901 ：デフォルトの名無しさん：2013/07/18(木) 04:34:31.71 ID:OQxxU7Bi!

>>894
> ModelはControllerから依頼された処理結果に伴う状態の変化をViewに伝達して、
> ViewはModelに情報の再取得を依頼するという説明があったんだけど

多分それはMVCモデルの一般論について述べたもので、ウェブアプリ向けの現実の実装とはやや異なる
と思う。

MV間の通信については、Webの世界に持ち込まれる前のGUI開発の世界で使われていた元々のMVCでは
Modelは状態変化の通知を相手を決めずに「ブロードキャスト」するものだった。なのでModelはViewに
ついて知っている必要は無い。他方でブロードキャストとして通知を受信したViewは必要に応じてModel
から現在の状態をプルする。

ところがウェブというのはCometその他を除けば残りはクライアントからHTTPリクエストを投げてサーバー
がそれに応じたレスポンスを返す、クライアントにとっては基本的にプル操作しかない。
なのでWeb向けのMVCフレームワークの多くではModelの状態変更通知のブロードキャストの実装はすっ
飛ばされて、Modelからの状態のプルだけが残っているのが大まかな流れだと思う。

902 ：デフォルトの名無しさん：2013/07/18(木) 10:47:13.23

新しいWebサイトの開発もあるけど、既存のWebサイトの改修作業の方が仕事的には多いからな
改修作業においては、未だにStruts1.xが多い

でも、Struts2.x使ってるって話は、あまり聞かないな
Struts2.xよりは、SAStrutsの方が使われてる感じがする

903 ：デフォルトの名無しさん：2013/07/18(木) 15:58:13.00

Struts2をググったら致命的なセキュリティホールがあるらしいんだけど
どうなの？大丈夫なの？

904 ：デフォルトの名無しさん：2013/07/18(木) 18:10:35.35

>>903
セキュリティーホールがあるなら大丈夫なわけないだろ

Strutsなんて海外では人気ないし
ろくにメンテもされてないからセキュリティホールもあるってこと

905 ：デフォルトの名無しさん：2013/07/18(木) 21:43:50.84

>>903
「Struts 2の脆弱性を突いて不正侵入」、JINS通販サイトのカード情報漏洩」
ttp://itpro.nikkeibp.co.jp/article/NEWS/20130501/474536/

基本的な設計思想に穴があって、任意のOSのコマンドを実行できる。
対処療法でがんがんリビジョンが上がっているけど、完全にふさぐのは無理っぽい。
サービスを直ちに停止した方が良いレベル。

Struts1は、単なるディスパッチャとタグライブラリなんで、
基本的なことを押さえて造られていれば、まだしばらくは使えるはず

906 ：デフォルトの名無しさん：2013/07/18(木) 22:03:22.28

JPA2いいかもしれんな
EE仕様だからGlassfishに始めから同梱されてるし
バリデーションや2次キャッシュも簡単に仕込める
最初はJPAにテーブルを自動生成させて後からDDLを調整みたいな手っ取り早さもいい

907 ：デフォルトの名無しさん：2013/07/18(木) 22:06:51.34

新規は問題ないが、Strutsで構築してきた既存システムの
バージョンアップを今後どうするかだな。

908 ：デフォルトの名無しさん：2013/07/18(木) 22:15:41.20

>>907
Springも使いづらいし、RailsかASP.NET MVCだろう

Oracleは産廃みたいなフレームワーク、ライブラリしか作れないし
いいかげんJavaのコード捨てる時期

909 ：デフォルトの名無しさん：2013/07/18(木) 23:04:37.19

>>908
既存のシステムを作り変えられるほどの工数があればいいんだけどな
実際にそこまでの金を引き出せることは、まずほとんどない

910 ：デフォルトの名無しさん：2013/07/18(木) 23:19:36.30

勉強に時間かけて不便に耐えて
ようやく慣れたと思ったらセキュリティホールとかw
もう生で作った方が絶対いいだろ

911 ：デフォルトの名無しさん：2013/07/18(木) 23:26:16.01

ASP.NET推しカキコをよく見るけど、あれってJavaでも書けるん？
C#とかMS言語でないとダメ？

Javaで書けないんだったら、ASP.NET扱うスレでやってほしい。

912 ：デフォルトの名無しさん：2013/07/18(木) 23:30:44.99

この際だからStruts2は捨ててStruts1のサポート復活させてほしい。

913 ：デフォルトの名無しさん：2013/07/18(木) 23:55:25.85

>>911
ASP.NETはC#.netかVisualBasic.net。
Javaに対抗して作られたのがC#だから基本は割と似てる部分がある。

C#は静的言語でJavaできる人ならすんなり覚えられるし
Javaより短いコードで簡潔にかける。

Javaだとカプセル化するのにgetter/setterで馬鹿みたいに冗長なコードになるが
C#なら1行でかける。
public int CustomerID { get; set; }

JavaできるならC#は絶対に押さえておくべき言語。

914 ：デフォルトの名無しさん：2013/07/18(木) 23:59:18.68

>>908
Java→Railsはあり得ない

915 ：デフォルトの名無しさん：2013/07/19(金) 00:02:01.15

だから、どうしてこのスレで.netが出て来るの？
スレタイも読めないのか？

916 ：デフォルトの名無しさん：2013/07/19(金) 00:10:09.00

>>915
Javaにろくなフレームワークがないから

917 ：デフォルトの名無しさん：2013/07/19(金) 00:12:45.43

てかJava EEでいいよ

918 ：デフォルトの名無しさん：2013/07/19(金) 00:14:36.14

まあ、C#もJavaに負けず劣らずのウンコっぷりだから
わざわざJavaから乗り換える意味が無いんだわ

919 ：デフォルトの名無しさん：2013/07/19(金) 00:30:38.83

SpringMVC好きだけどな

920 ：デフォルトの名無しさん：2013/07/19(金) 03:31:03.02

Grails・・・なかなか賛同者は現れないしGroovyスレも過疎っているけど・・・良いよ。

921 ：デフォルトの名無しさん：2013/07/19(金) 06:28:53.75

社内SEがいるクライアントならば、Struts2のシステム構築を提案した時点で、
信用失墜するだろが。

922 ：デフォルトの名無しさん：2013/07/19(金) 07:51:09.18

たまにC#でも開発するけど、C系列はメソッド名が本当に覚えづらい。

923 ：デフォルトの名無しさん：2013/07/19(金) 10:35:18.62

JavaもC#もやってるけど、SpringMVCからASP.NET MVCに移ったが、
ASP.NET MVC はシンプルで書きやすいし、それでいて多機能。
そのあと SpringMVC の、一つのメソッドにアノテーションがやたらくっついているソースを見るとうんざりする。

>>915
たしかに Java のスレだけど、正直なところ、他の言語のwebフレームワークのほうが優れたものが多いと感じる。

ただ、それらを褒めてJavaのフレームワークをdisるのではなく、
「あのフレームワークの仕組みが Java にもきたらいいね」みたいな議論ができたらいいなとおもう。

自分は、結構過疎っていたこのスレが、ここ数ヶ月賑わっているのが、結構おもしろかった。

924 ：デフォルトの名無しさん：2013/07/19(金) 10:43:03.90

SpringMVCやってみたいけど個人情報登録しないとダウンロードできないから
やる気がしない

925 ：デフォルトの名無しさん：2013/07/19(金) 10:48:48.64

普通Mavenの類を使うでしょ。手動ダウンロードっていつの時代。

926 ：デフォルトの名無しさん：2013/07/19(金) 10:51:13.03

何事もまずは手動でやりたい。

927 ：デフォルトの名無しさん：2013/07/19(金) 12:40:41.28

まあ手動で手軽に導入可能なフレームワークは好きだな
GWTとかあっさりしてる
JBOSSはIDEにウェルカムページ要求してくるは細かいエラー（大事に至らない程度だが）が多くて使いづらい

928 ：デフォルトの名無しさん：2013/07/19(金) 13:32:58.49

MavenだのAntだのも面倒くさいね。
アプリ一つ作るのにやることが多すぎるだろJavaは。

929 ：デフォルトの名無しさん：2013/07/19(金) 14:36:22.16

Mavenだって十分に手動でしょ。手作業でdependency追加して、バージョン競合発生したら
場合によっては手作業でexclude追加したりとかdependency-management書いたりとか。
プラグインの類の設定も殆どは手作業だ。

ただし、そういう手作業が適切に出来るのもMavenが依存性情報を持っているから。
単に自動ダウンロードツールだから使っているわけではなかろうに。

今時手動ダウンロードがあり得ないって、別に手動でダウンロードすることがあり得ない
だけではなく、そこから先の記憶と偶然に頼っただけのJarファイル管理自体があり得ない。
手動ダウンロードが好きな人は、単に落としてきたJarのセットをアプリのlibフォルダに
上書きする以上のどんな依存性管理が出来ているのか実に知りたい。

特にSpringみたいに細かくパッケージが分かれているものは依存性ツリーを見られるだけ
でも使っているFWがどういう構成で出来ているのか理解出来るので価値がある。
単に全部入りのSDKを落としてきて解凍してわぁ動いた、では製品構成について何も理解
出来ないだろうに。

930 ：デフォルトの名無しさん：2013/07/19(金) 14:55:22.38

そんな重いフレームワークなのか。じゃあいいや。

931 ：デフォルトの名無しさん：2013/07/19(金) 16:18:26.01

Spring MVC単体だと600kb少々だね。
MavenとかつかうとSpring MVCを使うのに必要になる他のパッケージを自動的に特定して
ダウンロードする。
その中で自分の用途には明らかに必要としないパッケージがあればexclude指定することで
そのパッケージや付随するパッケージを簡単かつ比較的安全綺麗に取り除ける。

他方でSpringSourceのサイトから全部入りアーカイブを手動ダウンロードすると40MB超。
そこから必要なJarだけ切り分けるのは結構大変。

GWT? 100MB超のSDKを落とすしか方法は無いねw

932 ：デフォルトの名無しさん：2013/07/19(金) 16:23:13.20

Ruby の gem とか .NET の NuGet を使うと、Maven がクソに思える。

あと Maven は依存関係がたまにおかしく、よけいなものをたくさん持ってくるので、
結局、初回だけは毎回目で確認する必要がある。(これはおれが気にしすぎなのかもしれないが)

Ruby の gem や python の easy_install (ようするにLL用)はともかく、
Javaと同じようにIDEで開発し、コンパイルも行う、Visual Studio での NuGet は、Java勢もまねしてほしい。
ビルド時にも、無ければ勝手に落としてくれるし。

933 ：デフォルトの名無しさん：2013/07/19(金) 16:41:40.56

MavenのIDE対応ならEclipse用のm2eプラグインは素っ気ないけど結構まともだと思う。
個人的にはm2eのGUIとコマンドラインの両方使うかな。

インクリメンタルサーチができる依存性ツリー画面は便利だし、Mavenで解決した
依存性情報を利用しつつmvnコマンド経由ではなく直接プログラムを実行出来るので
毎度mvnコマンド経由で実行するNetBeansよりテストの実行時などは軽くて便利。

NuGet、面白そう。Artifactoryみたいに社内用のリポジトリとかも立ち上げられる
のかな。

何れにしても今更依存性管理ツールも使わず手作業でJar管理なんて無いでしょ。

934 ：デフォルトの名無しさん：2013/07/19(金) 17:16:28.05

>>932
MSのNuGetよくできてるよな

Javaに期待しても駄目だろう
Javaはコミュニティに力持たせてるから
平凡な開発者が議論ばかりしていて先に進めなくなってる。

決定権は一握りの天才に持たせたほうがうまくいくんだけどな

935 ：デフォルトの名無しさん：2013/07/19(金) 17:33:58.41

凡人用言語だから天才的発想でいいもの作られてもついていけないよ

936 ：デフォルトの名無しさん：2013/07/19(金) 17:43:56.20

別に個人情報登録せずともダウンロードできるだろ、Spring。

937 ：デフォルトの名無しさん：2013/07/19(金) 17:55:42.61

Java以外の話もしたいなら次スレのタイトルからJavaを外せばいいじゃない
そうすればASP.NET MVCもスレ違いじゃなくなる

938 ：デフォルトの名無しさん：2013/07/19(金) 18:50:08.58

>>905
試してみた。
適当に作った任意のアプリで?以降をコピペしたら動くとかどんだけだよｗ

939 ：デフォルトの名無しさん：2013/07/19(金) 20:45:59.60

Struts2はもう廃棄物として扱うほかないな
FW開発者も利用者プログラマも安全にできない末期的状態

940 ：デフォルトの名無しさん：2013/07/19(金) 20:59:08.19

ここまでJSF2.0なし
JSF1.2は使ったことがあるし、JavaEE6 だったかで JSF2.0 が新しくなったと
Oracleはアピールしているが、JSF2.0になって何かいいことあったの？

JSF1.2は、使いづらかったという思い出しかない

941 ：デフォルトの名無しさん：2013/07/19(金) 21:00:05.39

Jerseyのスレないのか。
試しに2.0使ってみたけど、ろくにログはかないからエラーの時困るわ。

942 ：デフォルトの名無しさん：2013/07/19(金) 21:14:11.27

JSF2はFaceletsベース(xhtml風）だから親和性が高い
NetBeansならJSF上でCDIを参照してくれるからStrutsの置き換えにはいいと思う
最近リリースされたJSF2.2(JavaEE 7)はテンプレートがちゃんとhtmlとして表示できるらしいね

943 ：デフォルトの名無しさん：2013/07/19(金) 21:23:01.16

まあ、俺はSpring MVCで困らないんですけどね。

944 ：デフォルトの名無しさん：2013/07/19(金) 21:51:03.42

Maven、ひな形を作るのには使うけど、それ以外には使いたくない。

945 ：デフォルトの名無しさん：2013/07/19(金) 22:01:16.59

pom.xmlがあればeclipseの.classpathが要らないって嘘だよねぇ

946 ：デフォルトの名無しさん：2013/07/19(金) 22:53:53.34

インターネットに繋がってない環境じゃない限りmaven使ったほうが圧倒的に楽だと思うけど…

947 ：デフォルトの名無しさん：2013/07/20(土) 03:12:29.01

Eclipse上でMavenプロジェクトを扱うときは他のEclipseプロジェクトと同様に
.classpathが必要だけど、m2eが.classpathにMaven dependencyコンテナを追加
すると以降jarファイルの解決はMaven任せになるので手動でjarをダウンロード
したりクラスパスにjarを登録する必要は無くなる。

>>946
だよねぇ。

プロジェクトが複雑になってpomをゴリゴリ弄り始めるとMavenは途端に厄介だけ
れども、素直な構成のプロジェクトなら圧倒的に楽。
手作業の方が好きだとかMなのか単に食わず嫌いなのかよく解らん。

948 ：デフォルトの名無しさん：2013/07/20(土) 05:22:18.75

このStruts2のセキュリティ騒ぎが無駄に延焼してStruts1やStrutsを利用した和製フレームワーク
までとばっちりで嫌がられる流れになればよいと思います。

949 ：デフォルトの名無しさん：2013/07/20(土) 11:09:55.01

>>948
まあ、ならねえな。
ド素人ならいざ知らず、Struts1とStruts2が全く違うってのは常識だし。

950 ：デフォルトの名無しさん：2013/07/20(土) 11:15:19.60

Struts1とJSP&Servletってあまり違いがないからStruts1は
要らないと思うけどでももうStruts1で作ったシステムが
いっぱいあるんだからサポートはしろよ。

951 ：デフォルトの名無しさん：2013/07/20(土) 11:23:04.51

>>950
時代遅れの化石だから俺たち知らね

952 ：デフォルトの名無しさん：2013/07/20(土) 12:40:44.60

無償で配布されているオープンソース製品にサポートを求めること自体ナンセンス。
すべて自己責任でどうぞ。

953 ：デフォルトの名無しさん：2013/07/20(土) 12:55:09.24

だよね。それならやっぱり使えないや。

954 ：デフォルトの名無しさん：2013/07/20(土) 12:57:09.74

NTTデータや富士通がサポート表明してるがどうでもいいな
自分でサポートできないヤツは使わなければいいだけのこと

955 ：デフォルトの名無しさん：2013/07/20(土) 12:58:08.24

自分でサポートするなら自分のフレームワークでいいや。

956 ：デフォルトの名無しさん：2013/07/20(土) 14:04:27.58

Maven、設定XML書くのがめんどい
JSONでできればいいのに。

957 ：デフォルトの名無しさん：2013/07/20(土) 14:10:11.85

>>942
2.1で大幅改善したとはいえメモリもCPUも消費が激しい重量級FWだけにStrutsの置き換えには向かん
支持者ですらユーザ数少ないイントラ限定という認識
JSFはASP.NETの後追いだが本家同様Java EEにもアクションベースでHTML返すASP.NET MVC相当のFWが必要
JSFとJAX-RSだけじゃ一番需要のあるところが埋めれない。相変わらずJava EEはダメ

958 ：デフォルトの名無しさん：2013/07/20(土) 14:26:24.41

次のプロジェクトは、
コントローラはJersey、モデルはSpring+Doma、ビューはHTML+Javascript
の構成で行くつもり。
クライアントのUIがコード丸見えなのがちょっと嫌だけど。

959 ：デフォルトの名無しさん：2013/07/20(土) 14:43:52.16

>>958
それ非効率極まりないね

あとJS無効にされてたらなにもレンダリングされないじゃないの。

プライベートブラウジング機能が搭載されてきてるから
JS無効になってるなんてケースは増えてる。

960 ：デフォルトの名無しさん：2013/07/20(土) 14:44:40.40

>>958
> クライアントのUIがコード丸見えなのがちょっと嫌だけど。

セキュリティホール確定。
クライアント側は当然偽装し放題ですよ。

ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも）
なので、見えないページはムカつきつつ閉じてます。
わざわざ開く価値なんてないし。

961 ：デフォルトの名無しさん：2013/07/20(土) 15:04:12.10

クライアントが偽装し放題なんて、別にJS関係ないし…。
そもそもJS無効どうこうなら、ajaxすら使えないわけで。

962 ：デフォルトの名無しさん：2013/07/20(土) 15:44:42.77

ダイナミックHTML時代のままで大いに結構
Ajaxまでは求めちゃいないよ

963 ：デフォルトの名無しさん：2013/07/20(土) 16:03:09.22

ビジネスロジックをJavaScriptに書かない限りセキュリティは関係無いでしょ。

ただ良くある「分厚いコントローラー」でビジネスロジックの一部がコントローラー等に
はみ出てビューロジックと混在して実装されているような場合、単にJavaScriptに置き
換えると大事なものが出ちゃうかも。

RESTインターフェイスを界面としてそこがどう叩かれようと内側を守るように実装する
必要があるわけだけど。
その結果何が発生するかというと、大抵は二度手間が増えるんだよね・・・
ビューは信用ならんという前提で設計するので、サーバー側のモデルやサービスと
JavaScriptのビューロジックで似たようなバリデータを書いたりする必要がある。

964 ：デフォルトの名無しさん：2013/07/20(土) 16:08:11.02

JAX-RSでXMLやJOSN使うならJavaScriptは前提だし構わん
Bean ValidationのアノテーションをJavaScriptに変換するライブラリが出来たらいいな

965 ：デフォルトの名無しさん：2013/07/20(土) 16:12:45.27

JavascriptのON/OFFとかサイトによって選択しろよ
常にOFFでむかつきながら閉じるとか言ってても
結局ネットバンキングとか必要なサービス受けるときはONにしてるんだろ？

基本OFFにして信用してるところはONにするって方針なら賛成だけど、
常にOFFとかもう時代に合ってないと思うわ。
JavascriptOFFだとJDKのダウンロードすらできないんだぞ？

966 ：デフォルトの名無しさん：2013/07/20(土) 16:54:41.01

>>952
趣味なら使ってもいいけど
客のシステムにそんなの使うのは残酷すぎるね

967 ：デフォルトの名無しさん：2013/07/20(土) 17:00:07.52

>>963 >>964
それはないと断言できる
プログラムの前にキミはWebがわかってない

968 ：デフォルトの名無しさん：2013/07/20(土) 17:03:32.81

Web先生おはようございます

969 ：デフォルトの名無しさん：2013/07/20(土) 17:24:06.61

JSだと偽装だのセキュリティホールだの言ってるバカは何なんだ
それがダメならHTMLのフォームもダメだろw

970 ：デフォルトの名無しさん：2013/07/20(土) 18:52:03.67

JSを無効にしても動くってのはいまは最低条件だな
それ実現できてないやつは無能

Ajaxはユーザビリティを高めるためにつかうもので
ブラウザでJS無効にしても動作することが求められる。

>>965
ネットバンキングでJS必須の銀行なんてないだろ
ネットバンキングで非同期読み込みとか使わないし

971 ：デフォルトの名無しさん：2013/07/20(土) 19:07:12.97

そら非同期を必要とするような処理がないからな
いつの時代から引っ越して来たのやら

972 ：デフォルトの名無しさん：2013/07/20(土) 19:10:46.04

なんか10年前みたいな話をしているな。

JS無効にしても動くというのはWebとしては基本だけど、
今時だと動作条件がJS前提で良いからユーザビリティ重視というニーズもあるんだよ。

973 ：デフォルトの名無しさん：2013/07/20(土) 19:37:05.71

そそ、要件次第よ
ユーザビリティを追求すればAjaxを補助的に使うんじゃなくてシングルページアプリに向かう
その時にJSをオフにしてる高々1～2%のユーザを救うには別途画面を用意するためコストがかかる
1～2%のユーザを捨てるか、ユーザビリティの追求をやめるか、コストをかけるか
決めるのは客
俺が縁のあった客は1～2%のユーザは捨てられない、そのためにコストはかけられない、
それでユーザビリティは追求しなくなるわけだが、その結果1～2%より多くのユーザを失ってると思ってる

974 ：デフォルトの名無しさん：2013/07/20(土) 21:02:30.86

JS切ってるのは2％どころじゃないわ
10%弱はいる

975 ：デフォルトの名無しさん：2013/07/20(土) 21:04:37.46

ねーよw

976 ：デフォルトの名無しさん：2013/07/20(土) 21:27:50.02

PHPは2位、7月PYPLプログラミング言語人気
http://news.mynavi.jp/news/2013/07/11/126/index.html

これはTIOBEより実態に近いランキングだな

どなたかそろそろ次スレよろしく

977 ：デフォルトの名無しさん：2013/07/20(土) 22:04:05.29

10%くそわろたw そんなんならもうネットやめとけw

978 ：デフォルトの名無しさん：2013/07/21(日) 01:46:10.64

未だにアンチJS派っているんだな。
ご愁傷様って感じ。

979 ：忍法帖【Lv=8,xxxP】(1+0：5) ：2013/07/21(日) 05:38:36.87

「ＥＲＲＯＲ：Lvが足りなくてスレッド立て(ら)れません。」でした orz
誰かよろしく

980 ：デフォルトの名無しさん：2013/07/21(日) 05:45:16.15

1～2%ってのはこれだね

JavaScriptをオフにしているブラウザは1％前後。米ヤフー調べ
ttp://www.publickey1.jp/blog/10/javascript1.html

981 ：デフォルトの名無しさん：2013/07/21(日) 12:08:21.50

ASP.NET MVCを推奨している意見には同意できるが
MVC3とMVC4は、優れた和訳本がなかなかないね。

982 ：デフォルトの名無しさん：2013/07/21(日) 12:44:19.43

優れてる以前に和書自体少ないのな
タイトルにMVCって入ってるのは2009年から年に一冊ずつで4冊だけ

2009 ASP.NET MVC実践プログラミング
2010 ひと目でわかるASP.NET MVCアプリケーション開発入門
2011 ASP.NET MVC 2 プログラミングリソース
2012 プログラミングMicrosoft ASP.NET MVC ASP.NET MVC 3対応版

今年はまだない。4もない

983 ：デフォルトの名無しさん：2013/07/21(日) 12:49:28.20

俺は生ASP.NETが好き

984 ：デフォルトの名無しさん：2013/07/21(日) 12:56:36.87

生ASP.NETってIHttpHandlerの事か？

985 ：デフォルトの名無しさん：2013/07/21(日) 13:17:05.95

aspxファイルとrequest&responseオブジェクトだけて作るのが生ASP.NETだね

986 ：デフォルトの名無しさん：2013/07/21(日) 15:45:25.11

もう和書なんて期待できないだろ。

987 ：デフォルトの名無しさん：2013/07/21(日) 15:56:30.54

わっしょいわっしょい和書わっしょい♪

988 ：デフォルトの名無しさん：2013/07/21(日) 16:08:48.88

フレームワーク否定厨あらためサポート厨って技術的なレスは一切しないよね
一日中張り付いて突っ込みとも煽りとも言えない面白くもないどうでもいいレスばかり
Servletとかわめいてたけど実際にServletをどう使ってるかには答えようとしない
なんでこのスレに粘着しちゃったのか知らんけどプログラマですらなさそう
ORMスレを乗っ取ったアニヲタ(？)と同類

989 ：デフォルトの名無しさん：2013/07/21(日) 16:15:31.63

欧州勤務なのだが職場の本棚のオライリー本を数冊日本語版に差し替えるというネタを仕込んで
はや数ヶ月、先日ようやく気がつかずに日本語版を手にとって開いた人の悲鳴があがったw

ともあれオライリーはもちろんその他の本についても日本語は非英語圏の中でも翻訳文化がまだ
比較的ちゃんと機能している恵まれた環境だと思う。

ただ流石に日本人の強力なコミュニティーや日本にも展開する企業のバックアップが無いFWは
なかなか和書や訳書は出にくいと思う。
結局日本ではSpring+HibernateよりもSeasar系に流れがちなのも日本語リソースの多さ新鮮さ
によるものなのかな。

990 ：デフォルトの名無しさん：2013/07/21(日) 16:37:43.62

でもフレームワーク使うとセキュリティホールだらけになるし

991 ：デフォルトの名無しさん：2013/07/21(日) 16:41:43.99

>>988
ただで教えるわけないだろ

992 ：デフォルトの名無しさん：2013/07/21(日) 16:46:09.82

俺がなぜ否定厨かというと、俺が反対したのに自社プロダクトに
Strus1なんか採用しやがって、さらにあっという間にサポート切れ。
会社の無能集団がムカつくからここで憂さ晴らし

993 ：デフォルトの名無しさん：2013/07/21(日) 17:34:52.55

結局技術力なければ、どのルートを辿ろうと同じことだろ。

994 ：デフォルトの名無しさん：2013/07/21(日) 17:42:33.01

Javaのフレームワークの場合、フレームワークのソース公開されてるんだから
問題あれば自分で直せばいいだけのこと
サポートうんたら言ってる馬鹿は、オープンソースというものを全く理解していない
多分、修正する技術力がないから、文句しか言えないんだろうよｗ

995 ：デフォルトの名無しさん：2013/07/21(日) 17:43:11.76

サポートが短いからダメって具体的にどのようなシステムを何年運用することを想定して
言っているのか非常に興味がある。
社内システムとかならともかくB2CのECサイトとかStruts1の時代のシステムをリニューアル
もせずに使い続けているのかな。

996 ：デフォルトの名無しさん：2013/07/21(日) 17:43:33.66

>>989
オフショア意識して英語情報必須だからSeasar選ばないってところもあるよ

997 ：デフォルトの名無しさん：2013/07/21(日) 17:46:28.71

>>992がいう無能集団より>>992本人が無能っていうねw
だから意見が通らないんだよ
実際、Struts1選んだ連中はEOLになっても何も困ってないだろうよ

998 ：デフォルトの名無しさん：2013/07/21(日) 17:55:15.29

>>994
だからー
自分で治すくらいならオレオレフレームワークのがいいってーの

999 ：デフォルトの名無しさん：2013/07/21(日) 17:58:59.43

>>998
結局他人が書いたフレームワークをメンテするなら、貴方が書いたオレオレよりも
情報が充実していてドキュメントも完備した名の知れたフレームワークの方が良いです。

自分一人の趣味なら、オレオレで良いんじゃ無いのかな。

1000 ：デフォルトの名無しさん：2013/07/21(日) 17:59:40.74

スレが埋まる前に白状する
>>959,960,962,967はそれぞれ>>537,559,555,539のこぴぺ
ついでに>>815は>>596,594のこぴぺ
晒しageのつもりでやった。今は反省していない
元レス書いたバカどもは反応見て自分のバカさ加減に気づけバカ
>>827、お前元レス書いたバカの一人だろw m9(^Д^)9mﾌﾟｷﾞｬｰ
もちろん俺のこの行為がバカげてることは自覚してる。てへぺろ

1001 ：１００１：Over 1000 Thread

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。