【Java】 Java Web Application Framework 総合

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


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

1 名前：デフォルトの名無しさん [2012/06/03(日) 16:18:39.74 ]: Java用のWeb Application Frameworkについて語るスレッド

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

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

特徴の比較
en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features
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みたいな大規模向けフレームワークをベースに、
小規模システム向けのスケルトンソース・ジェネレータでも作ったほうが良いんじゃね？

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

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