Java Spring Frameworkを語るスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。
語るべし。
0582デフォルトの名無しさん
2005/11/13(日) 16:09:48今から外出しないといけなくなった
とりあえずどんな実装をしていくかという
癖みたいなものはわかった。
出たついでに本屋にでも寄って理論を立ち読みしてくるわ
0583デフォルトの名無しさん
2005/11/13(日) 18:13:330584デフォルトの名無しさん
2005/11/13(日) 22:40:28理論読んでくるの忘れたから、検索するわ
あとで
0585デフォルトの名無しさん
2005/11/17(木) 20:48:050586デフォルトの名無しさん
2005/11/28(月) 11:55:560587デフォルトの名無しさん
2005/11/28(月) 12:00:14DIスレもSeasarスレも活気ないしな。
0588デフォルトの名無しさん
2005/11/28(月) 12:06:55言語レベルでの制約によるメリットが一部損なうことや、
リファクタリングがかなりし難くなるところがやはり気に食わないな。
0589デフォルトの名無しさん
2005/11/28(月) 12:33:48SetterInjectionとFactoryでいいけどさ。
AOPと親和力が高いのが魅力的だよね。
抜け出せない。
遅いのに。
0590デフォルトの名無しさん
2005/11/28(月) 13:15:500591デフォルトの名無しさん
2005/11/28(月) 13:18:05てのを受けて試しにSpring触って第一印象が>>577ってパターンが結構多い気がするな。
0592デフォルトの名無しさん
2005/11/28(月) 20:17:430593デフォルトの名無しさん
2005/11/28(月) 21:17:10何が一番使われてんの？
0594デフォルトの名無しさん
2005/11/28(月) 21:21:10モデルだった
0595デフォルトの名無しさん
2005/11/28(月) 22:32:06Strutsとは全くかぶってないので、StrutsをどうやきなおしてもSpringにならない・・・
0596デフォルトの名無しさん
2005/11/28(月) 22:33:25フロントコントローラ、まんまStrutsなんだが。
0597デフォルトの名無しさん
2005/11/29(火) 00:09:53XMLからクラスが生成できるだけ？
0598デフォルトの名無しさん
2005/11/29(火) 00:22:41次の次ぐらいのStrutsはWebWorkになるそうだぞ。
0599デフォルトの名無しさん
2005/11/29(火) 00:25:000600デフォルトの名無しさん
2005/11/29(火) 00:34:16ほれ。
ttp://www.mail-archive.com/dev%40struts.apache.org/msg13815.html
0601デフォルトの名無しさん
2005/11/29(火) 00:37:30ttp://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html
スレ違い。失礼。
0602デフォルトの名無しさん
2005/11/29(火) 00:42:46えーーーー。
なんかすっげー違和感・・・。
0603デフォルトの名無しさん
2005/11/29(火) 12:19:40なるか？
設定ファイル書き直しの手間が云々って意味？
0604デフォルトの名無しさん
2005/12/01(木) 20:40:22DelegatingIntroductionInterceptor の使い方がやっと分かった。
AOPヽ(´ー｀)ノﾏﾝｾｰ
0605デフォルトの名無しさん
2005/12/06(火) 10:25:250606デフォルトの名無しさん
2005/12/08(木) 08:03:220607デフォルトの名無しさん
2005/12/08(木) 08:41:400608デフォルトの名無しさん
2005/12/08(木) 09:35:460609デフォルトの名無しさん
2005/12/10(土) 23:50:35SpringのHello Worldでどのサイトをみても
これ以上のことがどこも書いていないのですが
どういった点が優れているのでしょうか？
いまいちこのフレームワークが他よりも優れいているというメリットが見えないのですが
また具体的に何が得意とかあるのでしょうか？
0610デフォルトの名無しさん
2005/12/11(日) 01:16:390611デフォルトの名無しさん
2005/12/11(日) 15:13:00全面的に使ってたりする？
0612デフォルトの名無しさん
2005/12/11(日) 15:47:190613デフォルトの名無しさん
2005/12/11(日) 15:49:33大根としてつかうだけならどこか１部だけでもOKでは。
0614デフォルトの名無しさん
2005/12/11(日) 16:10:46たとえばStruts使う場合だと、すべてのActionをSpringに委譲するし。
0615デフォルトの名無しさん
2005/12/11(日) 16:14:12具象オブジェクトの生成部分を切り出す単位って、そこしかないわけか
オイ？ﾓｯﾄどこにでもあるでしょうがよ。
0616デフォルトの名無しさん
2005/12/11(日) 16:20:570618デフォルトの名無しさん
2005/12/11(日) 17:11:400619デフォルトの名無しさん
2005/12/11(日) 17:54:34だから、逆に絶対やっといても損はない気がするけどさ。
0620デフォルトの名無しさん
2005/12/12(月) 10:29:59ただ単に便利なツールでいいのだと思うけど。
便利なBeanFactory、それで充分だよ。
おまけで付いてくる付属品はけっこういいよ。
AOPもそうだし、ORMやらmailやらが楽チンに扱えるのも嬉しい。
S2でもSpringでもどっちでもいいけど、これがない世界には戻りたくないね。
EJB3があれば不要という話もあるね、GabinKingが主張しているように。
でもSpringを通してEJB3を使った方がより簡単、そういう機能が出てくるって予想してる。
0621デフォルトの名無しさん
2005/12/12(月) 10:36:160622デフォルトの名無しさん
2005/12/12(月) 10:36:44EJB3を使いこなせるとは思えない。Annotationの裏で
起こっている出来事を多少は理解している必要はある、って
認識の元の考えだけど。
0623デフォルトの名無しさん
2005/12/12(月) 10:58:46EJB3でも、単にORマッピングだという認識で、なんだか裏側で勝手に結びつけてくれるという感じになるんじゃないかな。
0624デフォルトの名無しさん
2005/12/12(月) 16:27:03Java ソースにアノテーション埋め込むのと
設定ファイルに外出しされてるのと
どっちが疎結合か考えたら
EJB3 は退化してるとしか思えない。
0625デフォルトの名無しさん
2005/12/12(月) 18:56:400626デフォルトの名無しさん
2005/12/12(月) 19:05:38「疎結合のためにアノテーションを排除して、なんの意味がある？」
0627デフォルトの名無しさん
2005/12/12(月) 20:42:36おまいらどうせ来年にはAnnotationに文句垂れてると思うよ、飽きっぽいから。
0628デフォルトの名無しさん
2005/12/12(月) 21:45:25いや、それはそれで良いんじゃねぇの？
不満がなければ技術革新なんてねぇさ。
0629デフォルトの名無しさん
2005/12/12(月) 21:58:430630デフォルトの名無しさん
2005/12/12(月) 22:25:06WebApplicationContextを使って云々みたいな。。。
0631デフォルトの名無しさん
2005/12/12(月) 22:28:530632デフォルトの名無しさん
2005/12/12(月) 22:53:59XDocletとは違って定数を指定できるし、引数の型チェックも出来る
0633デフォルトの名無しさん
2005/12/13(火) 02:02:540634デフォルトの名無しさん
2005/12/13(火) 09:39:22ほらよ
http://www-06.ibm.com/jp/software/websphere/developer/j2ee/lightweight/
http://www5f.biglobe.ne.jp/~webtest/myapptutorial/index.html
https://appfuse.dev.java.net/
https://equinox.dev.java.net/
勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを
作ってるヤツ。（Facadeかけてるやつ）
とりあえずIBMのヤツを熟読しろ。
0635教えてください
2005/12/13(火) 21:35:54どこが間違ってるのかご指南ください。
問題のＨＰ http://urei.ojaru.jp/top.htm
フレームを使用してますが
Ｉｍａｇｅｓ→***のリンク→左使用不可ページ となってます。
*** のページ 左使用不可ページ直リン防止script
左使用不可ページ 左使用不可script
このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ
もうどうしていいのか分りません
0636デフォルトの名無しさん
2005/12/13(火) 22:01:210637デフォルトの名無しさん
2005/12/14(水) 10:05:470638デフォルトの名無しさん
2005/12/16(金) 02:08:32同じ？
0639デフォルトの名無しさん
2005/12/16(金) 13:48:47Spring.NETは基本的なDI・AOPの機能は既に実装済み。
DB、トランザクション、WEB等の機能はまだ開発中みたいだな。
だけど、正直.NETでDIは使う気にならないな。
0640デフォルトの名無しさん
2005/12/17(土) 13:07:47何故？
0641デフォルトの名無しさん
2005/12/24(土) 12:10:09このクラスのテストケースをstrutstestcaseを使って書こうとした時に
Actionから呼び出すBeanを変えてテストケース書きたい場合
Bean定義のXMLを変えるしか方法がない？
テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、
0642デフォルトの名無しさん
2005/12/25(日) 01:54:240643デフォルトの名無しさん
2005/12/26(月) 01:34:51Spring入れたほうが動作は安定して早くなりました。
0644デフォルトの名無しさん
2005/12/26(月) 11:56:02その方法がわからないんだよう
ポインタなぞあったら教えてぎぶみー
0645デフォルトの名無しさん
2005/12/28(水) 07:47:520646デフォルトの名無しさん
2005/12/28(水) 07:55:33セッターインジェクションの場合
setXxx(value);
フィールドインジェクションの場合
xxx = value;
で注入できますｗ
0647デフォルトの名無しさん
2005/12/28(水) 14:12:36設定ファイルがXML Schemaベースになってる。
0648デフォルトの名無しさん
2005/12/29(木) 12:31:25* Simplified, extensible XML configuration
* Powerful new Spring AOP features and AspectJ 5 integration
* Asynchronous JMS facilities enabling message-driven POJOs
* Spring Portlet MVC, a MVC framework for JSR-168 Portlets
* ... and much, much more
これって設定ファイルが結構変わるのかな？
個人的には三番目がようやくと言った感じ。
JmsTemplate はいろいろ思うように行かなくて
(非同期受信なし、リソースを開放するタイミングが制御できないなど)
結局新たに作成したものを使った。
JndiTemplate があればどうにかなった。
0649デフォルトの名無しさん
2006/01/08(日) 02:38:17パフォーマンス＆拡張性が要求される現場では役に立たない
方々乙かれさまです。
0650デフォルトの名無しさん
2006/01/08(日) 03:19:200651デフォルトの名無しさん
2006/01/08(日) 03:40:270652デフォルトの名無しさん
2006/01/10(火) 15:18:00本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。
さすがに起動時だけは遅いが、一度起動してしまえば
速度が気になったことはないな。
拡張性については具体的な例を挙げて欲しいな。
どういう要求が出た時にどういう対応をしたのかを。
0653デフォルトの名無しさん
2006/01/11(水) 03:07:47使うにはどうすればいいかご存じの方はいませんか?
getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。
getSession()して自分で処理するしかないかな。
Spring 1.2.6 です。
0654デフォルトの名無しさん
2006/01/11(水) 11:24:00HibernateCallback
0655653
2006/01/11(水) 22:34:55return getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) {
// クエリ投げて結果を返す
}
}
って感じですね。マニュアルにも載ってました。ポイントありがとう。
0656デフォルトの名無しさん
2006/01/21(土) 20:54:23> Drools 2.5 BETA 2において提供されている拡張モジュールはdrools-decisiontables、
> drools-dotnet、drools-examples、drools-groovy、drools-ide、drools-io、drools-java、
> drools-jsr94、drools-python、drools-smf、drools-smftest、drools-spring、
> drools-spring-examples、drools-spring-jdk5。ベースとなる藻ジュースはdrools-base、
> drools-core、drools-core-3.0。
Springにも対応しているらしいルールエンジンだが、なんだかベースが不味そうだ。
0657デフォルトの名無しさん
2006/01/21(土) 21:14:58「藻ジュース」(・∀・)ｲｲ
0658デフォルトの名無しさん
2006/01/22(日) 10:27:330659デフォルトの名無しさん
2006/01/23(月) 21:26:19まずはｱｰｷﾃｸﾁｬを決めるために、いろいろサンプルを作ってみてるんですが、質問です。
Struts&Springの連携で、代表的なのは
1) ActionSupport
2) DelegatingActionProxy
3) DelegatingRequestProcessor
の3つだと思うのですが、2) or 3) で決めかねています。
1)はせっかくなんでつまらないのでﾎﾞﾂ。
残るはDelegatingActionProxyとDelegatingRequestProcessorですが、
機能的にどちらが良いのか分かりません。
どちらかと言えばActionを継承させてBaseActionを使っていたことが多いのですが、
RequestProcessorの方が上位ですよね。
アプリケーションは到って小規模なんでどちらでも同じだと思いもするのですが、
考慮すべき点や拡張性の点等、ご助言･苦言を頂けないでしょうか。
非常に基本的な質問で恐縮ですが、
0660デフォルトの名無しさん
2006/01/23(月) 23:34:090661659
2006/01/24(火) 11:18:42確かに、ごもっともだと思います。
実はこれまでの開発ではSpringを使う機会もあったのですが、
見易さ、改修性の高さ、開発規模から
ServiceはInterfaceを使わずに実装しました。
(さすがにDAOはiBatis使って分けましたが)
それに比べ、今回は10年前にCで作った参照のみのアプリの更新で
時間的な余裕もあるので遊びたいと思ってます。
APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、
といった使い分けの程度しか理解できませんでした。
みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。
0662デフォルトの名無しさん
2006/01/24(火) 13:57:58(1) と (3) は Struts に変更があったら、思い切り引きずられそう。
TilesRequestProcessor が出ようが新規に Action が発明されようが
涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。
(ていうか (2) しか使ったことないですけど。)
その分設定ファイルは煩雑になるわけですが。
自分の分かりやすいと思える方法でやるのが一番かと。
小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。
XDOCLET は思ったほど便利じゃないと言うか、
開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。
↑これは設計がまずかっただけかも知れません。
0663デフォルトの名無しさん
2006/01/24(火) 23:17:11Actionベースはやはり分かり易いですよね。
人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。
いくつかサンプル作ってみたのですが、3種類の感想は
ActionSupport
-確かに楽だけど、Springの楽しさは十分に味わえない気が。
でも実装はまんまActionなんで、いたって簡単。
しかもプログラマの質がそれなりなら、自分入れて3人位いれば
中規模まで行ける気がする。
ActionProxy
-実質これがStruts&Springの標準でしょう。
至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで
スムーズに作れそう。
しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。
RequestProcessor
-Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと
思います。
が、幾分硬すぎる気が。大人数のRUPには向いているかな。
自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、
まあ当たり前、と言った感想でしょうか。
今回はActionProxyからやってみようと思います。
時間もある分、新しい人も多いんで。
また進展したら報告します。 いらんか。
0664デフォルトの名無しさん
2006/01/25(水) 12:22:51最近スレが過疎ってるからチラシの裏でも問題ないかと。
＞訳分からん害虫
でかいところが素敵なフレームワーク作ってるかと言うと
そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。
0665659
2006/01/25(水) 22:18:20なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。
確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。
1つはレガシーのためです。
やはり遺物であっても今から見ればあほあほなRDB設計であっても
どうしても引きずらないではいられません。
例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは
その他のホストのためにつないでやらないといけません。
おかげでせっかくのDAOも、結局は???になってしまいがちです。
これまで私も挑んだのですが砕け散りました。
もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。
本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、
掛けたくないのは人件費な訳ですから。
もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。
ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。
海外拠点との情報連携なんてつけてやれば大喜びです。
(フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・)
と、過疎板でうだつのあがらん社内SEが独り言ってみました。
0666デフォルトの名無しさん
2006/01/25(水) 22:53:35脱線させてごめんなさい。
0667デフォルトの名無しさん
2006/01/29(日) 00:03:480668デフォルトの名無しさん
2006/01/29(日) 09:45:51けど、とりあえず書いてみれ
0669デフォルトの名無しさん
2006/01/31(火) 10:23:30＞うだつのあがらん社内SE
お前様はオレですかｗ
疑問に思ったことを二つ。
＞見易さ、改修性の高さ、開発規模から
＞ServiceはInterfaceを使わずに実装しました。
何故だよ？ facadeした方がP層から見たときに理解しやすいし、
実装ロジックを意識しないで済むと思うのだけど。あと例えば
君がAPI定義して、君の手下が実装する、なんて作業も
スムースになると思うのだけど。
あと、その場所にSpringのTransaction制御は適用してるの？
それとも君達でゴリゴリ書いているの？
そこがSpringの一番美味しい所だと思うのだが。
0670デフォルトの名無しさん
2006/01/31(火) 10:24:23＞流行のSpringと扱い慣れているStrutsでと思っています。
扱い慣れているとはいえ、何故に死滅が確定している
現verのStruts？ 同じ社内SEの立場として言うが、
それって将来に禍根を残すんじゃないの？
特に、struts-taglibを使うのは忌むべきことじゃないのか？
高度にクリティカルじゃなくてもいいなら、素直にJSFを
採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を
確保できねぇと言うなら、せめて
org.springframework.ui.velocityパッケージの研究を
してから決定した方がいいんじゃないの？
0671デフォルトの名無しさん
2006/01/31(火) 12:13:28JSF はもう少し枯れてからの方が良くない？
今のところ、Velocity でやっちゃうのが一番直感的に思う。
0672デフォルトの名無しさん
2006/01/31(火) 12:24:21Servletすら使えない
0673デフォルトの名無しさん
2006/01/31(火) 15:42:570674デフォルトの名無しさん
2006/02/01(水) 09:47:13>>669
ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても
ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。
まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。
で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが
恐ろしいことになり、ある意味好き勝手にやってもらいました。
で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。
iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで
助かります。
これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。
0675659
2006/02/01(水) 10:14:07Strutsについては、JSFでの置換えも検討しましたが、
今回、自分以外はJavaでWebやるの初めてなんですよね。
やはりﾌﾞﾗｳｻﾞからRequestをServletで受けて、というのを実感
し易いのはStrutsかなぁ、と思います。
JSF、VBちっくにﾄﾞﾗｯｸﾞ＆ﾄﾞﾛｯﾌﾟでできてしまうんで、最初からこれだと
裏の理解が薄く後々に生きない気がします。
それと社内SE的にはもう少し枯れてからで良いかなと、正直思います。
Taglibについては、個人的にこれ以上覚えられるかー、ということで
beanとlogicにのみ制限しています。
まあ多少beanを拡張はしていますが。。。
個人的には、Struts → JSFで行きたいなと、Viewについては。
0676669
2006/02/01(水) 10:53:44＞DAOの中のみでTransaction制御
これって複雑なことをやろうとすると破綻しないかい？
複数のテーブルを更新するのもDaoのメソッド単位になる、
従って肥大したDaoImplを書かざるを得なくなる、という原因で。
オレのやり方だとこんな感じだ。
<ServiceLayer>
public void deposit(Account account, Money increasedMoney){
accountDao.update(account);
revenueDetailDao.insert(account, increasedMoney);
}
で、トランザクションはあくまでserviceLayerに置く。つまり上の
depositメソッドに対してPROPAGATION_REQUIREDを設定する。
オレはさらに、dao層、上の例ではaccountDao.updateと
revenueDetailDao.insertに対しては
PROPAGATION_MANDATORYをかけている。
これによりserviceLayerを通さずにDaoに触ったら即座にアポーン。
君の「DAOの中のみでTransaction制御」だと、上の二つの
メソッドを一つにまとめないと原始性を維持できないのでは？
勘違いだったらｽﾏｿ。
0677659
2006/02/01(水) 12:13:46DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。
でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、
2重ログインを防げば、問題無しという訳です。
美しくないことは、確かですが。
Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。
ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。
DAOは何を使われてるんですか?
今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。
0678669
2006/02/01(水) 13:12:05更新が途中で落ちる可能性なんてゴロゴロしてるワケだし。。。
（オレには納得いかんが）落ちる可能性を完全無視するとしても、
その場合は最低でもペシミスティックロックで組まんとイカンと
思うのだけど。。。
頼む、トランザクション管理層をserviceLayerに持ち上げとくれ。
Spring使えばチョチョイのチョイだ。
iBATISは好きだぉ。
0679デフォルトの名無しさん
2006/02/01(水) 16:24:19仰ってることが分かってきました。
自分が話しをごっちゃにした予感です、害虫さんと自分の立場を。
害虫さんのﾄﾗﾝｻﾞｸｼｮﾝ管理は、はっきり言って、信用してません。
で、問題があった際にDAOとServiceを引っ張って考えるのはしんどいんで
DAOについてはiBatisのAutoCommitにして、自分はServiceに集中できるように
している、という話です。
読み返してみると、確かに訳分からん話してますね、自分。
そういえば、SpringとベストマッチなDAOって何でしょ?
iBatisもいけるようだとﾈｯﾄに載ってた気がしますが、やはりHibernateですかね?
他に面白いのないでしょうか。
0680デフォルトの名無しさん
2006/02/01(水) 20:56:14既存のDBがからむならiBatisの方が無難だとおもう
害虫さんがいてiBatis学習コストが気になるっていうなら
Spring JDBCでもいいんじゃない？
0681デフォルトの名無しさん
2006/02/02(木) 01:17:25＞Taglibについては、個人的にこれ以上覚えられるかー、ということで
＞beanとlogicにのみ制限しています。
Strutsでやるんなら最低限必要なStrutsタグはhtmlタグのみで、後はJSTLで置き換えるのがお勧め
JSTLはJava EE5に含まれることが決定しているし、JSFも1.2からはJSTLと連携出来るようになる
■ このスレッドは過去ログ倉庫に格納されています