Java Spring Frameworkを語るスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。
語るべし。
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と連携出来るようになる
0682デフォルトの名無しさん
2006/02/02(木) 01:36:230683659
2006/02/02(木) 10:15:36既存DB、IMSもRDBもわんさかあるんで、これまではiBatisだったんですよね。
ｵﾌﾞｼﾞｪｸﾄﾍﾞｰｽでのDB考えるなら、Hibernateというｲﾒｰｼﾞは確かに強いですよね。
そんな幸せな開発はやったことありませんが。
>>681、682
z/OS中心の製造業社内SE的には、Webのプレゼンテーション層については過渡期に
感じるので、枯れ果てた技術で十分かなと思います。
新しい技術を入れても今後ﾒﾝﾃする人が大変なだけですよ、うちのような環境では。
JDKにしても既存のものは1.4.Xが限度で、5にすることなんてありえません。
ぶっちゃけ、手間の割にﾒﾘｯﾄがあんまり考えられません。
それよりも新しいWASには5を導入する方向で考えると思います。
個人的にはJSFの熟成を期待しつつ、ちょっと複雑になりそうだったらﾘｯﾁで、
と行ければ良いなぁ。
・・・今はこんなこと考えている自分が、ちょっと嫌。
Javaを始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。
他に居ないのかな、こんな方。
0684デフォルトの名無しさん
2006/02/02(木) 11:17:28beanを使うべきじゃないとは言っても、
messageはなかなか避けられないような。
0685669
2006/02/02(木) 11:31:58新技術に対する感動を忘れたらオレらの仕事はつまらなく
なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって
やってるんだろーが。何でviewだけそんなに野望を失うのさ？
struts-taglibは、数年後には非推奨API（あるいはそれに準じた
無体な扱いを受ける立場）になるんだぜ？ 君は後進に
非推奨APIのメンテをさせる気かい？
JSF怖くないってｗ つーかあれ便利だぞ。少なくてもstrutsに
比べりゃね。なんつったて同じ作者の二番煎じなんだから。
JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。
練れてなくて意味無い所で苦労を強いられるのは認めるけど。
な〜んて書きながら、オレ自身もJSFマンセーには
なりきれないのだけどね。初期の頃に宣伝されたリッチ
クライアント対応とか全然進んでねぇし。（JDNCは実質
ポシャったみたいね） 早いとこJSPの呪縛から抜け出して
欲しいと思っているのに、なんか全然別の方向に逝こうと
しているみたいだし。。。
愚痴ｽﾏｿ
0686デフォルトの名無しさん
2006/02/02(木) 11:44:00ちょっとこなれてない感じ。 EL式とかアレだし。
sunのより高機能なんでmyfaces使っても、バグが結構あって
DataTableとか微妙な挙動をする場合がある。
1.2待ちかな
0687デフォルトの名無しさん
2006/02/02(木) 13:02:24messageは使うね。
>>686
2年もたってるのに、出来立てはないとおもう
0688659
2006/02/03(金) 12:37:57Viewも野望だけはあるんですけどね。
ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。
それにお偉方の説得材料が足りません。
もう暫くおとなしく待って、淘汰されてから選んで良いかな。
Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。
0689デフォルトの名無しさん
2006/02/03(金) 13:49:520690デフォルトの名無しさん
2006/02/15(水) 15:03:14many-to-one のﾏｯﾌﾟで、もし該当ﾃﾞｰﾀが存在しなくても怒られない方法、
知りませんか?
例えば
<class name="item">
<id name="id"/>
<many-to-one name="bid"/>
</class>
<class name="bid">
<id name="id"/>
<pro name="amount"/>
</class>
これで
from Item item left join fetch item.bid をやって、
取得したリストを表示させると、bidを取得できなかったitemの
item.bid.amountをgetすると、
LazyInitializ E org.hibernate.LazyInitializationException TRAS0014I: 次の例外がログに記録されました。 org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed
と、ｱﾎﾞﾝです。
session閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、
と思うんだけど、教えて下され。
0691デフォルトの名無しさん
2006/02/15(水) 15:11:12スレ違い
http://pc8.2ch.net/test/read.cgi/tech/1134701684/
0692690
2006/02/15(水) 15:56:38ｽﾏｿ
0693デフォルトの名無しさん
2006/03/07(火) 11:35:440694デフォルトの名無しさん
2006/03/07(火) 12:03:360695デフォルトの名無しさん
2006/03/07(火) 12:49:550696デフォルトの名無しさん
2006/03/07(火) 23:10:380697デフォルトの名無しさん
2006/03/07(火) 23:40:25結局クライアントコードに依存性を書いてる辺りが、
確かに従来のJavaの文法じゃないけど
アノテーションと言う名前のただの lookup じゃん、とか。
(DIとは関係ないが)@Statefulも
アノテーションと言う名前の implicit な interface になっただけで
同じことをするのに書法のバリエーションが増えただけで
Perl のガラクタ折衷主義を思い出したり。
0698デフォルトの名無しさん
2006/03/08(水) 22:01:48interfaceがメソッドに付けれますか、と。
"ただのlookup"ではないしな。
結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。
0699デフォルトの名無しさん
2006/03/09(木) 01:38:51DIとはいいがたいと思ってます。
＞"ただのlookup"ではないしな。
どんな嬉しさがあるか、教えていただけないでしょうか。
煩雑な記述が減る程度しか思いつきません。
＞interfaceがメソッドに付けれますか、と。
@Stateful はメソッドに付かないと思うけど。
0700デフォルトの名無しさん
2006/03/09(木) 03:37:13> クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。
つまり、DIをわかってないと。
0701デフォルトの名無しさん
2006/03/09(木) 13:01:150702デフォルトの名無しさん
2006/03/09(木) 22:20:05変ってないだろ。
君が勘違いしてるだけ。
0703デフォルトの名無しさん
2006/03/11(土) 15:16:19近い将来でseasar使うか2.0使うか迷ってるんだが、
Spring側の利点が見つからない・・・
両方つかってみたけど、seasarだとXMLをかなり省けるから
楽なんだが・・・
誰か意見ください。
0704デフォルトの名無しさん
2006/03/13(月) 13:14:45DIって、クライアント側で明示的にリソース指定した部分が
コンテナが注入するようになって素敵だよって流れだと思ってたんですが。
で、勘違いのない本当の定義とは？
>703
利点が見つからないならSeaser2使えば良いかと。
とりあえずXMLが省けることは多分大した利点にならんよ。
0705デフォルトの名無しさん
2006/03/13(月) 21:56:40>>704
そもそもEJB3のDIは「明示的にリソース指定」はしないぞ
＞とりあえずXMLが省けることは多分大した利点にならんよ。
その根拠は？
書かなくて済むのであれば書かないに越したことは無いし
XMLのメンテナンスだって馬鹿にならない
0706デフォルトの名無しさん
2006/03/13(月) 23:15:36DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。
@EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。
そのままSpringやSeasar使えばそれなりに注入される。
0707デフォルトの名無しさん
2006/03/14(火) 10:32:53確かに自分でインスタンスとってきてるわけではないね。
俺はとってくる情報が書かれてることそのものが嫌いなんですが
これはDIとは関係ないってことですね。
>その根拠は？
autowire 使えばそれなりに記述量は減るけれども
曖昧さが増えてかえって混乱を招くだけだった、との経験から。
Seasar2だと違うのかも知れない。
適当なこと言ってごめんなさい。
それにしても盛り上がらないスレですね。なんでだろ。
0708デフォルトの名無しさん
2006/03/14(火) 18:46:23現場ではほとんど使われてないから。
0709デフォルトの名無しさん
2006/03/14(火) 19:36:290710デフォルトの名無しさん
2006/03/14(火) 22:14:33トランザクションに関してはとても楽だが
0711デフォルトの名無しさん
2006/03/15(水) 17:34:47いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。
0712デフォルトの名無しさん
2006/03/15(水) 17:52:50うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは
jspしか使えない
0713デフォルトの名無しさん
2006/03/15(水) 21:47:240714デフォルトの名無しさん
2006/03/15(水) 22:14:35BroadVision One-To-One
以前はC++しか使えなかった。マジで。
■ このスレッドは過去ログ倉庫に格納されています