国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0786デフォルトの名無しさん
2005/04/20(水) 20:20:34リファレンスの必要性自体を感じてないような気もする。
日本語情報が多いっていうのがひとつの売りということだったけど、koichikさんのSpring入門記の方がSeasarのドキュメントよりも充実してる気がするし。
ってか、サンプルとかその解説とかは部外者にも書けるんだけど、リファレンスは開発者じゃないと書けないんだよね。
0787デフォルトの名無しさん
2005/04/20(水) 20:40:25バージョンの依存関係がわけわかめ。
0788784
2005/04/20(水) 20:56:30確かに協力してく気があるなら、
リファレンスは無理にしても、
「こんなのにぶちあたっちゃったの」は公開していくべきでしたね。
でも正直、ぶち当たりすぎちゃって既に嫌になってる部分もあったり…＿|￣|○ ﾓｳS2Strutsﾃﾞｲｲﾓﾝ
「ドキュメント不足」っていう理由のせいで、
S2JSFから人が遠のくなんてことは、実に寂しいことだと思うのです。
まずは人を惹きつけて…卵が先か、の話にはなっちゃいますけどね。
>>787
1行目は何言ってるのかわかんないけど、2行目は禿同。
その辺も、Seasarの敷居が高くなってる原因の一つだと思う。
0789デフォルトの名無しさん
2005/04/20(水) 20:59:500790デフォルトの名無しさん
2005/04/20(水) 21:49:37漏れはプロモーションのセンスあると思うよ。
残念ながらSeasar は役立たずだけど、それでも雑誌の記事に載せるところまでは
到達できたのはたいしたもの。
Seasarのコミュニティがなかなか出来上がらないのは当然のことで、
もともとSeasarは実はあまり意味のない代物だから、分かってる人にしてみればスルーするだけだし
逆に、リテラシーの低い初心者が「分からないからドキュメントくれ」 が群れてくる。
いいプロダクトなら、リテラシーの高い人がチカラを貸すよ。カネになるってもそうだけど、
ちょっと頑張るだけで世界が変わるのを実感できる。
Seasarじゃ何も変わらないってのが、リテラシーの高い人には見えちゃうんだよ。
0791デフォルトの名無しさん
2005/04/20(水) 21:51:33開発されているものの価値を見出した人の中から広告塔になってくれるような
人が現れる流れがあると、自分らも楽しいと思わない？夢物語かなぁ。
作る才がある人が作ることにのみ集中できて、
その他の事をうまく分散できるといいのに。とか思ったりする。
0792デフォルトの名無しさん
2005/04/20(水) 21:58:27Seasarが価値があるものならそれは人は現われるけど、そうではないのだから、どうしよもない。
0793デフォルトの名無しさん
2005/04/20(水) 22:02:28的を射ているのかもしれない。
フレームワークなのだから、既にしっかりしたノウハウを持っている人の目には
今更…のように写ったりしそう。ただ、作成される多くのものが
そのフレームワークの作法に従うことで統一感が生まれて保守効率が
上がるような可能性はあるよね。それでは世界を変えるまではいかないけど。
プロジェクトとして推す時に「ここに詳細な情報があります」って言えることは
かなり大事じゃないかな。誰それのブログ端から読んでよってのはどうかねぇ。
情報は統一されていないと探しづらいと思うのだ。
これは、狙っている層がJavaの業務アプリだから特に思うこと。
0794デフォルトの名無しさん
2005/04/20(水) 22:03:49雑誌の記事に載せるくらいでプロモーション力あるというなら、プロモーション力の敷居はかなり低いんだな。
0795デフォルトの名無しさん
2005/04/20(水) 22:05:27MLのログもありますよｗ。
0796デフォルトの名無しさん
2005/04/20(水) 22:14:18作法には価値があると思う。
だから、Seasarはだめでも、「くーす」はなかなか、広める価値のあるものだと思ってて。
コントロールはステートレスとか、分かってる人にしてみれば、当たり前だろみたいなことだけど、
学習中はその徹を踏んでしまうかも。
オブジェクト指向プログラミングって、深い理由がわからなくても、ＯＯ的にデザインされた
ライブラリを使うことで自然に生産性上がるのを体感して意味もわかってくるみたいなこと
あるけど、ウェブ／データベースプログラミングにおいては、いまいち実感しづらいところもあって、
Seasar使えば分かるんじゃないかみたいな人いると思うんだけど、残念ながら、
これはいくら使っても体感できないんだよね。
作法は作法として覚えるしかないと思う。フレームワークが解決することとも思えない。
Javaはウェブ／データベースプログラミングには向いてないし。
ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
分かりやすいものだけが生き残る。
0797デフォルトの名無しさん
2005/04/20(水) 22:17:21雑誌って基本的にアホで、特にソフト開発者向けの雑誌ってさらにアホなんだけど、
それでも載せるってのは、あほだからこそでもあるけど、そう簡単じゃないぜ。
0798デフォルトの名無しさん
2005/04/20(水) 22:36:34自分とは思想が逆みたいなんだけど、面白いのでしつこく食い下がってみる。
作法はできる限りフレームワークで吸収してやる部分じゃないかな。
例を挙げちゃうと焦点がぶれたりする可能性があるので
逆にまずいかもしれないけど、StrutsなんてFrontControllerだよね。
これをFrontController知らない人でも強制的に使わせてるよなと。
覚えること、考えることを減らすためにフレームワークやライブラリは存在
すると思う。オブジェクト指向については流すよ。哲学論争になりやすいし。
＞ホントに原理がシンプルで扱いやすいフレームワーク／言語も含めたプラットフォームの
＞分かりやすいものだけが生き残る。
これには同意。特に多人数開発ではキーになる考え方だろう。
わかりやすくて、しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
そういう意味ではJavaもDIもそんなに的外れではないかなと思ってる。
0799デフォルトの名無しさん
2005/04/20(水) 22:43:44> しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
> そういう意味ではJavaもDIもそんなに的外れではない
フレームワークに関しては、漏れは、
ホントにいいものなら、無いよりはマシくらいの位置づけで、
たぶん、ほとんどの人はそうでないか。
フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
そっちのほうがはるかに社会的だと思わんか。
0800デフォルトの名無しさん
2005/04/20(水) 22:46:19Javaはもともとウェブ／データベースプログラミングに向いてないし、
Seasarとか評価してみたけどやっぱり使わないほうがマシなんだよ。
0801798
2005/04/20(水) 22:47:13>>793の「作法」はソースコードの統一感としての作法で
>>796以降の「作法」はもう少し価値の高いある種パターンのような
分野にまで発展した考えで論じられているね。
特に訂正は無いんだけど、確認のため投稿。
0802デフォルトの名無しさん
2005/04/20(水) 22:53:22>793の「作法」はソースコードの統一感としての作法
まさかとは思ったけど、こういうのをフレームワークで縛れるとか思ってる人がまだ結構いるんだよね。
現実に目の当たりにすると、腹の底から軽蔑しますよ。
ホントにヒドイと思う。
0803デフォルトの名無しさん
2005/04/20(水) 22:58:04> だから、もうSeasarとかJ2EEとかSpringやらに騙されるな
> 近寄るなと漏れは知らせたいんだよ。
> そっちのほうがはるかに社会的だと思わんか。
最後のこの部分しか読んでないが、この意見がアホなこといってることはわかる。
0804デフォルトの名無しさん
2005/04/20(水) 23:01:20優等生的に答えると、フレームワークは設計の再利用だよね。
これは実装の再利用であるライブラリと対になっていると思う。
無ければ自分でその時作るだけ。だけどある程度良い設計、実装が
既に提示されているのなら利用した方が良いぞと。
既存フレームワークで救うのはしょぼい開発者の中でも
駆け出しの設計者になるだろう。あと、熟練者でもわざわざ0から
フレームワークを構築しなくて良くなるので時間の節約になるよね。
ドキュメント書かなくても良いし、既にそれを知ってる人はいきなり使うだけだし。
＞フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
＞そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
教育の仕方をどうするかって話で解釈合っているかな。
もう少し上のレベルに話が広がってしまいそうなので流します。
0805デフォルトの名無しさん
2005/04/20(水) 23:11:08＞そっちのほうがはるかに社会的だと思わんか。
いろいろ書こうと思ったけど、まとまらなかったので質問してみる。
>>799の開発ではどんなフレームワークを使っているの？
もし良かったら書いてみてくれないかな。その方が話がわかりやすくなりそう。
>>802
うーんと、言わんとしているところが良くわからなかった。
ソースコードの統一感って言うのは見た目の問題だから
「Strutsで作ってるよ」「あー、じゃぁActionクラスを継承すんのね」
みたいな部分という意味で書いたんだ。もう少し書いてみてくれないか？
0806デフォルトの名無しさん
2005/04/20(水) 23:12:51自分はここ以外はそれほど的外れでも無さそうに思ってる。
0807デフォルトの名無しさん
2005/04/20(水) 23:25:02Seasar使うくらいならPure Servletのほうがいいよ。
シンプルにやりゃいい。
Struts使うことでAction使うことが自明になるとしても、それが？ って感じでしょ。
何の役にも立たない。なら使わないほうがいい。
ウェブインターフェースのアプリケーションなら、
Rubyが最適だと思いますよ。文字列処理が高機能、コードも短くて済む。
いい実装例だなと感じてるのは
http://www2a.biglobe.ne.jp/~seki/ruby/divip.html
バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。
0808デフォルトの名無しさん
2005/04/20(水) 23:35:47えーと、プロジェクトの中でみんなServlet開発をしているって意味かな。
それは開発のスピードが遅そうに感じるんだけど、自分だけだろうか。
StrutsのActionの話は、そういう部分を合わせないと理解が遅い人が
いるよねって話。逆にこんなもん合わせるだけでルーチンワークに
乗せられたりするものだったりもする。
自分は今までの話を「多人数で開発する」ということを念頭に書いてる。
これは、Seasarみたいなものが狙っているターゲットがそうだから。
紹介してくれたアプリも多人数で開発するようなものでは無さそうだね。
ちなみに、個人で使うなら今のS2を使わないってのは自分もそうだと思うよ。
一人でWEBサイト構築するならRUBYは触ったこと無いのでPHPかな。
共通部をまとめてるうちに結局自分用フレームワークできちゃうけど。
0809803
2005/04/20(水) 23:44:20あ、ほんとだ。
ってことはあれだね。
正しい意見を述べておいて、結論だけは正しくない意見にしておけば、正しくない意見を正しいと思わせることができるっていう高等技術。
0810デフォルトの名無しさん
2005/04/20(水) 23:45:51Strutsは単にフォームへの入力をBeanに格納してくれるただのライブラリだ。
0811デフォルトの名無しさん
2005/04/20(水) 23:52:585年かもっと前のJavaみたいなもんで、ユーザとか元請けのSIerから
止められるのが普通じゃない？ ちっちゃいところはいいかもしれんけど。
Rubyできるやつサクッと集められるとも思えないしね。
だから、ここでRubyが最適とかいわれても逃避にしか見えない。
Javaでどうするか、DIでどうにかなるのか、って所でスゲーやつの
話が聞きたいです。
0812デフォルトの名無しさん
2005/04/20(水) 23:57:13いや、大抵は>>803みたいに最後だけ見て「こりゃだめだ」って切り捨てられる罠。
そろそろ筆置きます。
長文連発すまなかった。＞スレの人々
あと、S2から凄く離れてしまってすまん。
長々付き合いありがとう。>>807
0813デフォルトの名無しさん
2005/04/21(木) 01:35:17>>787が1行目で言いたいのは、
メジャーなリリースと、マイナーなバージョンアップを分けてほしいということかと。
0814787
2005/04/21(木) 01:51:04いや、S2StrutsとかS2JSFとか、全部含んでSeasar2.x.xとして出して欲しいってことです。
S2JSFのこのバージョンはSeasar2.1.8じゃないと動きませんよ、とか、でもS2XXXはこのバージョンでは動きませんよとか、わけわからん。
0815デフォルトの名無しさん
2005/04/21(木) 10:33:20んだけど、十分に単純で便利だと思うんだが・・・・・・
なんでここでは否定的な意見の方が多いんだろう？
0816デフォルトの名無しさん
2005/04/21(木) 10:41:59そんな感じじゃないですか。
eclipseからJava始めた人はクラスパスとか
判ってなくてけしからん、とか。
俺は知らなくてもできるんならそれでいいし
トラブルになったらその時に調べて
覚えりゃいいと思うんだがなあ。
0817デフォルトの名無しさん
2005/04/21(木) 10:53:27この理解で概ね合っていると思っていいよな？駄目だったら頭いい人突っ込んでくれ。
AbstractFactoryにしたくなるような生成部分を統一的な方法で提供しているって
理解なんだけど。
0818デフォルトの名無しさん
2005/04/21(木) 11:11:31それならSpringの方が日本語の資料も多くて便利
0819デフォルトの名無しさん
2005/04/21(木) 11:22:28ここで小難しいこと言ってSeasarだめ論(もっと言うとJavaだめ論)を展開してる人って、
案外そういう簡単なことが分からないのかもね。
難しく考えすぎと言うか。
>>818
それは好みの問題でしょう。
0820デフォルトの名無しさん
2005/04/21(木) 11:34:14Seasarの説明に、次世代どうのこうのとか小難しく書いてあるから。
0821デフォルトの名無しさん
2005/04/21(木) 11:45:14S2とS2Daoと、あと戦略商品としてS2JSFをバンドルしてくれればいい。
個人的にはS2Strutsも。
0822デフォルトの名無しさん
2005/04/21(木) 11:59:000823デフォルトの名無しさん
2005/04/21(木) 12:09:22> Seasar使うくらいならPure Servletのほうがいいよ。
> シンプルにやりゃいい。
シンプルっていうよりサンプルしか作ったことないとか？
まともに開発したことあるやつとは思えない。
> バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
> みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。
後ろが分散できたってしょうがないだろ。なんか素人くさい。学生？
0824デフォルトの名無しさん
2005/04/21(木) 12:13:42標準セットパッケージみたいな感じだよね。
これ一個でとりあえず美味しい汁を吸えますみたいな。
0825デフォルトの名無しさん
2005/04/21(木) 12:14:32まぁまぁ、そう反応しなさんな。
見てる切り口が多分全然違うのだよ。
0826デフォルトの名無しさん
2005/04/21(木) 12:26:10Strutsすら必要ないなら、Seasarも使わずServletに処理ベタ書きの方がいいってことじゃない？
仕事にはいろんな規模のものがあるんだから、それはそれでいいかと。
0827デフォルトの名無しさん
2005/04/21(木) 12:27:54S2JSFがSeasarのコンテナ機能を使わずUtilだけ使ってるんだったら、UtilをわけてS2+S2DAO+Util/S2JSF+Utilというふたつのパッケージでもいい。
0828デフォルトの名無しさん
2005/04/21(木) 12:37:09普通にjsf.diconとかあるけど
0829デフォルトの名無しさん
2005/04/21(木) 15:57:26もちろんそれはそれで良いと思う。
けど、だからつって物知り顔で「誰にとってもフレームワークひいてはS2イラネ」って言うのはどうかと思う。
あんだけ自信満々で言われちゃうと、漏れみたいなお馬鹿チンは「本当にいらないのかな…」って不安になっちまう。
自分は今有効に使えてるのにね。
0830デフォルトの名無しさん
2005/04/21(木) 16:23:42残念だけど、その取捨選択は君がするしか無いと思うよ。
人の言っていることを盲目的に受け入れるべきなのかそうでないのかって
ことだから。ここの人は自分が思うことを好き勝手に書いているだけだし。
>>790->>807みたいにちゃんと突っ込んだ話をしないとその根拠が
明白にならないからなかなか判断しようが無いのだけれど。
で、自分は彼の話がごく一部しか捉えていないようだと判断した。
＞自分は今有効に使えてるのにね。
これを根拠に「自分には必要だ」でも良いんじゃない？
0831デフォルトの名無しさん
2005/04/21(木) 20:39:58日本語資料の多寡は「好みの問題」ではありません。
0832デフォルトの名無しさん
2005/04/21(木) 21:57:180833デフォルトの名無しさん
2005/04/21(木) 22:53:58JAVAはフレームワーク多すぎ！て言うか、なんでもかんでもフレームワーク
って呼びすぎ！
俺のこれまでの知識では、「フレームワーク＝湯の張られた鍋」と理解してた。
具材を入れていくと料理になるという、そんなイメージ？
でも、JAVAでは制御の反転が絡むと全部フレームワークって呼びやがる。
Seasarでどんな料理が出来上がるのか、10日も探し回っちまったじゃねぇ～か！
当然、それだけでは料理になんかなるわけねぇ～！そもそも、鍋ですらねぇ～！
どっちかっつぅ～と、やかん？とにかく、俺の馬鹿＿|￣|○|||
0834デフォルトの名無しさん
2005/04/21(木) 22:57:07最初からIoCコンテナ(DIコンテナ)としか言ってないような。やかんどころかコンロですな。
0835デフォルトの名無しさん
2005/04/21(木) 23:04:07コールバックを含むライブラリのことをフレームワークと呼ぶのだよ。
0836デフォルトの名無しさん
2005/04/21(木) 23:04:50分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
ある。て言うか、変な人ほどフレｄｊさｋｌｊｆｓぢｊｆさいｊふぉいｊ
やかんの心は、冷たい液体から温かい液体を生成するファクトリー
0837デフォルトの名無しさん
2005/04/22(金) 00:11:45> >>834
> 分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
JARの名前がs2-framework～である件について
0838デフォルトの名無しさん
2005/04/22(金) 00:24:17Avalonは(Jamesみたいな）サーバアプリケーションを作成するためのフレームワークと銘打ってるけどね。
0839デフォルトの名無しさん
2005/04/22(金) 00:39:32Seasarの場合は、S2Daoとか周辺を含まずにフレームワークなわけで。
0840デフォルトの名無しさん
2005/04/22(金) 00:49:59Avalon Frameworkだって周辺も何も含まずにフレームワークを名乗っていた。
あれはコンテナとコンポーネントのコントラクトを規定しただけのライブラリ。
Avalon Excaliburがコンテナの実装、Avalon Phenixになるとサーバ
アプリケーション用のフレームワークという位置づけになっていたかと。
Marlinはよーわからんがそうやって発散してお亡くなりに…
0841デフォルトの名無しさん
2005/04/22(金) 01:18:27分類の根拠がなんなのか位は抑えておいてもいいだろうけどな。
0842デフォルトの名無しさん
2005/04/22(金) 10:52:460843デフォルトの名無しさん
2005/04/22(金) 10:53:490844デフォルトの名無しさん
2005/04/22(金) 21:10:010845デフォルトの名無しさん
2005/04/22(金) 21:57:18俺も学習用につくってみてもいいか？
0846デフォルトの名無しさん
2005/04/22(金) 23:45:49それは文字通りのフレームワークだと思う。
ファンクタを要求する単体のオブジェクトはどうなんだろう？
IoCを伴ってはいるけど、これをフレームワークと呼ぶのに
は激しく抵抗を感じる。
>>845
いいんじゃない？
DIコンテナという言葉こそ出てこないけど、JAVAの格言に
は、抽象ファクトリーパターンと動的クラスローディングの
組み合わせ例として、iniファイルを利用したDIコンテナが紹
介されてる。
0847デフォルトの名無しさん
2005/04/23(土) 02:17:41いいよ。
AOPまで実装すれば、とりあえずSeasarの対抗馬としてプロモーションできるし。
ドキュメントとメディアの取り込みさえできれば、すぐ広められる。
ただし、そういうプロダクトを運営するのには、結構手間がかかるし、覚悟がいる。
0848デフォルトの名無しさん
2005/04/23(土) 02:32:29SeasarやSpringと張り合おうなんて気は毛頭ないから安心してくれ。
あくまで学習用だからきれいでシンプルな実装をしたい。
0849デフォルトの名無しさん
2005/04/23(土) 10:43:19俺はそういう取り組みの繰り返しが将来の技術力を養うと思う。頑張れ。
0850デフォルトの名無しさん
2005/04/23(土) 11:24:16そしたら、機能的にはPicoContainerとかをまず見てみるといいかも。
0851デフォルトの名無しさん
2005/04/23(土) 11:42:02おいらはいい加減おっさんだが35歳で限界を迎えないように精進するよ。ありがとね。
>>850
Spring、Seasar、PicoContainerあたりの実装は確認済み。
PicoContainerのシンプルさは好きだね。
で、CgLibとjavassistの比較してるサイトとかしらん？
0852デフォルトの名無しさん
2005/04/23(土) 22:31:40>で、CgLibとjavassistの比較してるサイトとかしらん？
ここらへんってちょっと前にSeasarでも話題になってたし、はてなでもいって探せば
参考になるサイトとか出てくるんじゃねー
0853デフォルトの名無しさん
2005/04/24(日) 01:43:13AbstractFactoryが必要な部分ってシステムのコアに相当する部分で、
ここは自由にプログラミングできてしかるべきところを、
言語の非標準機能を使ってまで、統一的にする意味あんのかってあたりが微妙で、
テストしやすいとかいってるけど、これも結構あやしいと思う。
要するに、モックオブジェクトを返したいってことなんだろうけど、
冷静に考えて、それを作りたいシーンって、ホントにシステムのコアに相当する部分で、
ごく一部であって、そこをフレームワークにまかせてどうにかなるってことも、
無い気がする。有効なシーンがあれば教えてほしい。
0854デフォルトの名無しさん
2005/04/24(日) 02:39:08もうフレームワークって呼ぶな。話が無駄に混乱する。
有効なシーンも何も、幹と枝葉の相関を切りたいという要求は
普通にと言うより普遍的にあるはずだが・・・・・・
0855デフォルトの名無しさん
2005/04/24(日) 02:57:19切りたい欲求はそんなに無い、あったとしても、
そこはそのアプリケーションに合った適切な切り方をしたほうが
DIコンテナ機構を使うよりいいってこと思うんだけど
0856デフォルトの名無しさん
2005/04/24(日) 21:42:58> そこはそのアプリケーションに合った適切な切り方をしたほうが
「アプリケーションに合った」部分をDIコンテナは侵食しないぞ。
あなたの設計だと、Factory部分のコードがアプリケーションによって変わってくるのか？
かなりひどい設計だと想像するけど。
0857デフォルトの名無しさん
2005/04/24(日) 22:57:32>>856
どう言っても無駄だと思うぞ。
変な話だが、円滑なコミュニケーションにデザパタがどれほど大き
く寄与してるか実感した。
JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
からコンパイルへの依存を排除できる点」だよ。
で、説明は終わりなんだよな。
多段に積み重なった知識の最上段のみを対象に会話を進めていく
って行為は、モードの違う相手とはチャンネルが合わないんだなとｗ
0858デフォルトの名無しさん
2005/04/24(日) 23:44:32> JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
> からコンパイルへの依存を排除できる点」だよ。
> で、説明は終わりなんだよな。
使ってるやつはそれで説明が終わりと思ってて、使ってないやつにとってはそれでは説明になってないと思う。
0859デフォルトの名無しさん
2005/04/25(月) 00:10:03SeasarにしてもSpringにしても使うのちとめどい・・・
Picoのほうが個人的には好きなのだが、それほど使われてない模様
SeasarにコアのDI以外にも便利な機能って何が入ってるのさ
S2Strutsはそれほど便利でなかったし、
JDBC連携もDbUtilsとかで代用できんの？
ともかくXMLの設定とかめどい
0860デフォルトの名無しさん
2005/04/25(月) 02:07:250861デフォルトの名無しさん
2005/04/25(月) 02:24:32>Factory部分のコードがアプリケーションによって変わってくるのか？
ソフトウェアの核になる部分って、やっぱり
キャッシュを解放するタイミングとか、ログの取り方、バックアップの取り方、パフォーマンスの計測とか
いろいろやることがあって、変わるに決まってると思うのだが
0862デフォルトの名無しさん
2005/04/25(月) 02:56:030863デフォルトの名無しさん
2005/04/25(月) 14:14:53XMLがめんどいというやつは、Springをちょっと使って、
Seasarを使ってないやつに多い｡
Picoがいいというやつは、最近あまりみたことないが、
PicoよりはSeasarが簡単だろう｡
同じようにコンストラクタによるAutowireができて、
classを登録するだけですむんだから｡
APIをじかにたたく分には、SeasarもPicoもあまりかわらない。
0864デフォルトの名無しさん
2005/04/25(月) 18:17:21ファクトリーは生成のパターンだから構造や制御とは無関係だよ。
0865デフォルトの名無しさん
2005/04/25(月) 19:03:38頭がツルツルなのがきたら、スルーでおっけ
0866デフォルトの名無しさん
2005/04/25(月) 19:08:27factory method数≒全クラス数
ただしfactory methodは大抵singletonを返す
ってのが居た。あの類だろｗ
0867デフォルトの名無しさん
2005/04/26(火) 00:15:33フツーにnewするのがナニが不満なのか。
なんでもないところにAbstractFactory用いる意味は無い。
もしAbstractFactoryを導入する価値のある個所があるのだとすれば、
それはシステムのコアであるから、どっちにしろ、ここは自由にプログラミング
できないと無意味である。
0868デフォルトの名無しさん
2005/04/26(火) 00:21:47なんて、１日の試用でわかるんじゃねえの？ EJB使った上で、DIなんて無意味非効率めんどくせえ、
とかいうやつがいたら、どっかいかれてるとしか思えん。
0869デフォルトの名無しさん
2005/04/26(火) 00:58:12て言うか、十中八九こいつVBプログラマだｗ
0871デフォルトの名無しさん
2005/04/26(火) 01:54:49あれだね。
EJBを必要と思わなかったら、まったく意味のない比較だね。
めちゃくちゃめんどいEJBがめんどいDIになっただけということ？
0872デフォルトの名無しさん
2005/04/26(火) 02:44:31そりゃそうだろ。DIコンテナが生まれてきた経緯を考えると、EJBへのアンチテーゼ
そのものなんだし。解決しようとしてる土俵で比較するのが筋じゃないか？
めちゃめちゃしんどいEJBが楽なDIコンテナに変わったってことだろ。
EJBはめんどいけど、コンテナのインスタンス制御機能（つまりファクトリとしての機能）や、
コンテナ制御のトランザクションなんて機能自体は必要なんだよ。そのために苦労して
EJB使うわけで。
DIコンテナはその両方を簡単に解決するじゃん。DIコンテナよりも簡単にEJBの機能を
提供してるものがあるんだったら、おれはすぐにでもそっちに乗り換えるよ。
0873デフォルトの名無しさん
2005/04/26(火) 03:30:160874デフォルトの名無しさん
2005/04/26(火) 04:05:050875デフォルトの名無しさん
2005/04/26(火) 04:14:520876デフォルトの名無しさん
2005/04/26(火) 05:00:17XMLはツールとの相性のよさってのがあって、
人間にも読めて機械にも読めるフォーマットとして意味があると思うんだけど、
なんつーか、DIコンテナなんつーものは、
本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
むしろそういうことなら、Eclipseのプラグインアーキテクチャにおけるxmlによる、
読み込むクラスの定義のほうが、価値があると思う。
0877デフォルトの名無しさん
2005/04/26(火) 05:46:20XMLでの定義がいやなら、アノテーション。
0878デフォルトの名無しさん
2005/04/26(火) 06:58:170879デフォルトの名無しさん
2005/04/26(火) 09:33:51＞本来はプログラミング言語が兼ね備えているべきレベルでの単純すぎるオブジェクト生成
＞にしか使えなくて、フツーにnew するのと変わらん。そんなのに意味あるか。
このあたりが何を言いたいのかもう少し知りたい。
それと、どんなアプリを作る人なの？
この辺の違いがわかると話が噛み合ってくると思う。
0880デフォルトの名無しさん
2005/04/26(火) 18:29:17正直、EJB3は全く追いきれてないんだが、DIコンテナ＋AOPという小さな
機能部品としてのSeasarには需要が残り続けると思う。
0881デフォルトの名無しさん
2005/04/26(火) 18:41:16>読み込むクラスの定義のほうが、価値があると思う。
いや、それがDI(Dependency Injection = 依存性の挿入)でしょ？
コンパイルへの依存性を排除できるって、そういう事だと思ワン？
「価値があると思う」って、思いっきり認めちゃってるみたいだけど・・・・・・
えと、どういう事？DIコンテナは認めるけど、Seasarは駄目って話？
て言うか、スレが進むうちに段々DIコンテナの利点が分かってき
たんじゃないか？別に無理繰り否定する必要はないんだぞ？
0882デフォルトの名無しさん
2005/04/26(火) 19:36:20それを一般アプリケーションに広げる価値はないといってるのでは？
0883デフォルトの名無しさん
2005/04/26(火) 20:19:59もっと楽な方法が出てきそう
0884デフォルトの名無しさん
2005/04/26(火) 20:22:20DIをするための方法として、一般的にDIコンテナと呼ばれている物の
方法は良くないと言いたいのかねぇ。
あ、違うよ。きっと彼はプラグインがDIだってわかってなかったんだ。
むしろそういうことなら、こんな不毛な議論なんかやめて
別の話したほうが、価値があると思う。
0885デフォルトの名無しさん
2005/04/26(火) 23:39:22「AとBを結びつけるときに、その結びつきがAやBの中に直接埋
め込まれているのではなく、Cがその仲介をしてあげてくれると
AとBの実装がお互いに依存しなくて嬉しい」
っていうのがDIのありがたみだと思うのだけれど、これ自体には
異論はないのかな。
それともこれ自体に異論があるのか？
で、DIコンテナは上記のCにあたるところを一括して面倒みてく
れるのだけれど、その方法として「AやBの生成を請け負う」とい
うやりかたをしているため、その副作用として「生成したものを一
定の方法で改ざんできる（＝AOPを適用できる）」というメリットが
出てきていて、そこが個別にAbstractFactoryを用いるのとは決
定的に異なるのかなと。
■ このスレッドは過去ログ倉庫に格納されています