トップページ⇒tech
1001コメント376KB

国産DIコンテナSeasarとくーす その3

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ?みんなもう使ってるの?
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。


本家 seasar.org
http://www.seasar.org/

Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/

ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/


前スレ
その1 http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その2 http://pc5.2ch.net/test/read.cgi/tech/1098885253/


関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
07597552005/04/18(月) 00:32:51
ウマくいきました。>>756、757さんありがとうございます。
(ドキュメントをきっちり読んでから質問します)
0760デフォルトの名無しさん2005/04/18(月) 21:44:59
Relax自体は価値があるけど、Relaxerであのソースコード自動生成とか、
図らずも Java ってダメさ具合を明確なものにしてるんだよね。
型を気にして無意味なクラスを作る気持ち悪さ、生産性の低下、これを実感できる。
Seaserも全く同じで、これもまた図らずも、Javaでのウェブ/データベースプログラミングの
向いて無いことを証明してる。なんでこんな複雑なもの覚えても、実際には
スクリプト言語で見通しよく書かれたコードのほうが、よほど生産性が高くて堅牢だよね。
0761デフォルトの名無しさん2005/04/18(月) 22:29:59
だからSeaserなんてないと何度言ったら(ry
0762デフォルトの名無しさん2005/04/19(火) 01:25:28
とはいっても、動くシステムつくってサービス提供して安定稼働させて設けてる香具師がゴマンといるわけだから。そっちが勝ち組
0763デフォルトの名無しさん2005/04/19(火) 01:52:23
後学の為にと思ってコンテナの部分だけをつまみ食いしてるんだけど
なんか出来上がりが自作PCみたい(CLASSがパーツでDICONが配線)
になってしまったんだけど、使いどこ間違ってる?

将来拡張するかもしれないと思われる部分にだけ、ピンポイントで使う
のが正しい?それとも、もうあらゆる部分を全部個別部品として作って
最後にDICONで繋いで完成とするのが正しい?

Seasarの使い方ではなく使われ方?上手く言えないけど、こういう例
ではこう使え!って感じのノウハウ集とかってのはないかな?
0764デフォルトの名無しさん2005/04/19(火) 04:45:13
>>762
Springのほうか?
それとも、SeasarもSpringも使わないやつらか?
0765デフォルトの名無しさん2005/04/19(火) 04:51:51
>>760
そうだね。だから君はこのスレに来る必要はないと思うよ。
0766デフォルトの名無しさん2005/04/19(火) 07:07:22
>>765

誰もこの疑問に反論はできないし、それでも、生産性が上がることをアピール
したいために、作者は一生懸命に作ってるのも分かるのだけど、
でも、老婆心だけど、ここは、引き返す勇気を呼び起こすときだと思う。
やりたきゃやっていいけど、根本的な間違いがあるが故に、
やった結果何も残らないのだとしたら、なんかもうかわいそうだ。
0767デフォルトの名無しさん2005/04/19(火) 07:42:29
ま、Seasarがどうこうはあるけど、DIコンテナ自体を「複雑なもの」としか思えないなら、スクリプト言語で見通しよく書かれたコードのほうが、よほど生産性が高くて堅牢だな。
DIコンテナを「複雑なもの」と思ったんなら、老婆心だけど、ここは、転職する勇気を呼び起こすときだと思う。
なんかもうかわいそうだ。
0768デフォルトの名無しさん2005/04/19(火) 07:54:03
正直、DIは一時的な流行に終わる可能性大と思われ。
ちょっと前に流行ったSWTのごとく。
0769デフォルトの名無しさん2005/04/19(火) 08:11:21
メタ議論で煽ってるのは荒し。
自分ではプログラムもできずに、
大規模プロジェクトに下請け派遣で入ってるだけの可哀想な人。

こーゆー可哀想なのにも半端仕事あてがってやれよw >> ISID
0770デフォルトの名無しさん2005/04/19(火) 08:12:57
>>762
画面一つ作るのに 1人月以上かけて、しまいにゃ実装をオフショア発注しちゃう、ダメダメ現場かw
0771デフォルトの名無しさん2005/04/19(火) 08:13:50
↑>>760の間違いです。首釣ってきます
0772デフォルトの名無しさん2005/04/19(火) 08:46:16
>>769
> メタ議論で煽ってるのは荒し。

どれをメタ議論といってるのかわからんが、その発言自体がメタ議論であることは確かだな。
ということはつまり、>>769はISIDに半端仕事くださいといってるわけか。
0773デフォルトの名無しさん2005/04/19(火) 09:13:41
しかし、DIをSWTと同じように見てるところが底が浅いというか。
0774デフォルトの名無しさん2005/04/19(火) 09:41:19
>>766
お前のせいじゃないから気にするな
心配しないでここから去れ
0775デフォルトの名無しさん2005/04/19(火) 09:43:36
SWTは必要だが、DIは不用だよな。SWTには明確な実益がある。
0776デフォルトの名無しさん2005/04/19(火) 10:23:26
SWTの明確な実益は、Swingの高速化で不明確な実益になった。
というか、いまどきSWTに明確な実益があるとか言いきってる時点で情報収集能力に疑問がでてくるね。
0777スレ違いとかそんなもんいいだろ2005/04/19(火) 17:17:43
>>776

>SWT の明確な実益は、Swingの高速化で不明確な実益になった。

まぁ、Swingも悪くは無いんだけど、JFaceのContentProvider, LabelProvider, Decorator あたりの
アーキテクチャはモダンだと思ったし、やっぱりまだ SWT のほうが速いし、ウィンドウシステムに
対して忠実であるのはSwingとの明確な違いとしてあると思う。
0778デフォルトの名無しさん2005/04/19(火) 21:43:00
ちょっと速くてもちょっと便利なところがあっても、全体的にはSwingの拡張性にかなわないしWindows以外では速いといえないし、資料はないしノウハウはないしツールはないし、デメリットで相殺されてしまう。
JDK1.4.1くらいまでなら、それでもデメリットに目をつぶれるような速度差があったけど、今はそこまでの速度差がない。
しかも、メモリやらリソースやら食うから、SWTの方が遅いこともありえるような気がする。
0779デフォルトの名無しさん2005/04/20(水) 10:35:44
>>777,778
スレチガイウザス

ところで、S2JSF(だけに限らずSeasar2全般)のリファレンスマニュアルって作る気ないのかな。
皆あの中途半端な「サンプルの解説」だけで満足できるの?
俺一人なら、ソース読むなり何なりするのでいいんだけど、
チーム全員にそれを強要するのは、うちのチームじゃ無理だね。

本気でS2を普及させる気があるなら、バージョンアップより先に詳細なマニュアルを早く作ってくれろ。
0780デフォルトの名無しさん2005/04/20(水) 11:09:44
http://www.amazon.co.jp/exec/obidos/ASIN/4839917779
立ち読みしたけど、連打対策とか戻るボタン対策とかの話まであって
かなり実践寄りでよさげだった。

マニュアルとういか、これのS2JSF/S2Dao/S2バージョンを
書いてくれないかなあ。
0781デフォルトの名無しさん2005/04/20(水) 11:14:28
779がつくればいいとおもうよ
0782デフォルトの名無しさん2005/04/20(水) 12:46:38
>>779
「サンプルの解説」がダメなのにリファレンスなら大丈夫って
珍しいメンバーだね。
リファレンスだけあっても〜ならありがちだけど。
0783デフォルトの名無しさん2005/04/20(水) 13:57:03
>>782
サンプルでは機能が網羅してないってことだろ。
網羅してたとしてもリファレンス性も悪いし。
0784デフォルトの名無しさん2005/04/20(水) 15:18:28
>>782
違う違う。サンプル解説がだめなわけじゃないって。
サンプル解説のおかげで、
「S2JSF使えばどういうことが出来るのか」って言うのはよく分かったよ。
それはいいのよ。確かによく分かったしありがたいこってす。

でもね、いざ新しい物を作ろうと思うと、どういう部品がどういう風に絡み合ってるのか、
新しい部品を作るにはどうしたら良いのか、そういうことが全然わかんなくて、すぐ壁にぶち当たりまくり。

「どういうことができるか」はとってもよく分かるけど、
「どういう風に作ればよいのか」が全然わかんない。サンプルの解説だけじゃね。

ちょいと誤解してるようだけど、リファレンスだけあれば良いっつってんじゃないよ。
サンプルの解説も、リファレンスも両方(できればチュートリアルもw)欲しいって言ってるの。

>>781
ごめんね。100%完璧に理解してるわけじゃないからこそ、
リファレンス等のドキュメントが欲しいのよ。


俺必死だなw
0785デフォルトの名無しさん2005/04/20(水) 15:55:26
ちょっと雑談させてよね。
>>784
確かに資料、情報は多いに越したことはないもんな。
多くの人に普及させたければ必要なことだろうと思う。

ただ、こういうのって必要と思った人が用意するって文化を推奨してる
から。君がぶち当たった壁をWikiなりなんなりで公開すると
みんなウハウハ・・と。実際はそんな理想的にならないんだろうけど。

作者の周りには人が集まっているようで、いろいろ仕事割り振って
うまく回っていると俺は思っているんだけど、プログラマがあまりしたがらない
全体の統一的なドキュメント化のような部分をやってくれる人が多数
参加するようになるともっと良いのかもしれないね。
それにはもう少し時間が必要なんじゃない?
0786デフォルトの名無しさん2005/04/20(水) 20:20:34
もう充分時間が経ったわけで。
リファレンスの必要性自体を感じてないような気もする。
日本語情報が多いっていうのがひとつの売りということだったけど、koichikさんのSpring入門記の方がSeasarのドキュメントよりも充実してる気がするし。

ってか、サンプルとかその解説とかは部外者にも書けるんだけど、リファレンスは開発者じゃないと書けないんだよね。
0787デフォルトの名無しさん2005/04/20(水) 20:40:25
それはそうと、SeasarもSpringみたいに、主要バージョンは取り込んでバージョン番号をつけてリリースして欲しいね。
バージョンの依存関係がわけわかめ。
07887842005/04/20(水) 20:56:30
>>785
確かに協力してく気があるなら、
リファレンスは無理にしても、
「こんなのにぶちあたっちゃったの」は公開していくべきでしたね。
でも正直、ぶち当たりすぎちゃって既に嫌になってる部分もあったり…_| ̄|○ モウS2Strutsデイイモン

「ドキュメント不足」っていう理由のせいで、
S2JSFから人が遠のくなんてことは、実に寂しいことだと思うのです。
まずは人を惹きつけて…卵が先か、の話にはなっちゃいますけどね。

>>787
1行目は何言ってるのかわかんないけど、2行目は禿同。
その辺も、Seasarの敷居が高くなってる原因の一つだと思う。
0789デフォルトの名無しさん2005/04/20(水) 20:59:50
結局ひがさんには、プロダクトを開発するセンスはあっても、プロダクトをプロモーションするセンスはなかったってことだよ。
0790デフォルトの名無しさん2005/04/20(水) 21:49:37
>>789

漏れはプロモーションのセンスあると思うよ。
残念ながらSeasar は役立たずだけど、それでも雑誌の記事に載せるところまでは
到達できたのはたいしたもの。

Seasarのコミュニティがなかなか出来上がらないのは当然のことで、
もともとSeasarは実はあまり意味のない代物だから、分かってる人にしてみればスルーするだけだし
逆に、リテラシーの低い初心者が「分からないからドキュメントくれ」 が群れてくる。

いいプロダクトなら、リテラシーの高い人がチカラを貸すよ。カネになるってもそうだけど、
ちょっと頑張るだけで世界が変わるのを実感できる。
Seasarじゃ何も変わらないってのが、リテラシーの高い人には見えちゃうんだよ。
0791デフォルトの名無しさん2005/04/20(水) 21:51:33
でも、開発者に全てを望むのは酷だよね。
開発されているものの価値を見出した人の中から広告塔になってくれるような
人が現れる流れがあると、自分らも楽しいと思わない?夢物語かなぁ。

作る才がある人が作ることにのみ集中できて、
その他の事をうまく分散できるといいのに。とか思ったりする。
0792デフォルトの名無しさん2005/04/20(水) 21:58:27
>>791

Seasarが価値があるものならそれは人は現われるけど、そうではないのだから、どうしよもない。
0793デフォルトの名無しさん2005/04/20(水) 22:02:28
>>790
的を射ているのかもしれない。

フレームワークなのだから、既にしっかりしたノウハウを持っている人の目には
今更…のように写ったりしそう。ただ、作成される多くのものが
そのフレームワークの作法に従うことで統一感が生まれて保守効率が
上がるような可能性はあるよね。それでは世界を変えるまではいかないけど。

プロジェクトとして推す時に「ここに詳細な情報があります」って言えることは
かなり大事じゃないかな。誰それのブログ端から読んでよってのはどうかねぇ。
情報は統一されていないと探しづらいと思うのだ。
これは、狙っている層がJavaの業務アプリだから特に思うこと。
0794デフォルトの名無しさん2005/04/20(水) 22:03:49
>>790
雑誌の記事に載せるくらいでプロモーション力あるというなら、プロモーション力の敷居はかなり低いんだな。
0795デフォルトの名無しさん2005/04/20(水) 22:05:27
>>793
MLのログもありますよw。
0796デフォルトの名無しさん2005/04/20(水) 22:14:18
>>793

作法には価値があると思う。
だから、Seasarはだめでも、「くーす」はなかなか、広める価値のあるものだと思ってて。
コントロールはステートレスとか、分かってる人にしてみれば、当たり前だろみたいなことだけど、
学習中はその徹を踏んでしまうかも。

オブジェクト指向プログラミングって、深い理由がわからなくても、OO的にデザインされた
ライブラリを使うことで自然に生産性上がるのを体感して意味もわかってくるみたいなこと
あるけど、ウェブ/データベースプログラミングにおいては、いまいち実感しづらいところもあって、
Seasar使えば分かるんじゃないかみたいな人いると思うんだけど、残念ながら、
これはいくら使っても体感できないんだよね。

作法は作法として覚えるしかないと思う。フレームワークが解決することとも思えない。
Javaはウェブ/データベースプログラミングには向いてないし。
ホントに原理がシンプルで扱いやすいフレームワーク/言語も含めたプラットフォームの
分かりやすいものだけが生き残る。
0797デフォルトの名無しさん2005/04/20(水) 22:17:21
>>794

雑誌って基本的にアホで、特にソフト開発者向けの雑誌ってさらにアホなんだけど、
それでも載せるってのは、あほだからこそでもあるけど、そう簡単じゃないぜ。
0798デフォルトの名無しさん2005/04/20(水) 22:36:34
>>796
自分とは思想が逆みたいなんだけど、面白いのでしつこく食い下がってみる。
作法はできる限りフレームワークで吸収してやる部分じゃないかな。
例を挙げちゃうと焦点がぶれたりする可能性があるので
逆にまずいかもしれないけど、StrutsなんてFrontControllerだよね。
これをFrontController知らない人でも強制的に使わせてるよなと。

覚えること、考えることを減らすためにフレームワークやライブラリは存在
すると思う。オブジェクト指向については流すよ。哲学論争になりやすいし。

>ホントに原理がシンプルで扱いやすいフレームワーク/言語も含めたプラットフォームの
>分かりやすいものだけが生き残る。
これには同意。特に多人数開発ではキーになる考え方だろう。
わかりやすくて、しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
そういう意味ではJavaもDIもそんなに的外れではないかなと思ってる。
0799デフォルトの名無しさん2005/04/20(水) 22:43:44
>>798

> しょぼい開発者がいてもちゃんと動く仕組みが宜しいかと。
> そういう意味ではJavaもDIもそんなに的外れではない

フレームワークに関しては、漏れは、
ホントにいいものなら、無いよりはマシくらいの位置づけで、
たぶん、ほとんどの人はそうでないか。

フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。

だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
そっちのほうがはるかに社会的だと思わんか。
0800デフォルトの名無しさん2005/04/20(水) 22:46:19
フレームワークが少しは寄与するっつっても、それはいいフレームワークの場合の話で、
Javaはもともとウェブ/データベースプログラミングに向いてないし、
Seasarとか評価してみたけどやっぱり使わないほうがマシなんだよ。
08017982005/04/20(水) 22:47:13
ちょっと「作法」の意味がずれてしまっていたかもしれない。
>>793の「作法」はソースコードの統一感としての作法で
>>796以降の「作法」はもう少し価値の高いある種パターンのような
分野にまで発展した考えで論じられているね。

特に訂正は無いんだけど、確認のため投稿。
0802デフォルトの名無しさん2005/04/20(水) 22:53:22
>>801

>793の「作法」はソースコードの統一感としての作法

まさかとは思ったけど、こういうのをフレームワークで縛れるとか思ってる人がまだ結構いるんだよね。
現実に目の当たりにすると、腹の底から軽蔑しますよ。
ホントにヒドイと思う。
0803デフォルトの名無しさん2005/04/20(水) 22:58:04
>>799
> だから、もうSeasarとかJ2EEとかSpringやらに騙されるな
> 近寄るなと漏れは知らせたいんだよ。
> そっちのほうがはるかに社会的だと思わんか。

最後のこの部分しか読んでないが、この意見がアホなこといってることはわかる。
0804デフォルトの名無しさん2005/04/20(水) 23:01:20
>>799
優等生的に答えると、フレームワークは設計の再利用だよね。
これは実装の再利用であるライブラリと対になっていると思う。
無ければ自分でその時作るだけ。だけどある程度良い設計、実装が
既に提示されているのなら利用した方が良いぞと。

既存フレームワークで救うのはしょぼい開発者の中でも
駆け出しの設計者になるだろう。あと、熟練者でもわざわざ0から
フレームワークを構築しなくて良くなるので時間の節約になるよね。
ドキュメント書かなくても良いし、既にそれを知ってる人はいきなり使うだけだし。

>フレームワークでしょぼい開発者が救われるのかといえば、少しは寄与するかしれんが、かなり嘘で、
>そんなもん、ただ開発プロセスの中に学習・フィードバックの仕組みが機能してるかどうかだけにかかってる。
教育の仕方をどうするかって話で解釈合っているかな。
もう少し上のレベルに話が広がってしまいそうなので流します。
0805デフォルトの名無しさん2005/04/20(水) 23:11:08
>だから、もうSeasarとかJ2EEとかSpringやらに騙されるな、近寄るなと漏れは知らせたいんだよ。
>そっちのほうがはるかに社会的だと思わんか。
いろいろ書こうと思ったけど、まとまらなかったので質問してみる。
>>799の開発ではどんなフレームワークを使っているの?
もし良かったら書いてみてくれないかな。その方が話がわかりやすくなりそう。

>>802
うーんと、言わんとしているところが良くわからなかった。
ソースコードの統一感って言うのは見た目の問題だから
「Strutsで作ってるよ」「あー、じゃぁActionクラスを継承すんのね」
みたいな部分という意味で書いたんだ。もう少し書いてみてくれないか?
0806デフォルトの名無しさん2005/04/20(水) 23:12:51
>>803
自分はここ以外はそれほど的外れでも無さそうに思ってる。
0807デフォルトの名無しさん2005/04/20(水) 23:25:02
>>805
Seasar使うくらいならPure Servletのほうがいいよ。
シンプルにやりゃいい。

Struts使うことでAction使うことが自明になるとしても、それが? って感じでしょ。
何の役にも立たない。なら使わないほうがいい。

ウェブインターフェースのアプリケーションなら、
Rubyが最適だと思いますよ。文字列処理が高機能、コードも短くて済む。
いい実装例だなと感じてるのは

http://www2a.biglobe.ne.jp/~seki/ruby/divip.html

バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。
0808デフォルトの名無しさん2005/04/20(水) 23:35:47
>>807
えーと、プロジェクトの中でみんなServlet開発をしているって意味かな。
それは開発のスピードが遅そうに感じるんだけど、自分だけだろうか。
StrutsのActionの話は、そういう部分を合わせないと理解が遅い人が
いるよねって話。逆にこんなもん合わせるだけでルーチンワークに
乗せられたりするものだったりもする。

自分は今までの話を「多人数で開発する」ということを念頭に書いてる。
これは、Seasarみたいなものが狙っているターゲットがそうだから。
紹介してくれたアプリも多人数で開発するようなものでは無さそうだね。

ちなみに、個人で使うなら今のS2を使わないってのは自分もそうだと思うよ。
一人でWEBサイト構築するならRUBYは触ったこと無いのでPHPかな。
共通部をまとめてるうちに結局自分用フレームワークできちゃうけど。
08098032005/04/20(水) 23:44:20
>>806
あ、ほんとだ。
ってことはあれだね。
正しい意見を述べておいて、結論だけは正しくない意見にしておけば、正しくない意見を正しいと思わせることができるっていう高等技術。
0810デフォルトの名無しさん2005/04/20(水) 23:45:51
>>807
Strutsは単にフォームへの入力をBeanに格納してくれるただのライブラリだ。
0811デフォルトの名無しさん2005/04/20(水) 23:52:58
いくらRubyがよくってもまだまだ採用しやすい状況じゃないんだよね。
5年かもっと前のJavaみたいなもんで、ユーザとか元請けのSIerから
止められるのが普通じゃない? ちっちゃいところはいいかもしれんけど。
Rubyできるやつサクッと集められるとも思えないしね。
だから、ここでRubyが最適とかいわれても逃避にしか見えない。
Javaでどうするか、DIでどうにかなるのか、って所でスゲーやつの
話が聞きたいです。
0812デフォルトの名無しさん2005/04/20(水) 23:57:13
>>809
いや、大抵は>>803みたいに最後だけ見て「こりゃだめだ」って切り捨てられる罠。

そろそろ筆置きます。
長文連発すまなかった。>スレの人々
あと、S2から凄く離れてしまってすまん。
長々付き合いありがとう。>>807
0813デフォルトの名無しさん2005/04/21(木) 01:35:17
>>788
>>787が1行目で言いたいのは、
メジャーなリリースと、マイナーなバージョンアップを分けてほしいということかと。
08147872005/04/21(木) 01:51:04
>>813
いや、S2StrutsとかS2JSFとか、全部含んでSeasar2.x.xとして出して欲しいってことです。
S2JSFのこのバージョンはSeasar2.1.8じゃないと動きませんよ、とか、でもS2XXXはこのバージョンでは動きませんよとか、わけわからん。
0815デフォルトの名無しさん2005/04/21(木) 10:33:20
XMLファイルで生成物を変更できる小洒落たファクトリーとしてしか理解できてない
んだけど、十分に単純で便利だと思うんだが・・・・・・
なんでここでは否定的な意見の方が多いんだろう?
0816デフォルトの名無しさん2005/04/21(木) 10:41:59
簡便なものが実用可能となると決まって反発がある。
そんな感じじゃないですか。

eclipseからJava始めた人はクラスパスとか
判ってなくてけしからん、とか。
俺は知らなくてもできるんならそれでいいし
トラブルになったらその時に調べて
覚えりゃいいと思うんだがなあ。
0817デフォルトの名無しさん2005/04/21(木) 10:53:27
>>815
この理解で概ね合っていると思っていいよな?駄目だったら頭いい人突っ込んでくれ。
AbstractFactoryにしたくなるような生成部分を統一的な方法で提供しているって
理解なんだけど。
0818デフォルトの名無しさん2005/04/21(木) 11:11:31
>>815
それならSpringの方が日本語の資料も多くて便利
0819デフォルトの名無しさん2005/04/21(木) 11:22:28
>>815
ここで小難しいこと言ってSeasarだめ論(もっと言うとJavaだめ論)を展開してる人って、
案外そういう簡単なことが分からないのかもね。
難しく考えすぎと言うか。

>>818
それは好みの問題でしょう。
0820デフォルトの名無しさん2005/04/21(木) 11:34:14
>>819
Seasarの説明に、次世代どうのこうのとか小難しく書いてあるから。
0821デフォルトの名無しさん2005/04/21(木) 11:45:14
>>814
S2とS2Daoと、あと戦略商品としてS2JSFをバンドルしてくれればいい。
個人的にはS2Strutsも。
0822デフォルトの名無しさん2005/04/21(木) 11:59:00
koichikさんレスアリガ�d
0823デフォルトの名無しさん2005/04/21(木) 12:09:22
>>807
> Seasar使うくらいならPure Servletのほうがいいよ。
> シンプルにやりゃいい。

シンプルっていうよりサンプルしか作ったことないとか?
まともに開発したことあるやつとは思えない。

> バックエンドとの分離も簡単シンプル、台数並べれば並べるほど比例して処理を分散する
> みたいな仕組みも作れる。そのプログラミングも贅肉なしのライブラリが使えるし。

後ろが分散できたってしょうがないだろ。なんか素人くさい。学生?
0824デフォルトの名無しさん2005/04/21(木) 12:13:42
>>821
標準セットパッケージみたいな感じだよね。
これ一個でとりあえず美味しい汁を吸えますみたいな。
0825デフォルトの名無しさん2005/04/21(木) 12:14:32
>>823
まぁまぁ、そう反応しなさんな。
見てる切り口が多分全然違うのだよ。
0826デフォルトの名無しさん2005/04/21(木) 12:26:10
>>823
Strutsすら必要ないなら、Seasarも使わずServletに処理ベタ書きの方がいいってことじゃない?
仕事にはいろんな規模のものがあるんだから、それはそれでいいかと。
0827デフォルトの名無しさん2005/04/21(木) 12:27:54
>>824
S2JSFがSeasarのコンテナ機能を使わずUtilだけ使ってるんだったら、UtilをわけてS2+S2DAO+Util/S2JSF+Utilというふたつのパッケージでもいい。
0828デフォルトの名無しさん2005/04/21(木) 12:37:09
>>827
普通にjsf.diconとかあるけど
0829デフォルトの名無しさん2005/04/21(木) 15:57:26
>>826
もちろんそれはそれで良いと思う。
けど、だからつって物知り顔で「誰にとってもフレームワークひいてはS2イラネ」って言うのはどうかと思う。
あんだけ自信満々で言われちゃうと、漏れみたいなお馬鹿チンは「本当にいらないのかな…」って不安になっちまう。
自分は今有効に使えてるのにね。
0830デフォルトの名無しさん2005/04/21(木) 16:23:42
>>829
残念だけど、その取捨選択は君がするしか無いと思うよ。
人の言っていることを盲目的に受け入れるべきなのかそうでないのかって
ことだから。ここの人は自分が思うことを好き勝手に書いているだけだし。
>>790->>807みたいにちゃんと突っ込んだ話をしないとその根拠が
明白にならないからなかなか判断しようが無いのだけれど。

で、自分は彼の話がごく一部しか捉えていないようだと判断した。

>自分は今有効に使えてるのにね。
これを根拠に「自分には必要だ」でも良いんじゃない?
0831デフォルトの名無しさん2005/04/21(木) 20:39:58
>>819
日本語資料の多寡は「好みの問題」ではありません。
0832デフォルトの名無しさん2005/04/21(木) 21:57:18
Tapestryが好みでしか使えないように、Seasar2も好みでしか使えないと。
0833デフォルトの名無しさん2005/04/21(木) 22:53:58
またTapestryが何者だか訳分からんのだよなw
JAVAはフレームワーク多すぎ!て言うか、なんでもかんでもフレームワーク
って呼びすぎ!
俺のこれまでの知識では、「フレームワーク=湯の張られた鍋」と理解してた。
具材を入れていくと料理になるという、そんなイメージ?
でも、JAVAでは制御の反転が絡むと全部フレームワークって呼びやがる。
Seasarでどんな料理が出来上がるのか、10日も探し回っちまったじゃねぇ〜か!
当然、それだけでは料理になんかなるわけねぇ〜!そもそも、鍋ですらねぇ〜!
どっちかっつぅ〜と、やかん?とにかく、俺の馬鹿_| ̄|○|||
0834デフォルトの名無しさん2005/04/21(木) 22:57:07
Seasarってフレームワークだっけ?

最初からIoCコンテナ(DIコンテナ)としか言ってないような。やかんどころかコンロですな。
0835デフォルトの名無しさん2005/04/21(木) 23:04:07
>>833
コールバックを含むライブラリのことをフレームワークと呼ぶのだよ。
0836デフォルトの名無しさん2005/04/21(木) 23:04:50
>>834
分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は
ある。て言うか、変な人ほどフレdjさkljfsぢjfさいjふぉいj

やかんの心は、冷たい液体から温かい液体を生成するファクトリー
0837デフォルトの名無しさん2005/04/22(金) 00:11:45
>>836
> >>834
> 分かってる人ほどSeasarをフレームワークとは呼ばないみたいな印象は

JARの名前がs2-framework〜である件について
0838デフォルトの名無しさん2005/04/22(金) 00:24:17
Apache AvalonがFrameworkを名乗るからには、SeasarだってFrameworkって名乗ったっていいだろうなあ。

Avalonは(Jamesみたいな)サーバアプリケーションを作成するためのフレームワークと銘打ってるけどね。
0839デフォルトの名無しさん2005/04/22(金) 00:39:32
>>838
Seasarの場合は、S2Daoとか周辺を含まずにフレームワークなわけで。
0840デフォルトの名無しさん2005/04/22(金) 00:49:59
>>839
Avalon Frameworkだって周辺も何も含まずにフレームワークを名乗っていた。
あれはコンテナとコンポーネントのコントラクトを規定しただけのライブラリ。
Avalon Excaliburがコンテナの実装、Avalon Phenixになるとサーバ
アプリケーション用のフレームワークという位置づけになっていたかと。
Marlinはよーわからんがそうやって発散してお亡くなりに…
0841デフォルトの名無しさん2005/04/22(金) 01:18:27
まぁ、分類は学問的なこと考える人たちがすれば良い訳で。
分類の根拠がなんなのか位は抑えておいてもいいだろうけどな。
0842デフォルトの名無しさん2005/04/22(金) 10:52:46
Javaでは>>835の定義だな。
0843デフォルトの名無しさん2005/04/22(金) 10:53:49
テンプレートメソッドなクラスがあれば、フレームワークなのだよ。
0844デフォルトの名無しさん2005/04/22(金) 21:10:01
とゆーか生Servletだってフレームワークだし
0845デフォルトの名無しさん2005/04/22(金) 21:57:18
DIコンテナって、いろんな実装があるけど・・・
俺も学習用につくってみてもいいか?
0846デフォルトの名無しさん2005/04/22(金) 23:45:49
>>843
それは文字通りのフレームワークだと思う。

ファンクタを要求する単体のオブジェクトはどうなんだろう?
IoCを伴ってはいるけど、これをフレームワークと呼ぶのに
は激しく抵抗を感じる。

>>845
いいんじゃない?
DIコンテナという言葉こそ出てこないけど、JAVAの格言に
は、抽象ファクトリーパターンと動的クラスローディングの
組み合わせ例として、iniファイルを利用したDIコンテナが紹
介されてる。
0847デフォルトの名無しさん2005/04/23(土) 02:17:41
>>845
いいよ。
AOPまで実装すれば、とりあえずSeasarの対抗馬としてプロモーションできるし。
ドキュメントとメディアの取り込みさえできれば、すぐ広められる。
ただし、そういうプロダクトを運営するのには、結構手間がかかるし、覚悟がいる。
0848デフォルトの名無しさん2005/04/23(土) 02:32:29
>>847
SeasarやSpringと張り合おうなんて気は毛頭ないから安心してくれ。
あくまで学習用だからきれいでシンプルな実装をしたい。
0849デフォルトの名無しさん2005/04/23(土) 10:43:19
>>848
俺はそういう取り組みの繰り返しが将来の技術力を養うと思う。頑張れ。
0850デフォルトの名無しさん2005/04/23(土) 11:24:16
>>848
そしたら、機能的にはPicoContainerとかをまず見てみるといいかも。
0851デフォルトの名無しさん2005/04/23(土) 11:42:02
>>849
おいらはいい加減おっさんだが35歳で限界を迎えないように精進するよ。ありがとね。

>>850
Spring、Seasar、PicoContainerあたりの実装は確認済み。
PicoContainerのシンプルさは好きだね。

で、CgLibとjavassistの比較してるサイトとかしらん?
0852デフォルトの名無しさん2005/04/23(土) 22:31:40
>>851
>で、CgLibとjavassistの比較してるサイトとかしらん?
ここらへんってちょっと前にSeasarでも話題になってたし、はてなでもいって探せば
参考になるサイトとか出てくるんじゃねー
0853デフォルトの名無しさん2005/04/24(日) 01:43:13
>>817

AbstractFactoryが必要な部分ってシステムのコアに相当する部分で、
ここは自由にプログラミングできてしかるべきところを、
言語の非標準機能を使ってまで、統一的にする意味あんのかってあたりが微妙で、
テストしやすいとかいってるけど、これも結構あやしいと思う。
要するに、モックオブジェクトを返したいってことなんだろうけど、
冷静に考えて、それを作りたいシーンって、ホントにシステムのコアに相当する部分で、
ごく一部であって、そこをフレームワークにまかせてどうにかなるってことも、
無い気がする。有効なシーンがあれば教えてほしい。
0854デフォルトの名無しさん2005/04/24(日) 02:39:08
>>853
もうフレームワークって呼ぶな。話が無駄に混乱する。

有効なシーンも何も、幹と枝葉の相関を切りたいという要求は
普通にと言うより普遍的にあるはずだが・・・・・・
0855デフォルトの名無しさん2005/04/24(日) 02:57:19
>>854
切りたい欲求はそんなに無い、あったとしても、
そこはそのアプリケーションに合った適切な切り方をしたほうが
DIコンテナ機構を使うよりいいってこと思うんだけど
0856デフォルトの名無しさん2005/04/24(日) 21:42:58
>>855
> そこはそのアプリケーションに合った適切な切り方をしたほうが

「アプリケーションに合った」部分をDIコンテナは侵食しないぞ。
あなたの設計だと、Factory部分のコードがアプリケーションによって変わってくるのか?
かなりひどい設計だと想像するけど。
0857デフォルトの名無しさん2005/04/24(日) 22:57:32
俺はもう説明を諦めたんだが・・・・・・

>>856
どう言っても無駄だと思うぞ。
変な話だが、円滑なコミュニケーションにデザパタがどれほど大き
く寄与してるか実感した。

JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
からコンパイルへの依存を排除できる点」だよ。
で、説明は終わりなんだよな。
多段に積み重なった知識の最上段のみを対象に会話を進めていく
って行為は、モードの違う相手とはチャンネルが合わないんだなとw
0858デフォルトの名無しさん2005/04/24(日) 23:44:32
>>857
> JAVAで会話可能な相手なら、「DIコンテナの利点は抽象ファクトリ
> からコンパイルへの依存を排除できる点」だよ。
> で、説明は終わりなんだよな。

使ってるやつはそれで説明が終わりと思ってて、使ってないやつにとってはそれでは説明になってないと思う。
■ このスレッドは過去ログ倉庫に格納されています