Java Spring Frameworkを語るスレ

1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51] www.springframework.org/ 乱立するフレームワークと競合するプロトコルの嵐のなかで、 リスクの高い決断を余儀なくされているJavaデベロッパ、プ ロジェクトマネージャに対する福音です。 語るべし。 577 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 13:39:20 ] なにこれ？ あほですか？ ただ、指定のクラスを生成して、ついでにプロパティも入れるというだけ？ くだらん。 ただのFactoryじゃん。 messageを生成時に注入してHello World!かよ。 おめでてーな。 まあ、記事が馬鹿だということを予想して付属のSampleためしてくるよ。 578 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 13:43:19 ] >> Spring Frameworkで理解するDI（1） (2)は、まだー？ 579 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 13:53:10 ] >>578 もちろん1,2,3を読んでの感想ね。 いま、ExampleのCountryを読んでるんだけど、 いきなりソースを読んでも意味わからんわ。 それぞれのクラスが他に依存しないってことは Utilを読むみたいに、いきなり読めるってことかと思ってしまった。 今から/samples/countries/*.txtを読んでデプロイして実行してみる。 580 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 14:08:34 ] 日本用のpropertiesがないからぬるぽい。 適当になぶる 581 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 14:59:14 ] 解説しよう なぶる　＝　触る 582 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 16:09:48 ] 解説ありがとう 今から外出しないといけなくなった とりあえずどんな実装をしていくかという 癖みたいなものはわかった。 出たついでに本屋にでも寄って理論を立ち読みしてくるわ 583 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 18:13:33 ] ぬるぽ 584 名前：デフォルトの名無しさん mailto:sage [2005/11/13(日) 22:40:28 ] 帰ってきたよ 理論読んでくるの忘れたから、検索するわ あとで 585 名前：デフォルトの名無しさん [2005/11/17(木) 20:48:05 ] 1.2.6記念 586 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 11:55:56 ] 閑古鳥だな 587 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 12:00:14 ] DIは結局流行り物だってこった。 DIスレもSeasarスレも活気ないしな。 588 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 12:06:55 ] 需要は大いにあるけど、 言語レベルでの制約によるメリットが一部損なうことや、 リファクタリングがかなりし難くなるところがやはり気に食わないな。 589 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 12:33:48 ] DIコンテナがなくても SetterInjectionとFactoryでいいけどさ。 AOPと親和力が高いのが魅力的だよね。 抜け出せない。 遅いのに。 590 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 13:15:50 ] つか、もうEJB3でおけ 591 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 13:18:05 ] でも「EJB？ﾊｧ？これからはSpringだろ」 てのを受けて試しにSpring触って第一印象が>>577ってパターンが結構多い気がするな。 592 名前：デフォルトの名無しさん [2005/11/28(月) 20:17:43 ] フロントしか弄ってない俺には、Strutsの焼き直し。 593 名前：デフォルトの名無しさん [2005/11/28(月) 21:17:10 ] 今って分散環境だとビジネスロジックには 何が一番使われてんの？ 594 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 21:21:10 ] あ、これじゃいみわかんねえや モデルだった 595 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 22:32:06 ] >>592 Strutsとは全くかぶってないので、StrutsをどうやきなおしてもSpringにならない・・・ 596 名前：デフォルトの名無しさん mailto:sage [2005/11/28(月) 22:33:25 ] >>595 フロントコントローラ、まんまStrutsなんだが。 597 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:09:53 ] これってどこがいいの？ XMLからクラスが生成できるだけ？ 598 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:22:41 ] >>595 次の次ぐらいのStrutsはWebWorkになるそうだぞ。 599 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:25:00 ] ん？IDEと統合するのを目標に作られたJSFがあるからそれはないべ？ 600 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:34:16 ] >>599 ほれ。 ttp://www.mail-archive.com/dev%40struts.apache.org/msg13815.html 601 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:37:30 ] もうひとつ。 ttp://blogs.opensymphony.com/webwork/2005/11/webwork_joining_struts.html スレ違い。失礼。 602 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 00:42:46 ] >>600-601 えーーーー。 なんかすっげー違和感・・・。 603 名前：デフォルトの名無しさん mailto:sage [2005/11/29(火) 12:19:40 ] >リファクタリングがかなりし難くなる なるか？ 設定ファイル書き直しの手間が云々って意味？ 604 名前：デフォルトの名無しさん mailto:sage [2005/12/01(木) 20:40:22 ] SpringFrameworkのDefaultIntroductionAdvisorと DelegatingIntroductionInterceptor の使い方がやっと分かった。 AOPヽ(´ー｀)ノﾏﾝｾｰ 605 名前：デフォルトの名無しさん mailto:sage [2005/12/06(火) 10:25:25 ] 使う場所を見つけるまでがAOPです 606 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 08:03:22 ] AOPとDIと、どっちが偉いの？ 607 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 08:41:40 ] 別々の話だから、比べてもしかたない。 608 名前：デフォルトの名無しさん mailto:sage [2005/12/08(木) 09:35:46 ] どっちも偉くはないですが 609 名前：デフォルトの名無しさん [2005/12/10(土) 23:50:35 ] muimi.com/j/aop/spring/ SpringのHello Worldでどのサイトをみても これ以上のことがどこも書いていないのですが どういった点が優れているのでしょうか？ いまいちこのフレームワークが他よりも優れいているというメリットが見えないのですが また具体的に何が得意とかあるのでしょうか？ 610 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 01:16:39 ] 他ってなんのことを言ってるの？ 611 名前：デフォルトの名無しさん [2005/12/11(日) 15:13:00 ] みなさん実際に実務だとどんなところにSpring使ってます？ 全面的に使ってたりする？ 612 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 15:47:19 ] Springは使うなら全面的だろ。 613 名前：デフォルトの名無しさん [2005/12/11(日) 15:49:33 ] >>612 大根としてつかうだけならどこか１部だけでもOKでは。 614 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 16:10:46 ] >>613 たとえばStruts使う場合だと、すべてのActionをSpringに委譲するし。 615 名前：デフォルトの名無しさん [2005/12/11(日) 16:14:12 ] >>614 具象オブジェクトの生成部分を切り出す単位って、そこしかないわけか オイ？ﾓｯﾄどこにでもあるでしょうがよ。 616 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 16:20:57 ] ？？？ 617 名前：伝説新人タクシ mailto:sage [2005/12/11(日) 16:23:20 ] >>609 疎結合であるとかそれによって単体テストがしやすいとかいうこと？ 618 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:11:40 ] Springわかんなかったんなら、EJB3を待ってたほうがいいかもね。 619 名前：デフォルトの名無しさん mailto:sage [2005/12/11(日) 17:54:34 ] 予習でやるならともかく、今の流れだと、これから本格的にSpring使うってのはなしなきがするな。 だから、逆に絶対やっといても損はない気がするけどさ。 620 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:29:59 ] そんな難しいものじゃないし、画期的な機能に満ち溢れているわけでもないよ。 ただ単に便利なツールでいいのだと思うけど。 便利なBeanFactory、それで充分だよ。 おまけで付いてくる付属品はけっこういいよ。 AOPもそうだし、ORMやらmailやらが楽チンに扱えるのも嬉しい。 S2でもSpringでもどっちでもいいけど、これがない世界には戻りたくないね。 EJB3があれば不要という話もあるね、GabinKingが主張しているように。 でもSpringを通してEJB3を使った方がより簡単、そういう機能が出てくるって予想してる。 621 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:36:16 ] というか、普通のTomcatで動かせて面倒なパッケージング不要なEJB3、みたいな感じになると思う。 622 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:36:44 ] 追伸：煽るワケじゃないが、Springごときを理解できない方が EJB3を使いこなせるとは思えない。Annotationの裏で 起こっている出来事を多少は理解している必要はある、って 認識の元の考えだけど。 623 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 10:58:46 ] Springってかなり裏方的な働きだから、単体ではよさがわかりにくいんだと思う。 EJB3でも、単にORマッピングだという認識で、なんだか裏側で勝手に結びつけてくれるという感じになるんじゃないかな。 624 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 16:27:03 ] EJB3 って来ると思う？ Java ソースにアノテーション埋め込むのと 設定ファイルに外出しされてるのと どっちが疎結合か考えたら EJB3 は退化してるとしか思えない。 625 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 18:56:40 ] アノテーションで疎結合じゃないという話は、すでに時代遅れだし、EJB3が来ないと思うなら、別の部分で批判しないといけない。 626 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 19:05:38 ] 簡単に理由をいえば 「疎結合のためにアノテーションを排除して、なんの意味がある？」 627 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 20:42:36 ] ﾌﾟｹﾞﾗ おまいらどうせ来年にはAnnotationに文句垂れてると思うよ、飽きっぽいから。 628 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 21:45:25 ] >>627 いや、それはそれで良いんじゃねぇの？ 不満がなければ技術革新なんてねぇさ。 629 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 21:58:43 ] Annotationの仕様には不満があるけど、Annotation自体はとても気に入ってるよ。 630 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:25:06 ] Springで簡単なWebアプリを作るサンプルがあるサイトしらない？ WebApplicationContextを使って云々みたいな。。。 631 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:28:53 ] Struts使った方が楽だからねぇ・・・ 632 名前：デフォルトの名無しさん mailto:sage [2005/12/12(月) 22:53:59 ] AnnotationとEnumの組み合わせが好きだな XDocletとは違って定数を指定できるし、引数の型チェックも出来る 633 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 02:02:54 ] StrutsよりもJSFをもう少し簡単にした物を使いたい 634 名前：デフォルトの名無しさん [2005/12/13(火) 09:39:22 ] >>630 ほらよ www-06.ibm.com/jp/software/websphere/developer/j2ee/lightweight/ www5f.biglobe.ne.jp/~webtest/myapptutorial/index.html https://appfuse.dev.java.net/ https://equinox.dev.java.net/ 勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを 作ってるヤツ。（Facadeかけてるやつ） とりあえずIBMのヤツを熟読しろ。 635 名前：教えてください [2005/12/13(火) 21:35:54 ] 左クリックを使用できないようにjavaScriptを組んだつもりでしたが、機能しません。 どこが間違ってるのかご指南ください。 問題のＨＰ　urei.ojaru.jp/top.htm フレームを使用してますが　 Ｉｍａｇｅｓ→***のリンク→左使用不可ページ　となってます。 ***　のページ　左使用不可ページ直リン防止script 左使用不可ページ　左使用不可script このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ もうどうしていいのか分りません 636 名前：デフォルトの名無しさん mailto:sage [2005/12/13(火) 22:01:21 ] >>635 はスレ(板？)違いの上に、マルチ 637 名前：デフォルトの名無しさん mailto:sage [2005/12/14(水) 10:05:47 ] 板違いというより、基地外 638 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 02:08:32 ] Spring.NETの方はどうですか？ 同じ？ 639 名前：デフォルトの名無しさん mailto:sage [2005/12/16(金) 13:48:47 ] >>638 Spring.NETは基本的なDI・AOPの機能は既に実装済み。 DB、トランザクション、WEB等の機能はまだ開発中みたいだな。 だけど、正直.NETでDIは使う気にならないな。 640 名前：デフォルトの名無しさん mailto:sage [2005/12/17(土) 13:07:47 ] >>639 何故？ 641 名前：デフォルトの名無しさん [2005/12/24(土) 12:10:09 ] ActionSupportを使ってStrutsとSpring連携させてるんだけど このクラスのテストケースをstrutstestcaseを使って書こうとした時に Actionから呼び出すBeanを変えてテストケース書きたい場合 Bean定義のXMLを変えるしか方法がない？ テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、 642 名前：デフォルトの名無しさん mailto:sage [2005/12/25(日) 01:54:24 ] 自分で注入しちゃったら？ 643 名前：デフォルトの名無しさん mailto:age [2005/12/26(月) 01:34:51 ] Struts + Sringでエ○画像掲示板つくってみました。 Spring入れたほうが動作は安定して早くなりました。 644 名前：デフォルトの名無しさん [2005/12/26(月) 11:56:02 ] >>642 その方法がわからないんだよう ポインタなぞあったら教えてぎぶみー 645 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 07:47:52 ] Spring2.0って機能面ではどう変わったんですか？ 646 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 07:55:33 ] >>644 セッターインジェクションの場合 setXxx(value); フィールドインジェクションの場合 xxx = value; で注入できますｗ 647 名前：デフォルトの名無しさん mailto:sage [2005/12/28(水) 14:12:36 ] >>645 設定ファイルがXML Schemaベースになってる。 648 名前：デフォルトの名無しさん mailto:sage [2005/12/29(木) 12:31:25 ] Important new features include: * 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 があればどうにかなった。 649 名前：デフォルトの名無しさん [2006/01/08(日) 02:38:17 ] フレームワークの議論ばかりしていて実際にハイレベルな パフォーマンス＆拡張性が要求される現場では役に立たない 方々乙かれさまです。 650 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:19:20 ] どこでも役に立たない>>649よりはマシだけどな。 651 名前：デフォルトの名無しさん mailto:sage [2006/01/08(日) 03:40:27 ] >>635>>637>>649 652 名前：デフォルトの名無しさん mailto:sage [2006/01/10(火) 15:18:00 ] 普通なら釣りなんだろうが現場見てると 本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。 さすがに起動時だけは遅いが、一度起動してしまえば 速度が気になったことはないな。 拡張性については具体的な例を挙げて欲しいな。 どういう要求が出た時にどういう対応をしたのかを。 653 名前：デフォルトの名無しさん [2006/01/11(水) 03:07:47 ] HibernateDaoSupportを使う場合にQuery#setFirstResults(int)やsetMaxResults(int)を 使うにはどうすればいいかご存じの方はいませんか? getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。 getSession()して自分で処理するしかないかな。 Spring 1.2.6 です。 654 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 11:24:00 ] >>653 HibernateCallback 655 名前：653 mailto:sage [2006/01/11(水) 22:34:55 ] >>654 return getHibernateTemplate().execute(new HibernateCallback() { public Object doInHibernate(Session session) { // クエリ投げて結果を返す } } って感じですね。マニュアルにも載ってました。ポイントありがとう。 656 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 20:54:23 ] ttp://pcweb.mycom.co.jp/news/2006/01/20/346.html > 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にも対応しているらしいルールエンジンだが、なんだかベースが不味そうだ。 657 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 21:14:58 ] >>656 「藻ジュース」(・∀・)ｲｲ 658 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 10:27:33 ] いや飲みたくはない…… 659 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:26:19 ] 今、新しいｱﾌﾟﾘ作るんで、まあ流行のSpringと扱い慣れているStrutsでと思っています。 まずはｱｰｷﾃｸﾁｬを決めるために、いろいろサンプルを作ってみてるんですが、質問です。 Struts&Springの連携で、代表的なのは 　1) ActionSupport 　2) DelegatingActionProxy 　3) DelegatingRequestProcessor の3つだと思うのですが、2) or 3) で決めかねています。 1)はせっかくなんでつまらないのでﾎﾞﾂ。 残るはDelegatingActionProxyとDelegatingRequestProcessorですが、 機能的にどちらが良いのか分かりません。 どちらかと言えばActionを継承させてBaseActionを使っていたことが多いのですが、 RequestProcessorの方が上位ですよね。 アプリケーションは到って小規模なんでどちらでも同じだと思いもするのですが、 考慮すべき点や拡張性の点等、ご助言･苦言を頂けないでしょうか。 非常に基本的な質問で恐縮ですが、 660 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 23:34:09 ] たいくつでつまらない技術が一番強い。 661 名前：659 mailto:sage [2006/01/24(火) 11:18:42 ] >>660 確かに、ごもっともだと思います。 実はこれまでの開発ではSpringを使う機会もあったのですが、 見易さ、改修性の高さ、開発規模から ServiceはInterfaceを使わずに実装しました。 (さすがにDAOはiBatis使って分けましたが) それに比べ、今回は10年前にCで作った参照のみのアプリの更新で 時間的な余裕もあるので遊びたいと思ってます。 APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、 といった使い分けの程度しか理解できませんでした。 みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。 662 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:57:58 ] >659 (1) と (3) は Struts に変更があったら、思い切り引きずられそう。 TilesRequestProcessor が出ようが新規に Action が発明されようが 涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。 (ていうか (2) しか使ったことないですけど。) その分設定ファイルは煩雑になるわけですが。 自分の分かりやすいと思える方法でやるのが一番かと。 小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。 XDOCLET は思ったほど便利じゃないと言うか、 開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。 ↑これは設計がまずかっただけかも知れません。 663 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:17:11 ] >>662 Actionベースはやはり分かり易いですよね。 人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。 いくつかサンプル作ってみたのですが、3種類の感想は ActionSupport -確かに楽だけど、Springの楽しさは十分に味わえない気が。 　でも実装はまんまActionなんで、いたって簡単。 　しかもプログラマの質がそれなりなら、自分入れて3人位いれば 　中規模まで行ける気がする。 ActionProxy -実質これがStruts&Springの標準でしょう。 　至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで 　スムーズに作れそう。 　しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。 RequestProcessor -Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと 　思います。 　が、幾分硬すぎる気が。大人数のRUPには向いているかな。 自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、 まあ当たり前、と言った感想でしょうか。 今回はActionProxyからやってみようと思います。 時間もある分、新しい人も多いんで。 また進展したら報告します。　いらんか。 664 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:22:51 ] ＞また進展したら報告します。　いらんか。 最近スレが過疎ってるからチラシの裏でも問題ないかと。 ＞訳分からん害虫 でかいところが素敵なフレームワーク作ってるかと言うと そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。 665 名前：659 mailto:sage [2006/01/25(水) 22:18:20 ] >>664 なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。 確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。 1つはレガシーのためです。 やはり遺物であっても今から見ればあほあほなRDB設計であっても どうしても引きずらないではいられません。 例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは その他のホストのためにつないでやらないといけません。 おかげでせっかくのDAOも、結局は???になってしまいがちです。 これまで私も挑んだのですが砕け散りました。 もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。 本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、 掛けたくないのは人件費な訳ですから。 もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。 ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。 海外拠点との情報連携なんてつけてやれば大喜びです。 (フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・) と、過疎板でうだつのあがらん社内SEが独り言ってみました。 666 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:53:35 ] 664ですがマ板向きな話題になりそうなのでこの件はクローズ。 脱線させてごめんなさい。 667 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 00:03:48 ] すいません、Spring.NETの話題もここで良かったりします？ 668 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 09:45:51 ] わかんない。 けど、とりあえず書いてみれ 669 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:23:30 ] >>659 ＞うだつのあがらん社内SE お前様はオレですかｗ 疑問に思ったことを二つ。 ＞見易さ、改修性の高さ、開発規模から ＞ServiceはInterfaceを使わずに実装しました。 何故だよ？　facadeした方がP層から見たときに理解しやすいし、 実装ロジックを意識しないで済むと思うのだけど。あと例えば 君がAPI定義して、君の手下が実装する、なんて作業も スムースになると思うのだけど。 あと、その場所にSpringのTransaction制御は適用してるの？ それとも君達でゴリゴリ書いているの？ そこがSpringの一番美味しい所だと思うのだが。 670 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:24:23 ] ＜連投＞ ＞流行のSpringと扱い慣れているStrutsでと思っています。 扱い慣れているとはいえ、何故に死滅が確定している 現verのStruts？　同じ社内SEの立場として言うが、 それって将来に禍根を残すんじゃないの？ 特に、struts-taglibを使うのは忌むべきことじゃないのか？ 高度にクリティカルじゃなくてもいいなら、素直にJSFを 採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を 確保できねぇと言うなら、せめて org.springframework.ui.velocityパッケージの研究を してから決定した方がいいんじゃないの？ 671 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:13:28 ] 死滅とかはNG Wordに入れてる人も居るから避けたほうが吉。 JSF はもう少し枯れてからの方が良くない？ 今のところ、Velocity でやっちゃうのが一番直感的に思う。 672 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:24:21 ] うちで使ってるアプリケーションサーバーはJSPしか動かねぇ Servletすら使えない 673 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 15:42:57 ] 釣りには屈しない 674 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 09:47:13 ] おぉ、まだ居る方が。 >>669 ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。 まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。 で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが 恐ろしいことになり、ある意味好き勝手にやってもらいました。 で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。 iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで 助かります。 これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。 675 名前：659 mailto:sage [2006/02/01(水) 10:14:07 ] 書き忘れですが、674 = 659です。 Strutsについては、JSFでの置換えも検討しましたが、 今回、自分以外はJavaでWebやるの初めてなんですよね。 やはりﾌﾞﾗｳｻﾞからRequestをServletで受けて、というのを実感 し易いのはStrutsかなぁ、と思います。 JSF、VBちっくにﾄﾞﾗｯｸﾞ＆ﾄﾞﾛｯﾌﾟでできてしまうんで、最初からこれだと 裏の理解が薄く後々に生きない気がします。 それと社内SE的にはもう少し枯れてからで良いかなと、正直思います。 Taglibについては、個人的にこれ以上覚えられるかー、ということで beanとlogicにのみ制限しています。 まあ多少beanを拡張はしていますが。。。 個人的には、Struts → JSFで行きたいなと、Viewについては。 676 名前：669 mailto:sage [2006/02/01(水) 10:53:44 ] >>659 ＞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制御」だと、上の二つの メソッドを一つにまとめないと原始性を維持できないのでは？ 勘違いだったらｽﾏｿ。 677 名前：659 mailto:sage [2006/02/01(水) 12:13:46 ] >>669 DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。 でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、 2重ログインを防げば、問題無しという訳です。 美しくないことは、確かですが。 Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。 ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。 DAOは何を使われてるんですか? 今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。

---

---

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

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