【DI】Java Spring Framewoｒｋを語るスレ 2.0

1 名前：デフォルトの名無しさん mailto:sage [2007/01/23(火) 10:59:45 ] 前スレ ttp://pc10.2ch.net/test/read.cgi/tech/1077465099/ 公式 ttp://www.springframework.org/ 596 名前：デフォルトの名無しさん mailto:sage [2007/08/12(日) 10:44:11 ] >>594 　　　　　　 ,-┐ 　,ｨ─､ri´^-─- ､ .┌f^f^f^f^f^f^f^f^f^┐ く　　/ ,　,'　　 ヽ　ヽ|　~ ~ ~ ~ ~ ~ ~ ~ ~│ 　`<' / ,'ﾚｲ+tVvヽ!ヽﾄ　知ってるが　　│ 　　!/ ,' i |' {］　, [}|ヽﾘ 　名前が　　　　 | 　　`!_{ iﾊﾄ､__iﾌ,ノリ,ｎ 　 気に入らない | 　　 ／/ (^~￣￣∃_ア____n＿＿＿＿＿| 　_r''‐〈　 `´ｱ/ﾄr──!,.--' <＿>─}､　　`」ﾚ 'ヽ､　　 ,.ﾍｰｧtｲ 　　 Y､.,___/　 |.| 　 　 |　　i `ｰ'i´ 597 名前：デフォルトの名無しさん [2007/09/19(水) 18:29:44 ] Struts+Springについて勉強始めました。いまはSpring入門(2.0でないほう)を読んでいます。 Springそのものはバッチ等のUIが絡まないところで使っていましたが、webアプリで使うのは今回がはじめてです。 (Strutsも単体では経験があります) >>33-45 を見てみましたが、ActionクラスでビジネスオブジェクトをDIで取得する場合、 getBean()ではなくsetter injection のほうがいいということは、 ActionSupport方式ではなく DelegatingActionProxyがいいということですか？ Spring入門によると、DelegatingActionProxy だと struts-config.xml と action-servlet.xml の 2箇所で定義が必要なので面倒という記述があり、私もそう思っていたので、 >>33-45 の流れのメリットがわかりません。 どなたか教えてください 598 名前：デフォルトの名無しさん mailto:sage [2007/09/19(水) 18:41:08 ] >>597 とりあえず↓よめば？ kakutani.com/trans/fowler/injection.html メリットはいろいろあるけど、DelegatingActionProxyのほうがテストしやすいよ 599 名前：597 mailto:sage [2007/09/19(水) 21:56:18 ] >>598 レスどうもありがとうございます。帰りの電車で読んでみます。 たびたび質問で申し訳ありません。2点聞きたいことがあります。 ○1. Struts + Spring を使ってビジネスロジック(ビジネスオブジェクト)を Action に DI したとしても、 ビジネスオブジェクトのメソッドの引数は web 層を引きずってはならないから public Interface KeiyakuService { 　KeiyakuInfo getKeiyakuInfo(String keiyakuId, String bushoCode, Date nendo); } みたいに細かく切り出しますが(ActionFormをそのまま渡すなどしない)、Struts + Spring 連携をしたとしても、 Action の execute() の最初のほうで、ビジネスロジックを呼び出す前に ActionForm から HTML Form で入力された入力値をせっせと取り出す作業は変わらない、という認識はあってますか？ # Spring とは直接関係ありませんが、ビジネスロジックやユーティリティクラスに # ActionForm や HttpServlet を引きずりこまないように＆楽するために、 # reflection(BeanUtils)を使って ActionForm からEntityクラスへの変換クラスを # 自作して使ってますが、もうすこしどうにかならないかなと思う ○2. DelegatingActionProxy から Action に処理が移っても、Action クラスは Struts を 生で使うときと同じようにスレッドセーフにしておかないといけないと理解してますが、 Actionクラスにビジネスオブジェクトを DI する場合、ビジネスオブジェクトもスレッドセーフに 作っておかないといけないのでしょうか？ ・Actionクラスはインスタンスがひとつだけ →ActionクラスのフィールドにビジネスオブジェクトのインスタンスがDIされるので、 　そのActionに同時アクセスがあった場合、ビジネスオブジェクトの単一のインスタンスが 　すべてのアクセスのスレッドで使いまわされる？ 600 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 19:58:01 ] >>599 598氏じゃないが。 Q1 はその認識であってる。詰め替えがアホらしいのは確かだが、 ある程度自動化するフレームワークも出てくるだろうし、あるいは自分で作ってもいい。 Q2 については「ステートレス万歳」の方向が良いかと。 ステートフルなロジックを作成して、スレッドセーフになってるか、その必要があるかに時間費やすよりも、 そのロジックをストートレスに出来ないかを考えた方が、早くて確実で見通しが良い。時が多いと思う。 601 名前：デフォルトの名無しさん mailto:sage [2007/09/20(木) 23:26:42 ] 時は皆に平等です。 602 名前：デフォルトの名無しさん mailto:sage [2007/09/21(金) 01:22:23 ] >>599 598だが。 >>600さんに同意です。 ビジネスロジックにリッチドメインモデルを使う場合以外は スレッドセーフを徹底すべきでしょうね 603 名前：デフォルトの名無しさん mailto:sage [2007/09/26(水) 17:35:59 ] >>599 dozer使っとけよ・・・ 604 名前：デフォルトの名無しさん [2007/10/06(土) 15:53:03 ] Struts + Springなら、AutowiringRequestProcessorもありかと 605 名前：デフォルトの名無しさん [2007/10/18(木) 11:16:42 ] d.hatena.ne.jp/sugapico/00000003/1118125623 上記サイト通りやったのですが、最後のInternalResourceViewResolverの定義がうまく行きません。 どうしてでしょうか？ 実際のソースは以下の通りです。 <bean id="exampleController" class="example.ExampleController"/> <bean id="secondController" class="example.SecondController"/> <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props> <prop key="/test.html">exampleController</prop> <prop key="/test2.html">secondController</prop> </props> </property> </bean> <!--ViewResolverを使う場合：何故か出来ない--> <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property> <property name="prefix"><value>/WEB-INF/jsp/</value></property> <property name="suffix"><value>.jsp</value></property> </bean> 606 名前：デフォルトの名無しさん [2007/10/18(木) 11:18:19 ] public class ExampleController implements Controller { /** * @see org.springframework.web.servlet.mvc.Controller#handleRequest(javax.servlet.http.HttpServletRequest, * javax.servlet.http.HttpServletResponse) */ public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // return new ModelAndView("/WEB-INF/jsp/test.jsp"); // ViewResolver return new ModelAndView("test"); } } 607 名前：デフォルトの名無しさん [2007/10/18(木) 11:18:53 ] エラーは以下のようなものです。 致命的: サーブレット example のServlet.service()が例外を投げました java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/fmt/LocalizationContext at org.springframework.web.servlet.support.JstlUtils.exposeLocalizationContext(JstlUtils.java:83) at org.springframework.web.servlet.view.JstlView.exposeHelpers(JstlView.java:82) at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:90) at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:246) at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1000) at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:761) at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:684) at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394) at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348) 608 名前：デフォルトの名無しさん [2007/10/18(木) 11:22:44 ] at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689) at java.lang.Thread.run(Unknown Source) 609 名前：デフォルトの名無しさん mailto:sage [2007/10/18(木) 11:37:50 ] 実行時にJSTLの実装ライブラリが無いんじゃないか？ アプリケーションサーバに含まれているか、あるいはアプリケーションの/WEB-INF/libに含まれているか確認。 610 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 21:45:00 ] 最近の狛犬もどきのカリスマ 今度はJPA仮想敵で俺達サイコーやってます。 「*2JDBC」のセールストークでマーチン・ファウラーの 「流暢なインターフェイス」引用してますが、JPAの インターフェイスをパクっている時点で既に論理的に破綻してます。 JPAベースで流暢なインターフェイスを実現するラッパーは作成可能であり、 流暢なインターフェイスを実装していることが「*2JDBC」のセールスポイント にならないことは明らか。 CoC(規約重視)マンセーで使った偽太陽etcがユーザ層の拡大に失敗している からCoCやめてみました、それだけ。 特定のDIコンテナに統合されている時点で「*2JDBC」は個人的には利用対象 外、モノは悪くないとは思うが狛犬もどき２に依存する気にはなれない。 "CoCの本質は最低限の規約で最大限の効果を得る"ことにあり、規約でがんじ がらめにしている時点でCoCを語る資格はない。 偽太陽をみるとわかると思うが「狛犬もどき」はCoCの本質を理解していない。 例えば、偽太陽の属性の扱いまわり、実装で楽をするためにあんな変な規約 を導入しているとしか思えない。 Clickマンセーな人でも偽太陽マンセーな人は少なく、狛犬もどきの信者だけが 偽太陽マンセー。 狛犬もどきの失敗は「狛犬もどき２」の中で閉じた世界を構築していること。 外側からみると、狛犬もどきの信者はハイレベルとは呼べないと感じる。 「"*2JDBC"が流暢なインターフェイスを実装しているから流暢なインターフェイス でないJPAより優れている」等のセールストークに騙される時点でおわってる。 「狛犬もどき」自体の開発者のうちカリスマ他数名はハイレベル(?)なんだろうが...。 新しいプロダクトをリリースする度に行われる「セールストーク」の質の低さには ウンザリ。 611 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 21:59:18 ] Seasarの煽りuzeee 612 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 23:01:09 ] ウザイと言うか・・・こんな書き方するってずいぶんとまぁ・・・ 池沼にはウンザリ。 613 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 23:11:37 ] 狛犬とか太陽とかいうのはうざいが、同意する部分あるな 614 名前：デフォルトの名無しさん mailto:sage [2007/10/27(土) 23:20:57 ] ASIP乙 615 名前：デフォルトの名無しさん mailto:sage [2007/10/29(月) 11:45:59 ] 内容に自身があるなら隠語や伏字やめれ。読みにくい。 どっかのスレの雰囲気を持ち込まれても困る。 616 名前：デフォルトの名無しさん [2007/10/29(月) 17:40:33 ] sessionFormをtrueに設定したんですが、このあとどうやってsessionを取得すればいいのでしょうか？ どなたか教えてください。 617 名前：デフォルトの名無しさん mailto:sage [2007/12/07(金) 00:13:54 ] Scopeのsingletonとglocal sessionの違いを確認できるような 構成ってどんなものがあるでしょうか？違いがわからんです。 618 名前：デフォルトの名無しさん mailto:sage [2007/12/15(土) 13:49:13 ] 前期のシグルイに今期のカイジ、渋い作品は探せばいくらでもあるが単にﾔｼらの趣向に合わんだけだろ 萌えとかいったって細かい趣向の違いがあって妹13人とか30人に囲まれたいﾔｼには今期はもの足りんだろうしな 619 名前：デフォルトの名無しさん mailto:sage [2007/12/15(土) 15:30:00 ] なんというSpring萌・・・ Spring2.5はすごいな GuiceやSeasar2の価値をゼロにしたかもしれん 620 名前：デフォルトの名無しさん mailto:sage [2007/12/15(土) 17:05:15 ] >>619 どのへんが？ 621 名前：デフォルトの名無しさん mailto:sage [2007/12/15(土) 17:18:02 ] >>620 妹13人とか30人に囲まれたいとか 622 名前：デフォルトの名無しさん mailto:sage [2007/12/17(月) 08:09:32 ] 基本的にコアは 1.1.x で完成していて、 1.2.x 以降は設定ファイルの書式が若干良くなったり かえって悪くなったりしてるだけじゃなかろうか。 (XML 名前空間は使いにくいから失敗だと思う。 機械が読むには悪くないけど、人間が書くには疲れる。) spring-ws や spring-webflow みたいなサブプロジェクトが どれだけ完成度高めていくかと、 新たに面白いサブプロジェクト生まれないかなぁって辺りに関心がある。 コアのバージョンはもうどうでも良いって言うか。 Guice や Sesar2 はハナから問題外じゃね？ デファクト取っちまってるプロダクトがどうしたって強いし。 あとは Rails にだまされてる人達が どれだけ早く DI の妥当さに気がつくかだけでしょ。 623 名前：デフォルトの名無しさん mailto:sage [2007/12/18(火) 01:24:31 ] 膣内射精断面図はまだですか？ 624 名前：デフォルトの名無しさん mailto:sage [2007/12/18(火) 03:18:04 ] >>623 明日の１３時にアルタ前で、直接手渡します。 ロッドジョンソンのTシャツを着て待っていてください。 625 名前：デフォルトの名無しさん mailto:sage [2007/12/29(土) 01:59:06 ] 相も変わらずG'sは狂ってるな。１９人の姉妹だとよ ttp://gs.dengekinet.com/suteki/ 626 名前：デフォルトの名無しさん mailto:sage [2008/01/09(水) 00:55:08 ] オレの嫁達紹介　全員判別できたら通報する ちょっと生意気だけどご近所の子のアイたんって子がマジ可愛い。リボンの似合うキュートガールなんだ＾＾ オレの同居人のかなみたんも可愛いすぐるんだ。なんか思考読まれてるんじゃないかってほど、的確に動いてくれて役に立つし＾＾ 他の女の子の話してると、彼女のロゼッタたんがディアボロで殴ってくるからそろそろやめとくか＾＾ オレのいとこのあすたんも可愛いんだ。貧乏だから色々支援してあげてる＾＾ ちょっと怖いけどオレにとりついてる幽霊のコゼットたんも好き。今はコップの中に引きこもってでてこないけどさ＾＾ 妹のクリスマスたんに女の子の話するとちょっと動揺したように逃げてくんだよね、普段読まないのにこっそりファッションの本とか読んでるの見たときはちょっと萌えた＾＾ 近所に住んでる蘭たんはすごいポーカーフェイスでいっつも狐のお面をかぶってるんだけど、オレには優しさと笑顔を見せてくれるんだよね。可愛いすぐるぜ＾＾ 幼馴染のテッサてんはクリスマスたんよりおいしい料理を食べさせてあげる！とか毎日いきまいてるけどなんでだろう＾＾ でもドジだからいっつもなにか間違えるんだよなぁ。まぁそこが可愛かったりするけど＾＾ 同じ職場のルリたんは皮肉屋でいっつもオレのこと小ばかにしてるけど。本当はオレにぞっこんなのは裏とれてるんだなぁ＾＾ お隣に住んでるアナたんは苗字で呼ぶと怒るんだけど、それがまた可愛くてやめられないんだ＾＾ クリスマスプレゼントでうちにきた電波系の自称オレの妹ちょこたんは本当に純粋無垢で可愛いんだなぁ＾＾ これまた近所の桜田さん家に遊びにくる金糸雀たんも激萌えなんだ。ちょっと頭足りないから、口喧嘩でいじめるのが楽しい＾＾ 前ジャングルに行ったとき出あった女の子のマリィっていう子も可愛いんだなぁ。好きな人がいたみたいだけど振り向いてくれないらしく オレが甘い言葉囁いたらすぐ落ちた。でもずっといるとちょっと疲れる子なんだよね＾＾ 以上13人がオレの嫁 627 名前：デフォルトの名無しさん [2008/01/29(火) 00:02:29 ] age 628 名前：デフォルトの名無しさん [2008/02/02(土) 00:06:18 ] Spring Dynamic Module が良く理解できないんだけど Struts2のアクションをダイナミックに変更できたらいいなーと思ってるけど出来そう？ 629 名前：デフォルトの名無しさん mailto:sage [2008/02/02(土) 00:25:09 ] >>560 いまどき履歴書なんて買うなよ。 OpenOfficeで書け。 写真は携帯電話で撮ってOpenOffice Write文書に貼り付けろ。 履歴書は面接先企業にメールで送りつけるのが現在の常識だ。 面接ではノートPCを持ってプレゼンし、自作プログラムを持参し、 自分の能力を強力にアピールろ。 >>571 派遣は下手な零細企業の正社員よりも稼げるのが現実 630 名前：デフォルトの名無しさん mailto:sage [2008/02/02(土) 00:43:50 ] アピールろ 631 名前：デフォルトの名無しさん mailto:sage [2008/02/08(金) 15:05:20 ] Spring2.5使っているのですが、 RequestスコープのBean内でServletRequest自身にアクセスするには どうしたらよいのでしょうか･･･ 632 名前：デフォルトの名無しさん mailto:sage [2008/02/09(土) 01:16:31 ] 死ねばいいと思うよ 633 名前：デフォルトの名無しさん mailto:sage [2008/02/14(木) 19:05:52 ] きがつけばSpringはもう2.5か 634 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 01:13:43 ] 2.0 と 2.5 の違いをざっと読んでみたんだが アノテーションをもっと全面的に押し出しますよって事？ 個人的にはイマイチだな。 635 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 01:32:52 ] >>634 中身がごっそりリファクタリングされて爆速化している。 636 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 01:43:31 ] アノテーションは使ってもいいし、使わなくてもいい ファサードが使いやすくなるので個人的には歓迎 切り分けたい外部インターフェースは明示的にxmlに書けばいいし問題はないね 637 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 02:08:21 ] @Resource、@PostConstruct、@PreDestroy とかのCommon Annotationsがそのまま使えるのはメチャメチャ便利だからすでに多用しまくり。 638 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 02:09:58 ] Springってバランス取れてるんだよね 標準技術で使えるところは使う、さらに拡張がほしければどうぞとか Seasar2は自前でなんでもやったるというのが多すぎる希ガス 639 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 04:16:56 ] >>638 Seasarもそれなりに標準サポートしてる。@Resourceなんかも使えるぞ。 S2Xxxで他のフレームワークとの連携もやってるがSpringほど手広くは できないのが国内限定の辛さだな。 640 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 09:37:12 ] >>634,635 thx. ここ最近スレが静かで寂しかったけど、ちゃんと人居て安心した。 トランザクションの記述はシンプルになるので 使える場面では積極的に使おうと思う。 >Seasar2は自前でなんでもやったるというのが多すぎる希ガス 何にフォーカスしてるのか一言で言い表せないプロジェクトが多くない気がする。 シンプルで高性能(!=高機能)なツールをどう組み合わせるかが技術者の腕の見せ所なんだけど 組み合わせの自由度が思いのほか少ない。 641 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 12:59:48 ] 日本語ドキュメントがあるSeasar2より日本語ドキュメントのないSpringのほうが 扱いが楽ってのもどうもしっくりこないな 642 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 13:12:28 ] >>640 「Next J2EE（笑）」とか「ブルーオーシャン（笑）」とか軸がぶれまくったのが悔やまれるな。 643 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 13:15:15 ] Seasar2ってJavaSE6対応してるの？ Springは2.5で対応したけど 644 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 17:23:11 ] SE6対応は分らんけど、アノテーションの利用に関しては Spring よりも積極的だったと思う。 でもドキュメント関連は壊滅的。 日本語ドキュメントとか言っても紹介レベルのものだし。 10の事を知りたいのに1しか教えてくれない日本語ドキュメントより 10どころか20や30書いてある英語ドキュメントの方が嬉しい。 645 名前：デフォルトの名無しさん mailto:sage [2008/02/17(日) 21:24:26 ] Seasar2 の話題は↓で 国産DIコンテナSeasar その12 pc11.2ch.net/test/read.cgi/tech/1203122931/ 646 名前：デフォルトの名無しさん mailto:sage [2008/02/24(日) 02:52:42 ] >>645 イラネ 647 名前：デフォルトの名無しさん mailto:sage [2008/03/01(土) 02:08:36 ] ttp://logch.info/logs/jun.2chan.net/b/src/1204003806653.jpg 妹の惑星を思い出した 648 名前：デフォルトの名無しさん [2008/03/20(木) 14:11:36 ] spring2 + struts2で開発しようとしてるが、 webapplicationContextへのアクセスで困ってます。 spring2 + struts1では、ActionSupport経由でできるらしいが、 struts2には対応してない。 どーしたら良いの？ 649 名前：デフォルトの名無しさん mailto:sage [2008/03/26(水) 22:34:58 ] 2.5 の DL パッケージに入ってる HTML ドキュメントが巨大な 1ファイル HTML なのは何故；？ 本家の static.springframework.org/spring/docs/2.5.x/reference/index.html これみたいな分割 HTML ドキュメントは配布してないの？ 650 名前：デフォルトの名無しさん [2008/03/31(月) 16:53:03 ] >>648 struts.apache.org/2.x/docs/spring-plugin.html 651 名前：デフォルトの名無しさん mailto:sage [2008/03/31(月) 22:11:54 ] >>648 ぐぐれかす 652 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 01:43:55 ] SpringMVCってあんまり使われてないの？ わざわざStrutsと組み合わせるの面倒くさくない？ 653 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 05:19:39 ] 世間的には Struts がまだまだ強いんだよ・・・ 個人的には SpringMVC + Velocity が一番だと思うが。 JSP なんて気持ち悪くて触りたくない。 654 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 09:33:40 ] つまりRailsもカスだと？ VelocityもJSPとかわらんだろ むしろツールのサポートがあるJSPのほうが楽なことも多い 655 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 10:59:21 ] ttp://cubby.seasar.org/ がSpringで使えるようになったらうれしい。 656 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 12:35:26 ] >>655 SAStrutsの方ならSpringで使えるようになる ttp://d.hatena.ne.jp/higayasuo/20080401/1207016839 > SAStrutsとS2JDBCもSuper Agile Spring上に移植する予定です。 657 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 15:50:20 ] >>654 POJOのパラメータありメソッドをサクサク呼び出せるのがVelocityの良いところ。 JSPでもFunctionとかあるけど、staticメソッドのみなうえにtdl書くのが死ぬほど面倒くさい・・・ ツールはEclipse+VelocityWebEditでコード補完もバッチリできるよ。 >>653 自分も数年間JSP⇔Velocity両方使って試行錯誤してたけど、 SpringとかDIとの相性がいいからVelocityに落ち着いた。 658 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 17:18:32 ] >>657 velocityだとデザイナとの分離が不可能 分離しないタイプならJSPのほうが融通が利く テンプレートとしては好きだけどね 659 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 22:29:08 ] >>656 4/1だもんな。 それに、Strutsはいらない。 660 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 23:35:09 ] >DIとの相性がいいから DI云々よりも目的がハッキリしてるから好き。 どうせテンプレート機能しか使わないんだから (タグ作り始めるとコードの暗号化を進めるだけ) そっちに特化してる方が何かとシンプルでやりやすかった。 JSP のコンセプトがどれだけボヤけてたかは その後に JSTL + EL を取り込んだことで自明でしょ。 最初からそれやっとけよって話。 661 名前：デフォルトの名無しさん mailto:sage [2008/04/01(火) 23:50:35 ] コンセプトというか、単にASPやPHPの対抗馬として作っただけだしな 662 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 02:46:05 ] >>660 たしかにカスタムタグ自前で作り始めるとわけわかんなくなる… JSPはスクリプトレットベースだったのを無理やりJSTL+ELを加えて あげくにスクリプトレットレス推奨になってる時点でスコープやらなにやらグチャグチャになってると思う。 >>658 デザイナとの分離ならむしろ圧倒的にVelocity有利では？？ 663 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 02:48:09 ] #foreach や#parse がデフォルトで無限ループができないようになってたり、 デザイナとの分業は余計な問題が起こらないようにいろいろ考えられてるよ。 664 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 03:11:31 ] FreeMarker はどうよ？ View 層に jsp より Velocity というのは自分も同意だが、 SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。 なんつーか冗長というかめんどくさい。 おれがわかってないだけかもしれないけど。 665 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 03:55:11 ] >>662 デザイナは通常DreamWeaverとかつかうからjspはhtmlと同じように扱えるんだよ しかもtomcat連携も可能で動的htmlを表示したままcss設定できたりな 666 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 04:10:36 ] >>664 SpringMVCはなんかクラス名がピンとこないのが多い・・・ Model、View、CommandとかMVCでいうと実際にはController部分（？）なのに 紛らわしい感じで混乱する。 667 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 11:06:33 ] SpringMVCはシンプルで薄いラッパだから迷うことはないと思う 2.5とそれ以前とでだいぶ中身は違うと思うけど 668 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 22:41:07 ] >SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。 ModelAndView と Contoroller 作るだけなんで これ以上に少なくってことになると Teeda で Page に全部詰め込むか Tapestry で PHP 的なプログラミングするしかない。 669 名前：デフォルトの名無しさん mailto:sage [2008/04/02(水) 22:48:57 ] SpringMVCはどちらかといえばDIベースで作られているのだから いくらでも好きにいじってください、というものだと思うが Viewに他のフレームワーク＋Springよりはるかに融通は利くのだが 機能がほしいのならStripseとか普通に使ったほうがいいと思う Springの他のDIコンテナの追随を許さない圧倒的な利点は 自前でも用意はするし、他のフレームワークの連携も最大限に考慮することだから 670 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 22:56:24 ] >>669 Struts連携もHibernate(JPA)連携もSeasarの方が上。 671 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 23:13:39 ] ラップして存在を隠すことを連携と言うならそうだろうな。 672 名前：デフォルトの名無しさん mailto:sage [2008/04/03(木) 23:34:53 ] SeasarってJPAとの相性そんなにいいか？ まずトップがJPAを消そうとしてるように見えるんだが 673 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 00:15:19 ] >>672 Kuina＞＞＞＞越えられない壁＞＞＞＞JpaTemplate 簡単な問合せはインターフェース書くだけ ttp://kuina.seasar.org/ja/user_guide/query.html 複雑ならCriteria ttp://kuina.seasar.org/apidocs/org/seasar/kuina/dao/criteria/CriteriaOperations.html SQLサポートも強力 ttp://kuina.seasar.org/ja/user_guide/query.html#SQLによる検索 EntityManager直に使うこともできる。何も隠されてない 674 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 01:17:22 ] どうでもいいけど、Springスレにまで出張するのは頭おかしいとおもうんだ スレまちがえてないか？ それにSpringだってEJBのように直につかえるよ そもそも何も考えずつ変えるという意味でJPA使うのならEJB3使うのが一番効率的だと思うけど もともとJPAはオブジェクトプール用に設計されてるからね 675 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 01:40:11 ] >>674 >672の問いに答えただけだが > JPA使うのならEJB3使うのが一番効率的だと思うけど EntityManager使う面倒さは何一つ解消しないしそもそもSFSBが効率的じゃない 676 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:43:13 ] 何を根拠にSFSBといきなり限定的な話になるのだ それにステートフルが怖い人ですか セッションになんでもかんでもぶちこむより活性化、否活性化がちゃんと動くEJBでやったほうがまし Seasar2ってその辺全部やってくれるの? 677 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 02:51:01 ] >簡単な問合せはインターフェース書くだけ で、_NOT_IN やろうとして失敗して、 コード見たら失敗するのが当たり前で、 ローカルで修正して JAR 入れ替えたらきちんと動いて、 ああ、やっぱり俺悪くないわ、ろくにテストされてねーじゃんとか思うわけだ。 このレベルの項目すらテストされてないのに 他が題目どおりに動くことなんて微塵も期待できない。 それでも Kuina サイコーだってんなら好きにしてくれ。 678 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 03:11:52 ] >>676 > 何を根拠にSFSBといきなり限定的な話になるのだ SLSB+JPAはメリットないからSFSB+拡張コンテキスト限定に決まってるだろ常考 それともSLSB+JPAが効率的とか書いたのか？何が効率的なんだ？ > セッションになんでもかんでもぶちこむより なんでもぶちこんだらSFSBでもだめだろ > 活性化、否活性化がちゃんと動く 拡張コンテキストがあると非活性化されない 679 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 03:46:27 ] >>677 コミッタに教えてやれよｗ 680 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 12:16:26 ] >>678 拡張コンテキストについて詳しく 681 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 12:32:44 ] >>680 SFSBのライフサイクルに合わせた寿命の長い永続コンテキスト 永続コンテキストはキャッシュみたいなもん 682 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:30:30 ] >>680 トランザクション境界ぬけたら非管理下におかれるんじゃないの？ 683 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:31:07 ] >>681 だった。 684 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:50:49 ] >>682 それ通常の永続コンテキスト 685 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 13:57:34 ] KuinaもJPAもEJBもスレ違い 「Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4」 ttp://pc11.2ch.net/test/read.cgi/tech/1134701684/ 686 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 15:00:38 ] >>684 なら拡張つかうのやめれば？ むしろSFSBはWebに紐付けしないといけないほうが問題。 seamはそのためにあるともいう。 687 名前：デフォルトの名無しさん mailto:sage [2008/04/04(金) 20:05:18 ] >>686 通常のコンテキスト使うならEJB使うメリットはない SpringでもSeasarでも同等 >674が言うEJBが効率的てのは何なのかと スレ違いらしいから続けるならO/Rスレで 688 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:25:32 ] >>686の発言はいみふ 689 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:35:46 ] >>688 SFSB使ったことないのかい? 690 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 19:42:09 ] Swingクライアント+SFSBならWebと紐付け不要 691 名前：デフォルトの名無しさん mailto:sage [2008/04/12(土) 22:16:02 ] >>690 揚げ足取りイクナイ 692 名前：デフォルトの名無しさん mailto:sage [2008/04/13(日) 10:19:14 ] ロジックをステートレスにするのは フレームワーク側の都合にプログラマが合わしてるだけで 本来の姿じゃないって発言をたまに見かけるが、 ステートフルにするとプログラマの能力を超えてしまう事が多数。 693 名前：デフォルトの名無しさん mailto:sage [2008/04/13(日) 13:44:32 ] つーか、ステートフルであることがアプリケーションの基本でしょ? そんな基本ができないやつはいらね 難易度が高いのならともかく、基本がないやつは退場してもらったほうが業界のためにいいよ 694 名前：デフォルトの名無しさん mailto:sage [2008/04/13(日) 14:25:15 ] >>693 ロッド・ジョンソンに言ってこい 695 名前：デフォルトの名無しさん mailto:sage [2008/04/13(日) 14:39:37 ] >>693 何が基本なんだかさっぱりわからん そんなもんケースバイケースに決まってるでしょ 696 名前：デフォルトの名無しさん mailto:sage [2008/04/13(日) 20:59:49 ] ステートレスだのステートフルだのうるさい奴らはSpringの設定を全部シングルトンにしてそうだ。 ステートレスなロジックオブジェクトとステートフルなエンティティオブジェクトのみで 作られたプログラムなんてオブジェクト指向とは到底呼べない。

---

---

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

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