05/12/12 22:53:59
AnnotationとEnumの組み合わせが好きだな
XDocletとは違って定数を指定できるし、引数の型チェックも出来る
633:デフォルトの名無しさん
05/12/13 02:02:54
StrutsよりもJSFをもう少し簡単にした物を使いたい
634:デフォルトの名無しさん
05/12/13 09:39:22
>>630
ほらよ
URLﾘﾝｸ(www-06.ibm.com)
URLﾘﾝｸ(www5f.biglobe.ne.jp)
URLﾘﾝｸ(appfuse.dev.java.net)
URLﾘﾝｸ(equinox.dev.java.net)
勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを
作ってるヤツ。（Facadeかけてるやつ）
とりあえずIBMのヤツを熟読しろ。
635:教えてください
05/12/13 21:35:54
左クリックを使用できないようにjavaScriptを組んだつもりでしたが、機能しません。
どこが間違ってるのかご指南ください。
問題のＨＰ URLﾘﾝｸ(urei.ojaru.jp)
フレームを使用してますが
Ｉｍａｇｅｓ→***のリンク→左使用不可ページ となってます。
*** のページ 左使用不可ページ直リン防止script
左使用不可ページ 左使用不可script
このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ
もうどうしていいのか分りません
636:デフォルトの名無しさん
05/12/13 22:01:21
>>635 はスレ(板？)違いの上に、マルチ
637:デフォルトの名無しさん
05/12/14 10:05:47
板違いというより、基地外
638:デフォルトの名無しさん
05/12/16 02:08:32
Spring.NETの方はどうですか？
同じ？
639:デフォルトの名無しさん
05/12/16 13:48:47
>>638
Spring.NETは基本的なDI・AOPの機能は既に実装済み。
DB、トランザクション、WEB等の機能はまだ開発中みたいだな。
だけど、正直.NETでDIは使う気にならないな。
640:デフォルトの名無しさん
05/12/17 13:07:47
>>639
何故？
641:デフォルトの名無しさん
05/12/24 12:10:09
ActionSupportを使ってStrutsとSpring連携させてるんだけど
このクラスのテストケースをstrutstestcaseを使って書こうとした時に
Actionから呼び出すBeanを変えてテストケース書きたい場合
Bean定義のXMLを変えるしか方法がない？
テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、
642:デフォルトの名無しさん
05/12/25 01:54:24
自分で注入しちゃったら？
643:デフォルトの名無しさん
05/12/26 01:34:51
Struts + Sringでエ○画像掲示板つくってみました。
Spring入れたほうが動作は安定して早くなりました。
644:デフォルトの名無しさん
05/12/26 11:56:02
>>642
その方法がわからないんだよう
ポインタなぞあったら教えてぎぶみー
645:デフォルトの名無しさん
05/12/28 07:47:52
Spring2.0って機能面ではどう変わったんですか？
646:デフォルトの名無しさん
05/12/28 07:55:33
>>644
セッターインジェクションの場合
setXxx(value);
フィールドインジェクションの場合
xxx = value;
で注入できますｗ
647:デフォルトの名無しさん
05/12/28 14:12:36
>>645
設定ファイルがXML Schemaベースになってる。
648:デフォルトの名無しさん
05/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:デフォルトの名無しさん
06/01/08 02:38:17
フレームワークの議論ばかりしていて実際にハイレベルな
パフォーマンス＆拡張性が要求される現場では役に立たない
方々乙かれさまです。
650:デフォルトの名無しさん
06/01/08 03:19:20
どこでも役に立たない>>649よりはマシだけどな。
651:デフォルトの名無しさん
06/01/08 03:40:27
>>635>>637>>649
652:デフォルトの名無しさん
06/01/10 15:18:00
普通なら釣りなんだろうが現場見てると
本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。
さすがに起動時だけは遅いが、一度起動してしまえば
速度が気になったことはないな。
拡張性については具体的な例を挙げて欲しいな。
どういう要求が出た時にどういう対応をしたのかを。
653:デフォルトの名無しさん
06/01/11 03:07:47
HibernateDaoSupportを使う場合にQuery#setFirstResults(int)やsetMaxResults(int)を
使うにはどうすればいいかご存じの方はいませんか?
getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。
getSession()して自分で処理するしかないかな。
Spring 1.2.6 です。
654:デフォルトの名無しさん
06/01/11 11:24:00
>>653
HibernateCallback
655:653
06/01/11 22:34:55
>>654
return getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) {
// クエリ投げて結果を返す
}
}
って感じですね。マニュアルにも載ってました。ポイントありがとう。
656:デフォルトの名無しさん
06/01/21 20:54:23
URLﾘﾝｸ(pcweb.mycom.co.jp)
> 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:デフォルトの名無しさん
06/01/21 21:14:58
>>656
「藻ジュース」(・∀・)ｲｲ
658:デフォルトの名無しさん
06/01/22 10:27:33
いや飲みたくはない……
659:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/01/23 23:34:09
たいくつでつまらない技術が一番強い。
661:659
06/01/24 11:18:42
>>660
確かに、ごもっともだと思います。
実はこれまでの開発ではSpringを使う機会もあったのですが、
見易さ、改修性の高さ、開発規模から
ServiceはInterfaceを使わずに実装しました。
(さすがにDAOはiBatis使って分けましたが)
それに比べ、今回は10年前にCで作った参照のみのアプリの更新で
時間的な余裕もあるので遊びたいと思ってます。
APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、
といった使い分けの程度しか理解できませんでした。
みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。
662:デフォルトの名無しさん
06/01/24 13:57:58
>659
(1) と (3) は Struts に変更があったら、思い切り引きずられそう。
TilesRequestProcessor が出ようが新規に Action が発明されようが
涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。
(ていうか (2) しか使ったことないですけど。)
その分設定ファイルは煩雑になるわけですが。
自分の分かりやすいと思える方法でやるのが一番かと。
小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。
XDOCLET は思ったほど便利じゃないと言うか、
開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。
↑これは設計がまずかっただけかも知れません。
663:デフォルトの名無しさん
06/01/24 23:17:11
>>662
Actionベースはやはり分かり易いですよね。
人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。
いくつかサンプル作ってみたのですが、3種類の感想は
ActionSupport
-確かに楽だけど、Springの楽しさは十分に味わえない気が。
でも実装はまんまActionなんで、いたって簡単。
しかもプログラマの質がそれなりなら、自分入れて3人位いれば
中規模まで行ける気がする。
ActionProxy
-実質これがStruts&Springの標準でしょう。
至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで
スムーズに作れそう。
しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。
RequestProcessor
-Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと
思います。
が、幾分硬すぎる気が。大人数のRUPには向いているかな。
自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、
まあ当たり前、と言った感想でしょうか。
今回はActionProxyからやってみようと思います。
時間もある分、新しい人も多いんで。
また進展したら報告します。 いらんか。
664:デフォルトの名無しさん
06/01/25 12:22:51
＞また進展したら報告します。 いらんか。
最近スレが過疎ってるからチラシの裏でも問題ないかと。
＞訳分からん害虫
でかいところが素敵なフレームワーク作ってるかと言うと
そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。
665:659
06/01/25 22:18:20
>>664
なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。
確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。
1つはレガシーのためです。
やはり遺物であっても今から見ればあほあほなRDB設計であっても
どうしても引きずらないではいられません。
例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは
その他のホストのためにつないでやらないといけません。
おかげでせっかくのDAOも、結局は???になってしまいがちです。
これまで私も挑んだのですが砕け散りました。
もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。
本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、
掛けたくないのは人件費な訳ですから。
もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。
ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。
海外拠点との情報連携なんてつけてやれば大喜びです。
(フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・)
と、過疎板でうだつのあがらん社内SEが独り言ってみました。
666:デフォルトの名無しさん
06/01/25 22:53:35
664ですがマ板向きな話題になりそうなのでこの件はクローズ。
脱線させてごめんなさい。
667:デフォルトの名無しさん
06/01/29 00:03:48
すいません、Spring.NETの話題もここで良かったりします？
668:デフォルトの名無しさん
06/01/29 09:45:51
わかんない。
けど、とりあえず書いてみれ
669:デフォルトの名無しさん
06/01/31 10:23:30
>>659
＞うだつのあがらん社内SE
お前様はオレですかｗ
疑問に思ったことを二つ。
＞見易さ、改修性の高さ、開発規模から
＞ServiceはInterfaceを使わずに実装しました。
何故だよ？ facadeした方がP層から見たときに理解しやすいし、
実装ロジックを意識しないで済むと思うのだけど。あと例えば
君がAPI定義して、君の手下が実装する、なんて作業も
スムースになると思うのだけど。
あと、その場所にSpringのTransaction制御は適用してるの？
それとも君達でゴリゴリ書いているの？
そこがSpringの一番美味しい所だと思うのだが。
670:デフォルトの名無しさん
06/01/31 10:24:23
＜連投＞
＞流行のSpringと扱い慣れているStrutsでと思っています。
扱い慣れているとはいえ、何故に死滅が確定している
現verのStruts？ 同じ社内SEの立場として言うが、
それって将来に禍根を残すんじゃないの？
特に、struts-taglibを使うのは忌むべきことじゃないのか？
高度にクリティカルじゃなくてもいいなら、素直にJSFを
採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を
確保できねぇと言うなら、せめて
org.springframework.ui.velocityパッケージの研究を
してから決定した方がいいんじゃないの？
671:デフォルトの名無しさん
06/01/31 12:13:28
死滅とかはNG Wordに入れてる人も居るから避けたほうが吉。
JSF はもう少し枯れてからの方が良くない？
今のところ、Velocity でやっちゃうのが一番直感的に思う。
672:デフォルトの名無しさん
06/01/31 12:24:21
うちで使ってるアプリケーションサーバーはJSPしか動かねぇ
Servletすら使えない
673:デフォルトの名無しさん
06/01/31 15:42:57
釣りには屈しない
674:デフォルトの名無しさん
06/02/01 09:47:13
おぉ、まだ居る方が。
>>669
ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても
ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。
まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。
で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが
恐ろしいことになり、ある意味好き勝手にやってもらいました。
で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。
iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで
助かります。
これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。
675:659
06/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
06/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
06/02/01 12:13:46
>>669
DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。
でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、
2重ログインを防げば、問題無しという訳です。
美しくないことは、確かですが。
Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。
ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。
DAOは何を使われてるんですか?
今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。
678:669
06/02/01 13:12:05
う～ん、オレにはそれはチョト怖く感じる。
更新が途中で落ちる可能性なんてゴロゴロしてるワケだし。。。
（オレには納得いかんが）落ちる可能性を完全無視するとしても、
その場合は最低でもペシミスティックロックで組まんとイカンと
思うのだけど。。。
頼む、トランザクション管理層をserviceLayerに持ち上げとくれ。
Spring使えばチョチョイのチョイだ。
iBATISは好きだぉ。
679:デフォルトの名無しさん
06/02/01 16:24:19
>>669
仰ってることが分かってきました。
自分が話しをごっちゃにした予感です、害虫さんと自分の立場を。
害虫さんのﾄﾗﾝｻﾞｸｼｮﾝ管理は、はっきり言って、信用してません。
で、問題があった際にDAOとServiceを引っ張って考えるのはしんどいんで
DAOについてはiBatisのAutoCommitにして、自分はServiceに集中できるように
している、という話です。
読み返してみると、確かに訳分からん話してますね、自分。
そういえば、SpringとベストマッチなDAOって何でしょ?
iBatisもいけるようだとﾈｯﾄに載ってた気がしますが、やはりHibernateですかね?
他に面白いのないでしょうか。
680:デフォルトの名無しさん
06/02/01 20:56:14
HibernateはDBを一から設計するっていうならおすすめ
既存のDBがからむならiBatisの方が無難だとおもう
害虫さんがいてiBatis学習コストが気になるっていうなら
Spring JDBCでもいいんじゃない？
681:デフォルトの名無しさん
06/02/02 01:17:25
>>675
＞Taglibについては、個人的にこれ以上覚えられるかー、ということで
＞beanとlogicにのみ制限しています。
Strutsでやるんなら最低限必要なStrutsタグはhtmlタグのみで、後はJSTLで置き換えるのがお勧め
JSTLはJava EE5に含まれることが決定しているし、JSFも1.2からはJSTLと連携出来るようになる
682:デフォルトの名無しさん
06/02/02 01:36:23
お勧めとかではなく、beanとかlogicを使うべきではない、という感じだな。
683:659
06/02/02 10:15:36
>>680
既存DB、IMSもRDBもわんさかあるんで、これまではiBatisだったんですよね。
ｵﾌﾞｼﾞｪｸﾄﾍﾞｰｽでのDB考えるなら、Hibernateというｲﾒｰｼﾞは確かに強いですよね。
そんな幸せな開発はやったことありませんが。
>>681、682
z/OS中心の製造業社内SE的には、Webのプレゼンテーション層については過渡期に
感じるので、枯れ果てた技術で十分かなと思います。
新しい技術を入れても今後ﾒﾝﾃする人が大変なだけですよ、うちのような環境では。
JDKにしても既存のものは1.4.Xが限度で、5にすることなんてありえません。
ぶっちゃけ、手間の割にﾒﾘｯﾄがあんまり考えられません。
それよりも新しいWASには5を導入する方向で考えると思います。
個人的にはJSFの熟成を期待しつつ、ちょっと複雑になりそうだったらﾘｯﾁで、
と行ければ良いなぁ。
・・・今はこんなこと考えている自分が、ちょっと嫌。
Javaを始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。
他に居ないのかな、こんな方。
684:デフォルトの名無しさん
06/02/02 11:17:28
>682
beanを使うべきじゃないとは言っても、
messageはなかなか避けられないような。
685:669
06/02/02 11:31:58
おいおい、そんな後ろ向きになるなよ。
新技術に対する感動を忘れたらオレらの仕事はつまらなく
なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって
やってるんだろーが。何でviewだけそんなに野望を失うのさ？
struts-taglibは、数年後には非推奨API（あるいはそれに準じた
無体な扱いを受ける立場）になるんだぜ？ 君は後進に
非推奨APIのメンテをさせる気かい？
JSF怖くないってｗ つーかあれ便利だぞ。少なくてもstrutsに
比べりゃね。なんつったて同じ作者の二番煎じなんだから。
JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。
練れてなくて意味無い所で苦労を強いられるのは認めるけど。
な～んて書きながら、オレ自身もJSFマンセーには
なりきれないのだけどね。初期の頃に宣伝されたリッチ
クライアント対応とか全然進んでねぇし。（JDNCは実質
ポシャったみたいね） 早いとこJSPの呪縛から抜け出して
欲しいと思っているのに、なんか全然別の方向に逝こうと
しているみたいだし。。。
愚痴ｽﾏｿ
686:デフォルトの名無しさん
06/02/02 11:44:00
JSFも悪くないと思うけどね、まだ出来たてのせいか
ちょっとこなれてない感じ。 EL式とかアレだし。
sunのより高機能なんでmyfaces使っても、バグが結構あって
DataTableとか微妙な挙動をする場合がある。
1.2待ちかな
687:デフォルトの名無しさん
06/02/02 13:02:24
>>684
messageは使うね。
>>686
2年もたってるのに、出来立てはないとおもう
688:659
06/02/03 12:37:57
>>669
Viewも野望だけはあるんですけどね。
ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。
それにお偉方の説得材料が足りません。
もう暫くおとなしく待って、淘汰されてから選んで良いかな。
Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。
689:デフォルトの名無しさん
06/02/03 13:49:52
正直jsp2.0で十分な気が
690:デフォルトの名無しさん
06/02/15 15:03:14
Hibernate3初心者ですが、ちょっと教えて下さい。
many-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閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、
と思うんだけど、教えて下され。
691:デフォルトの名無しさん
06/02/15 15:11:12
>>690
スレ違い
ｽﾚﾘﾝｸ(tech板)
692:690
06/02/15 15:56:38
>691
ｽﾏｿ
693:デフォルトの名無しさん
06/03/07 11:35:44
保守、というか1.2.7記念。
694:デフォルトの名無しさん
06/03/07 12:03:36
EJB3.0 のどこが DI なのかと思い始める今日この頃。
695:デフォルトの名無しさん
06/03/07 12:49:55
つまり、勉強不足？
696:デフォルトの名無しさん
06/03/07 23:10:38
@EJBアノテーションによるフィールドインジェクションだが？
697:デフォルトの名無しさん
06/03/07 23:40:25
まぁ勉強不足なのは確かだが。
結局クライアントコードに依存性を書いてる辺りが、
確かに従来のJavaの文法じゃないけど
アノテーションと言う名前のただの lookup じゃん、とか。
(DIとは関係ないが)@Statefulも
アノテーションと言う名前の implicit な interface になっただけで
同じことをするのに書法のバリエーションが増えただけで
Perl のガラクタ折衷主義を思い出したり。
698:デフォルトの名無しさん
06/03/08 22:01:48
"アノテーション使ってるからDIじゃない"っていいたいの？
interfaceがメソッドに付けれますか、と。
"ただのlookup"ではないしな。
結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。
699:デフォルトの名無しさん
06/03/09 01:38:51
クライアント側でリソース名を明示的に書いているから
DIとはいいがたいと思ってます。
＞"ただのlookup"ではないしな。
どんな嬉しさがあるか、教えていただけないでしょうか。
煩雑な記述が減る程度しか思いつきません。
＞interfaceがメソッドに付けれますか、と。
@Stateful はメソッドに付かないと思うけど。
700:デフォルトの名無しさん
06/03/09 03:37:13
>>699
> クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。
つまり、DIをわかってないと。
701:デフォルトの名無しさん
06/03/09 13:01:15
そっか。DIの定義が変わったのか。
702:デフォルトの名無しさん
06/03/09 22:20:05
>>701
変ってないだろ。
君が勘違いしてるだけ。
703:デフォルトの名無しさん
06/03/11 15:16:19
2.0になってどう？
近い将来でseasar使うか2.0使うか迷ってるんだが、
Spring側の利点が見つからない・・・
両方つかってみたけど、seasarだとXMLをかなり省けるから
楽なんだが・・・
誰か意見ください。
704:デフォルトの名無しさん
06/03/13 13:14:45
>702
DIって、クライアント側で明示的にリソース指定した部分が
コンテナが注入するようになって素敵だよって流れだと思ってたんですが。
で、勘違いのない本当の定義とは？
>703
利点が見つからないならSeaser2使えば良いかと。
とりあえずXMLが省けることは多分大した利点にならんよ。
705:デフォルトの名無しさん
06/03/13 21:56:40
横槍ｽﾏｿ
>>704
そもそもEJB3のDIは「明示的にリソース指定」はしないぞ
＞とりあえずXMLが省けることは多分大した利点にならんよ。
その根拠は？
書かなくて済むのであれば書かないに越したことは無いし
XMLのメンテナンスだって馬鹿にならない
706:デフォルトの名無しさん
06/03/13 23:15:36
>>704
DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。
@EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。
そのままSpringやSeasar使えばそれなりに注入される。
707:デフォルトの名無しさん
06/03/14 10:32:53
DIに関して705氏と706氏の意見で納得。
確かに自分でインスタンスとってきてるわけではないね。
俺はとってくる情報が書かれてることそのものが嫌いなんですが
これはDIとは関係ないってことですね。
>その根拠は？
autowire 使えばそれなりに記述量は減るけれども
曖昧さが増えてかえって混乱を招くだけだった、との経験から。
Seasar2だと違うのかも知れない。
適当なこと言ってごめんなさい。
それにしても盛り上がらないスレですね。なんでだろ。
708:デフォルトの名無しさん
06/03/14 18:46:23
一部雑誌や新しいもの好きが飛びついてるだけで
現場ではほとんど使われてないから。
709:デフォルトの名無しさん
06/03/14 19:36:29
はい、飛びつきました
710:デフォルトの名無しさん
06/03/14 22:14:33
うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？
トランザクションに関してはとても楽だが
711:デフォルトの名無しさん
06/03/15 17:34:47
>>707
いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。
712:デフォルトの名無しさん
06/03/15 17:52:50
ｲｲﾅｰ
うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは
jspしか使えない
713:デフォルトの名無しさん
06/03/15 21:47:24
そりゃないんじゃね～の？
714:デフォルトの名無しさん
06/03/15 22:14:35
>>712
BroadVision One-To-One
以前はC++しか使えなかった。マジで。
715:デフォルトの名無しさん
06/03/15 22:14:55
713宛てだった
716:デフォルトの名無しさん
06/03/15 22:30:54
「Portal,Commerceの価格は1CPUで810万円からとなっております。」
ΣΣ（ﾟдﾟlll）
717:デフォルトの名無しさん
06/03/16 00:03:31
そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。
718:デフォルトの名無しさん
06/03/16 00:05:24
製品カタログ見ても何をするものなのかが分からん。
719:デフォルトの名無しさん
06/03/16 02:13:23
JSPしか動かないTomcatみたいなの
ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる
あと やたら高い
720:デフォルトの名無しさん
06/03/16 03:57:55
うちの会社で出してるゴミコンポーネントも945万円するお。
1年で1個売れれば万々歳だって。
721:デフォルトの名無しさん
06/03/17 16:09:08
そりゃむしろ、945万もするから売れるんだろう。
金を出す人間は、無料でしっかりしたモノを嫌がって
バカ高くてヘボいモノを好む傾向にあるから。
で、現場は地獄を見る、と。
722:デフォルトの名無しさん
06/03/17 17:20:41
無料だとちょっと問題が出るとすぐ捨てるけど、
金かけてると捨てるわけにはいかないからなあ
723:http://www.vector.co.jp/soft/win95/util/se072729.html
06/03/18 20:26:19
TextSS のWindowsXP(Professional)64bit化おながいします
もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
724:デフォルトの名無しさん
06/03/25 12:11:47
なあ、参照しかしないクエリーでもトランザクション切ってる
なんて事ないよな？
サービスのインスタンス化時にトランザクション切るのをデフォルト
にしてるのを見たことあるぞ。。。
同時アクセス数増えたとき、大変な事になるのがわからんのじゃろうか。
725:デフォルトの名無しさん
06/03/27 10:58:31
AOPでトランザクション管理するなら、
READだけの処理では普通は開かんようにするはず。
726:デフォルトの名無しさん
06/03/27 14:11:08
>AOPでトランザクション管理するなら
してなかったりして
727:デフォルトの名無しさん
06/03/27 16:22:43
貼っとく
【BEA】Using the Java Persistence API with Spring 2.0
URLﾘﾝｸ(dev2dev.bea.com)
728:デフォルトの名無しさん
06/03/27 19:02:56
>>724
どうして大変な事になるの？
729:デフォルトの名無しさん
06/03/28 09:58:12
複数のテーブルを参照してひとつのデータを作るような場合は、
読み込みでもトランザクションきらないとまずいんじゃないの？
730:デフォルトの名無しさん
06/03/28 10:11:35
>>729
> 複数のテーブルを参照してひとつのデータを作るような場合は、
JOINではなくて、複数のSELECT発行って事？
731:デフォルトの名無しさん
06/03/28 11:05:09
>>730
ISOLATION_LEVELのデフォルトって普通はREAD_COMMITTEDじゃないの？
複数のSELECTまで考えるとISOLATION_LEVELをREPEATABLE_READに変更しないと駄目じゃない？
732:デフォルトの名無しさん
06/03/28 11:33:17
>>731
InnoDBのデフォルトはREPEATABLE_READみたいだなあ
733:730
06/03/28 11:45:37
>>731
>>732
DBベンダによってデフォルトが異なる。んで、大抵はREPEATABLE_READ(らしい)。
結論としては、複数のSELECTを発行するサービスのメソッドは
トランザクション制御しなきゃならんって事か。
734:731
06/03/28 11:59:04
>>732
Oracleのデフォルトは文レベルの読み取り一貫性(READ_COMMITTED)だったような...
>>733
>結論としては、複数のSELECTを発行するサービスのメソッドは
>トランザクション制御しなきゃならんって事か。
加えて以下の様に明示的にISOLATIONレベルを指定しないといけないのかな？
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ, readOnly</prop>
</props>
</property>
735:733(=730)
06/03/28 12:24:32
>>734
いささか古いが、
URLﾘﾝｸ(www.tomlauren.com)
によると、OracleのデフォルトはREAD_COMMITTEDみたいだ。
でも、REPEATABLE_READがNotSupportって事になると、
SERIALIZABLEしかないな。
最新の公式資料キボン。
736:731
06/03/28 14:16:43
>>735
Oracleで以下の操作をやると
conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ);
java.sql.SQLException:
READ_COMMITTEDおよびSERIALIZABLEのみが有効なトランザクション・レベルです。
...
ってエラーが出るよ。
Oracleだと更新処理を伴うトランザクションでトランザクションレベルの読み取り一貫性を
保証したいのであればSERIALIZABLEを指定するしかないのでは？
※更新処理を伴わないのであればreadOnlyだけで大丈夫みたい
でも実際にSERIALIZABLEがどうしても必要になる局面があんまり無いような気も...
で、元の話は
>>724
> なあ、参照しかしないクエリーでもトランザクション切ってる
> なんて事ないよな？
ってことだけどこれって
読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、AutoCommitも無効にしている場合、
明示的にトランザクションを開始する必要があるのか？
という意味なのかな？
737:デフォルトの名無しさん
06/03/28 16:19:46
Strutsを使った場合の、AOPによる宣言的トランザクション管理について意見を聞かせてください。
(前提)
・サービスクラスの各メソッドはAOPによって宣言的トランザクション管理されている。
(処理)
・リクエスト->更新Action->表示Action->JSPとディスパッチする。
・更新Actionと表示ActionはサービスクラスのupdateHoge()やfindHoge()を呼び出す。
これだと、1回のリクエスト中に2つのActionが2回ビジネスロジックを実行するから、
トランザクションも2回発生してしまいますよね？(1操作=2トランザクション)
何となく腑に落ちませんが、これが当たり前なんでしょうか？
それとも、Facadeサービスから更新も検索もまとめて呼ぶべきでしょうか？
更新と検索の引数リストが全く異なる場合はFacadeしたくないんですが…
738:デフォルトの名無しさん
06/03/28 20:03:23
好きにしろとしか……
個人的には、更新作業の頻度次第で決める
739:デフォルトの名無しさん
06/03/29 11:26:28
本家よりコピペ
Spring 2.0 Release Party in Stuttgart (organized by JUGS)
Submitted by Juergen Hoeller on Fri, 2006-02-24 18:31. Event
Start: 2006-03-30 14:00
End: 2006-03-30 23:00
Timezone: -14400
いよいよ2.0が間もなく到来だぬ。
ところで2.0の目玉って何なのさ？（恥）
740:デフォルトの名無しさん
06/03/29 16:35:27
>>738
んじゃ、Action2つにする。
とりあえず、HibernateでOpenSessionInViewしておけばAction2つでも
1トランザクションになるよね？
741:デフォルトの名無しさん
06/03/31 23:11:17
>>740
トランザクションとHibernateのセッションの区別はついてますか？
742:デフォルトの名無しさん
06/03/32 00:26:43
これ、掻い摘んでいうと何？
743:デフォルトの名無しさん
06/03/32 01:38:39
軽量コンテナ
744:デフォルトの名無しさん
06/03/32 05:59:35
>>742
「Java2EEなんかクソくらえ」
745:デフォルトの名無しさん
06/03/32 06:03:37
今日は32日だ。うそをついていい日ではない。
746:デフォルトの名無しさん
06/03/32 10:39:20
URLﾘﾝｸ(www.2ch.net)
＊エイプリルフール中止のお知らせ＊
本年度、ITバブル崩壊の余波、またライブドア事件の混迷、楽天ゴールデンイーグルスぶっちぎり最下位など、
悪条件の重なりによる株価低迷が２ちゃんねる運営費にも多大なる影響を与え、
火の車である今の財務状況を鑑みるに、エイプリルフールの全面中止もやむなしという判断にあいなりました。
ご期待されていた皆様には大変申し訳ありませんが、どうぞよろしくご理解いただければ幸いです。
また、妄言民族と呼ばれ、近隣アジア諸国に多大なる苦痛を与えている日本国民としてこれを良い機会と考え、
例えエイプリルフールだとしても嘘を無くし、世界平和に貢献できる公明正大な言論の場を標榜すべく襟を正しつつ、
２ちゃんねるはエイプリルフールの根絶に今後とも邁進していく所存でございます。
747:724
06/04/02 12:30:05
>読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、
>AutoCommitも無効にしている場合、明示的にトランザクションを開始する必要があるのか？
そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
データをコピーしている（OracleとSQL Serverは少なくともそう）。
この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
（同時アクセスが多いと、Tempがクリアされる前に次が来ちゃうからじゃ）
このエラーを受けてDB屋にTemp領域増やせっていうのはナンセンス。
もちろん、ビジネスロジック上大きなTempが必要な場合もあるからそれは、
ちゃんと見積もりをDB屋に伝えればいい。大きくするのに否定的な訳じゃなく
PGの手抜きに対して文句を言ってるんじゃ。
また、上記の事だけじゃないが、上記だけからでも結構コスト（負荷）
が掛かることは言うまでもないよな。
748:デフォルトの名無しさん
06/04/02 13:10:03
>>747
> そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
> データをコピーしている（OracleとSQL Serverは少なくともそう）。
オラクルは違うだろ。
データがコピーされるのは読み取り時じゃなくて更新時。
コピー先はテンポラリじゃなくてUNDO表領域。
> この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
頻繁に閲覧されてもそれだけじゃエラーにならない。
頻繁に更新されている時にのんびり読んでるとORA-01555
本当に理解して書いてるか？
749:デフォルトの名無しさん
06/04/02 15:04:58
> > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
>
> 頻繁に閲覧されてもそれだけじゃエラーにならない。
> 頻繁に更新されている時にのんびり読んでるとORA-01555
> 本当に理解して書いてるか？
激しく同意。
付け加えるなら、Oracleではトランザクションの有無にかかわらず
文レベルの一貫性は常に保証しようとするから、
> 頻繁に更新されている時にのんびり読んでるとORA-01555
という状況はトランザクションの有無にかかわらず起こりうる。
だから、>747の主張は少なくともOracleには当てはまらない。
750:740
06/04/02 18:58:45
>>741
スマソ＆サンクス
考えてみれば、サービス層でAOPトランザクション管理していると、
複数Actionが複数サービス呼び出す時点で複数トランザクションになる…
んでOpenSesseionInViewしてもHibernateのSessionが1つに保たれるだけですな。
結論すると、2Actionだと2トランザクションでいくしかないのか。
751:731
06/04/03 14:34:04
あんまりSpringと関係が無くなって来たような気が...
>>747
>>748
>>749
読み取り一貫性に関しての詳細は置いておいて元の話だとOracleでは
以下になるんじゃないかな？
必要な読み取り一貫性が文をまたがるのであれば読み取り専用の
トランザクションを明示的に開始する必要がある。
必要な読み取り一貫性が文レベルでよいのであれば明示的にトランザクションを
開始しなくても良い(コネクションを生成した際のトランザクションがずっと使われている)
但し、更新処理の前にはCommitを発行して明示的にトランザクションを開始する必要がある
どちらにしてもOracleで更新やロックを伴わないトランザクションでCommitを行っても
無視される(v$sesstatのuser_commitは増えない)のでパフォーマンスには大した影響を与えない
結局のところ空コミット(参照のみトランザクションでのコミット)のコストの話なのかな？
752:740
06/04/07 20:14:03
今さらだが、ようやくStruts+Spring+Hibernate
(DelegatingActionProxy、
StandardXAPoolDataSource、
JOTM、
OpenSessionInViewFilter、
JtaTransactionManager)
のアプリが作れたよ…
さて、次はSeasarも試してみるか…
753:デフォルトの名無しさん
06/04/07 23:51:41
Hibernateって使える？
754:デフォルトの名無しさん
06/04/08 06:37:50
Java標準になったくらい使える。
755:デフォルトの名無しさん
06/04/08 13:40:24
DB設計がしっかりしているならHibernate
DB設計が腐っているならiBATIS
どっちも便利であるのは間違いない。
適材適所で。
756:デフォルトの名無しさん
06/04/27 06:56:47
spring 使いたい。しかしEJBコンテナを捨てるには問題が。
リモート呼び出しやORM（hibernateで）は置き換えることが
できたけど、EJBのMessage Driven Beanを代替するものが
見つからない。MDB便利すぎる。
757:デフォルトの名無しさん
06/04/28 01:17:20
Struts+Springで
SpringのViewクラスを使用したい場合は
どうすれば良い？
758:デフォルトの名無しさん
06/04/28 21:03:44
それってStruts使う意味あんの?
759:デフォルトの名無しさん
06/04/29 20:34:44
>>757
既存システムとしてStrutsの部品があって
ExcelとかPDFを出力したいので
SpringのViewを使用する
760:デフォルトの名無しさん
06/04/29 20:36:33
つ POI
761:デフォルトの名無しさん
06/05/08 16:21:07
Struts(SpringのStrutsインテグレーション機能)とSpringMVCって同時に動作できないの？
web.xmlとXXX-servlet.xmlを調整すれば、実現できそうだけど？
762:デフォルトの名無しさん
06/05/09 09:52:00
1.2.8記念
って何なのこれ？
763:デフォルトの名無しさん
06/05/10 18:31:22
1.2.8 についてか、Spring についてか。＞何なの
764:デフォルトの名無しさん
06/05/11 00:10:50
クラス属性に対応するbean定義の<property name>の値って、何でもいいんだな。
setterの名前さえ整合性が取れていれば。
765:デフォルトの名無しさん
06/05/19 09:53:31
貼っとく
Rodが語った2.0@JavaOne
URLﾘﾝｸ(www28.cplan.com)
user:contentbuilder
pass:doc789
766:デフォルトの名無しさん
06/05/19 14:31:03
>765
thx.
Message-Driven POJO なんて構想もあったのか。初めて知った。
Extensible XML Confinguration は
俺様設定が乱立しそうでちと怖いな。
767:デフォルトの名無しさん
06/05/19 14:32:45
>>761
そりゃできるだろ。
768:デフォルトの名無しさん
06/05/19 16:50:26
では757は解決だな
769:デフォルトの名無しさん
06/05/20 00:21:20
ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合、どうしてます？
いい方法を考えているうちにgetBean("BeanId")のコードがいっぱいできた
まんまプロジェクト終盤にきてしまった。。。
770:デフォルトの名無しさん
06/05/20 00:56:56
そんなに気にしなくていいと思うけど、
getBeanId()のメソッドを用意して静的にアクセスできるようにはしてる。
771:デフォルトの名無しさん
06/05/20 00:59:34
もちろんID取得もSpringで管理するんだよな?
772:デフォルトの名無しさん
06/05/20 01:01:22
そもそも、自分でgetBeanしなくていいように作ります。
StrutsならDelegatingActionProxy使えばいいし
TapestryもSpringと連携させてコンポーネントにInjectしてもらえるし。
773:デフォルトの名無しさん
06/05/20 06:12:45
それができない場合はルックアップするしかない。
どこからでもルックアップできてしまうので収集がつかなくなるおそれはあるけど、
>>770 のように bean の種類ごとにルックアップするメソッドを用意しておけば
いく分見通しもよくなると思われ。
774:デフォルトの名無しさん
06/05/20 08:56:55
それただのサービスロケータになってる
別にいいけど
775:デフォルトの名無しさん
06/05/20 12:58:25
サービスロケータだと何がダメなの?
776:デフォルトの名無しさん
06/05/20 13:05:37
DI自体がサービスロケータ
777:デフォルトの名無しさん
06/05/20 15:56:24
>>775
サービスロケータに依存してしまうからですよ。
778:デフォルトの名無しさん
06/05/20 15:59:55
ただ、サービスロケータはコンパイルエラーでミスを検地できるので
単純にどっちが上とかはいえない
ってDIってネーミングつけた人いってなかったっけ？
779:775
06/05/20 16:13:32
>>777
なるほどー。ありがとうございます。
となるとそれくらいの依存は気にならないなー。
元レスは注入できない場合の話だし
780:769
06/05/20 16:55:15
かといって他の解決方法もないのですよね。たぶん。
ドメインモデルとは相性が悪いのでしょうか。やはり。
いまさら設計をトランザクションスクリプトにできないし。。。
まっ宣言的トランザクションだけでもかなり有効であることには
変わりないわけだし。
781:デフォルトの名無しさん
06/05/20 22:52:38
＞ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合
ってどういう場合なんだろう？
素朴な疑問。
782:デフォルトの名無しさん
06/05/21 03:47:30
私が使っているフレームワークにはイベントリスナを登録しておくと
コールバックしてくれるという機能があるけど
イベントリスナには依存性注入のチャンスがないのでApplicationContextを使う。
783:デフォルトの名無しさん
06/05/21 07:33:25
>>782
ここで解説されているみたいなことをやるべし
URLﾘﾝｸ(www-128.ibm.com)
784:782
06/05/22 00:01:56
>>783
自分でインスタンスを生成する必要がある場合の話です。
785:769
06/05/22 15:49:50
getBeanを利用する主な場面とは。。。
たとえば親子関係をなすドメイン（請求書と請求明細）などは
ロジック上で画面の内容をドメインに変換する必要があるのですが
明細クラスのような１クラスで複数インスタンス必要になる場合は
betBeanで必要数分インスタンスを生成する必要がある。
みたいな場面です。
786:デフォルトの名無しさん
06/05/22 16:54:00
>>785
内部でインスタンスを生成する必要があるロジックの場合は、
そのインスタンスを生成するFactoryクラスをインジェクトする
ってのをよくやる。
787:デフォルトの名無しさん
06/05/23 22:20:49
てかドメインモデルとはめちゃ相性悪い。
アナパタ時代の設計にDI使おうとすると死ねる
788:デフォルトの名無しさん
06/05/24 11:41:00
よくわからんが、
higaﾀｿが提唱しているシンドメインモデルならドメインロジックだけDIにして、ドメインモデル(データ)
だけ通常の手段(new)で生成すればよいのでは？
URLﾘﾝｸ(d.hatena.ne.jp)
789:デフォルトの名無しさん
06/05/24 13:07:20
▽どっちが速いSeasar2 VS Spring
URLﾘﾝｸ(cm.thinkit.co.jp)
790:デフォルトの名無しさん
06/05/24 14:00:57
>>788
オレもそうしてる。ドメインのPOJOは自分でnewする方がOOしてる気分になるね。
DIに生成させるのはServiceLayer～DataStoreLayerのドメイン『操作』クラス達だぬ。
>>789
ｷｬﾊｷｬﾊ。なんかヒガﾀｿ最近人格が変わった？ JavaOneでイジメでもくらったのかな。
PowerdBySpringのフレームワークがこんなにポコポコ誕生している現状を見れば、
1.2.xとスピード競争やった所で焼け石に水ﾀﾞﾇ。
AspectJが推奨スタイルになる2.0のこと知らぬ訳ではないだろうにね。
別にRodファンではないけどさ。
791:デフォルトの名無しさん
06/05/24 15:39:44
785が考えるケースで getBean() することはない。
データは普通に new したらいい。
なんで getBean() しようとしたのか教えてくれ。
メリットが何一つ思い浮かばない。
792:788
06/05/24 17:02:50
>データは普通に new したらいい。
激しく同意。
ビジネスロジック周りでDIしたいと思うなら、
ドメインビジネスとしてクラスを切り分ければいいのでは？と思った次第。
793:769
06/05/24 22:06:40
>シンドメインモデル
>ドメインビジネスとしてクラスを切り分ければ。。。
ということは、私の思うトランザクションスクリプト + DAOという
組み合わせがDIでは有効という考えと同意と考えられます。
そちらのほうが合っているという結論ですよね。結局は。
DIを利用する上では状態をもつドメインはミスマッチであるということですね。
794:769
06/05/24 22:24:03
>なんで getBean() しようとしたのか教えてくれ。
>メリットが何一つ思い浮かばない。
785であげた例も悪かったですが。。。
1.getBeanするドメインが他のドメインを持っている。
オブジェクトグラフの一気取りが可能（Factory作ればすむという話もあるが）
2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
この２つはかなりのメリットです。
もちろん前提がドメインロジックとデータの分離であれば、データに対して
getBeanするメリットが何もないというのは理解できますが。
DIを利用する上では状態をもつドメインはミスマッチである
けれども
上記の理由があるためドメインモデルでもDIを採用しました。
けれども
getBeanする部分をもっといいやり方はないですかねーという質問でした。
795:デフォルトの名無しさん
06/05/25 01:09:09
Hibernate等のORマッパでドメインモデルを取得すれば、
one-to-manyなんかの関係は勝手に構築してくれる。
1の芋づる式にとりたいというだけでgetBeanするのはDIの役割とは違う希ガス。
（もしかして、DAOが生成するデータが≠ドメインモデルな設計？）
>2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
はちょっと意味が理解できん。ｽﾏｿ。解説ｷﾎﾞﾝ。
>DIを利用する上では状態をもつドメインはミスマッチである
と
>上記の理由があるためドメインモデルでもDIを採用しました。
は納得できないなぁ。
そう考えた理由は？
あと、ビジネスロジックを切り出しただけでトランザクションスクリプトって呼ぶの？
SQLで記述するのか、呼び出し側の言語で記述するのか、が
ドメインモデルとトランザクションスクリプトの最大の相違だと思ってた。
URLﾘﾝｸ(capsctrl.que.jp)
796:デフォルトの名無しさん
06/05/25 01:14:00
うーん、ドメインモデルとかDIとかいろいろいじった結果一時DIに傾倒したが....
結局ところ、ドメインモデルのサポートとしてDIを使うくらいにしておきたいと
思った。
もしどうしてもどっちかを取らなくちゃいけなくなったら、サービス層を内製しても
ステートフルなドメインモデルを選択したい。Hibernateとか使うと、リッチなJava
オブジェクトをそのままＤＢにマッピングできたりするし。
それに、そっちのほうがオブジェクト指向っぽい感じがするから。
797:デフォルトの名無しさん
06/05/25 15:57:44
精読したが
＞ 上記の理由があるためドメインモデルでもDIを採用しました。
の結論に至った理由が理解できなかった。
実際何を getBean() したのかが分からない。
getBean(リテラル文字) まくりな状況より
new した方が可読性高いし変なキャストもせずに済む。
設定ファイルで singleton="false" を書き忘れる心配もない。
どうしても生成部分を隠したいなら、
簡単な Factory を作って、そいつを DI でセットしたらいい。
798:デフォルトの名無しさん
06/06/29 07:36:24
RC2あげ
799:デフォルトの名無しさん
06/07/04 09:35:38
過疎スレ保全
つか、2.0期待sage
800:デフォルトの名無しさん
06/07/04 20:58:53
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所 所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ－ｗａｎｔ－ｔｏ－ｓｔｕｄｙ－ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
801:デフォルトの名無しさん
06/07/05 03:49:26
コンビニのバイトより安いですが、よろしくお願いします。
802:デフォルトの名無しさん
06/07/05 16:53:11
おひおひ、1,000\/h っていくら何でも安すぎだよ。
それじゃ労働しようとする意欲湧かねぇな。
君が♀なら別。
803:デフォルトの名無しさん
06/07/05 17:12:10
javaを教えると一言に言っても色々あるしな
804:デフォルトの名無しさん
06/07/05 19:13:48
Springと関係ないな
805:デフォルトの名無しさん
06/07/05 19:33:12
>>804
つーかスレタイにJavaが含まれているスレに無差別絨毯爆撃しているだけだから無視するのがよろしいかと
806:デフォルトの名無しさん
06/07/05 22:35:28
しかし以外にたくさんあるんだな。
>つーかスレタイにJavaが含まれているスレ
ブックマークしていながら、今回のマルチが出るまで気づかなかった。
807:デフォルトの名無しさん
06/07/07 15:39:40
Spring WS のドキュメントが結構揃ってきたすね。
前は XML-Object Mapping の章しかなかったのに。
そろそろまじめに調べ始めるかな。
808:800
06/07/17 21:33:22
教える対象は超初心者です。
専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
809:デフォルトの名無しさん
06/07/18 12:06:26
javaの前に常識って物を勉強したほうが良いと思います^^;
810:800
06/07/18 12:49:11
常識も教えていただければと思います。
811:デフォルトの名無しさん
06/07/18 14:19:48
ここで聞いても学べません
812:デフォルトの名無しさん
06/07/20 22:25:56
もはや完全にSeasarに押されてるな。
813:デフォルトの名無しさん
06/07/21 00:57:25
>>812
獄長乙
814:デフォルトの名無しさん
06/07/21 23:57:04
WebMVCのSimpleFormControllerで、
フォームのパラメータ名とCommandのフィールド名を
任意にマッピング（バインド）する方法がわからない…
815:デフォルトの名無しさん
06/07/24 17:54:58
spring:bind使ってないの？
816:デフォルトの名無しさん
06/07/26 12:31:58
Java World 2006/09 特集
2.0 とか関係なしに
・EJB3.0 に懐疑的
・ORM は最終的に JDBC に回帰する
な姿勢が良かった。
あと Acegi の記事が後で役に立ちそう。
817:デフォルトの名無しさん
06/08/01 13:18:00
漏れJavaWorld斜め読みした所。詳しくはこれから読む。
豆蔵が書いたのねコレ。漏れは以前、長谷川ダンナの話を
聞いたことがあるのだが、
「Hibernateは確かに優れたプロダクトだが万能じゃない。
陥りやすい穴もあるから慎重に検討してから導入した方がいい。」
って言ってた。禿同だったんだけどね。今回の記事もその思想が
根底に流れているみたいだね。
JPAマンセーな流れの中でこういう視点は貴重だと思う。
818:デフォルトの名無しさん
06/08/09 01:22:18
Servlet依存のコード(JSFバッキングBeanも含む)とサービスメソッド
のデータ受け渡しってPOJOでもDTO使った方がいいのかな？
直にビジネスオブジェクト受け取った方がコーディングが楽なんだが・・・
819:デフォルトの名無しさん
06/08/10 09:35:55
>>818
URLﾘﾝｸ(www.atmarkit.co.jp)
から抜粋
このように、POJOをそのままEntity Beanとして扱うことができれば、従来のEJB開発で
Web層とのデータ交換に利用されてきたDTO（Data Transfer Object）パターンはもはや
不要となる（実のところ、J2EEパターンの多くはEJBの使いにくさを緩和するために
生み出されたアンチパターンであるという見方もある）。
820:デフォルトの名無しさん
06/08/15 22:23:19
うーん、結局、「Web層」って、BCE でいうと、どこになるんだろか。
「Web層」がBだけの役割であれば、M に B を依存させないために、
DTO(のようなもの)は必要のような気がする。
表示で使うPOJOを直接永続化するということは、
逆に永続化の都合に（N:N関係は扱えないとか）、
表示部のロジックが依存してしまう、ということになるんじゃないの？
821:デフォルトの名無しさん
06/08/16 10:13:12
この本の書評たのむ。
URLﾘﾝｸ(www.amazon.co.jp)
特にオレが知りたいのは、
・2.0を紹介してるか。
・JPAを使ったWebApp例で、マンセー記事ばかりではなく
注意点やアンチパターン的な解説もしているのか。
・SpringWebServiceの解説あるのか。
・SpringRichClientとかAcegi(SpringSecurity）の解説あるのか。
でも、読んだ印象でも何でもいいから知りたい。
822:デフォルトの名無しさん
06/08/17 11:01:55
>820
> 表示で使うPOJOを直接永続化するということは、
> 逆に永続化の都合に（N:N関係は扱えないとか）、
> 表示部のロジックが依存してしまう、ということになるんじゃないの？
シンプルなアプリなら問題ないと思うんだが。
ただ、発想としては「永続化するPOJOを直接表示する」が正しいかと。
どうしても気になるなら、
サービス層で永続化用DTOからプレゼン用DTOへ変換してやれば良いと思う。(higaﾀｿのシンドメインモデルってやつね)
問題は、プレゼン用DTO・変換ロジックを実装するコストに対して価値があるかどうか。では？
823:822
06/08/17 17:21:40
間違い。
× シンドメインモデルってやつね
○ Dxoってやつね
あと
URLﾘﾝｸ(capsctrl.que.jp)
824:デフォルトの名無しさん
06/08/22 09:50:14
貼っとく
【IBM】Introduction to Spring 2 and JPA
URLﾘﾝｸ(www6.software.ibm.com)
825:デフォルトの名無しさん
06/08/25 23:20:47
URLﾘﾝｸ(www.sssg.org)
Seasarの連中もキモイけどこれもイタイ。
826:デフォルトの名無しさん
06/08/25 23:23:36
>>824
ログインパスワード教えて
827:デフォルトの名無しさん
06/08/26 09:06:37
>>825
ゆるされるはんいじゃない？
828:デフォルトの名無しさん
06/08/26 10:29:20
回答がおもろい。
829:デフォルトの名無しさん
06/08/26 23:38:21
仲間由紀恵でなく蛯原友里にすべき
830:デフォルトの名無しさん
06/08/27 23:31:05
>>829
仲間由紀恵は沖縄出身
831:824
06/08/28 09:30:04
>>826
ごめんごめん、先に米IBMの会員登録してくれ。
無料＆誰でもOKね。
URLﾘﾝｸ(www.ibm.com)
832:デフォルトの名無しさん
06/08/28 12:16:59
抜粋くらいないとわざわざ会員登録してまで見ようとは思わない。
833:デフォルトの名無しさん
06/08/28 12:43:34
ここでそんな文句言われても…
834:824
06/08/28 18:21:41
序文
Java server applications need not be difficult and tedious to create.
Now in its second generation, the lightweight Spring framework adds a large suite of features
that make it simple for even new server application developers to use.
One key enhancement is Spring 2's integration with the Java Persistence API (JPA),
a cornerstone of the Enterprise JavaBeans (EJB) 3.0 specification. In this tutorial,
learn how to create server applications from scratch using the Spring 2 framework.
835:824
06/08/28 18:26:13
その次
Before you start
For almost a decade, the "proper" way to build a robust and
maintainable server-side Java application has been the exclusive domain
of the Java 2 Enterprise Edition (J2EE) platform.
J2EE applications are built using Enterprise JavaBeans (EJB) technology
and run on servers that facilitate deployment and provide rich container services
(such as the management of database connections and pooling).
These servers also add value by providing deploy-time declarative control of
important features such as security and transactions. Although versatile,
the J2EE development process involves many tedious and repetitive tasks
and the creation and maintenance of large numbers of source code files.
Many lightweight Java frameworks claim to simplify server application development,
but none matches the Spring framework in maturity and popularity (see Resources).
Now in version 2, Spring was designed from day one to simplify the server application
building process.
836:デフォルトの名無しさん
06/08/28 18:26:48
その次
Instead of approaching development from an all-in-one container perspective,
Spring aims to provide just enough support for an application's requirements
without the burden of a full-fledged container environment. Spring eliminates code bloat:
you can code and test business objects completely outside of any container,
letting your business-object code remain simple, testable, maintainable, and reusable.
With the arrival of Java EE 5 and EJB 3.0, the J2EE community is poised to meet
the Spring developer community. EJB 3.0 supports the notion of lightweight POJOs
(Plain Old Java Objects) as EJB components and introduces the Java Persistence API (JPA),
a persistence mechanism that can run externally to the container.
This persistence mechanism automates the movement of information between business objects
and external relational databases.
Version 2 of the Spring framework has continued its evolution and also leverages JPA
as a persistence mechanism.
In this tutorial, you will work with Spring 2 and JPA persistence.
You'll create a server application using the Spring 2 framework, complete with access
to a DB2 Express-C database. The Eclipse IDE facilitates the development of the Java application
and enhances your exploration of the Spring 2 framework.
これ以上は面倒見ない。
837:デフォルトの名無しさん
06/08/29 10:38:46
いつの間にやら SpringLDAP っちゅーSubProjectができてるね。
これってAcegiと被ってないんだろうか・・・？
どうやって棲み分けしようとしているのか、理解している人いたら教えて。
838:デフォルトの名無しさん
06/08/29 17:36:04
acegi とはレイヤーが違う。
LDAP ってセキュリティとはあまり関係ないのでは。
一種のDBを操作するプロトコル(書きより読みに重点)
程度のもんだと思う。
839:デフォルトの名無しさん
06/08/30 08:04:35
>>821
Acegi使ったサンプルは載ってた。
840:デフォルトの名無しさん
06/08/31 10:13:57
Eclipse RCPとSpringによる実用的なシッククライアントの構築
URLﾘﾝｸ(codezine.jp)
841:デフォルトの名無しさん
06/08/31 11:59:47
>>799
> 過疎スレ保全
> つか、2.0期待sage
Web2.0に期待揚げ
842:デフォルトの名無しさん
06/08/31 15:09:25
マーケティング用語なんてどうでもいい
843:デフォルトの名無しさん
06/08/31 15:12:01
「Web2.0」を使いたがるのは40代以上
844:デフォルトの名無しさん
06/08/31 17:58:42
>>838
説明thx、acegi に AuthXxxLdapImpl みたいなのがあるので
混乱していたのですが、確かに違うレイヤの話ですね。
（基本的に「業務アプリ屋」なもので、LDAPの本質とか
頭脳から抜け落ちていました）
>>839
情報ｱﾘｶﾞﾄ、今度その辺を試そうと思っているので購入
してみることにします。
>>840
お、これイイ。今度の仕事、このパターンになりそうなんです。
（EclipseRCPじゃなくてSwingになりそうだけど）
丁度都合よく記事が出てラッキー!!
845:デフォルトの名無しさん
06/09/06 23:21:30
>>844
Swingを選ぶあたり、保守性を考慮してあっていいね
SE5.0から速度が向上してるよ
846:デフォルトの名無しさん
06/09/07 01:34:24
データベースのフロントエンドで、Eclipse RCP使ってもメリットないし。
847:デフォルトの名無しさん
06/09/07 15:27:08
ここでCGLIB聞いちゃいますが、
最も単純な、あるクラスの全メソッド呼び出しをインターセプトする場合、
Enhancer使って、MethodInterceptorをCallbackさせます。
この時CGLIBは一体どうやって実現してるか分かる方いますか？
CGLIBは、対象のクラスは弄らず、サブクラス化してるらしいが、
そのサブクラスにはどういう仕掛けをしてメソッドインターセプトする
でしょうか。
848:デフォルトの名無しさん
06/09/10 21:58:06
URLﾘﾝｸ(www.google.co.jp)
849:デフォルトの名無しさん
06/09/11 01:01:18
OpenSessionInViewInterceptorを定義して、それをSpringMVCで使うときは
bean定義でSimpleUrlHandlerMappingのinterceptorsにていぎするのまではいいのですが。
トランザクションのコミットとロールバック条件などはどのように設定するものなんでしょうか。
850:デフォルトの名無しさん
06/09/12 01:32:58
Seasar2使え
851:デフォルトの名無しさん
06/09/20 09:59:17
>>849
ぐぐれ
852:デフォルトの名無しさん
06/09/29 00:22:03
カウントダウンｷﾀ━━(ﾟ∀ﾟ)━━!!!!
ってEclipseのパクリかよｗ
853:デフォルトの名無しさん
06/09/29 21:48:32
この道はいつか来た道
854:デフォルトの名無しさん
06/09/29 22:11:27
ああ そうだよ
855:デフォルトの名無しさん
06/09/30 21:57:09
その下の The Spring Rich Client Project ってのも木になる。
856:デフォルトの名無しさん
06/10/02 18:46:19
質問です。
以下の場合、スレッドセーフになりますか？？
・SpringとStrutsの連携で「DelegatingActionProxy」を使用
・Service層のオブジェクトをSetterインジェクションしてインスタンス変数に保持
※Service層のオブジェクトはスレッドセーフを意識していない
StrutsはスレッドセーフにするにはActionでインスタンス変数を使用しないとなると
↑の場合、スレッドセーフにならないような気がします。
もし、スレッドセーフにならないとして、synchronizedする以外でいい方法が
あれば教えてください。
やっぱ、ActionSupport使うしかないんですかね？？
857:デフォルトの名無しさん
06/10/02 20:18:36
＞スレッドセーフになりますか？
ここで言う setter injection てのは
定義ファイルに書いといてコンテナにDIしてもらう事？
Action も Service も singleton="false" にすれば
スレッドセーフを考えなくてもOK。(コストは最悪。)
＞ActionSupport使うしかないんですかね？
ActionSupport も Action に違いないので
インスタンス変数持たせたら大変。
インスタンス変数を ThreadLoacal で保持させる方法も考えられるけど、
サーブレットコンテナが Action のインスタンスを使い回したりするから、
execute 抜ける前に、確実に変数クリアする等の注意が必要。
結局、いろいろやるより、Service 層をスレッドセーフにした方が楽。
858:デフォルトの名無しさん
06/10/03 10:02:49
>>857
コンテナに DI してもらうという意味です。
言葉足らずでした．．．
確かに ActionSupport も Action を extends してるから
DelegatingActionProxy だろうが一緒ですね
Service 層をスレッドセーフな構造になるように考えてみます。
859:デフォルトの名無しさん
06/10/04 00:10:57
Spring 2.0 リリース記念age
860:デフォルトの名無しさん
06/10/05 09:43:31
豆の人たちあたりが早く解説記事書いてくれんかな。
読んでたら宜しく＞豆
861:デフォルトの名無しさん
06/10/27 01:13:54
Spring-Annotation v1.0 ｷﾀ━━(ﾟ∀ﾟ)━━!!
やってみたー。動かなかったー。
orz
862:デフォルトの名無しさん
06/10/31 20:38:16
↓の記事だけどさ、動かなかったんだよね。
URLﾘﾝｸ(journal.mycom.co.jp)
そんでさ、インスタンスをサ、createBeanで作ってやったワケよ。
とりあえずサ、動くこと確認してから記事にしろと言いたいわけ。
ソースまで追っかけさせんナ。ヽ(`Д´)ﾉｳﾜｧﾝ
TOAnnotationXmlApplicationContext ctx =
new TOAnnotationXmlApplicationContext("classpath*:applicationContext.xml");
ConfigurableListableBeanFactory factory = ctx.getBeanFactory();
//createBeanの第2引数の0とか１とか2とかね、第3引数のtrue, falseとかね。ﾍ(ﾟ∀ﾟﾍ)ｱﾋｬ
TargetBean bean = (TargetBean)factory.createBean(TargetBean.class, 1, true);
bean.xxx();
プログラムは漏れの本業じゃないのに…。
烏賊にも動きました的な記事は要らんよ。検証してから書けや！
spring-annotation 試したヤシ、居る？
863:デフォルトの名無しさん
06/11/01 10:38:09
試すならライターの記事よりもリファレンス見たり
テストケース触った方が良いかも知れんですよ。
annotation なんて無視するのが一番だと個人的には感じる。
864:デフォルトの名無しさん
06/11/01 12:20:21
間違ってるのに記事を起こすのはどうかと思うのです。
しかもSpring-annotation同梱のサンプル・ソースも同じコードだし、ドキュメントないし。
結局ソース追っかけてくしかないね。
865:デフォルトの名無しさん
06/11/01 12:36:59
Springにアノテーション使うと、エラく簡単になるよ。
866:デフォルトの名無しさん
06/11/02 01:59:49
>>865
どのへんが？
867:デフォルトの名無しさん
06/11/02 11:11:00
>>865
アノテーションでInjectionとか出来るなら使えるけど、そうじゃなきゃ意味ないぽ。
868:デフォルトの名無しさん
06/11/02 11:21:38
アノテーションでDIならEJB3でおｋ
869:デフォルトの名無しさん
06/11/02 22:28:27
>>862
普通に動いたけど。
それだとアノテーション書いてる意味なくね？
870:デフォルトの名無しさん
06/11/02 22:34:44
>>866 >>867
アノテーションの定義のやりかたによってはXML不要になる。
オレオレアノテーションの定義もそれほど難しくないし。
871:デフォルトの名無しさん
06/11/02 23:17:18
>>862
あと、createBeanの第2引数はファクトリの定数でいいかと。
872:デフォルトの名無しさん
06/11/03 00:02:37
>>869
え゛？
new TOAnnotationXmlApplicationContext("classpath*:applicationContext.xml").getBean("bean");
だと、
NoSuchBeanDefinitionExceptionが返ってきて"No bean named 'bean' is defined"って言われる。
factory.createBean(); で動きました？
>ファクトリの定数
ソース見たら、BY_NAMEは１だって書いてあったので。
ConfigurableListableBeanFactory.AUTOWIRE_BY_NAME
でいいわけですね。
873:デフォルトの名無しさん
06/11/07 14:49:21
spring hibernate strutsでアプリを組んでorg.hibernate.StaleObjectStateExceptionを発生したときのハンドリングって、global-exceptionで行うのが正しいのだろうか・・？
874:デフォルトの名無しさん
06/11/25 18:53:10
んでこのフレームワーク結構導入実績でてきた？
MSの.netもおんなじようなSpring出しているけど
最近なんかMSさん追随してません。
875:デフォルトの名無しさん
06/11/25 19:55:24
.Netな世界ではみんなCOM+サービスに満足してるんじゃね？
876:デフォルトの名無しさん
06/11/26 02:57:30
.NET版SpringのSpring.NETって導入されてるんだろうか
877:デフォルトの名無しさん
06/11/26 18:43:09
Spring Web Flowってどうなの？
ドキュメンツ読んでもいまいちよくわからんし、管理するxmlが増えそうだし。
878:デフォルトの名無しさん
06/12/03 19:40:12
>>876
Spring.NET 1.0.2ならC/SのWindowsFormsな案件で使ってる。
SpringにはFormとDataAccessを管理させてる。
あと、AOPでDataAccessモジュールのSQLクエリキャッシュとトランザクション制御をやってる。
879:デフォルトの名無しさん
06/12/06 16:53:07
なんで2chではspringとSeasarとでスレの勢いがぜんぜん違うの？
仕事(主に顧客の業務イントラ)でDIコンテナ使うとき、springを使うときのほうが圧倒的なのだが。
seasarを使っているというのをほとんど聞いたことがない。
ソフトウェアとしてどちらが優れているということについては
ここでは置いときますが、個人的にはSeasarには興味があるけど、
もっとspringのスレも盛り上がっていいと思うのだが・・・
880:デフォルトの名無しさん
06/12/06 16:58:10
国産だし、どうしても目がいっちまう。
実際問題、Springで十分実用に耐えるんだけどな。
日本以外も含めれば、実績も多いみたいだし。
881:879
06/12/06 17:04:00
>>880
2ヶ月前アメリカに行ってとあるカンファレンスに出席してきたけど、
やはりみんなspring使ってた。
SSH(Struts, Spring, Hibernate)を肌で感じた。
>国産だし、どうしても目がいっちまう。
おれの周りだけかもしれないけど、
みんなspringという名前は知っているけど、Seasarという名前は
知らない人が多い。
882:デフォルトの名無しさん
06/12/06 17:44:11
>>879
教祖ネタというか、燃料が供給されるかの違いだと思うけど。
883:デフォルトの名無しさん
06/12/06 18:39:26
まぁどっちもがんばってくれと言うことで。
でも2ヶ月前でまだStrutsってどうなんだろうな。
俺はもうリッチクライアント以外をお勧めする気にはならんですよ。
自分で作っててもムカつくし。
WebでやりたいならRailsにしましょうとか、そんな感じ。
884:デフォルトの名無しさん
06/12/06 19:50:33
RIAの人気って業界ではどうなの？
Flash＋JSFとかあっても良さそうなんだけど。
Flex2とかOpenLaszloとかもうちでは聞かないし。
885:デフォルトの名無しさん
06/12/06 23:56:01
>879
ここはSpringのプロダクトをヲチするスレ
あっちはSeasarな人たちをヲチするスレ
886:デフォルトの名無しさん
06/12/06 23:56:45
今後はAjax + Railsというパターンが増えてくる気がする
887:デフォルトの名無しさん
06/12/06 23:59:44
RoRとJavaは市場がかち合うことは無いんだが・・・
888:デフォルトの名無しさん
06/12/07 00:05:30
Ajax+Railsは、まだまだマニアのおもちゃだしな。
889:デフォルトの名無しさん
06/12/07 15:18:11
おもちゃってことはないと思う。
あれはあれで立派なプロダクト。
なんだけどRailsって言うだけあって
規約にガチガチなのが俺には合わなかったです。
これはもう好みの問題だけど、
強い型付けでガチガチに守られつつも
コンポーネント間をゆるゆるにつなげるDIが
俺的には良い落とし所。
890:デフォルトの名無しさん
06/12/07 19:23:27
Rails の考えかたって、「規約にガチガチ」なのかなぁ。
自分は、「いちいち書かなくてもだいたい分かるだろ」
だと思うんだけど。
891:デフォルトの名無しさん
06/12/07 21:58:41
Rubyの決まりごとは「脳にフィットする」だそうだから
合わない奴に合わせる気はないから使わなくていいよって規約だろうな