Java Web Application Framework総合　ver2

■ このスレッドは過去ログ倉庫に格納されています
2013/07/21(日) NY:AN:NY.AN
Java用のWeb Application Frameworkについて語るスレッド

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

前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/

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

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features
2013/08/07(水) NY:AN:NY.AN
Java知っていれば学習コストはかなり低そうだからな〜 > Groovy
2013/08/07(水) NY:AN:NY.AN
>>40-41
Scalaもコンパイル遅いし大したことないよ
たいして人気もでてない
2013/08/07(水) NY:AN:NY.AN
>>40
Grailsだから流行ったフレームワークではなく、まず良く出来たフレームワークが
あって、それを使うことからGroovyを再発見した人も多いのでは。
RailsやPlay!もそうだよね。人気のあるフレームワークがその言語の新規ユーザを
増やす呼び水になっている。

フレームワークとしてはGrailsは良く出来ていると思う。でかいけどね。
2013/08/09(金) NY:AN:NY.AN
Glassfish3.1.22なんだけどj_security_checkで認証すると
認証前のリクエストがPOSTだった場合でも認証後に再びPOSTされるんだよな。
なんかChrome見ると302の後にChromeはちゃんとGETでアクセスしてるから
Glassfishが認証フィルタあたりで何かきもいことやってるんだろうけど
HttpServletRequest#login使った手組だとどうにも再現できん。
2013/08/10(土) NY:AN:NY.AN
HTTPの仕様上、302はメソッドを変えずにリダイレクトするのが正しい(前がPOSTなら後もPOST)
しかしほとんどのブラウザは常にGETでリダイレクトするのでHTTP 1.1で303と307が追加された
303は常にGETでリダイレクトする (現実の302と同じ)
307はメソッドを変えずにリダイレクトする (仕様上の302と同じ)

Glassfishは303を使ってるとか？
4746
垢版 |
2013/08/10(土) NY:AN:NY.AN
最後の一行間違った

Glassfishは307を使ってるとか？
2013/08/10(土) NY:AN:NY.AN
Glassfishは302を返してるよ。メジャーなブラウザは302にGETを返すらしい。
あとChromeは303にはGET、307には前回と同じメソッドとこちらはちゃんとしてくれる。

どうもGlassfishはj_security_checkの段階ではなく、
次のリクエストで認証してるみたい（Set-Cookieのタイミングがここ）
BASIC認証と動きを合わせるためにきもいことしてるんだろうなぁ

JBOSS ASとかも後で確認する
2013/08/10(土) NY:AN:NY.AN
きもいきもい言いすぎ
どうしたのってば
5045
垢版 |
2013/08/10(土) NY:AN:NY.AN
どうやらこの現象はTomcat側にmaxSavePostSizeってプロパティで設定できるらしいね
Glassfishはどうやって設定するのかまだ分からないけど、JBoss AS7.1.1は無効にしてるっぽい
2013/08/23(金) NY:AN:NY.AN
wicketはダメ？
2013/08/25(日) NY:AN:NY.AN
Viewをサーバ側で動的に生成する仕組みが
そもそもオワコンになってきてる気がする
MVCのMCだけサーバ側で担当してVはHTML5+JS+CSS3
連携はJSONかpjaxで。
2013/08/25(日) NY:AN:NY.AN
WPFはWebのページアプリの概念を取り込んだが
Webは逆にSDIアプリの概念にシフトし始めてるのかもな
2013/08/25(日) NY:AN:NY.AN
>>52
またそうやって「JSON返すのはサーバサイドFW不要論そのもの」
「その不要論を言いだすと、Java不要論になるしこのスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定」厨を煽る作戦ですね
2013/08/25(日) NY:AN:NY.AN
誰が一番煽っているんだか
2013/08/25(日) NY:AN:NY.AN
(・ω<) ﾃﾍﾍﾟﾛ
2013/08/25(日) NY:AN:NY.AN
サーバ側はJSONだけを返せればそれで良い、…そう思っていた時期が、私にもありました(´・ω・`)
2013/08/25(日) NY:AN:NY.AN
HTMLフラグメントをサーバから非同期で返す
pjaxてのがあるのか。よさげだな。
2013/08/25(日) NY:AN:NY.AN
狭義(jQueryプラグイン)のPjaxは何年か前に話題になっただけでオワコン臭
2013/08/25(日) NY:AN:NY.AN
よくわからんがInnerHTMLに直接代入できるテキストをくれる感じか
2013/08/25(日) NY:AN:NY.AN
javascriptでJSONパースしてはめてくって処理が要らなくなるのはええね
2013/08/26(月) NY:AN:NY.AN
pjaxは結局動的にHTMLフラグメントを生成するのに従来同様にJSPの類を使う事になる。
なので静的なページが中心で一部だけ動的にしたい場合など無理にJSONでやりとりするより
楽だし、動的でかつクローラブルでハイパーリンク可能にするのもJSON使う場合より手間は
少ない。
2013/08/26(月) NY:AN:NY.AN
>>57
一度挑戦したが結局挫折したわー。
最近のサーバーの性能だとよっぽど大規模なユーザー数のアプリじゃないと
そこまでするメリットがない上に実例がなくてだるい。
2013/08/26(月) NY:AN:NY.AN
JSONで済む割合はサイト毎に全然違うしょ
スマホネイティブアプリ向けサイト＞＞＞＞シングルページアプリ向けサイト＞＞＞＞旧来的なサイト
2013/08/26(月) NY:AN:NY.AN
つーかね、HTMLのフラグメント返した方が更新が綺麗だったり、仕組みが単純だったり、JSONよりそっちの方が良いや、ってなっちゃったりもして。
2013/08/26(月) NY:AN:NY.AN
サーバ側でやる処理と、クライアント側でやる処理を
どこで区切るかってだけの話だよね

スマホ向けWebアプリだと、意外とJSONのほうが小回り利いたりする
2013/08/27(火) NY:AN:NY.AN
HTMLのフラグメントっていうのは、partial view というか、部分的なHTMLのこと？
(<div> のなかみだけ、とか)

JS で innerHTML でさしかえる用、とか。
2013/08/28(水) NY:AN:NY.AN
そんなイメージ
jQuery使うようになってからは素のJS書かなくなって
innerHTMLとかもう遠い昔
2013/08/29(木) NY:AN:NY.AN
サーバサイドの人がJSP書きながらちょっとjQuery使うだけならPjaxいいかもね
クライアントサイドの人はBackboneやAngular、つまりテンプレートエンジンや
データバインディング使うから無用だけど
2013/08/29(木) NY:AN:NY.AN
TwitterがHTMLのフラグメントを使う様にしたとかいう話ってなかったっけ？
あれって、どういう理由でそうなったの？
2013/08/29(木) NY:AN:NY.AN
初回表示が遅くなった対策に一発目はHTML返すよう戻したって話？
表示後は今でもJSON(コンテントタイプはtest/javascriptでgzip圧縮されてる)でタイムライン更新してる
2013/08/29(木) NY:AN:NY.AN
デザインサイドだとどの程度ライブラリに依存するのがトレンドなんだい？
jQuery + Normalize.css あたりで頑張るのか、Twitter Boostrapとか使うのか
2013/08/30(金) NY:AN:NY.AN
>一発目はHTML返す
HTMLに<script>タグで囲んだJSON一緒にくっつけて
返すとかはよくやるな。リクエスト減らす目的で。

Boostrapは便利なんだけど、アレ使うとLook&Feelがまんま
Boostrapテイストになっちゃうんで、デザインちゃんと
考えてるプロジェクトだと意外と使わない。
CSSの学習素材としては素晴らしいが。
HTML5-Boilerplate + jQuery + 独自CSSって感じかな。
Normalize.cssも使う。
2013/09/09(月) 05:42:14.14
クライアントサイドでもサーバーサイドでもどちらでも良いけれども、JSONとか
使うREST APIを開発するにあたって認証はどの方式を使っている?
2013/09/09(月) 10:53:11.74
>>74
サーバサイドの REST API の場合は、クライアントがブラウザとは限らないため、
完全なステートレスでの利用を前提にハンドシェイク後にキーを発行して、
クライアントは受け取ったキーを常にパラメータとして付与しながら API を叩く
仕様にしてる。

一旦キーが発行された後は、サーバ側では、渡されたキーと接続先アドレスを
使って認証の判定をしている。自分のシステムの場合は、複数のツール/システム群から
順に連携して叩かれる事もありうるから user-agent の判定とかはあえて行っていない。

あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
使われていないキーは一定期間が経過したらどんどん失効（削除）させてる。
実運用では律儀に終了処理なんて呼んでくれない奴の方が多いからね。

誰もが使えてもいい公共性のある API なら、そもそもそんな仕掛けも要らないだろうけれど、
緩い個体の識別から、サーバ側に登録された ID が持つ権限内容との紐付けをした上での
識別までハンドシェイク部分の作り方次第で自由に切り替えられるから、自分が最近作った
システムは大枠としてはどれもそういう作りにしてるかな？
2013/09/09(月) 11:22:00.96
>>75
> サーバ側では、渡されたキーと接続先アドレスを使って認証の判定をしている

接続元IPアドレスを認証に使うのは、IPアドレスの偽装もあり得るので危険なのでは？

と思ったが、 >>75 さんの環境がイントラ内とかだったら、わりきってそれもありかな、と思った。
(イントラネット内で、ちゃんとIPアドレスや、それがどんなサーバなりスイッチか、などが管理されていれば)
2013/09/09(月) 12:57:39.68
IPアドレスは保険みたいなもんで認証の主はキーでしょ？
2013/09/09(月) 13:53:43.53
AWS方式でリクエストをHMACで署名。
2013/09/09(月) 16:01:47.48
巷のAPIはSSLを使った上でAPI Keyでリクエスト署名ってパターンが多い気がする。
うちもそうしている。
HTTP Method name + Request Path + Timestamp + bodyからHMAC-SHA1計算して
HTTPヘッダに埋め込む。

ただこれだとクライアントの開発時にAPIをテスト目的でcurlとかで叩くことが
面倒なので、同じキーでBasic認証も出来るようにしている。
2013/09/09(月) 23:53:31.08
SSL+BASICじゃダメなの？
2013/09/10(火) 00:51:23.89
サーバではコミットしたけどクライアントで反映失敗とか
セッションハイジャックをかんがえると
OTPとはいかないまでもシリアル値くらいないとダメな場合もある。
2013/09/10(火) 04:06:22.73
>>80
認証だけなら良いと思うよ。SSLをかましているのであれば。

ただSSL経由とはいえ秘密鍵を平文で投げたくない、かつステートレスにしたい
のであれば自ずとリクエストと秘密鍵から計算したハッシュ値で署名するという
解決策にたどり着く。
仮にリクエストがのぞき見されても秘密鍵は漏れないし、ハッシュ値を計算する
データの中にタイムスタンプを含めておけばリプレイ攻撃にも多少は強くなる。
2013/09/10(火) 07:09:16.75
なるほど、勉強になります。
2013/09/10(火) 18:00:55.33
>>82
>>75と同じ人だよね？
>>75じゃサーバからクライアントにキーを渡すことになってるけど、それが秘密鍵？
だとしたらレスポンスのぞき見されたら秘密鍵漏れない？
「SSL経由とはいえ秘密鍵を平文で投げたくない」になってるのか疑問なんだが
さらに、「かつステートレスにしたい」と続いてるが>>75の以下を見るにステートレスに
なってなくね？

> あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
2013/09/10(火) 19:20:04.33
>>84
違う人です。すまん。
2013/09/10(火) 20:34:00.07
>>85
別人か、正直すまんかった
それでクライアントの秘密鍵ってどう扱ってる？
サーバから渡すんじゃ「SSL経由とはいえ秘密鍵を平文で投げたくない」は難しそうなんだが
クライアントがイントラ内の別サーバなら楽だけどJSとかだと…
2013/09/10(火) 21:25:30.82
>>86
API Keyはセッション毎の使い捨てではなく永続的なものね。
うちのシステムでは顧客、というかデベロッパにはまずユーザ登録をしてもらって、あとは
Webブラウザから管理ダッシュボードにログインしてAPI Keyを好きなだけ生成したり既存の
キーを無効にしたり出来る。
秘密鍵の文字列はまぁ、管理ダッシュボードのWeb画面からコピペw
でもAPI Keyを使った認証を提供しているサービスはこのやり方が多いと思う。
2013/09/18(水) 22:43:53.60
画面をさくさくっと作っていきたいんですが、なんかいいフレームワーク無いですかー？
2013/09/29(日) 11:59:59.03
>>88
ASP.NETがおすすめ
2013/09/29(日) 17:43:57.35
貴方が書き込んだのはこの銀のループするスレですか?
それともこちらの金の過疎るスレですか?
2013/09/30(月) 08:36:15.59
>>88
好きなもの使いなはれ
ttp://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks
2013/10/01(火) 14:51:21.87
Grails2.3か。
新機能はともかくivyを捨ててMavenと同じ依存性解決エンジンを使うように
なるのが嬉しいな。SNAPSHOTやclassifier周りのタコな動作がようやく解決。
93デフォルトの名無しさん
垢版 |
2013/10/08(火) 21:16:15.34
Struts2もSpring2もまだ現役だというのにSeasar2ときたら…
2013/10/09(水) 22:00:27.05
やっぱり日本産は駄目だな！
2013/10/09(水) 22:03:15.11
ひとめぼれ、うまー
2013/10/09(水) 23:27:12.84
>>93
うちSeasar2バリバリ現役です・・・。
Spring2はいいとして、Struts2なんて欠陥品だろ。
2013/10/09(水) 23:31:27.53
>>95
時代は今、コシヒカリですよ！
http://i.imgur.com/sP8Stc9.jpg
2013/10/10(木) 00:42:32.12
そこでStruts1.2が現役な私の会社の出番ですよ。
2013/10/13(日) 16:00:34.45
>>93
今更GWTに手を出そうとしてる人でしょ？
2013/10/13(日) 16:12:20.17
>>94
そのとおり
SpringはRod Johnson抜けても続いてる
個人に依存しないビジネスとして成立してるわけ
日本はいつまでも個人のモチベーション頼み
そのくせ応援しないですぐdisる
OSSで身を立てるにはこの国は地獄だぜヒャッハー
2013/10/13(日) 18:14:47.77
>そのくせ応援しないですぐdisる

スマホアプリのストアのレビュー見ててもそう感じるな。
AppStore、GooglePlayともに。
無料アプリなのに、ちょっとバグがあるとか自分の端末では
動かないってだけで、鬼の首を取ったようなdisりかた。

スマホ向けアプリ作るのは海外向けがいいな。
国内市場向けに作っても旨みは少ない。
2013/11/08(金) 16:41:59.01
某ブログでそろそろSeasarは終わりでいいよね、JavaEEも悪くないという話をやっているけど
日本でSpring等々ではなく和製FWが広まって萎んで今微妙な状況になっているのはつくづく
ドキュメントやコミュニティの言葉の壁の問題なのだなぁと思う。
2013/11/08(金) 19:29:03.36
>>102
盛り上がったのは普通にseasarの出来がよかったからだし、衰退したのは開発ストップしたからだろ
2013/11/08(金) 22:11:18.14
SpringMVCでweb開発してるけど、いったん設計と実装の仕組み整えちゃえば
あとは仕様が増えても基本的に、コントローラ、インタフェース、サービス
周りのコピーでガンガンいけるから、自分的にはSpring一択だな。
2013/11/09(土) 02:04:11.76
>>102
クライアント側の新しい機能ならほしいかもしれないが、
サーバー側の開発って別にそんな新しい機能いらないんじゃないかねってのはある。
あえて新しくする必要がないというと叩かれるのかもしれんがそんな感じ。
2013/11/09(土) 09:09:47.92
Struts1.2＋内製フレームワークをJava5で動かしている弊社が最強です。
2013/11/09(土) 09:18:39.71
webアプリだとサーバ側はたしかに、だいたいやること決まってきてるしな。
モデル側処理とか認証周りとかバッチとかサブシステム連携とかviewに必要な情報の生成くらい。

フロント側は最近はブラウザの表現力と処理能力上がってるから
JSPとかのサーバーサイドテンプレート使うよりは、jQuery使ったり
Backbone.jsやAngulerJSみたいなフロントエンドMVC使うケース増えてる。
サーバーサイドとはRESTでやりとりできればいいし。
2013/11/09(土) 12:10:01.79
>>102-103
開発を継続する人材が集まらないのは言葉の壁の問題といえるな
2013/11/22(金) 03:31:52.24
Vaadinってどうなの？
2013/11/22(金) 13:52:04.12
>>104
SpringMVC関係なくね？
2013/11/26(火) 23:06:10.99
>>109
それ、俺も知りたい
vaadin日本語ドキュメント少なすぎて涙出るよねー

皆さんは画面をどうやって作ってますか？使っているフレームワークを教えて頂きたいのですが
デザイナーに丸投げしているって回答以外にあったら教えて頂きたい
GWTをここ数ヶ月勉強してみたのですが、GWTは微妙な気がします
2013/11/29(金) 23:28:49.51
自分の場合、今は画面はサーバサイドで作らなくなった。
HTML5+CSS3であれこれやってる。

こういう画面デザインの事例見てると、綺麗に作るには
画面は画面でちゃんと作りたくなる。
http://www.pinterest.com/_f7/gui-great-ui-collection/
http://pttrns.com/
http://www.uiparade.com/
2013/11/30(土) 06:16:21.11
>>111
RIA系の開発プロジェクトでGWTを使った経験があるけれども、メリットはGUIロジックもJavaで
書けるのとサーバ側のAPIを叩く非同期RPCの仕組みの出来が秀逸なこと。
逆にこの二つが無ければ単に重くて面倒なフレームワーク。基本的にJavaの開発者がGUIも作る
ケースでないとあまり意味が無いと思うし、RPCを叩かず静的なページ間の遷移だけのアプリ
であれば他のフレームワークを使った方が楽だと思う。
例えばSwing+AppletとかFlexとかで作っていたRIAをプラグインレスのDHTMLベースに以降する
場合などは開発者のスキルも比較的生かしやすいのでよい候補になると思う。ただ率直な感情
としてはこの領域、今現在もFlex+MXML+ActionScript3の出来の良さは頭一つ飛び抜けていると
思うんだよね・・・フェードアウトしつつあるのがつくづく残念。

今は専らGrails。
画面云々以前に認証やセッション管理やフィルタやロギングといったアプリを作るのに必要な
裏側の機能が手作りしないでも全部入っているフルスタックなので。
Jerseyも使うけど結局は上記のものが必要になってくるので生Jerseyを使うことは無いかな。
Grailsに組み込んで使う。
RESTであってもAJAX用途であればステートレスに拘らずセッション使った方が楽だしねw
114111
垢版 |
2013/12/01(日) 11:15:32.04
>>112
そんな感じのリッチな画面を作りたいんです。

画面周りを手書きするのはよくあることなので我慢できますが、
javascriptを手動でデバッグするのだけは避けたいなと思いました。だから、GWTを勉強してみました。
結果、GWTは遅すぎてSSDマシンじゃないと厳しいってことがわかりました。
会社では自分の気分でマシンを変更できないので、GWTを使うのは難しいという結論になりました。

>>113
普段、Flexを使って開発しているので、Flexライクなjava frameworkが欲しいなーと思いました。
Flexは非同期処理基本だし、画面周りの制御が難しい(と言うより、処理速度が遅い）のがダメなところですよね。
javafxはflexのパクリだと思うのですが、javafxのweb版みたいなのがあればいいですよね
JSF勉強してみようかなって思いました
2013/12/02(月) 12:33:50.80
何も分かってないのが良く分かった
2013/12/03(火) 23:01:57.91
>>115
どこらへんが
2013/12/04(水) 22:23:08.22
>>114
サーバー側の仕組みに比重を置いてリッチなUI/UXを実現するのは不可能だよ。
見栄えについてはCSS3必須。その見栄えに命を吹き込むのがJavaScript。
サーバーサイドでできる範囲は、HTML5+CSS3+JSが育って実をつけるための
大地と水と肥料を用意すること。

GWTがどうとかって話じゃないことだけは確か。
2013/12/05(木) 00:11:39.37
>>117
GWTについて知らないでしょ。
知っていればサーバーサイドが云々とか言うコメントは出ない。
2013/12/05(木) 02:18:51.42
>>118
あー、すまんかった。
GAEと勘違いしてた。
2013/12/05(木) 11:24:55.81
GWTって今でもメンテされてるの?

GWTが楽ってのは聞いたことがあるけど、結局ブラウザ側のUI/UXを作り込むなら、
jQueryとかを直接使った方がいいと思っているのだけど・・・
2013/12/05(木) 16:20:11.52
jQuery を直接使って特に問題が起こらないならば、それで実現すれば良いのでは？

GWT などは Java だけで RIA がサポートできる所とかがポイントなわけですから、
（自分は使ったことないからあれですけれど）開発対象、人員、保守性、工期とか
色々踏まえて考えれば、状況次第ではアリな気がしています。

逆に凝った UI が要らなければ、旧来型の使い慣れたフレームワークや
テンプレートエンジンの方が開発も運用も過去資産も含めた実績があるので
トータルで安定するでしょうし、部分的に凝った UI が必要なら、そこだけを
重点的に対策した方が無難だと考えてしまいますね。
2013/12/05(木) 22:11:40.25
GWTはクオリティの高いUI/UX作るにはいろいろ役不足なイメージしかないな。
jQueryとその周辺プラグインのほうが、世界も広いし圧倒的に充実してるのと
Look&Feelに関しては、CSS3と各種CSSフレームワークで大抵のことはこなせる。

GWT採用しちゃうと、どうしてもGoogle風味から抜けられなくなるでしょ。
2013/12/06(金) 06:46:40.59
GWTとjQueryはちょっとレイヤーが違うので比較は出来ないかな。

jQueryはイベント周りの昨日とかjQuery UIはあるけれども総体としてはDOMの
直接操作を基本とした低水準(悪い意味じゃ無いよ)のライブラリ。
レイアウトや装飾はHTMLベースで記述して、そこにインタラクションをjQuery
で装飾していくイメージ。

他方でGWTは自身のレイアウト記述とウィジェットライブラリを持った一つ上の
レイヤーのツールキット。基本的には用意された部品を組み合わせて画面を
作る。

スタイリッシュで凝ったUIは作りにくいけれども、事務事務したおっさんくさい
UIを手っ取り早く作るのには結構便利 > GWT
2013/12/06(金) 11:46:30.47
>>123
これだけ読むとGWTはJSFと競合しそう
2013/12/07(土) 23:22:13.02
JSFってすごい難しいね
全然分からないや
2013/12/08(日) 03:06:58.87
FreeMakerがいい感じ
2013/12/08(日) 08:12:33.17
テンプレートとしてはGSPはええで。
2013/12/08(日) 16:23:40.46
GSPって、今でもGrails縛りなん？
129デフォルトの名無しさん
垢版 |
2013/12/08(日) 22:34:18.01
JavaSEとJavaEEの違いで、SEにはJDBCが入っているが、EEには入っていない。
これは、EEに含まれているEJBの中にJDBCの機能が入っているからだと、納得してよいでしょうか？
2013/12/08(日) 22:57:00.51
JavaEEはJavaSEを含んでるから
131デフォルトの名無しさん
垢版 |
2013/12/08(日) 23:02:22.74
>>130
なるほど。ありがとうございます。
132デフォルトの名無しさん
垢版 |
2013/12/08(日) 23:09:42.71
中小企業の現行システム（旧来のクライアントサーバーシステム）を
Webシステム化するのですが、JavaEE＋JSF＋？・・・を考えています。
しかし、JavaEEは、中小企業レベルでは重いかなと心配です。
やはり、JavaSE + Strus2 + ・・・とかで、行うべきでしょうか？

サーバーのハード機能が良くなっているのでJavaEEでも問題ないでしょうか？
2013/12/08(日) 23:15:42.24
一番いいのはASP.NETだけどJavaじゃないとだめなの？
134デフォルトの名無しさん
垢版 |
2013/12/08(日) 23:20:38.05
>>133
元請けの中小SIerが、Javaを希望してきているのです。
135デフォルトの名無しさん
垢版 |
2013/12/08(日) 23:22:54.72
あー、コレ失敗するパターンやわ。
2013/12/08(日) 23:26:57.59
言語だけ指定されたとしたら、その元請は馬鹿だなｗ
137デフォルトの名無しさん
垢版 |
2013/12/08(日) 23:34:10.39
>>135,>>136
Javaのシステムを他にも横展開したいようです。
それと、.NET系はコストが掛かるのがネックみたいです。
2013/12/09(月) 02:38:16.30
>>132
中小企業でSIerに丸投げするレベルならJavaはやめたほうがいい
Javaには開発生産性の高いフレームワークがないから、
開発のコストが高くつく。
一番高いコストはライセンス料金ではなくて人件費だよ

絶対にASP.netがベストだと思うよ
Windows認証使わずにベーシック認証を使うようにすれば
クライアントアクセスライセンスも要らない。
データベースもMySQLなどのオープンソースを使えばいい。
Windows Server(IIS)のライセンスだけならASP.netは安いものだよ。

>>137
.NETが高いとか言ってるようではそのSIerのレベルは怪しい。
SIerはJava以外はよくわかってない人ばかりなんだと思う。
そいつらの本音はJavaの知識と経験を使いまわしたいだけだよ
2013/12/09(月) 02:55:38.46
既にStrutの蓄積があるならともかく今から始めるなら普通にJavaEEかSpringMVCで
良いんじゃね?

元請けがJavaの経験あるなら彼らがそれを使い回すのは普通に合理的判断だしそこ
に.Net提案したところで干されるだけでしょ。
2013/12/09(月) 02:59:40.78
>>138
Windows認証とベーシック認証を比べる人にこの分野のアドバイスはあまり聞きたくないと思う。
2013/12/09(月) 03:16:26.31
>>140
何がおかしい？
認証方法でASP.netのトータルのライセンス料金が
大きく変わるんだから触れるのは当然だろう
Windowsの認証を使わなければ安くなる

あんたこそライセンスなにも知らないんじゃないか
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況