【Java】 Java Web Application Framework 総合

1 名前：デフォルトの名無しさん [2012/06/03(日) 16:18:39.74 ] Java用のWeb Application Frameworkについて語るスレッド 海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない 開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを 比較しながら、最高のフレームワークを探してみるスレッド Web Application Framework　のリスト en.wikipedia.org/wiki/Comparison_of_web_application_frameworks 特徴の比較 en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features 75 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 10:02:16.75 ] >>73 でもScalaは結局はやらなかった。 76 名前：デフォルトの名無しさん mailto:sage [2012/10/16(火) 10:27:38.54 ] Sunの時代にJavaは進化が止まっていた。 ORACLEのJavaになって多少は進歩するんじゃないか propertyは、C#やってる人間なら便利さがわかるが、 Javaの世界では「可読性がおちる」といって反対意見があった。 他のドットの意味と区別がつかないんだとさｗ C#は開発生産性重視で、柔軟にいろいろと取り入れているが Javaは厳格すぎるために生産性が悪くなってるな 77 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 08:30:51.72 ] この前Javaのセミナーに行ったが、 ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。 前々からStrutsならDisってたけど。 >>79 見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。 81 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 11:21:09.89 ] >>80 > ついにオラクルの担当者がSeasar2とTomcatをDisりはじめたのが印象的であった。 あの人はそれが仕事だから・・・(笑) 聴衆は、それを笑ってあげるのが仕事(話の内容が合っているかどうかに関わらず) ちなみにおれもその場にいた。 > 見たことないなあ…。まだSeasar2の方が多いんじゃないの日本では。 おれの周りでは SpringMVC のほうがかなり多い。Seasar2はだいぶいなくなった。 >>80 さんのレスを否定するわけではないが、日本全体でちゃんとした調査をしないと、そこら辺は何とも言えんのでは。 82 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 12:53:34.35 ] 俺の周りもSpring MVCが多いよ。 Seasarはもう役目を終えた感じだし。 ついでにJAX-RSは良いねという意見を聞くこともあるけど、Spring MVCの完全置き換えが出来るようになるのはJ2EE8とか9の頃じゃね、とも思う。 あと、良いのはJAX-RSではなくJerseyだろ、っという話もあるけど。 83 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 13:56:20.03 ] >>80 寺田氏？ならTomcatは前々からおおっぴらにdisってたな とはいえGlassfishを運用する勇気はねぇっす 84 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 13:58:18.68 ] >>82 Seasarは中の人がJavaからいなくなったしな 85 名前：デフォルトの名無しさん mailto:sage [2012/12/03(月) 17:49:10.59 ] TomcatをdisったりGlassfishをステマするのはまだわかるよ。 でも、開発にJ2EEを使え、っというのは笑うところ。 86 名前：デフォルトの名無しさん mailto:sage [2012/12/04(火) 00:55:45.19 ] >>85 J2EEじゃなくてJavaEEだろ！ と笑えって意味？ 87 名前：80 mailto:sage [2012/12/04(火) 01:27:58.76 ] >>81 自分の周りがそうだってのはあるけど、 やっぱり他の会社が何使ってるかってのは参考になるよ。 Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。 SpringMVCは使ってみたいんだけどなんか昔やった時やたらとっつきが悪かったイメージがあって…。 最近大分あれから使いやすくなってるとは聞いてるんだけどね。 ネットで調べろって言われるんだろうけど、いい解説書があればいいんだけどなー。 ・・・もっとも、今やってる仕事デフォのStrutsアプリの改良案件だから それ以前の問題がうちの会社にはあるけどね。 あんな馬鹿デカいアプリSeasarにせよSpringにせよ移行できないよー(涙）。 88 名前：デフォルトの名無しさん mailto:sage [2012/12/04(火) 08:43:26.29 ] >>85 JavaEEのツールですべてまかなえ、ということだろう やさしいな、おれ 89 名前：デフォルトの名無しさん mailto:sage [2012/12/04(火) 09:03:53.58 ] ごくごく小規模ならJSF2.1にEJB3.1orCDI、裏はJPA2.0とかで組めなくもないけど… 小規模でやるには仕組みが大げさすぎるし、逆に大規模になると今度は大雑把すぎて扱いにくいんだよなぁ。 足りないところを色々と足して俺俺F/W作って教育するくらいなら、技術者集めやすい他の選択肢を探してしまう 90 名前：81 mailto:sage [2012/12/04(火) 10:34:09.96 ] > >>81 > 自分の周りがそうだってのはあるけど、 > やっぱり他の会社が何使ってるかってのは参考になるよ。 あ、それは私もそう思うので、正しいかどうかは置いといて、 「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね (そういう意味では >>81 の自分のレスは書き方が良くなかった) ただですらJavaの開発現場は衰退してきているので。 > Seasarスゲー安定してると思うけど、確かに発展性ないのは痛いからね。 たしかにSeasar2は発展性はないだろうけど、安定はしているし、Springよりは簡単で軽くていいと思う。 使い捨てとか、あまり大規模にならない開発だったら選んでもいいと思うけどね。 Springはアノテーション地獄になって読みづらいし、追いかけづらくなった。 XML地獄の方がまだマシだと思う(あとからメンテする側としては、追いかけやすい) 91 名前：81 mailto:sage [2012/12/04(火) 10:35:30.46 ] あ、 >>90 は >>87 へのレスです。 あと、誤記： 誤： 「自分の周りだこうだよ」っていうレスは、うれしい資産高になりますね 正： 「自分の周りだこうだよ」っていうレスは、うれしいし参考になりますね 92 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/04(火) 20:53:08.58 ] >>93 専用のO/Rマッパーはないはず。 親和性の高さだとHibernateが一番だと思う。 あと、有名どころのプロダクトならSpringとつなぐための仕組みが提供されてるからその辺りの選択肢は広いよ。 95 名前：デフォルトの名無しさん mailto:sage [2012/12/04(火) 21:13:48.85 ] >>93 そうそう、SeasarはS2JDBCは良いんだけどね−。 他のFWでデータアクセスする時は、APTでマッピング用のDTOから条件式用のクラスを作ったり、 多少賢いSQLビルダーを自作して、実行とマッピング自体はFW付属やその他データアクセスFWの エンジンを使うことで、S2JDBCに近いことができるようにしているかな。 逆に言うと、S2JDBCに近いことをやりたいなら、SQLビルダーの自作やメタデータ系クラスの 操作なんかは必須。 96 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/05(水) 20:54:09.65 ] 直近2年で6システムに絡んだけど採用0だったな。 2システムは客の親会社が作ったF/W(JDBCラッパーレベル)、 残りはMyBatis2, DOMA1, S2JDBC1。 客視点で見た時にもSQLはわかりやすいんだろうなぁと思う。 99 名前：デフォルトの名無しさん mailto:sage [2012/12/05(水) 22:33:15.22 ] Hibernateなんかが想定しているオブジェクトモデルと、 Javaが多く利用されているであろう業務システムのデータ設計、クエリパターンは異なるので、 採用が少ないというのもまあ当然なんだろう。 100 名前：80 mailto:sage [2012/12/05(水) 23:03:29.36 ] >>97 Hibernateは使ったことがある。まあ悪くない。 JPAは・・・ごめんよくわからない。 仕事は今のところS2JDBCか、 そうでなかったら直にSQL書いてせいぜいCommonDBUtilかます程度。 101 名前：デフォルトの名無しさん mailto:sage [2012/12/05(水) 23:43:06.07 ] 仕事で今までSpringもSeasarも使ったことがないんだけど、 最近はSpringが多いのでしょうか 102 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 06:20:39.96 ] 何が使われるのか？なんてのは F/W 選定できる権限持ってる担当者の コダワリとか、会社の文化やらでだいぶ変わるんじゃないかな？ ゴールを取れる事が本質だとは思うけど。周りが使っているのは気になるね。 ということで、私の環境も晒しておくよ。自分たちで選定できる案件なら、ここ数年は Tapestry5系と MyBatis3 が中心。あとは分散時に Spring の Remote を使うかな？ 他では類を見ない変態的構成かもしれんｗ 103 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 07:07:48.52 ] Struts1.3だけ使ってるけど時代遅れ？ 104 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 11:13:53.50 ] 複雑な業務ドメインの場合、パーシステントの実装とモデルはむしろ分離しているからなぁ。 リポジトリを境界にして、その内部はSQL書くでもかまわない感じで。 大規模というか大量になったときにSQLを書きたくないのはそうだけど、 基本的な処理の自動生成なんかはどのFWにもあるし。 業務系といっても、レポートが大半、DB設計もそれを想定みたいな所が多いから、結局SQLというケースになるんじゃないかな。 107 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 11:24:07.78 ] 個人的にはJSP&Servletが最強 108 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 13:34:47.17 ] 5年前ならともかく, いま皆さんが Web アプリ作るのにわざわざ Java を使う理由って何ですか？Ruby とか Python で十分な気がするんだけど・・・。 109 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 14:42:34.80 ] 業務系アプリ作るならやっぱり静的言語のほうが安全なもんで 110 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 15:28:34.02 ] >>108 運用側が(彼等にとって)新しいのを入れたがらないから常にJava前提 111 名前：デフォルトの名無しさん mailto:sage [2012/12/06(木) 23:21:33.64 ] >>108 RubyとかPHPならありかもしれんけど、 日本でWebにpythonはないと思うよ。 何故と聞かれたら情報がない。 Java、Ruby、PHPはいろいろ探せばwebアプリ作成のための情報ソースが その辺にいくらでも転がってるからね。 ちなみにあえてJavaである理由って言えば既存の資産が既にJavaだからだね。 今のの保守と新規の開発を両立するのならぶっちゃけ言語変える必要がないので。 別の環境作んないといけないじゃん。 別にEclipseとか使って開発する分にはそんなPHPとかに比べて開発しにくいとも思わないし。 困った時にはライブラリ探せば結構どうにかなるくらい既存の資産が大量にある。 もちろん慣れてるってのも大きいけど。 それにもいろいろ変えるにはお金がかかるし、なんで今動いてるやり方じゃダメなのって意識が 顧客にあるので意外にOKしてくれないのよ。 >>104さんみたいな事例はいっぱいあるからねえ・・・。 112 名前：デフォルトの名無しさん mailto:sage [2012/12/07(金) 00:55:35.11 ] 新規開発は一瞬で終わりだけど、その後の長く続くメンテは お客さんのシステム部門(子会社が多い)が既存システムと 掛け持ちでやるから、既存システムと同じ技術ベースが 求められるケースが多いな 部分最適(案件毎に最適な技術を選択)の総和が全体最適に なるとは限らないってやつだわ 113 名前：デフォルトの名無しさん mailto:sage [2012/12/07(金) 10:38:55.48 ] Javaは、いい意味でも悪い意味でも、これからのCOBOL、VB6 になっていくと思う。 先鋭的な技術系の会社、ベンチャーと違い、SIerやヘボいソフトウェア開発会社は、Javaしかできないやつが多すぎるから。 逆に言うとJava要員は集めやすい。 バージョンの下位互換もかなり取られているし。 114 名前：108 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 08:51:32.87 ] MS狂と議論してもしょうがない 117 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 10:03:33.47 ] >>113 Javaでビジネスロジック程度のプログラムを書くことしかできない技術者は多い。 フレームワークを自力で設計・構築できる程度のスキルを持つ技術者とか アプリケーションサーバやJavaVMの内部を熟知している技術者はほとんどいないね。 118 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 10:17:57.48 ] アンチMSもちょっとなぁ。 どっちの信者でもなければ>>115の言ってることは正しいもん。 119 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 10:54:04.22 ] >>118 俺もJavaよりC#の方が…とは思うが、このスレでそれを言っても荒れるだけだと思うので控えておく。 120 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 11:07:03.44 ] >>118 こんにちはMS信者 121 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 13:50:25.31 ] BizBrowser とか懐かしいな。8年ほど前にそれ用のリクエスト処理と JSON 返す Java 製のシンプルな枠組みとクライアント側のライブラリを セットで書いたことがあるわ。それ以来使ったこと無いけど。 リッチクライアントとかと連携するサーバシステムって、結局 HTML の代わりに クライアントが欲しいデータとのやり取りができればいいだけだから、 HTTP ベースなりの API を整備すれば大概事足りるよね。 124 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 21:32:47.36 ] RIA用途だとJAX-RSとかが使われるようになっていくのかねぇ？ 今のところ、拡張ポイントやヴァリデーションとかを考えた場合に、SpringMVCを使った方が良い気がするけど。 125 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 21:37:10.77 ] 普通にStrutsとJSPで今もシステム作ってるが、 最近Ajax的なの当たり前に要求されるようになったから JSONか下手すれば直にHTML書いて送って Jqueryでぼんみたいなことばかりやってるから正直既存機能とのかい離が激しい。 出来るものなら全部作り変えたいがもちろんそんな余力はない。 126 名前：デフォルトの名無しさん mailto:sage [2012/12/08(土) 23:37:41.63 ] バリデーションはむしろ、JavaScript側でやっちゃいたい。 JAX-RSってRESTFulなことやるんだっけ。実装は別？ SpringMVCのコントローラでもアノテーションでRESTFulなこと できるけど、どっちが軽量なんだろ？ 127 名前：108 mailto:sage [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 mailto:sage [2012/12/09(日) 00:36:21.77 ] あ、レスが別になっちゃった・・・。 >>115 C# で Web 開発ってあんまり聞いたことないですけど（当然だけど）普通にあるんですね。会社的には C# より Java が基本なので採用はちょっと難しいですが・・・。 >>113 なんか色々やってますね・・・。今度のプロジェクトはクライアントが HTML だったり Excel だったりするみたいです。 Excel を使った EUC クライアントみたいな感じの機能を沢山作る必要があるとか。Excel と上手くつなぐ方法があんまり無さそうなんですが・・・。 129 名前：デフォルトの名無しさん mailto:sage [2012/12/09(日) 09:46:56.19 ] Visual StudioでExcelブックなアプリケーション作成ってあんま情報無いよな。 Excelも2013だとWEBSERVICEなんてものもあるけどなｗ 130 名前：デフォルトの名無しさん mailto:sage [2012/12/09(日) 09:48:29.53 ] JAX-RSって、実務経験の足りない優等生、っていうイメージがあるんだよなー。 131 名前：113 mailto:sage [2012/12/09(日) 15:09:36.86 ] JAX-RSを使う場合(自分は使ったこともなく、webで斜め読みした程度の知識しかないですが), どのプロダクトを使うのがいいのかな？ やっぱり Tomcat + Jersey が一番ポピュラーなんだろうか。 あとは Glassfish は標準で JAX-RS に対応しているみたい。 というかJavaEE6 に準拠しているコンテナは標準で対応しているのか。 さっき見つけたページ JAX-RS(Jersey)を使ってみる - azuki note d.hatena.ne.jp/w650/20110119/1295411262 あと、最近このスレが活気づいていてうれしい。 自分はRailsも好きだしPlay!も気になるけど、なんだかんだでJava歴が一番長いので。 132 名前：デフォルトの名無しさん mailto:sage [2012/12/09(日) 18:11:32.73 ] デファクトはJerseyじゃないの Glassfishが組み込んでるのもJerseyじゃなかったけ？ JAX-RS、前に採用しようとして評価したんだけどさ。 そのときの感想として思ったのは、結局、実装固有の機能とかを使わないと、 JAX-RSで定義されている仕様だけだとちょっと(´・ω・`)だな〜という点。 それはJAX-RS 2.0の仕様を見る限りも微妙な感じで。 まあ、将来には期待しているけどね。 133 名前：108 mailto:sage [2012/12/10(月) 10:58:04.97 ] Dropwizard というものを発見しましたがどうでしょう。 これは JAX-RS を使ってるみたいですね。 dropwizard.codahale.com/ Jetty を内包していてスタンドアローンで動くようです。 134 名前：デフォルトの名無しさん mailto:sage [2012/12/10(月) 15:20:26.80 ] xsltを使用したフレームワークってないのかな 135 名前：113 mailto:sage [2012/12/10(月) 15:52:41.00 ] >>134 大昔から cocoon や Xalan があるではないか Xala は XML 出連携されてきた内容を HTML に変換して表示、とかやったな。 136 名前：デフォルトの名無しさん mailto:sage [2012/12/14(金) 00:38:24.74 ] xsltとかタグライブラリとか、マークアップ言語大嫌い 137 名前：デフォルトの名無しさん mailto:sage [2012/12/15(土) 09:23:47.44 ] JavaScriptでゴリゴリDOM操作して CSSでスタイル当てる方が好きだな 138 名前：デフォルトの名無しさん mailto:sage [2012/12/15(土) 22:25:08.69 ] ちょっとでかい会計系のWebアプリ立ち上げる計画があるそうだが、 フレームワーク何にするかなー。 今ならSpringMVCですかねー。個人的にはSeasar2にしたいけど、 これからの大規模プロジェクトで採用するのはつらいかもなあ。 小規模なら遠慮なくSeasar2にするんだけど。 でも上司の思うが儘にやらせてたらStrutsとかになってしまいかねんし 早いうちから口酸っぱく違うフレームワークにしよう運動しとかないと。 JSFとかは・・・うーんよく知らないので判断がつきませんわ。 139 名前：113 mailto:sage [2012/12/16(日) 01:30:49.93 ] JSFは、細かいところで身動きが取れないので止めた方がいい。 Strutsは、悪く言えばごりごり書けば、汚くなるけどいくらでも逃げ道はある。 会計系というか業務系だと、顧客のいうことを聞いて実現しようとすると、 かならずフレームワークの流儀に合わない画面制御のところとかが出てくる。 多少汚くなってもいいから、逃げ道があるフレームワークを選んだ方がよい。 140 名前：デフォルトの名無しさん mailto:sage [2012/12/16(日) 03:06:02.73 ] Struts使うなら、v2よりv1だな Seasar2もいいけど、Tomcat7あたりは大規模でも十分使えるよ 141 名前：デフォルトの名無しさん mailto:sage [2012/12/16(日) 08:58:23.46 ] 自分はSeasar2が良いと思っていて、プロジェクトをコントロールできる自信があるならSeasar2で良いんじゃ無いの？ 今後の発展に期待が出来ないだけで、悪いものな訳じゃないし。 多少の生産性より柔軟性の方が重要なのは139の言うとおりで、JSFはまず無いし、Springはありで。 142 名前：デフォルトの名無しさん mailto:sage [2012/12/16(日) 09:29:56.11 ] 「アーキは予測できないことを予測しろ」って誰かエロい人が言ってたけど、 想定外の状況が生まれた時に一番対処できる自信のあるのを選ぶのがいいかなー。 こと仕事においてはあまり冒険をしないで堅実にやれるのがいいと思う 143 名前：デフォルトの名無しさん mailto:sage [2012/12/16(日) 09:35:44.44 ] だよな。やっぱりStruts1が最高 144 名前：138です。 mailto:sage [2012/12/16(日) 11:39:49.96 ] いろいろ意見もらえてうれしいです。 >>139 JSF・・・叩かれてること自体は知ってますが、そんな使いにくいんだ。選択肢から外します。 >>142の意見は確かにその通りだなーと思います。 Struts（もちろん1）もそう考えるとうち開発者Strutsが多いんで考え方的にはありなのかなあ。 Struts2は一回検討してなんじゃこりゃとなったのでもう選択肢にはないですね。 とすると・・・ Seasar2（使いやすい） Struts1(経験者多し） Spring(使ったことはあるけど上二つほど自信ないっす、 慣れるといろいろ便利なプロダクトがあるけども・・・） この3択（今のところ上二つのどっちかにってことになるのかな）。 うちの会社で堅実な選択肢となるとやっぱり上二つのどっちかになりますね。 まだもうちょっと先の話なんでいろいろ相談しながら決めていきます。 145 名前：デフォルトの名無しさん mailto:sage [2012/12/17(月) 17:26:53.84 ] RESThub ってのを見つけた。 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 www.infoq.com/news/2012/12/spring-32 VMware's SpringSource team has released the GA version of Spring Framework 3.2 147 名前：デフォルトの名無しさん mailto:sage [2012/12/24(月) 09:08:10.96 ] Play! は選択支にはいらないですか。 148 名前：デフォルトの名無しさん mailto:sage [2012/12/24(月) 10:27:40.04 ] >>147 昔Play検討したときにDB周りに問題ありそうだったので選択肢から外したことあるけど今どうなんだろうな。 ・・・でも今の日本でPlayとかここでの評判劇悪のJavaEE6より敷居が高そうだ。 あえてPlayにする理由がないと思う。 149 名前：デフォルトの名無しさん mailto:sage [2012/12/24(月) 12:28:21.18 ] 自分の感覚だと、Play は seaser 使うなら Play（２系） の方がコード量が少なく作れるなあ、という感じ。 DB は RoR な設計を出来るシステムだと ejb とか jpa で綺麗に作れる。 複雑なSQLが必要なシステムだと、Play にする旨味はない。 と思ってます。 150 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 00:01:00.50 ] 業務系のWeb層ならApache Wicket最強だな！と思うんですが、なかなか賛同されないんですよねぇ。 最近はちょっとした社内向けWebアプリを作るのにGrailsにハマってます。 151 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 11:14:06.31 ] >>150 使ったことないんだけど、Wicketがどの辺がいいの？ 何々のフレームワークと比べてXXだからいい、と具体的な理由が聞いてみたい。 152 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 13:31:31.50 ] 他のフレームワークはコード量を減らすおまじないに終始したり、 ホットデプロイとか小さいアプリ向けに特化している。 Wicketは大きなアプリになっても長所を失わない。 Wicketで小さなアプリから大きなアプリまで堅実に作れる。 あと地味にテスト環境が秀逸。 153 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 13:38:36.55 ] Wicketの欠点はIDEにスケルトンを自動生成してもらわないと疲れるぐらい スケルトンコードにあたる定型コードが多いことだな。 HTMLから生成するツールなりプラグインなりあればいいんだが なぜ誰も作らんのやら。 154 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 13:40:44.05 ] Wicket見てるとどことなくASP.NETを思い出す 155 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 15:03:36.62 ] ASP.NETはJSFとWicketの中間っぽいような。 156 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 15:09:40.52 ] struts3どうなったんだろう 157 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 17:42:30.19 ] ASP.NETは前世代思想のSpringMVCやStrutsより勝ると思うが、 新世代系FWは学習コストが高いから、実際には苦労する。 159 名前：デフォルトの名無しさん mailto:sage [2013/01/23(水) 17:45:50.00 ] ASP.NET MVCは使ったこと無いけど、ASP.NET WebFormは、 昔のVBライクにポトペタで作れたりするので結構楽ですよ。 作法に則ったアプリ作る分にはStrutsとかより全然楽かと。 Wicketも同様(?)に、html+javaでコードが散逸しないし可読性高いのが良い。 ボタン押下時のイベントは〜みたいな書き方で作れる。 欠点も裏返しで、ボタン押下時のイベントに1000行くらいの業務処理を書いたりするような プログラマに使わせたときに手に負えなくなったりする。 160 名前：157 mailto:sage [2013/01/23(水) 18:38:58.51 ] >>158-159 レスどうもありがとうございます。 いままでJavaがほとんどで(Railsは多少経験があるが)、 そもそも web開発 だろうがデスクトップアプリ開発だろうが、.NET による開発が初めてなんだけど、 がんばってみようと思います。 JavaとC#の両方に精通している同僚が、ASP.NET MVC + Entity Framework はおもしろいよって言ってた。 ひまなときに wicket やってみるか。 161 名前：デフォルトの名無しさん mailto:sage [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 mailto:sage [2013/01/24(木) 08:00:23.06 ] >>161 レスどうもありがとうございます。とても参考になります。 今度行くかもしれないチームは、すでにWebForm ですでにつくっていて、 これから ASP.NET MVC に作り替えるって言ってました。 (自分がどこから作業するのかはわからない) >ASP.NET MVC + Entity Frameworkがいいっていう同僚の意見には同意する。 いまは喰らうどの人になってしまったが、以前、Seasarプロジェクトのshotタソも、勉強会で同じことも言っていた。 163 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 10:20:17.98 ] なぜかDBがOracleでEntityFrameworkが使えないというオチに100000ペリカ 164 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 10:29:03.20 ] >>163 Microsoftが作った、というだけでそういう誤解を受けるんだよな Entity FrameworkはMySQLでもPostgreSQLでも ORACLEでもSQLiteでも使える。 SQL Server限定のORMではない。 今はEFは、Linuxの.net(Mono)上でも動く。 しかもオープンソース entityframework.codeplex.com/ ASP.net (asp.net MVC含む)もオープンソースになっていて、Linux上で動く 165 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 10:37:28.47 ] ん？今は使えるようになったのか？ 誤解というか普通にOracleが対応してなかったはずなんだがな。MSじゃなくOracleのODP.NETが対応してない。 ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。 166 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 10:37:38.11 ] ASP.net のオープンソースのリポジトリって、 aspnetwebstack.codeplex.com/ かな。 codeplex って MS がやっているオープンソースのサイトだよね。 167 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 10:52:40.24 ] >>165 EF側ではなくORACLE側が対応してなかったって話？ ぐぐったらすぐ出てきたけど www.infoq.com/news/2012/01/oracle-ef www.oracle.com/technetwork/jp/topics/dotnet/downloads/oracleefbeta-302521-ja.html MySQLは最新のConnector/netでEF4.3対応した、とリリースされていた。 168 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 11:03:06.80 ] >>167 > ざっと調べたけど、まだEF5に対応したという記事はみかけなかったけど。 > EF5 www.infoq.com/news/2012/01/oracle-ef > support for Entity Framework 4.1 and 4.2. 169 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 13:59:36.96 ] JPAとかS2JDBCとかあるし、今更XML地獄は古いよ。 だけどアノテーションやメソッドチェインも万能じゃない。 LINQがあるだけC#の方が短くかけるだろうけど、思想面では同じようなもん。 171 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 14:26:01.47 ] 用途は限られるがslim3ならメタクラス使ってTypeSafeなORM実現できるよ （GAEのDatastoreのみ） 172 名前：デフォルトの名無しさん mailto:sage [2013/01/24(木) 19:52:13.04 ] APTで作ったメタクラスを使うのと式木では、式木の方が表現力や柔軟性はある気がする。 あと、ちょっとしたものならEFで良いかもしれないけど、用途によってはMicro-ORMとかを使うし。 そういえばサイボウズの社内システムで、Oracleの商用プロバイダを使っているとかいう話もあったね。 ttp://developer.cybozu.co.jp/tech/?p=2071 173 名前：デフォルトの名無しさん mailto:sage [2013/01/26(土) 17:24:41.22 ] JAX-RS 人気ないですねぇ。 Jersey がデファクトなのかなと思いつつ、ドキュメントのしょぼさを見るとつい RESTEasy の方が良いんじゃないかと思ってしまう・・・。 174 名前：デフォルトの名無しさん mailto:sage [2013/01/26(土) 19:41:28.01 ] 人気ないか？ 他のFWに比べれば評価は高い気がするけど。 ただ、本当の実用を考えるなら、現状の各種実装系固有の良いとこどりしたレベルのものが出ないと厳しい気がするけど。 175 名前：デフォルトの名無しさん mailto:sage [2013/01/26(土) 22:38:07.97 ] 評価は高いけど実用してる人が少ないなーという印象。 自社運用の Web サービスとかで使ってるところはあるみたいだけど、エンタープライズでは使ってるって聞いたことない。 正直表面的なところだけ見ると他の FW より断然良いなと思うんだけど、やっぱり機能面で何か不足があるんですかねぇ。 それとも経験値の問題で、わざわざ他から移るほどの価値を見出せていないだけなのかどっちなんだろう？ エンタープライズ向けの Web アプリを JAX-RS + Backbone.js とかで作るのはやっぱり危険ですかね？ 176 名前：デフォルトの名無しさん mailto:sage [2013/01/27(日) 14:14:22.26 ] JAX-RSは2.0出てからかなぁという印象、いつになるか知らんが 177 名前：デフォルトの名無しさん mailto:sage [2013/01/27(日) 15:24:47.38 ] JAX-RSってSpring MVCに比べてメリットってあるの？ 煽るわけじゃないんだけど、アノテーション使った書き方はそう違わないし、 実用度の点からは細かいところにまで手が届いているSpring MVCで良い気がするんだけど。 178 名前：デフォルトの名無しさん mailto:sage [2013/01/27(日) 18:00:33.00 ] Spring MVC って思いっきり Framework って感じで重すぎる印象があってあんまり好きじゃないなー。 まぁそれはともかく Spring MVC は REST 対応が後付け感じがあるんですがどうなんでしょう？ RESTful なサービスを作りたい場合は JAX-RS の方に優位性があるのではと思ったりするんだけど。 例えばサブリソースの表現とかは Spring MVC だとベタに書かないといけない気がする（調べたわけではないけど）。 179 名前：169 mailto:sage [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年の記事だけど。 news.mynavi.jp/special/2006/jpa/index.html Javaで使用率高いORMは、JPAとTopLink Essentialsの組み合わせかな？ 両方オラクル純正だし Web Framework(for Java)の海外トップシェアはSpring MVCみたいだ。 ソースは俺の検索結果（主に海外サイト） 180 名前：デフォルトの名無しさん mailto:sage [2013/01/27(日) 18:21:36.77 ] つ ttp://www.infoq.com/articles/springmvc_jsx-rs 181 名前：デフォルトの名無しさん mailto:sage [2013/01/27(日) 21:55:42.86 ] >>180 読んでみたけど全体的に JAX-RS の方が美しく感じる。 ・レスポンス ・Conneg ・例外ハンドリング あたりは JAX-RS の方が良いと思った。けど実用性は多分 Spring MVC なんだろうな・・・。 各 JAX-RS 実装の拡張が色々あるから実際にアプリつくるときにあまり困ることはそんなに無いと思うんだけど、やってみないと分からないなー。 でもまぁ flush スコープとか validation とかあるからやっぱり Spring MVC なのかな・・・。 182 名前：デフォルトの名無しさん mailto:sage [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 toro.2ch.net/test/read.cgi/tech/1220671877/ その昔は、Javaの各ORマッパーについての議論が活発で、 とても勉強になるスレだったのですが、ここ数年は 全然関係ないアニメのコピペが貼られるだけになってしまいました。 残念です(まぁJavaのORマッパーの話題は、一通り行き着くところまで行ってしまったのかもしれないが) 183 名前：デフォルトの名無しさん mailto:sage [2013/01/28(月) 02:41:01.19 ] >>179 もう少しだけ補足。ご存じだったらすみません。 > JavaのORM = Hibernate = XMLマッピング地獄だと思ってた。 初期のHibernateは、そのとおりXMLマッピング地獄だったけど、 Hibernate Annotations というのができて、Enittyクラスにアノテーションでカラム名とか付けられるようになった (XMLに書かなくても良くなった) さらに Hibernate EntityManager というのができて、Hibernate が JPA をサポートするようになった。 184 名前：>>20 mailto:sage [2013/01/28(月) 21:39:34.15 ] かなり古いバージョンの記事が検索の上位にかかりやすいよね。 ちなみにJPAと同じ要領でXMLをマッピングするJAXBなんてのもあるぞ。 185 名前：デフォルトの名無しさん mailto:sage [2013/01/31(木) 14:25:30.71 ] 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の脆弱性ｗｗｗｗｗ 今すぐアンインストールしろｗｗｗｗｗ engawa.2ch.net/test/read.cgi/poverty/1359787786/ 187 名前：デフォルトの名無しさん mailto:sage [2013/02/02(土) 22:30:37.53 ] 昔Jerseyを使ったときにJAXBでアノテーションつけたbeanをJSONにシリアライズして レスポンスとして返す場合に、プロパティに配列やコレクションがあるとその要素数に よってそのプロパティのシリアライズの結果がArrayになったり裸単騎の値になったりして 頭を抱えたのだけれども今は大丈夫なんだろうか。 188 名前：デフォルトの名無しさん mailto:sage [2013/02/02(土) 23:13:34.40 ] XML地獄の次はアノテーション地獄か 昔のJavaが一番作りやすかったな いまは新入社員が入ってくる余地がないな 189 名前：デフォルトの名無しさん mailto:sage [2013/02/03(日) 17:15:48.97 ] 裸単騎ｗ 190 名前：デフォルトの名無しさん mailto:sage [2013/02/06(水) 14:28:49.36 ] >>187 MessageBodyWriter使ってjsonicあたりに処理させればいいんじゃないの 191 名前：デフォルトの名無しさん mailto:sage [2013/02/07(木) 00:34:05.94 ] アノテーションが増えてソースコードがXMLみたいになるな。 言語やＦＷを変化させても冗長性と簡略化のトレードオフになるだけで 優れたものに前進しないな。 192 名前：デフォルトの名無しさん mailto:sage [2013/02/07(木) 13:38:09.81 ] そこで設定より規約ですよ 193 名前：デフォルトの名無しさん mailto:sage [2013/02/07(木) 13:43:15.61 ] rubyやphpのほうが作りやすいということ Javaは方向性間違ったな 194 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/02/07(木) 20:26:49.56 ] 「規約と完全一致ならBeanクラス自体がなくてもいい。」 アノテーションプロセッサでここまでできればRailsに勝てるだろう。 IDEにスケルトンプログラムのジェネレータプラグイン入れて クラスファイルの山を作ってるのが現状。 今度はコンパイルが重くて仕方ないか。 197 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 01:48:59.44 ] Rails(というかActiveRecord)の便利なところは、 モデルクラスにメソッドを定義してなくても、呼び出し側が適当なメソッド名を 呼んでしまえば、Method Missing により、規約に沿って自動的に解釈されてSQLを実行してくれるところだと思う。 コンパイル言語でのJavaでは、これは絶対に無理。 S2Daoなど、Interfaceだけ定義すれば proxy オブジェクトを作ってくれるフレームワークはいくつかあるけど、 かならず Interface にメソッドだけは定義しないと行けないし。 198 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 02:18:23.89 ] 本当に無理なんかなあ。Javaって回り道ばかりしてるじゃん 生活費1000万くれて1年それだけに集中していいって言われたら 開発者みんなが楽できる最強のフレームワーク作れる自信あるわ 199 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 05:10:55.98 ] 最強のフレームワークなら１０００万円以上で売れるんじゃね？ 200 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 07:11:01.57 ] Beans無しでしかも型安全なフレームワークが実現可能ならまだ存在意義もあるだろうけれども Beans無しというだけでは全く流行らないだろうね。 201 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 14:27:57.43 ] >>198 コンセプトだけプレゼンしてみ？ よさげならうちの職場に紹介するよ 1年1千万なら余裕で出せるはず 202 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 15:22:57.86 ] Beans無しがそんなに嬉しいかねぇ。 203 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 16:00:08.22 ] >>200 >>202 Beansってなんのこと？ Entityクラスを作るってこと？ (SpringMVCにおける、Form の Modelクラスでもいいけど) 204 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 16:19:47.38 ] そういうことじゃね? 厳密にはEntityクラスは作るにしても、ActiveRecordだけ継承すればあとはフィールドや アクセサの類を定義しない空のクラスのままでもよろしく動くということだと思う。 205 名前：198です。 [2013/02/08(金) 21:19:31.37 ] star-123@yahoo.co.jp メール下さい。 206 名前：198 mailto:sage [2013/02/08(金) 23:00:45.38 ] 早くメール下さい。 207 名前：デフォルトの名無しさん mailto:sage [2013/02/08(金) 23:38:25.89 ] １０００万の仕事を捨てメアドで募集してるときいて 208 名前：196 mailto:sage [2013/02/09(土) 01:13:47.47 ] アノテーションプロセッサができるのはコンパイル時クラスの自動生成だよ。 Javassistとかは実行時生成だからインターフェースとか必要になるけど、 アノテーションプロセッサだとソース上では全く定義されていないクラスを new HelloBean();とかしても型安全に操作できる。 今のアノテーションプロセッサでＦＷはかなり作りづらいし、見向きもされていない。 209 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 02:08:32.22 ] >>208 型安全… だと？ HelloBeanじゃなくHalloBeanと書いた場合にどうやって間違いを見つけるんだ？w 210 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 03:06:41.17 ] コンパイル時にターゲットのDBに接続してスキーマ引っ張ってくる必要があるな。 211 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 03:13:38.12 ] アノテーションプロセッサを使うというのは、(webフレームワークではなくORMだけど)Domaも似たようなものかな。 Interfaceクラスだけつくって、アノテーションプロセッサを一度実行しないといけないけど、Entityクラスが自動生成されるのはいいかも。 でも、それって Excel などでつくったプロジェクト内自動生成ツールを事前に実行するのと、手間的には変わらない気もする。 212 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 03:23:31.64 ] DBから生成できるEntityのプロパティはアノテーションプロセッサで作る必要ないな >>197が言ってるのはSQL生成するメソッドだから、O/Rマッピングパターンだと 存在しないDAOを呼び出すとアノテーションプロセッサが作ってくれるイメージだろ 213 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 09:38:16.20 ] 自動生成してくれるのは結構なんだがきっちりドメインオブジェクトを書き起こさずに メソッドの自動生成に任せていて開発規模的にどの程度スケールするのかは気になる。 214 名前：196 mailto:sage [2013/02/09(土) 12:41:01.52 ] railsみたいにcocでもりもり削ろうぜって話だったはず 215 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 16:45:23.43 ] マイグレーションや関連、検証を書き始めるとあまり変わらん気もする。 JPA等を使うにしても結局面倒なのはそこで、Beansの定義自体は機械的作業でIDE使えば 面倒でも何でもないし、むしろBeansが無かったり動的生成されるほうが静的検証もやり にくいしむしろ色々面倒臭い。 216 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 17:55:05.13 ] Eclipseが標準でSQLJを手厚くサポートしていればいろいろ違ったかもな 217 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 22:10:06.33 ] ORMの話だしSQLJ等の埋め込みクエリはあまり関係ないかなぁ。でもJPQLは好き。 ORMを使っていても集約計算などするときは変にエンティティオブジェクトや フレームワークが提供する無駄に独自性溢れるクエリーAPIと格闘するよりSQL一本 書いた方が速いよね、という場面はそこそこあるし、そういった場合にはJPQLは DBMSの方言を気にせずハードコード出来てかつどんなSQLが吐かれるか大体見当が つくので個人的には時々便利に使う。 218 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 22:37:44.53 ] ORMったってマッピングの部分はほぼ完成していて問題にならない。 問題なのは相変わらずクエリを作るところだろ。 JPQLもクライテリアAPIもそこじゃん。 そこの標準が早期(JDK1.1)からあったんだからIDEがしっかりサポートしていれば もっといろいろな発展があったと思うね。 OracleのSQL Developer使ったことあればわかるだろうけど、エディタ上でSQL書くと その場で文法に加えて名前や型までチェックされて、即実行して結果も見える。 あれがJavaとシームレスにつながって関係するDAOやJavaBeansが自動生成されれば 相当便利なものになったんじゃないか。少なくとも、その基礎にはなり得たんじゃないか。 219 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 23:14:58.74 ] っていうか、こういう話を↓のスレで続けたかったな。 最初の頃はとても勉強になるスレだったのに、いまは変なアニメの人が居着いちゃってとても残念。 Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5 toro.2ch.net/test/read.cgi/tech/1220671877/ 221 名前：デフォルトの名無しさん mailto:sage [2013/02/09(土) 23:26:28.54 ] そのスレまだ蹂躙されてたのかw 222 名前：デフォルトの名無しさん mailto:sage [2013/02/11(月) 17:04:04.35 ] アニメの話はアニメ板でやった方が 反応もあって楽しいだろうに何であそこなんだろうな。 223 名前：デフォルトの名無しさん mailto:sage [2013/03/02(土) 14:27:18.78 ] アニメ好きのJavaでDB開発担当してたやつが 仕事で下手こいてクビになったとか、メンタル壊して鬱病ヒキコモリに なってしまったとか、哀れな末路に驀進中なんじゃね？ 別スレ立ててもいいかもね。 そういえば、そのスレの１スレ目立てたの俺だった。。 最近、鯖側でスクリプト環境使うことが増えてきて、今までは スクリプトは遅いとかバカにしてたけど、即時修正とか 運用のしやすさとかを感じて見直している。 Javaにもこういう扱いやすさが欲しいな。。。 ホットデプロイ使えばいいのか。 224 名前：デフォルトの名無しさん mailto:sage [2013/03/02(土) 18:21:24.23 ] >>223 おお、あなたが Java⇔RDBのMapping-Frameworkを語るｽﾚ vol.1 スレを立てたのか。 乙です。 > 最近、鯖側でスクリプト環境使うことが増えてきて、今までは > スクリプトは遅いとかバカにしてたけど、即時修正とか > 運用のしやすさとかを感じて見直している。 今は何を使っているの? JavaじゃなくてRailsとかPHPとか? 225 名前：デフォルトの名無しさん mailto:sage [2013/03/02(土) 18:50:32.40 ] ポール・グレハム 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 名前：デフォルトの名無しさん mailto:sage [2013/03/04(月) 19:46:02.90 ] Eclipse統合M34【Java/C++/Ruby/Python/Scala】 toro.2ch.net/test/read.cgi/tech/1361510049/103-106n ↑のスレに質問したところ、こちらのスレが適切ということで、 こちらで質問させて頂きたいです どなたかよろしくお願い致します 227 名前：デフォルトの名無しさん mailto:sage [2013/03/04(月) 22:52:15.49 ] Javaの入門書を卒業して、サーブレット、JSP、jdbcでのDB操作もできるようになりました。 Webフレームワークを使って、勉強用に簡素なショッピングサイトでも作ってみようかと思ってるのですが、 いま、初めてやるとしたら、どのフレームワークを使うのがいいでしょうか。 228 名前：デフォルトの名無しさん mailto:sage [2013/03/04(月) 23:58:37.09 ] play framework 2.1 がいいと思う 229 名前：デフォルトの名無しさん mailto:sage [2013/03/05(火) 04:23:08.94 ] Grails 230 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 20:31:46.32 ] フレームワークなんかなくても、 サーブレットとJSPで作るのが一番正解だよ 231 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 20:49:59.21 ] 一番迷惑。 規模が大きくなると結局オレオレフレームワークの類を作り始めるので、そうなる前に ちゃんとしたフレームワークを使って欲しい。 232 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 21:15:41.74 ] >>231 ちゃんとしたフレームワークないじゃん ちょっと特殊なことしようとするとクソハマり だから>>230が正解 もしくはJavaを捨てる 233 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 21:27:58.57 ] >>232 とくしゅなことってどんなw 234 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 21:35:06.25 ] それは本当に特殊なのか？ 本当に特殊だとして、それは本当に必要なのか？ 本当に必要だとして、それは本当に特殊なことをしないと実現できないのか？ 235 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 21:43:27.90 ] ハマる回数が多すぎていちいち覚えてないよ フレームワークのサンプルまんまで業務が回るならいいけどそうじゃないだろ 236 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 21:47:18.97 ] 世の中にあるフレームワークは全てオレオレだからな。 いくつかのシステムと他の言語も経験すれば、「ぼくのかんがえたさいきょうのフレームワーク」を作る能力もつく。 結局それが一番正解に近いのさ。 車輪の再発明こそがプログラマーの醍醐味。 もちろん今あるフレームワークの長所短所も研究するべきだけどね。 237 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:09:52.61 ] >>229 デモ見るとGrailsはかんたんに扱えそうな感じだね grails.org/learn JavaじゃなくてGroovyになってるから性能が心配なところだけど 実行前にはすべてJavaのバイトコードに事前コンパイルされるのかな？ >>230 ゴリゴリJSPでやるのは生産性が悪いと思う >>232 例えば今まで何のフレームワークを試したの？ 238 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:24:12.80 ] 単にフレームワークを使うだけの力もなかったんだろ 239 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:29:33.88 ] サンプルからちょっと外れるとクソハマリなんてフレームワークの流儀や コンセプトを知らずに使ってる証 240 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:53:35.30 ] フレームワークってその流儀やコンセプトの押し付けがましいのが嫌。 241 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 22:57:37.87 ] >>238 力がないと使えないならいらない servletやjspなら力なんて一切必要ないぞ 242 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:21:15.89 ] ３次元配列が扱えるフレームワーク無いもんなー 使えないよな 243 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:28:15.29 ] >>241 効率よく作るにはむしろ相当な力が必要じゃね？ それこそ小さな画面一つ作って終わりじゃないだろ 244 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:31:37.49 ] >>243 そりゃライブラリの類はたくさん必要だよ でも外から自由を奪いにくるフレームワークは不要 245 名前：デフォルトの名無しさん mailto:sage [2013/03/06(水) 23:32:09.71 ] 力ないやつが生servlet/jspで作ったらメンテ不可能なものしかできなそう 246 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:25:47.22 ] >>244 規模が大きくなってくるとそのうちそのライブラリの中にフレームワークが入ってくるんじゃないのかw 247 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:32:52.10 ] >>246 入らないよ。ライブラリは実装から呼び出される側、 フレームワークは実装を呼び出す側、役割が全然違う 248 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 00:42:19.97 ] 匿名で使えるgistでもあればそのライブラリ使ったコード貼ってみろよで終わりなんだけどな お互い相手を下に見てるどうしが1、2行の文章だけでやりあっても不毛 249 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 06:14:07.70 ] >>236 誰も「さいきょうフレームワーク」の醍醐味なんか求めていない。趣味かよ。 オレオレにせよ商用にせよOSSにせよ、今すぐに使えてどれだけ継続的にアップデートが 続くかが問題。 どこかの天才が気まぐれで作ったさいきょうフレームワークよりも沢山のユーザに使われて ある程度の期間バグを叩かれまくっているそこそこのフレームワークを使うね自分は。 250 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 08:43:31.29 ] 画面が多いだけの大規模システム（いわゆる業務系）なら フレームワークも有効だろうねぇ 251 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 15:56:03.63 ] 「画面が多いだけ」ってよくわからん。 画面が多い「から」、フロントエンドの規模が大きいからウェブアプリのフレームワークを 使うのであって、その後ろに画面の多さ以外の何があろうが別問題だと思うのだが。 上から下まで全部一つのフレームワークで作ることしか頭にないのか。 252 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:10:25.88 ] でもおまいらの言ってるのは何が何でもフレームワークなんだろ？ とにかくまずフレームワークを使うことが第一であとは どうでもいいって感じ。 253 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:20:28.86 ] じゃなくて、Java使ってWAF使って開発すると決めた後の話題が主なのがこのスレ 違う決断した後の話は別スレでする 254 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:24:17.70 ] JavaとWAF使うってことは型にはめやすい、型にはめるメリットがある(似た画面多い、人が多い)案件って事 そうじゃないこともあるが、それをここで話す意味がわからない 255 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 16:36:01.22 ] >>254の「そうじゃないこと」は「そうじゃない案件」です 256 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:23:53.38 ] >>256 Grailsって、ORMはHibernateを同梱しているんだよね？ Hibernateあまり使いたくないんだよなぁ。 MyBatisなどに差し替えられないの？ 258 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:36:40.23 ] >>257 Mを構成するGORMというORマッパーはJPAどころかがっつりHibernateに依存しているので 無理っぽい。WAR等からHibernateだけ切り離すのも無理じゃないのかな。 ただ別のORMで書かれたMをVCから叩くのは普通に出来ると思う。たぶん。 259 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:39:36.67 ] >>256 ありがとう。 CoCが魅力的だったけど、速度も重視したいからSpring MVCも見てみる。 GrailsはJavaでも書けるようになってほしいな 260 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:46:34.27 ] やっぱり不自由が発生してるじゃん Aだけを使いたいのに使いたくないBまで使わなきゃいけないとかw 技術力が普通にあるのなら使う必要ないんだよ 261 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 18:57:29.88 ] >>260 ORMは好きなの使えるっていうフレームワークもある。 JPA使えるやつなら大半の人は文句ないんじゃないの JPAデファクトスタンダードだろうし 262 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:04:53.41 ] JPAｗ 263 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:05:31.48 ] デファクトｗｗ 264 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 19:16:01.10 ] なに草はやしてるんだ？ JPAはJavaでは一番メジャーなORMだろう 265 名前：デフォルトの名無しさん mailto:sage [2013/03/07(木) 22:06:26.45 ] >>260 フレームワークの実装が特定のライブラリにがっつり依存しているか交換可能なように 設計されているかの違いだろうなぁ。 そしてそれはフレームワークの開発の速さや使い勝手とのトレードオフでもある。 GrailsはHibernate似のcriteriaも提供していたりとHibernate以外に交換するのは しんどそう。 266 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 02:05:35.35 ] >>260 「やっぱり」って、不自由が発生するのを否定してるやついたか？ 制約する・型にはめることによるメリットが不自由というデメリットより大きいってだけだろ 267 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 02:16:55.15 ] 「特殊なこと」ってのが曖昧だから話にならんのだよな ビューに関してはJSP使ってるフレームワークだったら不自由もないだろ コントローラにしたって所詮HTTPの範疇じゃたいして特殊なことなんかできんだろ？ 268 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 07:21:32.53 ] listの中にlistが入ってて、さらにlistが入ってるような データが受け渡しできないから糞 そんなフレームワークばっかり。フレームワーク作ってる奴は 単純なサンプル画面しか作ったことないやつばっかり。 269 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 07:45:04.59 ] >>268 どのフレームワークのことを言っているのか皆目不明なのでざっくりMVCを使って尋ねるけど、 「受け渡しが出来ない」ってM・V・Cのどれからどれの間で受け渡しが出来なかったのさ。 フレームワークが使えない理由としてなにか高尚なものが来るかと思いきや、いきなり脱力な 例が飛び出してぐんにゃりですよ。 270 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 08:05:17.79 ] どこで受け渡しできないかも知らない程度の知識なんだとわかった 271 名前： 忍法帖【Lv=40,xxxPT】(2+0：5) mailto:sage [2013/03/08(金) 08:14:16.37 ] >>268 批判するならどのフレームワークを使ったかくらい書くべきだね すべてのフレームワークが同じわけではない 272 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 09:52:29.11 ] 仕事以外の時間もプログラム板に来るような勤勉でスキルも高いであろうおまえらは 不便なフレームワークでハマる必要ないんだよ 流行りに流されてるのに気づいたほうがいい チームに新人やスキルが低い人間がたくさんいてそいつらに大部分を任せないといけないから スパゲッティを避けるため仕方なく使ってるという話ならわかるけど 273 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 11:04:32.79 ] そこでPlay! Frameworkですよ Play! は Scala が話題になっているが、Javaでもかける。 274 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 11:58:37.45 ] wicketってのがXML書かなくていいらしいんだけど、うらやましい。 275 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 15:19:03.90 ] Playは独自感が半端なく強かったり、1.0=>2.0を見る限り不安定感が否めない。 wicketは素直な設計だし、1.5=>1.6を見る限り安定していて実用的な時期に思える。 用途に合わせて様々なフレームワークを使うぐらいなら、 wicketみたいな大規模向けフレームワークをベースに、 小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？ 276 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 15:57:00.15 ] フレームワークいらんという人はORMやDIは使うのかな。 今時手組のSQLに生のJDBCとか勘弁。 277 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:06:37.78 ] ORMなんか使わないよ。パフォーマンス悪いし。 278 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:12:45.10 ] >>276 ibatisはたまに使う。 一番いらないと思うのはDIかな。 newぐらい自分でしたい。 279 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:24:05.63 ] とはいえweb.xmlにサーブレット登録した時点でサーブレットクラスのnewに関しては既に サーブレットコンテナに委譲しているわけだからなぁ。 その先、各サーブレットクラスが必要とする依存性を自前でnewするかこれも委譲するかで 自前ファクトリをゴリゴリ書くかapplicationContext.xmlを書くかの違いが出てくる。 インスタンス生成の委譲の程度問題だと思うんだよね。個人的にはサーブレット使うことと DIを使うことの間にはあまり断絶はない。 280 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:33:16.09 ] とくにWebアプリでORMとかアホかと思う。 Webアプリなんてサーバー集中型なのになるべく負荷を減らさないでどうする。 ORMはクラサバアプリ向けだろ。少しは考えて欲しい。 281 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:55:04.22 ] DB知らない素人が手組みしたDBスキーマとクエリ。 DB知らない素人が定義したORマッピングとそれから自動生成されたDBスキーマ。 どちらを使えと問われれば自分は絶対に後者を使う。前者は墓穴の宝庫だが後者は 一応それなりに定石を外さないスキーマやクエリを吐く。 DBの素養のある人が手組みしたDBスキーマとクエリ。 DBの素養ある人が定義したORマッピングとDBスキーマ。 どちらを使えと問われれば、まあ使い勝手次第であって基本的にはどちらでも良い。 結局スキーマもマッパーが吐くクエリも手組と大差無いものに大抵は落ち着くから。 ただし成果物のAPIレベルでの使い勝手は当然ORMを使った方が初めから機能豊富。 結局DB理解している人間が担当しているか否かが重要なのであって、その上の上物 はプロジェクト毎に好きに決めれば良い。ただし手組みさせるとそのDB理解している 人間の手作業がバカにならん。許させる範囲でORMで楽させてあげても。 282 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 16:58:19.38 ] そうやって、もっさりアプリ量産してくれ。 俺の超サクサクアプリが高評価なのはおまいらのおかげだ。 283 名前：デフォルトの名無しさん [2013/03/08(金) 17:56:34.47 ] どうやらただの釣りだったようだな 284 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 19:25:26.20 ] ORMの必要性はわかるけど後でJDBCに差し替えにくい Hibernateとかはバッドノウハウだなと思ったり。 285 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 19:39:04.75 ] 最近のHibernateはJPA準拠してるんでしょ JPAならそのままSQLも扱えるとおもうけど 286 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 20:00:01.24 ] ORMから外れたことをするにしても外れ具合の程度によってJPQLから生SQLまで それなりに逃げ口は用意されているよね。 普通にORMを使って、困ったときにピンポイントでそういう逃げを利用するだけでも 大概のシナリオはカバーできると思う。 287 名前：デフォルトの名無しさん [2013/03/08(金) 21:11:52.51 ] ORMを使うなら範囲検索にJPQL使うのは避けられないだろ。 プロトタイプだとしても主キーと全検索だけで作るわけにはいくまい。 288 名前：デフォルトの名無しさん mailto:sage [2013/03/08(金) 21:29:37.43 ] その辺りはクライテリアとかフレームワークごとのDSLとか。 でもJPQLは良いものだ。サクッと使うのにちょうど良い。 289 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:00:06.57 ] >>281 DB知らない素人の件は俺なら前者かな。 ORMを理解してないやつが定義したものに ORM適用するとか足かせにしかならん。 もちろんベストはそれなりにわかってるやつにDB定義をさせることだが 知らないやつが定義した場合は昔ながらのSQLで対応する他ないと思う。 290 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:03:09.87 ] >>282 俺もフレームワークとかDIとかORMとか否定派なので主張には賛成なのだけど スマホアプリでもないただのWebアプリで 評価が高いとか低いとかどうやってわかるの？ 291 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:29:45.60 ] DIを使うのって、短期的に楽をしたりするためより、変更に耐えやすいように作るためだと思うけど・・・・ (これも、スパゲッティなコードをメンテするより、長期的に楽になる) Springスレだったかにも書いたけど、最初は Dao の実装を1つしか作らなかったけど (Implが１つしかないのに、わざわざインターフェースを作っていた)、 途中で、一部のテーブルだけKVSに移行したので、MyBatisImplから別のDaoImplを作って移行した。 このとき、Daoのメソッドのインターフェースを変えないようにできたので、 修正はapplicationContext.xml だけ。コントローラやサービスクラスは変更無しで済んだ。 あとUT時は、サービスクラスにDaoをDIするときにモックにするとか。 こういうことを経験すると、よほど小さかったり使い捨て以外では、DIを使った方がいいと思っている。 DIをつかうための面倒なコストは、2回ぐらい変更があったら、回収できていると思う。 292 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 01:49:16.30 ] JavaEEが複雑すぎたために、DIが生まれたという解説をある本で読んだ。 293 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 03:27:23.17 ] >>291 レイヤごとにインターフェイス統一するのは それなりのエンジニアなら誰でもやるし そのケースでDIコンテナを使う必然性は感じられないが… 294 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 06:22:09.43 ] こまめにインターフェイスを定義することとDIコンテナを使うことは別に考えるべきだと思う。 インターフェイスを定義して抽象度を上げると実装の差し替えなど融通が効くのは別にDIを 使わずとも得られる恩恵だし、DIコンテナを使うにしても別にインターフェイスの定義は 必須ではない。注入される口の型が実クラス名で決め打ちでもDIコンテナは使える。 それならDIコンテナの利点は一体なにかというと、う〜ん、DIコンテナを使っているフレーム ワークを使うときは自分もDIコンテナを使った方が楽という点が正直一番でかいかなw 例えばSpringを使ったフレームワークを使うときは基本的にコンポーネントもDI前提で開発 するのが殆ど作法になっている。コンポーネントはDIコンテナのコンテキストに登録すること でアプリ上にデプロイするという手順が大抵のフレームワークでほぼ共通なので、DI使えば どのフレームワークでも簡単に似た手順でデプロイ出来るのに対して他の方法だと途端に 苦労することになる。 295 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 06:38:14.57 ] DIコンテナの作者が後年DIコンテナはいらないと言ってた件 296 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 10:57:51.80 ] 当人がいらんと思ってても他の人が必要なら別にいいんじゃないの 297 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 11:04:21.79 ] >>296 いらないと思ってるやつが いると思ってるリーダーの下についたときは悲惨だぞ←俺の今の状況 だからもっといらない流れができてほしいわ 298 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 11:13:19.54 ] >>295 ひがやすお？ 299 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 12:11:10.88 ] >>298 YES テストがしやすければDIコンテナは必要ないってSlim3の時に 300 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 15:35:31.76 ] DIの目的はテストじゃないと思うけどな。 301 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 15:50:02.45 ] ソースコード資産を別のフレームワークにそのまま移行する例って実は少ないだろ 302 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:34:51.64 ] wicket は Play! と同じくらい独自色がある気がする。 Play! で Java の時は、 DB のテーブル定義は ebean で、sql は 生 sql がいい気がする。 303 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:39:17.86 ] iBATISがやはり最強だな。 今まで使わないで来て今じゃMyBatisになってるようだがやはり最強。 304 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:42:53.41 ] HibernateやJPA実装の類がダメな理由はなんだろう? 305 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 16:54:23.60 ] RDBMSとの対応を把握する必要があるなら 最初からSQLに書けばいいじゃない。 306 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 17:07:23.68 ] Entityオブジェクトのクラスが決まっているのならそちらに必要最小限の マッピング情報を書き足せば良いじゃない。 変なスキーマ相手だと苦労するけどJPA。 307 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:17:55.52 ] >>301 少ないっていうかほとんどない 著作権が客に移るからそのまま再利用できないし 308 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:45:15.19 ] >>300 DIの目的はオブジェクト(コンポーネント)を疎結合にすること、 DIコンテナによってそれが交換しやすくなる、 それが最大のメリットになるのが単体テスト。 だが単体テスト以外じゃ交換性は実は必要ない、 だったらテストがしやすけりゃDIコンテナはいらん、と読んだ。 309 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 18:52:55.16 ] 「DBスキーマが何も無い状態から」素直なスキーマを使う小規模Webアプリをサクッと開発する のであればMyBatisでも生JDBCでもなくJPA系が一番楽だと思う。要するにアノテーションからの スキーマの自動生成で事足りる範囲であればこれが一番コード量が少ない。 開発序盤はデフォルトのマッピングでORMにどんどん生成させて、ある程度エンティティクラスが 出そろったり怪しげなスキーマ吐くようになった時点で一旦止めてマッピングに手を入れる。 そっから先の苦労は、結局扱うドメインモデルの複雑さそのものなのでどのフレームワーク使っても あまり大差はないようにも思う。 310 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 19:08:28.23 ] >>304 JPA1.0の頃だが、一覧とかエンティティ以外の形で取るのが絶望的にダメだったところ 今はどうよ？ 311 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 20:42:00.68 ] >>310 1.0にも、それ以前のHibernateにも、一覧結果をEntity以外の形（普通のBeanやMap）で取得する方法はあったぞ JPQL使う必要があったけど どうしてもSQLで書かなければいけない場合でも、HibernateネイティヴのAPI使えば普通にEntity以外の形で取れていたし その手法を実際に適用して開発したこともある 312 名前：デフォルトの名無しさん mailto:sage [2013/03/09(土) 20:56:08.16 ] >>311 HibernateにResultTransformerがあるのは知ってるが、それは標準じゃない JPA標準でできるのは、 ・JPQLでnew Xxx(a, b, c, ...) ・SQLで@SqlResultSetMapping(columns={@ColumnResult(name="a")}, ...}) しか知らん 前者はJPQLってところが×。関連のマッピングがないと結合もできない。Mapが使えないのも× 後者は面倒なので×。結果がObject[]なのも× 間違ってたりJPA2.0で改善されてるところがあれば教えて欲しい 313 名前：デフォルトの名無しさん mailto:sage [2013/03/10(日) 21:32:05.66 ] ほんのちょっと前にJPA推しレスしてるやつ数人いるのに、 具体的な話になったらレス付かないとかwww 314 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:11:59.19 ] 軽く調べた ・JPA2.0のJPQLではFUNC("関数名",...)でネイティブSQLの関数が使えるようになった JPQLに無い関数も使えるのでカバーできる範囲が広がるが、 RDBに依存するならわざわざJPQL使わねーだろw ・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw これ誰も使ってねーだろw ・EclipseLinkは@QueryHint(name=QueryHints.RESULT_TYPE, value=ResultType.Map)でObject[]の代わりにMapになる 結局非標準w 集計的な一覧が多い日本の業務系では使い物にならんぞJPA 315 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:24:30.49 ] >>311 >>314 「一覧」という言葉を多用してるけど何のこと？ 多数のテーブルをJOINするようなクエリを意味してる？ 一覧とは何を指しているのかわからなかったからレスのつけようがなかった。 業務系では使えないという主張もよくわからない JPAに限らず、ORMはマッピングさえ終えてしまえば使えるでしょう 316 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:52:26.07 ] JPAが良いって言っている人達は、どんな用途にでもJPA最高って主張しているのか？ JPAで簡単に出来る範囲のことをやる分には、JPA最高っていう主張なのかと思っていたけど。 317 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 21:56:14.85 ] >>315 >>310に書いただろ、「エンティティ以外の形で取る」って >>311には伝わってたぞ 例えばMAXとかAVGとか集計関数使って部署別、期間別などの一覧を出すケース 当然、SELECT句の並びは元になったテーブル(エンティティ)とはまるで異なる 単純だがSELECT COUNT(*), AVG(a), MAX(a), MIN(a), AVG(b), MAX(b), MIN(b), ... が必要な時、JPAではどうする？(その答えが>>312と>>314だ) >>316 じゃあJPAで簡単にできる範囲を示さないとな。どんだけ狭いか見物だわ 318 名前：デフォルトの名無しさん mailto:sage [2013/03/11(月) 22:13:39.98 ] >>316 >>286は「それなりに逃げ口は用意されている」から「大概のシナリオはカバーできる」 と主張してるな。「大概のシナリオ」だ、意味はわかるよな？ 319 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 00:11:12.75 ] >>314 > ・HibernateのJPQLで複数引数のnew Xxx(a, b, c,...)は去年の夏(4.1.5)まで使えなかったw いやそれは無いはず。JPA1.0の時代にHibernate実装でそれを使っていたから JPAを使ったことのある身から言うと、SQLの直接記述が要件として必須なら、標準には拘らない方がいいと思う また、JPQLをまったく使う気が無いのなら最初から止めておいた方がいい JPA標準のNativeQuery関連は本当に使い物にならないし、SQL記述がほとんどならMyBatisで十分だろう 今はJavaの仕事していないので、最近のことについてはわからない 320 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 00:29:13.67 ] JPA とか吐き出されるSQLが微妙なときがあるから、変なSQL吐いてたら普通のSQLにするとか、速度的に気にしなくて良いならJPAで通すとか。各DBの方言を吸収してくれるのは便利だと思う。 321 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 01:55:03.35 ] hibernateから10年以上経ってて いまだにこんなややこしい議論が必要なら もうSQL書いたほうが早いってことだろ 322 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 09:13:52.20 ] でもこの差は何なんだろうね。 www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&geo=JP&date=today%2012-m&cmpt=q www.google.co.jp/trends/explore#q=Hibernate%2C%20MyBatis%2C%20JDBC&date=today%2012-m&cmpt=q 日本ではHibernateを使いにくい特殊事情でもあるのかな。 こんなのも。 www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&geo=JP&date=today%2012-m&cmpt=q www.google.co.jp/trends/explore#q=Maven%20Java%2C%20Ant%20Java&date=today%2012-m&cmpt=q 323 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 09:42:51.79 ] 俺の考えを述べさせてもらうと O/Rマッピングだけでも生SQLと速度差がほとんどなくなるか そもそもオブジェクトをそのまま扱えるDBが一般的になるまで 生SQLのほうがいいと思う。 324 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 21:47:36.02 ] >>319 Hibernate3.6以降の話かな https://hibernate.onjira.com/browse/HHH-6304 SSHから使ってた連中は別として、今JPA使うとしたらGlassFish(EclipseLink)が多いだろ 「Hibernateならできるし(震え声)」じゃダメなんだよ あえて標準技術を選ぶ意味がない 俺はJPA(JavaEE)への移行を却下したんで「止めておいた方がいい 」のは最初からわかってる そんなのよりJPA推し連中からのポジティブな反論を期待してたんだがな 325 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 23:22:04.17 ] 余談だけど、JPAと言いつつHibernate前提の話をしたり、JAX-RSと言いつつ特定実装系前提の話をするJava EE推称派は、そこんとこキッチリしてくれ。 326 名前：デフォルトの名無しさん mailto:sage [2013/03/12(火) 23:34:07.08 ] MyBatis触ってみたがこれで十分だわ EJBに組み込む方法も割と簡単だし 327 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 00:27:43.05 ] >>325 標準ですむ範囲の要件であれば標準ですませた方がよい、それだけの話では？ 328 名前：デフォルトの名無しさん [2013/03/13(水) 01:04:42.17 ] >>327 文盲乙 329 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 01:10:39.93 ] hibernateって昔、1000件DELETEするときに 1000回DELETE文が走るとかでこれは使えないと断念したことがあるのだけど いまのhibernateとかJPAとやらはそのへんは改良されてるの？ 330 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 01:13:34.55 ] 横断的な処理をする場合はJPQLを使って処理するんだろ JPAはSELECTがJava側から見て綺麗になるくらいで後は方言吸収くらいが利点か 331 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 11:42:57.54 ] Linuxサーバーって一回設定したら以後放置だよね。Windows Update + Windows Serverの方がよいよね engawa.2ch.net/test/read.cgi/poverty/1363142026/ 332 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 15:53:58.68 ] >>329 調査不足つか調査力不足 Hibernate2.xの頃ですらできてた 333 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 16:53:32.09 ] >>332 昔って書いたのに何でそういう否定の仕方するんかね。 俺が見たのは2003年ごろだよ。バージョンは忘れた。 334 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 17:18:16.36 ] 別に1000回DELETEすることは問題じゃないと思う。 それが1回のSQLでDELETEするのと同じ速度なら。 でもまだそういう時代じゃないからO/Rマッピングは悪だと思う。 335 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:07:27.21 ] >>333 事実だから 2002年1月リリースの0.9.2からできてたことに気づけず断念とか調査力不足だろ 336 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:34:57.15 ] >>335 まさかHQLのことじゃないよね？ 337 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 18:50:25.71 ] すり替えｷﾀwww 少なくとも10年選手なんだろ？情けねぇ・・・ 「hibernateって昔、1000件DELETEするときに」 「hibernateって昔、1000件DELETEするときに」 「hibernateって昔、1000件DELETEするときに」 どう見てもHQL使うべき場面です 338 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:00:25.43 ] できるできるってHQLのことかよ HQL書かないといかんのなら使わんよそんなもん 隠蔽されて実行されるSQLを最適化してくれるよう 進化してるかが質問の意図だったんだが 339 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:09:20.82 ] >>338 だよな それをわかってないんだよ ここの奴らは 340 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:11:33.54 ] は？その意図が「1000件DELETEするときに」で伝わると思ってんの？ 少なくとも10年選手なんだろ？大丈夫かお前 ついでに言っておくと、2002年の1.1からバッチ更新使うから 「1000回DELETE文が走る」も成立しない だいたいHQL書かないならDELETE関係なくHibernate使えないじゃねーか 1000件フェッチしてくるのだって大概HQL書くだろ idとナビゲーションだけでやるつもり？アフォですか 「10年前は未熟でした」で終わらせておけばいいものを「今も」バカだって晒してどうする 341 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:14:31.73 ] ファビョるなw 342 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:16:26.44 ] 一応書いておくが、俺(340他)はHibernate使えるとは思ってない ↓がバカだと思っただけだ > 1000件DELETEするときに > 1000回DELETE文が走るとかでこれは使えないと断念 343 名前：デフォルトの名無しさん mailto:sage [2013/03/13(水) 19:16:53.38 ] そもそもオブジェクトを操作するだけでSQLと遜色ない速度で 動いてくれないと意味ないんだよ。 344 名前：デフォルトの名無しさん mailto:sage [2013/03/15(金) 01:16:45.46 ] 亀レス＆スレチですまん。 >>224 いまだにメインはJavaなんだけど、node.jsを使い始めてる。 フロント側をJavaScript+jQueryでやることが多くなって サーバ側も同じ言語が使えるのは良い感じ。 ただ、JSはタイプセーフじゃないから、巨大なシステムにはまだ不安。 345 名前：デフォルトの名無しさん mailto:sage [2013/03/15(金) 14:12:49.96 ] タイプセーフは重要 346 名前：デフォルトの名無しさん mailto:sage [2013/03/16(土) 00:31:32.17 ] >>344-345 同じ言語を使えるってのは楽でいいね 言語の問題は置いておいて、node用のフレームワークの出来はどう？ expressだっけ？ TypeScript使えばJSも部分的にTypeSafeになるんじゃない？ 347 名前：デフォルトの名無しさん mailto:sage [2013/03/16(土) 00:47:09.87 ] Expressが必要なところでNode.jsを使ったら負けだと思ってる 348 名前：224 mailto:sage [2013/03/16(土) 22:53:33.58 ] >>344 node.jsか。レスありがとう! 349 名前：デフォルトの名無しさん mailto:sage [2013/03/18(月) 20:10:52.78 ] Mybatisのセカンドレベルキャッシュってどこに保存されてるんだろ Serializableを要求するからTEMPフォルダでも指定してるのかと思ったが見あたらない？ もしかしてインメモリなのか？ローカルキャッシュよりは全然遅いのだが 350 名前：デフォルトの名無しさん mailto:sage [2013/03/18(月) 20:49:09.28 ] ああreadonlyに設定してないと読み取りの度にシリアライズが走るのか イミュータブルにすると周囲にやや不評だろうけど安全だしそうするか 351 名前：デフォルトの名無しさん mailto:sage [2013/03/20(水) 00:08:40.52 ] mapper XMLでinsertをする時、useGeneratedKeysを指定すれば自動採番されたIDが取得できるのは わかってるんだけど、これって単発insertのときだけじゃないですか。 insert selectで複数行をinsertしたとき、全部の自動採番IDを取ることって出来るんですか？ 352 名前：デフォルトの名無しさん mailto:sage [2013/03/20(水) 01:00:57.18 ] 生JDBCのgetGeneratedKeys()はResultSetを返すんだからできるんじゃねーの？ 353 名前：351 mailto:sage [2013/03/20(水) 01:13:31.36 ] いろいろ端折り過ぎてた spring + myBatisでPostgreSQLです keyPropertyに指定するフィールドを配列やListにしてみたんだけどダメだったなー 生JDBCでできているてことは、自前でhandlerとか作ってやればいいのかな 354 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:00:30.07 ] O/R マッピングは便利なんだけど何を使ってもテーブル結合と集計で悩む. Entityと1:1にならない1000SQLのために対応するDTOを1000作るのか？ みたいな. 型の安全性とか名前の管理とか考えたらList<Map>よりずっとマシなんだけど数がなぁ… 355 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:10:09.19 ] あと、Tableに対応するクラスはEntityでいいとして、SQLに対応するクラスは何と定義してどのパッケージに突っ込んでる？ 前者をDomainEntity, 後者をCustomizeEntityと呼んで同じパッケージに突っ込んでるプロダクトもあるみたいだけど. 356 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:31:00.42 ] だからまったくSQLを意識しなくてすむレベルまでオブジェクトにしても パフォーマンスがぜんぜん問題にならないくらいになるまで 使うべきじゃない。時期尚早。 357 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 11:52:33.44 ] >>356 使わないのも選択肢としてありだと思うけど>>354-355の課題は使用有無に関わらず発生するよね これみんなどうしてるのかねぇ 358 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 12:15:04.22 ] >>354 適材適所でいいんじゃないの SQL使うほうが楽な場所はSQLで直接やればいい。 お決まりの処理で性能を満たす場合はORMで。 359 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 14:06:30.14 ] >>358 まったくそのとおりだと思う。 実際ORマッパには生SQLを発行できるタイプもあるし、 生SQLで検索したものをオブジェクトにマップもできる。 (マップできないようにもできる。集計やグループ化もたいていは対応してるんじゃないかな。) SQLインジェクションにならないようにするだけでも価値があるし、 コネクションプーリングだけでも有用だと思う。 ORマッパにもよると思うがあまり毛嫌いする要素はないと思う。 360 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 14:31:52.65 ] SQLインジェクションとコネクションプール用途で使うには重すぎるだろ そんなのcommonsあたりで簡単に対応できるしな 361 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:17:03.51 ] >>360 え、そんなことないよ。軽いものなんていくらでも。例えばS2JDBCとか。 マップする用途からしない用途までわざわざ書いたのはそういうことですよ。 CommonsだとCommons使わない人が出てくるのでSQLインジェクション対策としては 片手落ちだと思っています。 あえて言っておきますがORマッパを使わない選択肢は否定していませんからね。 362 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:36:33.34 ] >>359 ＞生SQLで検索したものをオブジェクトにマップもできる。 ここが気になるって話じゃないの？ マップできるのはいいとして、SQLに対応するクラスをSQLの数だけ作るのか、 またはList<Map<String, Object>>とかで済ませてるのか うちは後者で統一されてて、生SQLのSELECT句に対応するDTOは作成が禁止されてる Mapのキー管理がかなり面倒だけどクラスの数を増やしたくないらしい 363 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 15:49:27.32 ] >>362 あーORマッパ書いて公開しているんですが、 その手のものはいろいろ手法があって、ResultSetを便利にしたようなもの を使ってもらうことが多いと思います。 フィールド値を取得するときにその型で取ると。 int value = result.intValue(column); とか > SQLに対応するクラスをSQLの数だけ作るのか そういう手法もあります。GenericsなTuple作る手もありますね。 Scala的に書くと、 val (id, name, date) = result.get[M: (Long, String, Date)] とか。 364 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 17:45:17.21 ] >>354-355 俺はある程度割り切ってクラスを共有するよ。 ざっくりとした例なので批判されるかもしれないけど 会員名、店舗名、都道府県名を格納できるDTOを用意して 会員→店舗までしかJOINしない場合もそのDTOを使用する。 都道府県名はnullなので都道府県名が欲しい場合は別のSQL使ってねと。 365 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 17:50:01.38 ] ありだな 366 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 18:22:48.02 ] ありだと思うよ ただその場合だと複数機能で共有するだろうからパッケージに悩みそうかな SQL書くときって機能でパッケージ分けてると共有しづらいよなー ドメインモデリングは理解できる奴少なかったりするし 367 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 18:59:18.05 ] >>363 マッピングせずにResultSet(風)を触らせるのもありか SQL発行した側はカラム名も型もわかってるはずだしな この前久しぶりにMyBatis採用案件見たけど これくらいシンプルな方が設計者も実装者もわかりやすくていいのかもしれないな 368 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:05:13.70 ] ようするにO/Rマッピングは現段階では不要だな 369 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:26:38.33 ] >>368 それはさすがに極論すぎて、ORマッパ以前にバグやセキュリティホールの温床になりそうです。 現状Webアプリなどの場合はORマッパがボトルネックになるより、 RDBMSの処理の方がボトルネックになることが多くて、 ORマッパの意義はむしろ昔より重みが増しているように感じられます。 ＃つまりCommons DbUtils使ってやれはちょっと...ということです。 ＃そして最近のORマッパは結構薄いラッパであることが多く、 ＃そんなに重たくありません。 ただ素のSQLやPLSQL/pgSQLなどの手続き言語を併用するのを 否定することではなく、バッチ処理のようなデータベースで処理だと ORマッパ以前にフロントエンドの処理がボトルネックになることが あると思います。その場合はそれを選択すればいいだけです。 370 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:37:43.30 ] >>369 O/Rマッパーを使わないとバグやセキュリティホールの温床になるってのは 技術職、開発会社としてどうなんだ？ 俺は条件によってはO/Rマッパーが有効なプロジェクトもあると思ってるが 上記のことは本質とはだいぶ違うと思うのだが。 371 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:40:36.78 ] SQL生成用クラスを一個つくればいいよね 372 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:45:11.79 ] >>370 本質じゃないというか言いたいのは「直接JDBC触らせるな」(DbUtils含む)ということですよ。 ORマッパはDAOみたいな機構も持っていることがあるので、 それなら最初からORマッパを使えば?ということです。 そういう汎用性をちゃんと持っているという認識が必要です。 >>371 そうですね。 でもそのサポートもDAOやORマッパがやってくれますけどね。 373 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:48:36.82 ] あと聞きたいのですが、JDBCなどを使っている場合、 java.sql.PreparedStatementをちゃんと使ってますか? 374 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 20:04:13.30 ] SQL生成用クラスでPreparedStatementを使ってバインドしてるよ。 375 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:20:56.00 ] Javaソースの中で文字列連結しながらSQL作るようなのはダメ絶対 376 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:40:04.61 ] 別にダメじゃないだろ O/RマッパーやPreparedStatementがないと 基本的なセキュリティ対策すらできないことのほうが問題 Javaじゃないと作れない人になってしまうよ 377 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 02:09:42.74 ] JavaスレだからJavaソースと書いたがどの言語でも同じ ただしSQLを組み立てるライブラリは除く、を書き忘れた アプリで文字列連結しながらSQL作るようなのはダメ絶対 378 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 05:36:16.05 ] >>376 PreparedStatementを積極的に使わない理由が思いつかない。 動的SQLなんて大抵の言語とRDBMSで使えるでしょ。 Javaじゃないと作れない人になってしまう理由がない。 379 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 07:38:05.65 ] >>376 他の言語もJDBCに相当する機能では、今はPreparedStatement的な手法が主流だし問題ないと思う 380 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 11:20:44.10 ] 昔は、文字列と、変数の配列(リスト)の2つを受け取って、 SQLをStringBuffer(StringBuilder)で連結しつつ、 ? を埋め込んで、 PreparedStatement 発行したもんだ。 381 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 12:31:12.72 ] オープンソースJava O/Rマッピングソフト一覧（2013年1月版） | Unofficial DB2 BLOG ttp://db2.jugem.cc/?eid=2540 382 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 22:37:34.34 ] PreparedStatementってDBサーバ側の機能だからな >>376の発想がおかしい 383 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 05:23:30.46 ] >>382 「Javaじゃないと作れない人になってしまうよ」と言っている当人がJavaでしか作ったことがないパターンでは。 384 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:43:10.56 ] DBとのやり取りにDAOパターンを採用するとき何をどこに入れるかってどうすることが多い？ (1) Aテーブルに対する主キーでの1件取得、全件取得、挿入、更新、削除などの基本的な操作 (2) Aテーブルに対する業務に特化した操作(他業務で使うことはない) (3) 複数テーブルを結合する複数業務で利用する操作 うちの周りだと下記のようにすることが多いんだけど、保守フェイズに入ると(3)が問題になりがちなんだよね (1)は全テーブル分用意して共通パッケージに突っ込んでる (2)は業務ごとにパッケージとDaoクラスを作成してそこに突っ込む (3)は代表的なテーブルのDao(上記1に該当するもの)に突っ込んで他の業務でも使う 385 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:52:59.87 ] 開発の規模によるがうちなら⑴と⑶だけかな ⑵は他の業務から使えないのが微妙 386 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:54:46.69 ] 問題の内容忘れてたわ… 問題1. どの業務が使っているかわかりにくいから触るのが怖い 問題2. 最初は(2)のパターンだったけど改修の結果(3)のパターンになった時に共通パッケージに移動しづらい (移動すると共通Daoを触る全業務の再テストが必要になる) 個人的には問題1はお前保守なんだから調査しろよ、 問題2はそこの客の方針がそうなら移動諦めて各業務Daoで重複させるか再テスト頑張れよ って思ってて、実際そう伝えたんだけど納得されなくてなあ… 銀の弾丸はなかなかないんだよ 387 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 09:12:01.84 ] 結局生SQLが一番いいという結果になるな 388 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:55:44.21 ] >>382 その上「基本的なパフォチューすらできない」っていうねw SQLがどうやって実行されるか気にしたこともないんだろうな 389 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:58:16.26 ] 結局SQLがどうやって実行されるか気にしなければならない O/Rマッパは使わないほうがいい。 390 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 12:49:51.63 ] >>388 なんでセキュリティ対策のこと書くとパフォーマンスチューニングについて わかってないことになるの？議論がめちゃくちゃ 391 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 13:35:29.45 ] 前から言ってるけどO/RマッパやDAO、DSLか生SQL、どれを選択するのかは使う用途によると思う。 その前提がなくただO/Rマッパは使わないほうがいいというのは、少なくとも今のトレンドに あっていないことも自覚すべきじゃないかと思う。 #特に国内と国外との違いにいつも愕然とするんですよね。 SQLやその実行過程を理解しガリガリにチューニングしなければならないというのも間違っていないし、 そしてO/Rマッパを使って抽象化・簡略化するのも間違っていないと思う。 何が目的でどういう手段を使うべきかをもうちょっと考察して議論したほうがいいと思う。 PreparedStatementを例に出したのはちょっとしたトラップで、 * PreparedStatementの利点を理解しているか? * そもそも(たいていの場合)PreparedStatementを直接書くのが間違っているのを認識しているか? を知りたかったからです(すみません)。 392 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:38:38.18 ] でもJavaの用途はWebがほとんどだからパフォーマンス重視なのは 仕方ない。だから生SQLが一番いい。 393 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:49:37.60 ] >>392 興味本位で聞くのですけど、O/Rマップってどのくらい遅いのですか? 具体的にベンチマークしましたでしょうか? ＃「あおり」じゃないので興味あったらで。 十分選択肢に入るくらい軽くなってますよ。 ＃さらにいうと生SQLも書けるのですが(例えばMyBatis)。 394 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:02:22.39 ] O/Rマッピングはアンチパターン？ | スラッシュドット・ジャパン デベロッパー ttp://developers.slashdot.jp/submission/42933/ 395 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:14:44.15 ] >>393 びっくりするほど遅い。んで生SQLに書き直さないといけなくなる。 せめて生SQLにしないといけない割合が全体の1割未満なら使ってもいいけど 実際のプロジェクトではマスタメンテのような機能以外は 生SQLになってしまうので使い物にならない。 396 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:29:57.81 ] どういうケースでどんな理由で遅くなるのか具体例が欲しいな。 397 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:40:04.67 ] >>395 (また言いますけど煽りじゃないです。O/Rマッパ開発者としては現状認識を知りたい。) 生SQLをO/Rマッパに使ってもですか? 私の思う生SQLやストアドプロシージャを使う場面は、 * 長大で複雑ななクエリ(検索) * バッチ処理など、検索以外にも挿入や更新が多い処理 だと思うのですけど、そういうケースですか? あとO/Rマッパ(名前およびバージョン)に何使ったのかも気になりますね。 一般的なケースだとあまりボトルネックにならないのですが...。特にWebアプリだと。 >>395 そうそう気になりますよね。参考になりますし。 398 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 16:47:15.90 ] RailsみたいにORマッパに適したテーブル設計ができていれば、 結構不都合無いパフォーマンスになるんですけどね。 IOの激しいWeb系とかゲームだと設計的に厳しいし、 がちがちの業務系だとそういう設計のできないアホなSEばっかだし、 そもそも設計をフレームワークに合わせるのか、とか不毛な議論が始まるので。。。 小規模なアプリをサクッと作る場合には便利なんですけどねぇ。 399 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:42:51.07 ] 社内システムならDBの負荷はたかがしれてるから ORM使っても性能上の問題ないよ 開発スピードも上がる。 パフォーマンスが大きく変わるのはメモリ上にDBのデータが のっているかどうかだろう WebサービスであってもほとんどORM使って問題ないと思うし 本当に性能が必要な場面はストアドプロシージャ使えばSQLより速くなる。 必死にORM否定してる人は使い方が分からないか、 使いどころがわからないだけ 400 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:50:31.65 ] ストアドプロシージャは使いたくないです。 401 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 18:09:34.30 ] まぁ2:8の法則だわな。 8割の処理はORMで十分だし、利用頻度が高かったり負荷の高い2割の処理は生SQL。 ってのが常道だと思う。 俺がよく使ってるのはHibernateJPAだけど、速度的には不満は無いね。 むしろDBにきちんと索引張ったり外部キー設計する方が大事だと思う。 402 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:02:46.76 ] ORMいらない、と言っている人間ははよくわからんな。 Micro-ORMで十分、なら理解できるが。 403 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:14:49.27 ] ORMと一括りにして議論している時点で程度が知れてる、というべきだな。 404 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 00:33:47.55 ] 同じSQLでO/Rマッパーだけ遅いなら外すしかないね。 内部のリフレクションとかが遅いんじゃないの？ 405 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:24:46.14 ] 問題になる遅さなのそれ。 406 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:29:38.75 ] 生SQLとかORMいらないとか連投してるのは荒らしだろ 現実的にはこのどっちか ・SQLを暗黙的に発行することがあるHibernate含むJPA系のORM ・プログラムで指定したとおりのSQLを発行するMyBatisやSeasar系などのORM 407 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:06:46.51 ] 生SQLの定義がわからんね SQL*Plusなんかで直接実行できるSeasarの2way SQLは生SQLなのかどうか 408 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:32:20.33 ] フレームワークが勝手に作ったSQLを発行するんじゃなくて、 開発者が書いたSQLを流すのが生SQLでいいと思う MyBatisとかDOMAとかの生SQLベースのマッピングはめんどくさいところもあるけど入門編にはいいと思うわ 409 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:41:14.77 ] だとするとJPA系を除く多くのORMは生SQLが主なんだが 生SQL君が言いたいのはORMイラネじゃなくJPAイラネなのか？ ORMイラネ君と同一人物かと思ってたんだが 410 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:49:50.56 ] >>407 >>409 ORMはSQLを生成して、SQLを投げるだけだよ 複雑なJOINしない限り、ほとんど性能は落ちない。 生SQLってのは自分でSQL文を書くってことだろう JPAもORMの一種 ORM要らないって連呼してるひとは、 上のほうでフレームワークも要らないと必死に主張していたひとと同一人物だと思う。 411 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 15:07:49.10 ] >>410 自分で書いたSQLをORMで実行した場合も生SQLだとしたら、 生SQLが必要だからORMイラネってのはおかしいという話 生SQLが主のORMもたくさんあるわけだから 生SQL君とORMイラネ君が同一人物かどうかはしらんけど 412 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 18:43:58.87 ] 俺は生SQL書きやすいORMならOK派かな。 Hibernateみたいなのは勘弁。 フレームワークも不要。 413 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 20:20:44.35 ] MyBatis+標準SQL(SQL92あたり)でいいわ 414 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 22:50:54.10 ] まぁ日本の開発現場ではNIH症候群が蔓延してるからな。 車輪の再発明大好きだし。 415 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 00:30:58.37 ] おれもMyBATIS＋SQLだな 学習コスト少なめだし、バグがあっても追いやすいし 裏で動的にSQL生成してるようなフレームワークで いい思いをしたことがない 416 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 05:58:23.38 ] ＳＱＬ方言だけ吸収してくれれば 417 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 07:20:01.88 ] Hibernateかなぁ。 幸い個々のエンティティに関して比較的単純なCRUDしか必要が無いのでMyBatisでSQL書いた ところでHibernateが生成するSQLとあまり大差無いものを書くことになったり。 個人的にはエンティティ引っぱってくるときに射影相当の演算や、関連を引っぱってくるのを LazyにするのかEagerにするのか、固定ではなく場面に応じて簡単に指定出来ると有り難い。 HibernateだとCriteriaに頼ることになるので面倒。 418 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 09:24:08.73 ] >>415 どれでも発行SQLだけ確認やログ出しも出来るし 2WAYならチェックした上でマズいの手書きできる フレームワークで統一性のない動的生成ルールが面倒だけどな それよりもDTO周りの議論に戻ってくれ 俺も今DTO増殖中で疲れてる 419 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 10:34:49.59 ] DTOはある程度割り切って共有で結論出てなかったっけ 割り切り共有＋継承＋テーブル定義とにらめっこ、 すればそこまで増殖しないと思うが。 420 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:05:35.15 ] DTOのクラスが増えるのが嫌なら、全部Mapに突っ込んでしまえば？ｗ 421 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:07:19.28 ] Mapでええやろ 422 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:37:01.55 ] mapでいいならJavaじゃなくていいだろ getterがあるからキーの文字列を意識しないで済んでるのに 423 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 19:32:32.72 ] MapとDTOは使い分ければ良いと思うけどなぁ。 424 名前：デフォルトの名無しさん [2013/03/31(日) 10:16:31.71 ] Java系のフレームワーク、海外ではGrailsがすごい人気高くて驚いた Java系だとGrailsはトップ3に入ってる Java系でサクサク開発できるのはGrailsとPlayみたいだ Javaの方言のGroovyだからといってGrailsを敬遠しないほうがよさそう 425 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 11:10:40.80 ] GroovyはJavaの資産は使えるなら積極的に使おうって姿勢かな 426 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 22:08:24.97 ] GroovyはJavaの方言というかJavaプラスアルファぐらいに考えた方が良いと思う。 Javaの文法にRuby風の文法やメソッドも付け加えた感じで、両方を混ぜて書ける。 JavaとRuby両方の素養がある人だとすごく便利だと思うよ。 Grailsだと根っこのドメインロジックはJava風にカッチリ書いたりそれこそJavaとして書いて、 逆にGSP(Grails版JSPみたいなもの)に埋め込むコードとか簡単なコントローラーはGroovyの 文法駆使して簡単に書く。 427 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 00:51:09.20 ] Groovy、Rubyほどギークでもない人でもゆるく書けるし、scalaより難しくないので、もっと流行ってもいいと思うんだけどな。 といいつつ周りではやっとこさ少しずつ広がってきて、以下のようなことをやるような人が増えてきた。 →納品物(webアプリケーション本体)はJavaだが、UTコード、内部ツールはGroovy、など。 　ビルドはgradle、とか。 といいつつRubyに素養がある人はRubyでやっちゃうんだよな。 428 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 02:41:51.01 ] JavaのView層はいつまでも安定しないね 似たようなコードの書き方、次から次に覚えないといけないのはきつい 他の言語はほとんど安定してるのになあ 429 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 03:21:29.18 ] Grailsは確かにもっと流行っても良い気はする。 会社でやっているプロジェクトも最近ようやくGrails2.2.1にバージョンアップして依存性管理を Mavenに移行出来たので他のプロジェクトとの連携がよりやりやすくなった。 430 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 07:00:39.53 ] フレームワーク使わない人ってURLマッピングはどうやっているのだろう。 例えばクエリーを使ったレガシーなaaa/product_comment?id=12345&comment=6789みたいな URLではなく、よりRESTfulなaaa/product/12345/comment/6789みたいなURLを使う場合。 フレームワーク無しの生Servertだと毎度自前でpathをパースしたりサブリソース毎に条件分岐したりと 手作りできるにせよ無駄に面倒だと思う。 431 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 11:03:54.12 ] >>430 mod_rewrite 432 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 11:09:20.88 ] 自前でパースしないと遅いしな 433 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 17:14:29.59 ] 面倒を厭わない人たちなのはよく解った。 434 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 17:20:23.50 ] >>433 面倒を避けようとしてさらに面倒なことになってる印象。 435 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:00:58.98 ] でもSEO対策が入ってくるとできあいのフレームワークじゃ難しいんだよな みんなどうしてるか、そっちのが気になるわ 436 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:09:02.05 ] JSFだのASP.NETだのはイントラじゃなきゃ難しいな 437 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:22:26.68 ] >>435 どうやってタグを吐くかだから フレームワークは無関係 438 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:48:03.67 ] JSP&Servletだけで十分フレームワーク 439 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:50:16.68 ] URLについては、Struts時代はRouter自作。 Spring MVCでは無問題。 440 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 23:33:39.56 ] >>441 すいません。jspは文字コードを使い分けたいので、そのやり方はダメなんです・・・。 あくまで違う文字コードでの受け渡しでやりたいんです。 443 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 23:41:07.31 ] Java内部の文字列処理はUTF-16だよ サーブレットの文字コードって表現が既におかしいんじゃない？ JSPのcharsetもSJISにしたいなら req.setCharacterEncoding("Windows-31J"); とサーブレット側で受ければいい 444 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 00:05:07.91 ] >>443 サーブレットのソースコードのテキスト文字コードがUTF-8ってことです。 サーブレット側では冒頭で request.setCharacterEncoding("Shift_JIS"); response.setCharacterEncoding("Shift_JIS"); と書いています 445 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 00:29:51.55 ] >>443 ああ、サーブレット側でsetCharacterEncodingやsetConentTypeで Shift_JISを指定するだけで行けました。 サーブレット内での余計な変換処理は要らなかったんですね。 どうもです。 446 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 02:15:06.83 ] >>438 >JSP&Servletだけで十分フレームワーク これはマジでそう思う。 ただ他方で機能不足なフレームワークはその上にオレオレフレームワークが育つ格好の培地でもある。 447 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 04:23:34.10 ] JSPはServletのフレームワークだな。 JSP嫌いだから引っこ抜いちゃうｗ 448 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 04:40:47.74 ] >JSP&Servletだけで十分フレームワーク ただしServlet3以降に限る 449 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 10:51:31.04 ] Servlet2.5 と Servlet3 で大きな違いってあるの？ Servlet3はほとんど追いかけてないのですが、 HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい ぐらいのことしか知らん。 450 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:10:55.48 ] ないと思うなー。 ＞HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい フレームワーク自体を作る側の人にとって嬉しいくらいじゃね？ 451 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:15:23.37 ] そもそもアノテーションとか要らない 452 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:21:53.88 ] なにいってるんだか xml地獄を解決するために生まれたのがアノテーションでしょ 453 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:24:32.09 ] フレームワークさえなければXML地獄もなかったのに 454 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:29:46.34 ] >>453 GrailsはXML地獄なかったよ XML地獄のフレームワークはほんと時代遅れ コードが見づらくなるし、コンパイラで検出できないエラーがでる。 なるべくコードで設定するってのが流行りだし、アノテーションは必須の機能 455 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:31:41.31 ] じゃあなんでSQLをXMLに外出しするような糞ORマッパを 勧めたりするんだ？ 456 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:38:17.94 ] >>455 アンカーくらいつけてまともな日本語で書けよ 何が言いたいんだ 457 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:43:30.16 ] フレームワークとかORマッパが嫌い 458 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:47:54.30 ] >>457 だったらこのスレを見るなよ 459 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:53:54.35 ] いやさすがにわかるだろw XML地獄を敬遠するくせにSQLはXMLいいのかってことだろ？ Javaの中でしか使わない設定はアノテーションとかでJavaの中に取り込んでいいと思うんだけど、 SQLについてはDBに流して確認とかよくやるから中に入り込まない方がいいな 今の所はSeaser系の2-way SQLが一番その辺り楽にできる パラメータをSQLコメントに追い出すことで文法エラーにしないのは秀逸だと思った 460 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:04:33.36 ] 海外だとHibernateが第一選択肢でそれ以外は比較的測定限界以下なのに、日本だとMyBatisとか ガラパゴスフレームワークの類が幅をきかせているのは何か特殊事情があるのかな。 461 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:20:17.93 ] 外出しすれば綺麗だと思うのは間違い C++になっても変数宣言を関数の先頭でやるくらい汚い 462 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:21:15.39 ] 全部のORMがXML使うわけじゃないし TypesafeなORMが良ければそういうORMと組み合わせて 使えばいいだけだろ 入れ替えて使えるようにDIとかがあるわけで うんこフレームワークを体験したからといって フレームワーク全体を否定するのはアホ うんこORMを体験したからといって ORM全体を否定するのは馬鹿 463 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:23:53.81 ] いろいろなフレームワークがあること自体間違い 464 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 10:28:49.35 ] SQL外出しなオレオレフレームワークは色んな現場で見てきたけど、大体良い思い出が無いなぁ…。 大体SQLだけメンテしようとして、SELECT項目やバインド変数の数間違えてトラブるのが定番だった気がする。 事前にコンパイラみたいなのでチェックできるならいいんだけどね。 465 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 11:36:08.03 ] とりあえずSeasar信者の受け売りが嫌だ 466 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 11:47:15.81 ] 色んなフレームワークがあるのは構わんけど、色んな実装があるのは嫌だ。 JAX-RSとかJSF、JPAとか。 つーか、WebやORMのフレームワークで、わざわざ仕様と実装をわける意味がわからん。 結局、実装固有の拡張機能を使わないと使い物にならなかったりするし。 467 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 12:02:47.87 ] >>466 その無駄な複雑性はJavaの悪いところだし ORACLEが無能だからだろうな 468 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 13:39:18.89 ] 継承や委譲を使うべきところまでPOJOがどうのこうのとアノテーションだらけにする 無能な糞フレームワークがあるな。S2なんとかーだけど。 469 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 13:55:01.70 ] 自分も Hibernate より MyBatis のほうが好きなタイプだが、 Hibernate は嫌われるのに、Rails の ActiveRecord がみんなに受け入れられているのはなぜだろう？ 両方とも似たようなタイプなのに 470 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 14:58:00.57 ] 規約やアノテーションを活用する今のHibernateではなく、XML地獄時代のHibernateのイメージ があるからじゃないのかな。 471 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 16:26:08.57 ] ActiveRecordが受け入れられている理由 -> RoRを使用するような用途/データモデルではそれで困らないから Hibernateが受け入れられない理由 -> Javaがおそらく最も使用されているユースケース/データモデルではそのAPIモデルでは困るから ソーシャルなWebアプリっぽいもの、DOA世界な帳票とかのLOBアプリでは、APIに求められるインターフェースも違うだろうし。 472 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 19:43:14.80 ] そういやhibernate entity manager経由でしか触ってないな 今って生hibernateどうなってんだろ 後で試してみるか… 473 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 20:06:18.41 ] >>471 でもそれだけだと内外差の説明はつかないなぁ。 474 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 20:33:32.91 ] >>469 RailsのようにConvention over Configurationが徹底した フレームワークだと、ほとんどORMの設定することなく使える。 Javaの場合、RailsほどCoC重視したフレームワークがまだ少ないから Hibernateのめんどうなマッピング設定が必要になって、嫌われるのでは >>470 のいうように、昔のXML地獄のHibernateしか知らない人もいる のも原因かもしれない。 475 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:17:53.29 ] >>473 ニホンジンはガイコクジンに比べて帳票ダイスキー、っという説はどうだろう？ - 帳票の出力内容はSQLレベルで複雑な処理を書くのが一番効率的 - その場合、求められるAPIは文字列としてのSQLをそのまま実行できるようなもの - 日本において、Javaはもっぱらそういうアプリを作る用途で使われている(土方的な) - そういう現場にHibernateを持って行っても(ﾟДﾟ)ﾊｧ? 国内では受け入れられていない理由が、昔のXML地獄のイメージがあるからとかっていうのは、 自分としては枝葉の話な気がするが。 476 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:21:36.90 ] >>472 そういやHibernate4はEntityManager/Annotationsがネイティブになって 旧APIとXMLマッピングがその上のラッパーになるってどっかで見たけど 実現してないんだな。今もドキュメントはXMLマッピングから始まる 477 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:44:55.39 ] >>473 日本のIT業界が世界に取り残される一番大きな理由は 大半が英語ができないからだよ 英語のドキュメントが満足に読めない人ばかり。 日本語の書籍がでて日本語情報が充実してこないと普及しない。 478 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:51:43.05 ] iBatis/MyBatisなんて日本語の情報が充実してなくても結構使われてるだろ Springだって使われてる度合いに比べたら日本語の情報は少ないし Hibernateは使われてない割に情報多い たいして相関してる気がせんな 479 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:55:28.57 ] ぶっちゃけStringの連結なんてしたくないわ テキストに書けるならそっちの方がチューニングもしやすいでな 480 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:02:27.77 ] >>478 Batis系はHibernateよりも単純だから英語のドキュメント 読めなくてもなんとかなるからだろう Hibernateのほうがはるかに高機能な分、覚える概念が多い。 Hibernateの本、日本語のもあるけど今のと違いすぎて役経たないと思う 英語弱者にとって厳しいのがHibernate ORMにしてもEntityベースでやるのが主流になってるし SQLに近いBatis系はもう海外では流行ってない。 疑うならwebフレームワークの採用ORM見てみなよ 481 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:04:26.47 ] 内外差以前に海外の実情がわからんのだよな いつまでもTomcat使ってるのは日本だけと某エバンジェリストが言ってたけど www.javacodegeeks.com/2013/03/most-popular-application-servers.html を見ると海外でもTomcat強いしJetty含めてJavaEEじゃない方が主流だよな 海外じゃJSFやJPAが普及してるってのもどこまで本当か… マーケティングに釣られてるんじゃないかと思うことがある 482 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:07:31.15 ] >>480 > 疑うならwebフレームワークの採用ORM見てみなよ Playじゃebeanやnormも採用されてる件 483 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:36:07.96 ] 英語・日本語にかかわらず、ドキュメント読まなくても使えるシンプルなのがいいのは確かだな 484 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 00:51:54.82 ] Struts1のEOLが決定しました www.h3.dion.ne.jp/~alpha-pz/misc2811.html 潮流が変わるきっかけになるかね？ 485 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 02:02:52.91 ] RailsとHibernateが同じようなものというのはない JavaのフレームワークはXML地獄かアノテーション地獄 Railsなんて学習コストやハマりコストめちゃ低いぞ 486 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 02:21:25.71 ] こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん qa.atmarkit.co.jp/q/2826 487 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 04:49:50.13 ] う〜ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。 488 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:30:48.85 ] >>485 名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ Javaを知っている人ならGrailsのが学習コストは低いとおもう。 >>484 日本の遅れたIT業界のことだから、ダメなのわかっててStruts2 に移行したりするんだろうなぁ 489 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:35:07.70 ] >>484 フレームワークなんか使うからこうなる。 490 名前：デフォルトの名無しさん [2013/04/04(木) 07:44:26.43 ] >>489 お前自身がEOLってことに気づこうな 491 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:20.30 ] Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では アレになっている部分も少なくないと思う。 例えばmappingsやtransientといったORMの定義、staticフィールドにRails風に記述できる ようになっているけれども、型安全じゃないし正直JPA風のアノテーションの方がシンプルで 良かった。まあHibernateで定義したドメインクラスをインポートすれば良いのだけど。 あとビミョーに謎な振る舞いに悩むこともある。先日もドメインクラスにコンストラクタを定義 して使っただけでDIが動かなくなって暫し悩んだ。 492 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:35.61 ] >>489 まだこのスレにいたのか 必死にフレームワーク否定してるけど何つかったことあるんだよ 493 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:56:46.99 ] >>488 Javaのフレームワークにはいつも期待を裏切られてるけど 最後の最後ということでやってみるよ。アドバイスありがとう 494 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:05:53.42 ] 作っては捨て作っては捨て こんなのシステム開発では使えないよ。 趣味のプログラミングなら好きにやってくれていいけどさ。 495 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:52:46.84 ] >>494 毎回作り直してる俺々フレームワークのことですね、わかります 496 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:58:09.84 ] WicketライクなFW普及してくれ〜 497 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:59:04.31 ] >>495 受託や派遣ばかりやってるからそういう発想になるんですね。わかります。 498 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 09:18:37.61 ] >>496 Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ 499 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 20:48:10.99 ] JSFってFacelets+CDIだけやれるっけ？ バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる 501 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:33:20.22 ] javascriptの時代が来る気がする 最近のjavascriptのライブラリは凄まじすぎるわ jqueryuiとか、datatablesとか、jquery.sheetとか マジでなんでもできるんだな サーバーサイドもNode.jsになるんじゃないかな ブラウザの開発ツールやらcloud9やらと、開発環境も整いつつあるし Javaは下火になりそう 502 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:35:35.96 ] フレームワーク乱立のせいだな 503 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:41:00.19 ] >>501 その3つどれもただのjQueryのプレゼンテーション層よりの機能じゃないか jQueryは他の言語のフレームワークでも連携させて使えるし、 サーバサイドが強いJavaとは強みのあるエリアがちがうよ 本格的なオブジェクト指向言語にすらなれてないJavascriptで 開発なんてしたくない 504 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:54:27.01 ] >>501 phpと争って削ってくれたらそれで十分な感じかな あいつらだけはマ名乗ったらいかんレベル 505 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:59:26.63 ] apache cgi javaとかあればなー 506 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 23:23:40.46 ] >>503 それがさ、今single page applicationとかってのが流行ってるらしくて サーバーサイドのコントローラの機能をクライアント側が吸収し始めてるんだよ ライブラリさえあれば普通に本格的なオブジェクト指向言語だし backbone.jsとかember.js見て驚愕した requirejsやらcommonjsやらでモジュールもできるし、ビルドツールもある qunitとかphantom.jsとかでテストも完備 サーバーサイドでormっぽいことも出来るみたいだし nodejsdb.org/ ちょっと首を突っ込みはじめたんだが、マジで最強かも ものすごいコミュニティができつつある 507 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:10:40.11 ] Javaのフレームワーク関連で こんなにもたくさんの名前が出て来ること自体が異常 他の言語はここまで乱立してないから入りやすい 508 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:24:26.24 ] >>507 javaはまだマシだと思う ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい ぶっちゃけjeeだけってのもありだし この点ではjavascriptのライブラリの乱立が一番ひどい 509 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:51:39.39 ] springjs hibernatejs なんかつよそう jsf も js が付いていることに気がついた。でもうんこ 510 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 01:11:50.38 ] 選択肢が無い方が幸せって人もいるけど俺はいやだな 511 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:32:32.04 ] 趣味の自分プロダクトならそれでいいけど フレームワークがコロコロ変わると チームメンバーが大変だろう 512 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:47:37.60 ] そこまでころころは変わらない。 513 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 07:02:04.46 ] オレオレフレームワークで検索するとPHP率が結構高いのね。 514 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 08:05:54.47 ] Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな 515 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 09:36:15.65 ] >>508 DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね GrailsもSpringをベースにして、HibernateやGroovyや 独自テンプレートエンジンなどを組み合わせたものだった。 VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。 >>510 選択肢は多いほうがいいね ドキュメントが整備されているという条件つきだけど。 JSはドキュメントも十分にないようなライブラリが1万以上あってカオスだわ 516 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:15:07.30 ] 2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ たんにデコレーションする JQueryとprototype js と ext js しか知らなくて、 Backbone JS みたいにクライアントサイドでロジックまで制御するようなフレームワークが 出てくるなんて思わなかった(自分のスキルが低いのだろうが) 517 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:17:44.83 ] 俺はフレームワーク嫌いだからjQueryすら使わない 518 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:33:11.41 ] JSはただのライブラリであってフレームワークではないだろ 519 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:41:08.76 ] ネイティブが好き 520 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:47:27.52 ] Javaのフレームワークの乱立について指摘されてるのに JSのほうがもっと酷いからJavaの乱立はOK、というのはいかがなものか 521 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:53:42.65 ] >>518 MVCフレームワークが乱立してるよ todomvc.com/ 522 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:46:14.82 ] Node.jsはCPUを使う処理には弱いと書いてあるね。 シングルスレッドでしか使えない弱点が痛い。 グリーの宣伝（人材募集）みたいになっててアレな記事だけど。 codezine.jp/article/detail/6461?p=2 メリットはリアルタイム処理が強いことくらいかな でもソーシャルゲームとかチャットのようなリアルタイム性が 必要ないなら、Node.jsを使う意味は見当たらない。 JSは細かいライブラリが大量にあって情報追いかけるのがひたすらめんどくさいわ 現状は汎用的に使えるサーバサイドフレームワークって感じじゃなくて リアルタイム処理が必要な場面で使うものに見える。 523 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:49:07.16 ] 従来サーバ側のWebフレームワークが担ってきた役割、特にビューは クライアント側（JSに限らずObjCやJava含む）への移動が始まってる だからサーバ側もJAX-RS的なものでAPIだけ作る流れ これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる） 524 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:52:50.13 ] >>522 今はJavaでもNettyがあるし、その上に作られたNode.js風のVert.xもある Netty上に作られたErlang風のAkkaもあり、Akka上に作られたPlay!もある 技術的にはNode.jsを選ぶ理由はない 525 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:56:37.52 ] JAX-RSは地味によいものだと思う。 526 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:59:55.89 ] シングルスレッドとかありえねー 527 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:18:49.66 ] 逆だろ、単体ではシングルスレッドにしておき、 CPUコア数に応じてスケールさせたければ、プロセスを複数立ち上げておいて、 フロントのロードバランサーなりリバースプロクシで分散させればよい。 Nodeにしろ、こういったのは、パフォーマンスを上げるために、マルチスレッドではなく RubyのEventMachineみたいにイベント駆動にすることでパフォーマンスを上げようとするアプローチなんじゃないの？ って書いてて自分でも理解してないのだが、 マルチスレッドにしつつ、各スレッドは EventMachine 形式にしたら、もっといいんじゃないの？ と思うんだけど、併用できないんですか？ 528 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:35:47.71 ] 逆とか意味不明。シングルスレッドとか糞 529 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:44:10.18 ] シングルスレッドにはシングルスレッドの良さがある 同時1万接続をすいすい捌いてもメモリ256MBでおつりが来る これはマルチスレッドじゃ無理 クラウド（PaaS）ではこれがコスト面で効いてくる場合がある 要は適材適所の一つ 530 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:45:51.78 ] >>523 Viewがクライアント側に移動が始まっている、の意味がさっぱりわからんですわ。 例えばCRUDのうち、データ取得する(SELECT的)処理をするとして AP serverは、DBから得た結果を、htmlとマージして最終的にブラウザに 渡す必要があるのは何ら変わってないでしょう？ 要するにTemplateにデータを合成して、レスポンスを返す処理。 実際に、今の主流のMVCのフレームワークでも そういったViewのテンプレート処理を持ってるし、使ってるでしょう。 Node.jsをプッシュしてたひとと同じだと思うけど、「使われている事例がある」 というだけなのに、すべてそうなっていくかのように主張しているように見える。 531 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:50:45.64 ] >>529 ないない。 DB絡んだら1万同時接続なんて1台じゃ無理だし シングルスレッドならなおさら無理。 さらに256MBで足りるなんて妄想もいいところ 1万接続で256MBとか馬鹿な主張はいいかげんにしろといいたい 532 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:58:18.20 ] シングルスレッドはマルチスレッドになれないけど マルチスレッドはシングルスレッドになれるんだから シングルスレッドのほうがいいなんてありえない。 533 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:02:24.39 ] >>530 HTMLを返す必要がなくなってきてるってこと JSONだけ返しておけばあとはクライアント側でレンダリングする だからクライアント側のMVCフレームワークが注目なわけ 君だいぶ遅れてるみたいだから少しはキャッチアップしておいて損はないと思うよ 534 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:15:06.17 ] >>531 Node.jsじゃDB接続もノンブロッキングだし1スレッドで十分 DBとのやり取りってアプリ側はSQL投げて返ってくるまで待つだけじゃん？ だから影響はないよ もちろんDB側がボトルネックじゃない前提で >>532 用語の使い方の問題だな シングルスレッド: イベントループで複数の接続を扱うアーキテクチャ マルチスレッド:　 接続毎にワーカースレッドを使うアーキテクチャ まともな議論にならないなら用語変えた方がいいかもね 実際はNode.jsだってマルチスレッドだよ イベントループ以外のスレッドは持ってる 別にNode.jsプッシュしてるつもりはないんで 必要に応じて使ってるだけ 535 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:19:45.99 ] >>533 遅れてるとか馬鹿にしてるだけで答えになってないよ。 最終的にブラウザで表示されるhtmlはどうするんだよ HTMLを返す必要はなくなってきてなんてないから 536 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:21:03.02 ] bodyタグの中身は空でjsで全部書くってことでしょう。 537 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:24:45.46 ] >>536 それ非効率極まりないね あとJS無効にされてたらなにもレンダリングされないじゃないの。 プライベートブラウジング機能が搭載されてきてるから JS無効になってるなんてケースは増えてる。 538 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:27:03.82 ] フレームワークを使う人は開発効率のみ優先だから。 539 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:30:26.06 ] >>523 >>533 それはないと断言できる プログラムの前にキミはWebがわかってない 540 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:38:33.99 ] >>539 同意。 他人を遅れてると馬鹿にして上から目線で発言してるわりに アーキテクチャと利点、欠点などがわかってないわ 542 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:39:43.33 ] フレームワーク厨はフレームワークさえ使えればなんでもいいんだよ。 君らもフレームワークをありがたがってないでネイティブに回帰すべき。 543 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:49:34.93 ] そうやって間違った方向に進んでしまうのがIT業界の悪いところだな。 545 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:16:33.84 ] >>540 >>543 Google mapとかの地図サイトのように ページの一部分を頻繁に読み込むようなサイトなら JSは使うだろうし、それくらいは当然知ってます。 ページ全部を毎回読み込むのは非効率だし ただ、MVCのある機能がブラウザ側に移動したというより、サーバとクライアントが 協調して動作するようなシステムが出てきたってだけの話だと思う。 結局、サーバサイドのフレームワークがなくなることはありえない。 >>523は、「分散」とかではなく「移動」といったうえで 「これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）」 なんて結論づけたから噛みついたわけ。 Strutsがクソなのは知ってるけど、そこからサーバサイドのMVCフレームワークが なくなっていくという話につなげられると まったく同意しかねる、ということ。 Ajax, jQuery必須にしてしまえば、ブラウザでJS切ったら使い物にならないし 有効であってもバージョンの互換性でエラーが出る。 開発のコストも無駄にかかる。デメリットも大きい。 だから全般的に移行することはありえない。 デメリットを補ってあまりあるメリットがあれば使われる、というだけ サーバだけでやるのか、サーバ＋クライアントでやるのか、 使い分けの問題であって、サーバのみでやるのが遅れているわけでもない。 セキュリティ上の理由でクライアントサイドで処理できないこともある。 546 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:20:06.75 ] まったくだ。ニコ動もクライアントでいろいろやりすぎて 糞使いにくくなってる。 つまり何事もネイティブで考えることが必要だ。 547 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 18:58:11.74 ] 中の人にはソレが段々と見えんくなってくるのでしょう。 548 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 19:24:11.12 ] JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。 ちなみにうちは、jQueryの利用的なことから一歩進んで、JSフレームワークのLOBアプリへの適用もやりはじめた。 今までJSで個別に処理を記述していたところを、フレームワークを使って、 RESTなAPIの結果でObserverなVMのメンバを更新、バィンディングでHTMLの表示を更新というレベルだけど。 549 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 20:45:01.83 ] >>548 > JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。 どの辺がまだまだ? 550 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:28:07.76 ] >>545 もちろん、なかなか消えはしないだろうけど、 徐々にviewの部分が移行していく流れだと思う 下手すると、cの部分も 本当に最後まで残るのは、モデル層だけだろう 551 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:41:16.25 ] 今後流れがjavascriptに来るだろうというのは 確実に分かる 現在のライブラリの乱立がその徴候 今はその動きの中にいる人だけが気がついてる状態だが これがやがて、本流になる 552 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 00:35:34.78 ] 今後はクセモノであるHTTPセッションを クライアント側メモリに持ち込むのも増えていくだろうけど、 クライアントがスマフォとかだと大きいキャッシュデータとか無理だし サーバー側でセッション作る必要がある。 554 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:04:28.16 ] インタラクティブな処理が必要な場合に、 クライアントサイドでのタスクを増やすってのがJSの使いどころ このスレのJSやnode.js推してる人は、すべてクライアントサイドで やる方向にいくと思ってるところが大間違い。 デメリットがわかってない。 必要のない場所でまでJSでやったら開発コストも増すし ブラウザの互換性というやっかいな問題が現れる。 555 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:06:01.26 ] ダイナミックHTML時代のままで大いに結構 Ajaxまでは求めちゃいないよ 556 名前：keisuken mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:30:00.65 ] HTMLを返す処理はなくならないが フレームワークの要不要はまた別問題だな 俺はいらんと思うけど 558 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:33:29.51 ] ブラウザで多くをやる方法は限界やデメリットがある以上、 サーバ側のフレームワークにとって代わることはない。 JavaのWebフレームワークのスレなのにスレ違いのレスばっかりになってる。 559 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:34:45.31 ] >>553 >今後はクセモノであるHTTPセッションを >クライアント側メモリに持ち込むのも増えていくだろうけど、 セキュリティホール確定。 クライアント側は当然偽装し放題ですよ。 ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも） なので、見えないページはムカつきつつ閉じてます。 わざわざ開く価値なんてないし。 560 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:36:37.41 ] >>558 JAX-RSだってJavaのWebフレームワークだからこの流れはスレ違いじゃない 自分の意見と違うからって排他的にならないでほしいね 561 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:12:52.30 ] >>559 いまどきJavaScriptをOFFとかありえないだろ。 商品リストのページングとかSession+Ajaxでやっていたようなものにも クライアント側が操作しても問題ないようなデータは結構あるぞ。 562 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:19:09.71 ] >>559個人がどうするかは>>559の自由だから放っておいてやれw ようはJS無効にしてるユーザを救うことによって得られる 利益とかかるコストをそれぞれのサイトがどう評価するかだ 563 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:24:58.73 ] クライアントJavaScriptでバリデーションをするとか嫌だな。 たとえば登録フォームだとパスワード半角英数8桁とか以外にも 同じ名前が既に登録されているのかとかチェックするときがありうる。 そうなるとデータベースとバリデーションが関連するわけで、 Ajaxを通すのは良いとしてもバリデーション自体は鯖側で行うべきだ。 564 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:51:01.86 ] クライアントから投げられる値なんて基本的に信頼できないからサーバ側でのバリデーションは いつまでたっても必須だよ。ただsubmitする前にキー入力に応じてダイナミックにバリデーション したい場合などはJavaScriptを使ってブラウザ上で「仮」バリデーションする場合もあるというだけ。 ただこれするには同じバリデーションロジックをJavaとJavaScriptでそれぞれ書くことになるので 二度手間になる。この点でGWTは地味に便利だった。Javaで書いたロジックをJavaScriptに変換して ブラウザ上で使うから二度手間にならないし、Java上でロジックを書き換えるとそのままクライアント 側のロジックにも反映されるからロジックの同期も楽。 というわけでJavaからJavaScriptへのコード変換はそろそろjavaxとして仕様化すべきだと思う。 あるいはJava -> JavaScriptの変換を行う定番トランスレーターがデファクトで決まるのでも良い。 565 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 04:45:17.33 ] >>564 で、だったらはじめからサーバーもjavascriptで書けばいいじゃん という流れになったりしてな node人気が出てきたみたいだし 566 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:06:19.09 ] >>563-564 そうそう。 セキュリティ上の理由で、サーバ側でやらないといけないもの があると書いたのはそういうValidationとか。 クライアントサイドのValidationは仮のチェックだね レスポンスを高めるだけのものでしかない。 クライアントに渡した時点で汚染された（信頼できない）データに なってしまうし、再度DBに入ってくるようなデータは渡したくない。 全部クライアントサイドでやる流れ、とか言ってる人は セキュリティの観点が頭にない。 567 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:17:19.79 ] >>566 バッカだねぇ、「全部」クライアントでやる流れなんて誰が書いた？ サーバ側でバリデーションが必須なんて当たり前すぎて議論の余地無しだよ JAX-RS使うとバリデーションできないとでも思ってる？ BeanValidatorはMVCフレームワークと密結合してるとでも思ってる？ レベル低すぎて相手にするのやめようと思ったけど想像以上の低さに驚いたよ 568 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:24:52.99 ] つーか「StrutsとJSPの時代が終わる」と書いた>>523でもJAX-RSのこと書いてるのに なんで>>545みたく「サーバサイドのフレームワークがなくなることはありえない」 なんて的外れの反論しちゃうのかねぇ あげくに「全部クライアントでやる流れ」とか誤読どころの話じゃないだろ こんな文盲で仕事できるのかね？ 569 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:26:42.29 ] >>567 自分の発言読み返してみろよ そう読み取られてもおかしくない表現してる >>523なんてアホ発言そのもの 他にもnode.jsの時代になってるだの妄想垂れ流しすぎ 570 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:27:53.82 ] >>568 おまえはJSスレに帰れよ 完全にスレ違い 571 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:29:14.15 ] 一度スマホのネイティブアプリとだけつながるサービスの開発でもやってみると （何が必要か考えるだけでも）知見も広がっていい経験になるんじゃないすかね？ 572 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:32:39.84 ] >>569 具体的に指摘してみろよ どこに「全部クライアントでやる流れ」と読み取られておかしくない発言がある？ Node.jsの時代になってるってのもどこにある？ 573 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:43:39.54 ] >>572 誤解されてもおかしくない表現力だよ 他の人もそうとらえてる人がいる。 >>543もあんただろうけど滅茶苦茶 ＞最初は静的なHTMLで始まる（Javaで返す必要はない） それができない場面もあることはすでに書かれていたよな？ ＞まだそこまで極端なケースは少ないけど方向はこっち ほら、ここで自分でいってるだろう。 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。 あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。 自分ではないいうのなら自分のレス番号全部書くなりトリップつけないとわからない。 この板はIDでないから 574 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:55:48.45 ] >>573 > 他の人もそうとらえてる人がいる。 他の人じゃなくてさ、君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ > それができない場面もあることはすでに書かれていたよな？ できない場面「も」あるから何？ > 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。 「たくさん」っていうのは君の主観だね > あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。 そもそもどのレスがNode.js推しなんだよ？ ちなみに>>524は俺だよ。Node.js推してるように読めるか？ 575 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:03:44.94 ] >>574 >>524は別人だと思ったよ 俺とかいわれてもIDでないしわからない。 ＞君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ 散々書いただろ。めんどくさいやつだな あんたの発言がどのレスだか判別つかないことくらいわかってくれ。 俺のレスもすべてはわからないだろう。 576 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:25:47.54 ] >>575 「散々書いた」ってどこにあるんだよw 具体的に指摘する気はないみたいだからこれ以上は追求しないが、 勝手に拡大解釈して文句をつけるのはもうやめてくれ 577 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:33:12.04 ] >>576 散々書いたってわからないって？ 俺もお前のレスがどれだかわかんないのよ IDでないから そういうしょうもない掲示板でまともな議論なんてできないの 578 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:37:32.20 ] >>577 あぁ、続ける気なんだ 別に「俺の」じゃなくていいからさ、君がどのレスのどの表現から 「全部クライアントでやる流れ」と読み取ったのか教えてよ 寝ぼけててもできる簡単なお仕事だろ？ 579 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:19.34 ] >>572 「APIだけ作る流れ」 「HTMLを返す必要がなくなってきてる」 580 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:23.42 ] >>576 ちなみに俺は「君が」書いたレスかどうかは「気にしないで」読み返したけど どこに「散々書いた」のか見つけられなかったよ 突然飛躍してるレスしか見あたらない 581 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:47:57.92 ] >>578 >580 しつこいなぁ、あんたも 「続ける気なんだ」どころか真逆だわ IDでないしょうもない掲示板でまともな議論なんてできないってかいたろうに IDでないんだから違う相手に反論してるなんてことあるだろ？ だからこれだけレスもついたし、検証作業なんてやりたくないの。 全員が正直に自分のレスを書いてトリップ書いたりしないと今となってはわからない。 582 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:49:57.54 ] >>579 それかよ（失笑） Twitterが「API」も提供してのはもちろん知ってるだろ？ Twitter4Jとかあることくらいは知ってるだろ？ そのAPIはHTML返さないのも知ってるだろ？ じゃあTwitterのAPI叩くとTwitterのサーバじゃバリデーションも行わず、 「全部クライアントでやる」と思ってる？ 違うだろ？冷静に考えてみてくれ 583 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:52:13.77 ] >>581 別に違う相手でも構わないよ >>579にしたってさっきまでの誰かと同じかどうかはどうでもいい それで議論できないなら半年ROMってろ 584 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:54:41.95 ] >>580 581 だけど>>579の人とは別人だぞｗ ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ？ だれかJS押しの必死な人がいるように見えるわけ。 でも、IDでないから同一人物かすらもうわからないわけ。 くだらないだろ？ 無意味なレスばっかりになってる上にスレ違いだから、 クライアントJSの話題はJSのスレでやってくれ 585 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:56:09.01 ] >>582 スレ違い。荒らしになってる。 冷静にスレタイを読めとしか言えない 586 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:59:59.38 ] >>582 喧嘩してるとこ横レスして混乱させてすまんかった JSONを返す流れについていってないやつは遅れてるとか HTMLを返す仕事してるやつを小馬鹿にする発言もあったしなあ じゃあバリデーションやデータの受け渡し以外は 全部クライアント側でやる流れってことでいいの？ 587 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:01:53.46 ] >>585 JAX-RSはWebフレームワークだからスレ違いじゃないだろ それともここはHTMLを返すフレームワーク限定なのか？ スレタイにも>>1にもそんなこと書いてないのに？自治厨？ 588 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:10:29.51 ] >>587 スレ違いといってるのはクライアントサイドのJS フレームワークという言葉を拡大解釈して、 スレ違いではないと強弁するのはやめたほうがいい 589 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:25:56.10 ] >>588 俺のに限らずクライアントJSの話が主のレスなんてほとんどないだろ どのレスがスレ違いなんだよ 「フレームワークって用語を拡大解釈」ってJAX-RSに対して言ってる？ 590 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:33:44.14 ] >>589で「俺のに限らずクライアントJSの話が主のレスなんて ほとんどないだろ」って書いた俺涙目w 593 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:37:56.40 ] いいんじゃないの？ 今はクライアントJSまで考慮しないとどうしようもないんだから どうせスレ違いに拘ってるのは一人だけだろうし 594 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:43:45.27 ] >>589 ずっと上から読み返してみ？ サーバサイドのフレームワーク不要論を唱えだした奴いるだろ >>579 の引用がその一例 その不要論を言いだすと、Java不要論になるし このスレも全否定だし、 スレ住人が携わっているであろうサーバサイド開発も全否定になる。 要するに、このスレもスレ住人の仕事もJavaも全否定になるから、 サーバサイドフレームワーク不要論は反論されるし、 スレ違いだと言われるわけ。 比較のためにRailsとか他の言語のフレームワークの話題でることも あるけど荒れなかった。 違いはなにかというと、ここのスレと住人を全否定したかどうか、 だと思う。 595 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:57:23.38 ] >>594 >>572は>>523からの引用だが、それのどこが「サーバサイドの フレームワーク不要論を唱えだした」？ JavaでJAX-RSでAPIを提供するサービスを作る流れっていうのが 「Java不要論になる」？「サーバサイド開発も全否定」？ 頭おかしいんじゃね？ 596 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:08:47.77 ] >>595 JSON返す流れになってるだのアホなこといってるのは サーバサイドFW不要論そのものだろ サーバサイド不要論唱えてる奴はいたわけ このしつこさからしておまえの可能性高いけど 597 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:11:00.43 ] >>595 頭おかしいだの遅れてるだの口が悪い 598 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:15:15.54 ] >>596 JSON返すと「サーバサイドFW不要論」wwwwwwww ダメだこいつw 俺とは「サーバサイドFW」の定義が違うようだが、 俺だけとじゃなくてこのスレ住人、Java開発者、Web開発者、 その他多くと違う定義だよそれ 負けたよ、さすがにもう相手にできないわwww 599 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:18:21.51 ] >>598 お前来てから荒れた。出てけ このスレは遅れていて、相手にできないんだろ はよでてけ 600 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:19:53.00 ] 荒らしはLLスレにいたやつと同じにおいがする これからはJavascriptの時代だってしつこいのなんの 601 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:22:13.99 ] このスレの連中は真面目に相手しすぎだわ 602 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:31:31.35 ] >>601 まったくだ 俺は>>563の時点で目眩がしたわｗ CGI全盛時代のスレかと思ったよ 603 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:42:25.02 ] でも流行りに流されたほうが金になるというのもまた事実 604 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:53:37.29 ] Javascriptがもう少し機能的にもデザイン的にも優れものだったら、 プリミティブ型が使えて静的型・型推論・LINQ・JAXBとか持ち合わせていたら 「これからはJavascriptの時代だ」でも別にいいけどね。 ログ出力すらブラウザ互換性云々いってる糞言語は書きたくないし、 Dartとかも出力対象のJavascriptが糞すぎて未来が絶望的だろう。 WicketはJavaコンポーネントにJavascript自動生成させることで隠蔽し、 Javascriptを開発者から少しでも消し去ろうとした素晴らしいＦＷだった。 Javascriptフレームワークが乱立する現状とは逆の立場で流行らなかったが。 605 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:58:25.30 ] >>591 > どうもネイティブアプリ化を睨んでいるみたいで、 うちじゃ最初のターゲットがスマホアプリだけってケースが増えてる 先週ローンチしたサービスもそう（Webサイトはあるが静的コンテンツのみ） だからブラウザ対応する場合も同じAPI叩くだけでやりたいって意見は強いね SEO担当部署は抵抗してるが、検索サイトからの流入どころかブラウザで アクセスする人が激減してるのが現実（もちろんサービスによるだろう） LINEの成功もあってブラウザ対応はいらないってケースも増えそう 606 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 10:07:04.86 ] >>591 クライアントJSのMVCフレームワークが乱立してるわけだけど、 世界的には一番話題になってそうでリッチなAngularJSよりも、 日本じゃシンプルなBackbone.jsが人気あるように見えるのは、 JSFとStrutsを見てるようで興味深いw 607 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 10:22:53.57 ] >>606 apachcommons的なのなんて乱立なんてもんじゃない 手軽環境で誰でも書けるしハブとかあるからゴミが多くてフルパックじゃないとスタンダードになりえない 馬鹿でも書けるから調べて類似見つけて拡張依頼やコミッタ申請なんて事も少ない アンドロマーケットと一緒 608 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 11:33:00.31 ] XML+XSLTが攻守最強だな リッチクライアントでもブラウザでも行ける 609 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 11:34:57.01 ] もうそういうのやめてくれ ネイティブが一番いい。 610 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 16:34:25.16 ] とりあえずJAX-RSに関してはあまり否定的な意見は出てこないな。 611 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:01:52.60 ] 評価保留って感じじゃないの、2.0になってから本番な感じだし 612 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:08:36.83 ] JAX-RSの否定ではないが、各実装固有の機能を使わないと微妙、っという点は多々ある。 613 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:35:44.41 ] JAX-RSに限らないんだけど、JSRと実装とか馬鹿な事はさっさとやめて、今ある各実装の良いとこどりしたMVC機能も持った単一の実装を作ってよ。 そしたらSpring MVCから乗り換えるのに。 615 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:45:35.77 ] サーバーサイドはvalidation等のセキュリティ関連と、 データベースだけ残るだろ あとは全部クライアントサイドに行く それにサーバーサイドもjavaがやってる部分はnode.jsに置き換わるよ 616 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:48:56.77 ] ないない。Javaが持つ膨大なライブラリをカバーするのに何年かかんだよ 617 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:51:23.43 ] もう既にカバーしてるし、できないこともたくさんできてしまってる 618 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:53:08.10 ] 釣る気満々のレスに速攻で釣られるなよ 619 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:55:43.89 ] >>615 またJS信者湧いてるのかよ 620 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:59:31.13 ] node.jsなんてlibuvだけだろ 621 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 01:08:38.35 ] ここ見てオシッコちびるなよ？ www.nodecloud.org/ 622 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 07:24:36.04 ] Javascript云々のくだらない流れで過疎ったぞ 623 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:27:17.03 ] 【超速報】 Java8、仮想マシンに.NET/Mono採用検討開始　−　プログラミング界に激震 engawa.2ch.net/test/read.cgi/poverty/1365643043/ 624 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:43:32.25 ] Mono、のちのちMS.netランタイムでjarが動くようになるなら Javaデスクトップアプリケーションにはありがたいなぁ。 625 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:49:37.28 ] でも .class → JVM → .NETランタイム(CLR)ということで、変換が二重になってパフォーマンスが悪い、 ということにはならないのかな。 626 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:52:56.26 ] 何事もネイティブが一番 627 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 12:21:34.13 ] IKVMはありえんよ、最悪の選択肢 628 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 17:51:08.92 ] 最良の選択肢はjavascript 629 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 19:46:00.52 ] マルチパラダイム対応が一番。 Java、Scala、Groovyを自在に混ぜて使えばよいし、それはさほど難しくない。 630 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 01:22:11.91 ] ScalaとかGroovyとかいらんよ Java周辺は勉強してもすぐ消えていくから信用ならない 631 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 01:57:44.58 ] ScalaやGroovyをちょっと勉強してみたら とてもそうは思えなくなる やっぱり利便性が全然違う 632 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 07:12:38.76 ] >>622 JS推してたうざいやつのせいだな >>623 Monoはまず品質をなんとかしてほしいわ MS純正版との互換性がなさすぎてMono版のASP.net MVCは 使いものにならなかった。 633 名前：デフォルトの名無しさん mailto:sage [2013/04/24(水) 21:18:24.48 ] Java8延期された Java 8 Delayed to 2014 by Ongoing Security Woes www.infoq.com/news/2013/04/Java_8_Delayed 634 名前：デフォルトの名無しさん mailto:sage [2013/04/26(金) 23:42:43.59 ] >>632 どうやったらlinuxServer＋ASP,netとかアホな構成を選べるのかわからんけど実務で使ってるアホいるんだぜ？ 635 名前：デフォルトの名無しさん mailto:sage [2013/04/27(土) 23:37:45.83 ] EE7がそろそろ？ 636 名前：デフォルトの名無しさん mailto:sage [2013/04/28(日) 23:31:36.49 ] JavaEE使いづらいよママン… 637 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 08:26:27.28 ] 使いづらいものをなんでわざわざ使おうとするの？、Mなの？ 638 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 09:28:07.82 ] >>637 フレームワークの選択権限俺じゃないんだよ・・・。 そりゃ俺ならSpringMVCかSASｔrutsにするよ…。 639 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:26:27.70 ] 上がアホだとどうしようもないよな 640 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:28:42.07 ] ﾌﾟｯ､バーカｗ 641 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 12:00:06.81 ] >>640 なんだこいつ 642 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 14:01:22.83 ] >>638 SpringもJavaEEつかってるんじゃないの？ 643 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 17:22:34.76 ] なに言ってんだおまえは…。 644 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 20:09:51.80 ] >>642 ・・・ 開発をSpringMVCでやるかSAStrutsでやるか 標準のJavaEEでやるか？っていう話だと言えばいいのか？ SpringMVCの中身の話ではない。 単に何で開発したいかと言うことだ。 645 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 20:25:40.36 ] >>644 SAStrutsなんて日本でしか使われてないやつでしょ？ 新規でそんなの使う意味がわからない 646 名前：デフォルトの名無しさん [2013/04/29(月) 20:29:28.26 ] dev.worksap.co.jp/Members/inoue_se/archives/38 JavaOne参加者は、JavaEE利用者とSpring利用者が半々くらいだったらしい。 JavaEEはJavaEE5以降でSpringを取り入れてきているとも書かれてる。 純正JavaEEでやる人がまた増えてきてるということじゃないの 647 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 17:20:11.87 ] >>645 世界で戦ってるわけでもあるまいが…。 648 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 17:53:07.34 ] Authentication/Authorizationには皆さん何使ってる？ 社内システム用にSpring Securityを使い始めたもののなんか微妙。 649 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 19:04:34.20 ] Spring使ってるけどSpring Securityは微妙。 認証・承認って、結局システム固有の要素が入ることがほとんどなので、自分はそこはいつも自前。 650 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 19:08:13.20 ] 今更SAStrutsを奨めもしないけど、海外でどうだからという話は無視して良いと思う。 禿とかがそういうdisりをしたりもするけど。 自分のニーズにあったものを選択するのが基本。 それに海外ではどうこういうなら、海外の人は細かい部分にルーズだ、みたいな話だってあるし。 それでJSFやJPA実装の細かい部分が微妙だったりとか。 651 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 20:26:41.12 ] さてJavaEE7きましたよ。 652 名前：デフォルトの名無しさん mailto:sage [2013/05/02(木) 13:40:33.64 ] >>651 どこにきたの？ www.oracle.com/technetwork/java/javaee/downloads/index.html 653 名前：デフォルトの名無しさん mailto:sage [2013/05/02(木) 14:39:16.33 ] https://blogs.oracle.com/theaquarium/entry/java_ee_7_platform_completes 654 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 10:39:23.30 ] >>650 細かい部分にルーズにしては、国産FWが少ないし Springに比べてS2Forumのアーティクルは少ねぇよなぁ ほんとに海外について知ってるつもり? 655 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 11:33:01.75 ] 良いものは海外でも流行る。 日本限定のマイナーなフレームワークなんかつかうと すぐにメンテ終了になってしまう 656 名前：650 mailto:sage [2013/05/10(金) 12:38:17.38 ] 俺は「世界ではJava EEが標準です(ｷﾘｯ」みたいな発言を真に受けたり引用したりするのはやめれというだけで。 別に国産FWが良いと思っているわけじゃないよん。 657 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 13:07:44.12 ] 俺が作ったフレームワークがどう考えても最高 658 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 09:13:44.19 ] >>656 何でやめなくちゃいけないんだ？ 事実は事実のまま捉えろよ 659 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 10:26:19.98 ] JavaEEは最高のフレームワークです(ｷﾘｯ ほかのフレームワークを使っている奴らは無知なだけのｶｽ 660 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 10:35:01.25 ] フレームワークがないと作れないやつって不幸だな 661 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 15:17:14.27 ] 標準って用語は多重定義されてるからな JavaEEが標準仕様なのは事実だしデファクト標準じゃないことも事実 662 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 15:41:42.22 ] 依存性管理はそろそろデジュール標準でいって欲しいな。 そんで依存性ツリーを持たないAntプロジェクトとか撲滅して欲しい。 現状リポジトリはほぼMavenリポジトリがデファクトで、依存性解決はMavenの他に ivyやGradle等といった複数の実装があるわけだけど、実装毎に微妙に解決した結果 が異なったりとか依存性の記法が異なるとかちょい勘弁。 って何時だよProject Jigsaw使えるようになるの。 663 名前：デフォルトの名無しさん mailto:sage [2013/05/17(金) 20:56:32.32 ] うちなんて未だにApache Ant + CVSだよ 今年の予定がSubversionの適用とか10年遅れてるわ 664 名前：デフォルトの名無しさん mailto:sage [2013/05/17(金) 21:51:50.52 ] もうSubversionはスキップしていいでしょw GitやMercurialにすればよいのに。 665 名前：デフォルトの名無しさん mailto:sage [2013/05/18(土) 01:26:59.84 ] >>663 昨年までEclipseとファイルコピーで何とかしてた俺よりましだな。 さすがに最近Git入れたけど。 666 名前：デフォルトの名無しさん mailto:sage [2013/05/20(月) 08:38:34.64 ] CVSと用語の使い方が似ているとか長く使われて実績があるって意味ではSubversionもありはありだけど、それ以外に取り柄が無いよなぁ 分散リポジトリは概念説明からスタートだからめんどくさいとかあるのかな 構成管理担当のスキル不足で使いこなせないなんて笑えない理由だったら笑うがw 667 名前：デフォルトの名無しさん mailto:sage [2013/05/20(月) 22:57:38.89 ] トラブルが起こらないという意味ではsubversionで十分かもな Mavenとかだと、やれプロキシの設定だの、レポジトリが無いだの、 新しく入ったメンバーが自分で設定できないだの、 依存性が解決できないだのと、問題がつきもの 668 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 04:14:23.88 ] 手動でインストールって何のことだ eclipseのフォルダごとコピーして終わりだわw 670 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 08:17:14.09 ] え、scalaやgradleなんて何から何までeclipseプラグインが用意してくれるし、 eclipseプラグインはローカルフォルダごとコピーすればついてくるがな 672 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [2013/05/22(水) 01:17:21.75 ] 複数人開発するならMavenで管理するがいいと思うけど、 1人身開発だとあんまり利便性がない気がする・・・。 まあ、一人で開発してる俺みたいなのは少数派なんだろうけど。 単に開発者いないだけだし。 674 名前：デフォルトの名無しさん mailto:sage [2013/05/22(水) 04:34:46.93 ] 一人で開発する場合も依存性管理は便利だけど。 ライブラリのパッケージを手動で落としてきて展開してJarをコピったり プロジェクトのビルドパスに登録したりとかもう今更。 Eclipseプラグインをupdateサイトからではなく手動でzip落としてきて インストールしたり、aptの類を使わずにtarballに固執する程度には 使わないのは勿体ないなぁと思う。 確かに凝ったビルドをし出すと俄然ややこしくなるしモジュールの切り分け などに頭を使うけど、その他の大多数の定型的なビルドに関してはMavenは すごく楽だと思う。 675 名前：デフォルトの名無しさん mailto:sage [2013/06/04(火) 23:22:07.93 ] Mavenはリポジトリ整理してくれ、マジで

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

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