国産オープンソースDIコンテナSeasar V2(S2)

一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
それではスタート！

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

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

関連スレ(なのか?)

Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/

Java⇔RDBのMapping-Frameworkを語るThre Vol.3
http://pc5.2ch.net/test/read.cgi/tech/1090653286/

2 ：デフォルトの名無しさん：04/08/09 18:39

またJavaのゴミフレームワークかよ。
いい加減スレ一本化しろよ。
下火言語が調子に乗るなよ。

3 ：デフォルトの名無しさん：04/08/09 19:00

うほぅ！これ激しくイイ！

4 ：デフォルトの名無しさん：04/08/09 20:03

他のフレームワークに対する利点と欠点をまとめてくれ。

5 ：デフォルトの名無しさん：04/08/09 20:23

利点 - 国産
欠点 - 資料なし

終了。

6 ：デフォルトの名無しさん：04/08/09 21:37

資料無しはダメダメだね

7 ：デフォルトの名無しさん：04/08/09 21:43

/// 糞スレ終了

8 ：デフォルトの名無しさん：04/08/09 22:12

資料って？マニュアル？チュートリアル？

9 ：デフォルトの名無しさん：04/08/09 22:17

フレームワークというよりはお手軽なライブラリじゃねえの？
・クラス間の依存性を減らす（DI）
・ORM難民でも使える便利なS2DAO
・各種フレームワークとの連携（S2Struts,S2Tapestry,S2Hibernate,S2OpenAMF)

10 ：デフォルトの名無しさん：04/08/09 23:48

10get

11 ：デフォルトの名無しさん：04/08/09 23:53

とりあえず使ってみた上での批判レスがあんまり無いね。

12 ：デフォルトの名無しさん：04/08/09 23:57

ageるなヴォケ
javaみたいな糞がいくつもスレたてんな

13 ：デフォルトの名無しさん：04/08/10 00:05

>>11
使ってるやつがいないんじゃないの(ﾌﾟｹﾞﾗ

14 ：デフォルトの名無しさん：04/08/10 00:09

>12 こんな僻地の板で堅いこというな、言語でどうこうホザくのはなんかヴォケ通り越して哀れだぞ。

15 ：デフォルトの名無しさん：04/08/10 00:15

>>14
煽る暇あったらネタ振ったら。
ないなら終了だな。

16 ：デフォルトの名無しさん：04/08/10 00:17

時代はLL
Javaは糞
よって終了

17 ：デフォルトの名無しさん：04/08/10 00:20

普通本スレであまりにその話題が多すぎて
スレから追い出される形で専用スレ立てるのが常識なのにな。

18 ：デフォルトの名無しさん：04/08/10 00:26

本スレってどこよ？
>>1立て逃げせずにちゃんとネタ振れよ

19 ：デフォルトの名無しさん：04/08/10 00:30

＞＞１７
２ｃｈの常識（藁

20 ：デフォルトの名無しさん：04/08/10 00:36

>>16
LLのイベントには Groovy と Pnuts のプレゼンがあったわけだが。

21 ：デフォルトの名無しさん：04/08/10 00:40

開発者のblogだ
ttp://d.hatena.ne.jp/higayasuo/

チュートリアルだ。少し古いバージョンだが使えるだろう
ttp://www.wikiroom.com/Seasar/?Seasar%20V2

ここもわかりやすい
ttp://garbagetown.zive.net/eewiki/Viewpage.do?pid=@53656173617232

設計関連はこっちにまとまっている
ttp://www.wikiroom.com/tpircs/?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1

後は付属のドキュメントを読めば一通りわかると思うんだがなー

22 ：デフォルトの名無しさん：04/08/10 00:49

>14 おまいのレスからほとばしる知性と知見でまともに一行書いてやってくれ、Groovyも対応してるしな。
時代はヘブライ語でもPythonでもRubyでも何でも良いわ、外でLLとか略すと恥書くぞ。
>15 ネタって？マニュアル見たら、この板に徘徊してんなら技術的見地から突っ込めるだろ？笑いが欲しけりゃ他あたって下さい、すまんな。

23 ：デフォルトの名無しさん：04/08/10 00:57

今日も暑いな

24 ：デフォルトの名無しさん：04/08/10 00:58

ああまったくだ

25 ：デフォルトの名無しさん：04/08/10 01:03

漏れはS2使ってる

26 ：デフォルトの名無しさん：04/08/10 01:12

本スレってこれか？
http://pc5.2ch.net/test/read.cgi/tech/1077465099/l50
ちょっと見ただけだが粘着っぽいのがいるようだな
だからこのスレもこんなに荒れてるのか？

27 ：デフォルトの名無しさん：04/08/10 01:26

このスレに書き込んでる輩は、
みんあひがさんに合ったことあるに違いない。

28 ：デフォルトの名無しさん：04/08/10 01:42

俺はないが何か？

29 ：デフォルトの名無しさん：04/08/10 06:53

2次ドキュメントがないのかと思ったら、1次ドキュメントがまったくないのな。
JavaDocすらついてないし。
DIファイルに何が書けるかももちろんどこにも載ってない。

S2Hibernateのドキュメントが特徴的なんだけど、コメントもないソース列挙しておいて
「簡単に利用できるということが分かっていただけたと思います。」
と書いてしまう感覚の持ち主。
ダウンロードファイルがjarになっているのは、jarも解凍できないやつは使うな、というメッセージなんだろう。

お友達に便利に使ってもらえればいい、っていう、とってもローカルなライブラリだね。
ひがさんのお友達以外には、使う価値はありません。

30 ：デフォルトの名無しさん：04/08/10 08:03

パッケージソフトみたいなものを作るとき、S2を使えばソースを直接いじらなくても、
カストマイズできるようになる。カストマイズ→出荷、を何回も繰り返せれば、
S2投入のオーバーヘッドは回収できる。
もちろん再利用を前提とした作りにしなければならないけど、実はこれが難しい。

反対に受託とかで、毎回違うものを開発しているところはS2のメリット無いでしょ。
単に作って納品するだけなら、S2を使わない方が速い。教育のコストもあるしね。
再利用を考えないなら、１つのプログラムを、あんな風にいくつものファイルに分割して
散在させるのは無駄というもの。

S2の作者さんが働いているような大手SIerなら利用価値はあるけど、それ以外はどうかな？

31 ：デフォルトの名無しさん：04/08/10 08:16

>>29
> ダウンロードファイルがjarになっているのは、jarも解凍できないやつは使うな、というメッセージなんだろう。

Java使ってるならjarの解凍は普通出来ると思うんだが

32 ：デフォルトの名無しさん：04/08/10 08:23

>>30
S2に限らず、POJOを利用するDIパターンなら兵隊の教育は不要なんだが……。

33 ：デフォルトの名無しさん：04/08/10 08:25

>>30
> 再利用を考えないなら、１つのプログラムを、あんな風にいくつものファイルに分割して
> 散在させるのは無駄というもの。

お前、Java使った仕事してないだろ？　プログラムとかファイルとかいう単位ってなんだよ（ｗ

34 ：デフォルトの名無しさん：04/08/10 08:33

何かドキュメント粘着多いようだが
漏れは落としてきて普通に使えたぞ
ちょっと触ればすぐわかるだろこれくらい

35 ：デフォルトの名無しさん：04/08/10 08:39

>>32
> S2に限らず、POJOを利用するDIパターンなら兵隊の教育は不要なんだが……。

S2をどこまで使うかにもよるけど、裏側で何をされているかは理解させないと
まずくない？つーか、それがわからなければS2を使う価値ないよ。

36 ：デフォルトの名無しさん：04/08/10 08:43

>>34
> 漏れは落としてきて普通に使えたぞ

それは、強いて言えば
「簡単なサンプルプログラムが動いた」
「実戦投入して客に納めた」
のどちらかな？そこが問題だ。

37 ：デフォルトの名無しさん：04/08/10 08:44

釣られすぎですよ

38 ：デフォルトの名無しさん：04/08/10 08:46

JSP使ってるのにServletの仕組みを理解してないヤシがいるほうがまずいくらいだがな
フレームワーク使うってそういうもんだ。全員がフレームワークの裏側まで知らないといけない
というようでは意味がないだろう

39 ：デフォルトの名無しさん：04/08/10 08:47

漏れはS2で作って納品しましたが何か？
一人有限なので今年はこれで十分かと思ってますが何か？

40 ：デフォルトの名無しさん：04/08/10 09:00

>>29
> DIファイルに何が書けるかももちろんどこにも載ってない。
components.dtd見れ

41 ：デフォルトの名無しさん：04/08/10 09:02

>>29
> S2Hibernateのドキュメントが特徴的なんだけど、コメントもないソース列挙しておいて
> 「簡単に利用できるということが分かっていただけたと思います。」
> と書いてしまう感覚の持ち主。

まずはhibernate使えるようになろうな。話はそれからだ。こっちいけ
http://pc5.2ch.net/test/read.cgi/tech/1090653286/l50

42 ：デフォルトの名無しさん：04/08/10 09:04

>>29
> ひがさんのお友達以外には、使う価値はありません。

なんだひがさんに嫌われてるやつの粘着か。つまらん。

43 ：デフォルトの名無しさん：04/08/10 09:07

>>39
> 一人有限なので今年はこれで十分かと思ってますが何か？

そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。

44 ：デフォルトの名無しさん：04/08/10 09:13

そうだな。頭悪い奴とこれ以上一緒に仕事できねーって思って
独立したから一人で出来る程度しかやらないよ。
ちゃんと保守契約も結んでるから問題ナッシング。
さくっと納品できたので金額を考えるとおいしい仕事だったよ。
S2はありがたいよ。

45 ：デフォルトの名無しさん：04/08/10 09:15

そんなつまらんことでスレ立てたのか。
まったくスタンドプレーの好きな迷惑な奴だな。

46 ：デフォルトの名無しさん：04/08/10 10:00

>>43
> そーだよな。自分ひとりでやるなら、自分だけわかってりゃいいからな。

漏れのとこは、無理だな。
旗振ってもついてこねーだろうし、上司もいい顔しねーよな。

47 ：デフォルトの名無しさん：04/08/10 13:10

なんだ、単なる宣伝スレか。

48 ：デフォルトの名無しさん：04/08/10 13:31

ならもっと宣伝してよ。

49 ：デフォルトの名無しさん：04/08/10 14:22

S2の作者の会社(電通国際情報サービス)で、有償サポートの検討開始だってさ。
価格はプロジェクト単位の年間サポートで50万。
http://d.hatena.ne.jp/higayasuo/20040810

日本発のオープンソースビジネスかな？めでたし、めでたし。
これまでS2を盛り上げたみんな、お疲れ様でした。

50 ：デフォルトの名無しさん：04/08/10 15:53

>>49
よかったよね。サポートを欲しがる客でも
安心して提案できるようになるね。
これでもっとS2を使っていきやすくなるよ

51 ：デフォルトの名無しさん：04/08/10 17:12

SRAを忘れるなよ＞日本発のオープンソースビジネスかな？

52 ：デフォルトの名無しさん：04/08/10 19:12

>>51
> SRAを忘れるなよ＞日本発のオープンソースビジネスかな？

作者が日本人ということでは、多分初めてじゃないかな。
Rubyはどうなんだろ。

53 ：デフォルトの名無しさん：04/08/10 20:07

>>49
> S2の作者の会社(電通国際情報サービス)で、有償サポートの検討開始だってさ。

そのうち「S2認定技術者試験」みたいなもんもはじめたりして。

54 ：デフォルトの名無しさん：04/08/10 21:22

上のほうで絡んでるヤシは正にそういうのが欲しいんじゃないの＞認定
何かオプソ使うの好きなタイプじゃなさそうだし認定なら当然ドキュメントとか出てくるだろうし

55 ：デフォルトの名無しさん：04/08/10 22:22

>>30
> 反対に受託とかで、毎回違うものを開発しているところはS2のメリット無いでしょ。
> 単に作って納品するだけなら、S2を使わない方が速い。教育のコストもあるしね。

お前は仕様が完全に固まってから作れるのか。うらやましいぞ。
仕様変更のときにこそDIは便利なんだがな。お前触ってないだろ。
別にS2でなくてもいいからDI触ってみろ。Picoとかわかりやすいぞ。

56 ：デフォルトの名無しさん：04/08/10 23:11

>>53
> そのうち「S2認定技術者試験」みたいなもんもはじめたりして。

で、その前に認定試験対策研修が開催されると。

57 ：デフォルトの名無しさん：04/08/11 00:45

恐ろしく具体的な話の出ないスレだな

58 ：デフォルトの名無しさん：04/08/11 00:57

使ってない人間ばかりだからだろう。使ってる人間は来てないようだな。

59 ：デフォルトの名無しさん：04/08/13 17:04

>>41
サイトのトップページで「優しさや易しさを重視」って書いてなければ問題ないんだが。
と思ったら、「優しさや易しさを重視」の記述なくなってるね。
じゃあ、問題ないよ。

それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。

60 ：デフォルトの名無しさん：04/08/13 20:23

ソースのインスタンス変数名の"_"がイヤ。
あとは完結でいい

61 ：デフォルトの名無しさん：04/08/14 01:39

>>59
> それより、Springがある状況で、Seasarにどういう価値があるのかよくわからないんだけど。

WebSphereやWebLogicがある状況で、JBossにどういう価値があるのかわからん、といってるのと同じだよ。
それはさておき、DIという一種のパターンに対して、実装の形はいろいろあるってことだな。
SpringはBeanにこだわりすぎて結果として色んなものがどんどん密結合していっていると漏れは感じる。
S2はバラバラであることとつなぎやすさを優先している。理念と現場の違いじゃないかな。
両方触れば実感できることだ。トップページごときをとやかく言う前にどっちもダウンロードして触ってみろ。
ここはプログラム板のはずだ。Spring以外にもHiveMindやPicoContainerとか触ってみてくれ。
個性の違いを感じられると思う。DIの面白さを実感してみてくれ。

62 ：デフォルトの名無しさん：04/08/14 07:24

JBossはフリーだし、AOPも楽しそうだし。

なんか、Springでできることをやりなおしてる感じだと思ったんだが。
できることの違いじゃなくて、やりかたの違いなのか。

それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
仕様がないので、いつ使い方が変わってもおかしくない印象。
ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。

63 ：デフォルトの名無しさん：04/08/14 08:21

>>62
ほとんどの機能はドキュメントで説明されているはず。
記述が足りないところはあると思うけど。
なんで、ドキュメントがないといいきっているのか分からん。

64 ：デフォルトの名無しさん：04/08/14 12:40

>>62
> 仕様がないので、いつ使い方が変わってもおかしくない印象。

そうだね。
J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。

65 ：デフォルトの名無しさん：04/08/14 12:47

>>62
> JBossはフリーだし、AOPも楽しそうだし。

S2もフリーだし、S2のAOPは楽しいですよ。

> なんか、Springでできることをやりなおしてる感じだと思ったんだが。
> できることの違いじゃなくて、やりかたの違いなのか。

それをいったら、Geronimoとかどうするんですか（ｗ

> それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。
> 仕様がないので、いつ使い方が変わってもおかしくない印象。
> ソースとか見ればメソッドはわかるけど、それってメンテナンスで変更されたりしないの？みたいな。

ドキュメントのあるなしとメソッド変更のはなしは別でしょ。
Java自体だってそういうことはあるわけだし。

66 ：デフォルトの名無しさん：04/08/14 12:49

S2に限らず、DIって今のJ2EEでの開発に困ってないなら別にいらないよ。
今の状況に困っているなら、解決策のひとつとして検討する価値はあると思う。

67 ：デフォルトの名無しさん：04/08/14 12:52

>>64
> J2EEみたいにSpecificationがあって、それに沿った実装が開発されているわけじゃないしね。
> そういうリスクを取ってでも取り組む価値があるかどうかは、人によりけり。

そうだね。別にS2だけじゃなくて独自規格って多いしね。
共通規格がないものは使わないっていうのも大切だと思うよ。
S2はSpring同様にAOPアライアンスに準拠しているっていうけど
AOPアライアンス自体が公的な機関じゃないしね。

68 ：デフォルトの名無しさん：04/08/14 12:56

>>63
> >>62
> ほとんどの機能はドキュメントで説明されているはず。
> 記述が足りないところはあると思うけど。
> なんで、ドキュメントがないといいきっているのか分からん。

そうだね。そもそもS2って機能が少ないから、あれで一通りの説明にはなっている。
言葉足らずのところはあるかもしれないが、サンプルのコードとあわせて読めば
実際に使うのに必要なことはわかるよ。

>>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。

69 ：デフォルトの名無しさん：04/08/14 13:14

>>67
> 共通規格がないものは使わないっていうのも大切だと思うよ。

そこでC#でつよ！　dotNETマンセー！！

70 ：デフォルトの名無しさん：04/08/14 14:20

>>68
> >>62が気にしているのは、どんな風に使えばいいのかってことなのかもしれないね。
> でもそれってSQLのマニュアルを読んで「プログラマのためのSQL」みたいな書籍に
> 書いてるようなことが書いてないじゃないかっていってるようで、ちょっと違うんじゃないかと俺は思う。

うん。そう思う。現状S2のドキュメントって「何ができるか」が中心で、「どう使えばいいか」みたいな
ところまでは行ってない。だから使い手の力量が問われる。もっともその辺は有志(?)も気が付いて
いるはずで、サンプルプログラムの開発が進んでいる。単に使い方を知りたいという人は、それが
出てきてからでも良いんじゃないかな。始めるのは。

71 ：デフォルトの名無しさん：04/08/14 14:20

>>62
> それにしても、ここまでドキュメントがないと、実際に使うのは怖いな。

少しでも実際に触ってみた？　何か全然S2を触ってないように見えるんだけど。

72 ：デフォルトの名無しさん：04/08/14 14:31

>>68
逆で、「プログラマのためのSQL」みたいなHOW-TOは書いてあるけど、「SQLのマニュアル」がない。

73 ：デフォルトの名無しさん：04/08/14 14:35

えーとね、ソースをざっとみたところ、
フレームワークはほとんどinterfaceと実装クラスの組からできているので、
仕様の大幅な変更は少ないと予想できる。
実装の変更はあるだろうが。

で、S2のコア部分はシンプルなことしかしていない。
色んなクラスへのアクセス方法とライフサイクル管理、Weaving、これらを提供するのみ。

便利なコンポーネントは作ったのだが。
じゃあどうやってそのコンポーネントにアクセスするの？
ファクトリクラス？するとファクトリの作り方がコンポーネントごとにばらばらになっちゃうね。
JNDI経由？するとレジストリにコンポーネントを登録するのは何が担当するのかな。
コンポーネントの処理を変えてみたいんだけど、ソース改変はバグの元だね。ソースなかったりするし。

というのを、ぜんぶS2が面倒見ますよん、というわけ。
コンポーネントを取得したあとは、それぞれの作法に従ってクライアントコードを実装するだけ。

74 ：デフォルトの名無しさん：04/08/14 15:11

ま、Seasarはドキュメントを軽んじてるから、このままじゃ大きく普及するのは難しいだろう、と。
大きく普及することに意味があるかどうかは別として。

75 ：デフォルトの名無しさん：04/08/14 15:17

もまいは使わんでよろしい

76 ：デフォルトの名無しさん：04/08/14 15:50

何か妙にドキュメントのことばかり話題になっているが
マニュアルの不備を指摘してる人は
S2の技術的なことについてはどう思ってるの？

77 ：デフォルトの名無しさん：04/08/14 16:29

ドキュメントがちゃんとしてないと使えないくらいS2は複雑だっていいたいのかな？
それともドキュメントさえ整備されればS2がもっと普及するのに勿体無いっていいたいのかな？

78 ：74：04/08/14 16:54

>>77
後者。
せめてJavaDocとDICONファイルに何がかけるかのリファレンスは欲しい。

79 ：デフォルトの名無しさん：04/08/14 19:46

見てみたらソースにコメント全然ないね。。。

80 ：デフォルトの名無しさん：04/08/14 20:19

Aspect関連のクラスにちょっとだけ日本語コメントがある

81 ：デフォルトの名無しさん：04/08/14 22:07

コメントも含めて何でそんなにドキュメント話ばかりなんだ？
他にもっとネタはないのかよ

82 ：デフォルトの名無しさん：04/08/14 22:30

>>81
> コメントも含めて何でそんなにドキュメント話ばかりなんだ？

普通の人にとってドキュメントは使い物になるかどうか判断する大切な材料の一つだから。
「今あるドキュメントで十分だろ」という人は、そういうことに気が付かない。
もっともそういうことを気にする立場ではないから、そう思って当然なんだけどね。

83 ：デフォルトの名無しさん：04/08/14 23:40

今はまだ「分かってる人が使える」存在のもの。
EarlyAdopterがそれこそS2に限らずPicoContainerとか色々試してる段階。
俺みたいに、仕事で使うには標準であることのメリットが甚大だという理由でEJB3.0を待っている人間もいる。

ドキュメント整備は、それこそ普及戦略の上での問題だな。
もちろんもっとあったほうがいいというのには同意。
ドキュメントがあろうがなかろうが、いわゆる「厨」は一定比率は発生してしまうがな。

84 ：デフォルトの名無しさん：04/08/15 00:42

実務優先でやってるから、ドキュメントより実装が先ってのは分かる。
ちょっと前の大きな仕様変更で痛い目見たんだが、ドキュメントが沢山
あるとああいう場合に大変だよね。
だからドキュメントが必要最低限なのかなーと思ったりする。

便利なのは間違いないんだけど、現状じゃあんまり他人に勧められん。
コアの部分が大きく変わることはもう無いんじゃないかと思うけど、
あったら辛いしなあ。

85 ：デフォルトの名無しさん：04/08/15 03:22

ミドルウェアを標準先決めで作ると、CORBAみたいな恐竜が出来上がることがしばしば・・・

そういう意味では仕様文書を整えるよりも実装＋HowToを先出しするという方針もありだとは思うけど、確かに現状で手を出すのはちょっと怖いような。

86 ：デフォルトの名無しさん：04/08/15 04:57

>>84
一応、ひがさん本人は、もうコアの部分に大きく手を入れることはない、と言ってるしね。

87 ：デフォルトの名無しさん：04/08/15 05:01

チュートリアルで、とりあえず使うことはできるんだけど、リファレンスがないから
「できないことがわからない」

機能を網羅したリファレンスがあれば、設定項目に用意されてないのが確認できれば、できないというのがわかる。
もちろん、設定を組み合わせて実現するようなものは簡単に「できない」というのはわからないんだけど。

88 ：デフォルトの名無しさん：04/08/15 09:39

よくもまあこんなに無内容な長文をダラダラと書き続けられるもんだな

89 ：デフォルトの名無しさん：04/08/15 10:21

>>83
今のEJBも標準だけど、使えないわけだが。
EJB3が使えるようになるのはまだまだ先。
使えるものになるかも分からないしね。

重要なのは今何を使うかじゃないの。

90 ：デフォルトの名無しさん：04/08/15 11:27

>>21

> チュートリアルだ。少し古いバージョンだが使えるだろう
> ttp://www.wikiroom.com/Seasar/?Seasar%20V2

最新のS2.0.15では、いきなり最初のプログラムが例外発生で動かない。
(「要素タイプcomponentsは定義されていません」...)

原因は
・list03-4. car.xmlにDOCTYPEがない
・classpathに通すjarが違う(log4j-1.2.8.jar, ognl-2.6.5.jar, s2-framework-2.0.14.jarなら動く)
ため。

全体的には

> ここもわかりやすい
> ttp://garbagetown.zive.net/eewiki/Viewpage.do?pid=@53656173617232

こっちの方が親切かな。eclipseベースでどういった操作をするか細かく書いてあるし。
でもdiconファイルの書くのにXMLBuddyつかうのは冗長な気がする。
単にコピペさせればいいと思うけど。

91 ：デフォルトの名無しさん：04/08/15 23:06

>>90

× s2-framework-2.0.14.jar
○ s2-framework-2.0.15.jar

だろ。

92 ：デフォルトの名無しさん：04/08/16 01:28

縮小再生産を作っておいて「Springには負けない」とか言われてもね。
まあその発言が勇み足だったとして、そもそも真似してる先人を全く
リスペクトする気が無いみたいで、Springのここがだめだとか、作者を
からかうような書き込みとかばかりだし。そういう文化、体質が本当に嫌だ。

組織として責任を持つプロダクトならばともかく、オープンソースな
ソフトウェアは、そういったコミュニティに対する印象も使うかどう
かに大きく影響してくると思うんだが、そういう自覚は全く無いみたいだな。
もちろん全員とは言わないが。

93 ：デフォルトの名無しさん：04/08/16 02:52

コミュニティーの印象がどうであれ、良いプロダクトであれば、使うと思うけど。

あと、先人じゃなくて、ほぼ同じ誕生日だし。
S2で言っているType4を、後から取り入れたのは、Springだし。
その辺は、どっちも、どっちじゃないか？

まず、プロダクトの事実をちゃんと見たら？

94 ：デフォルトの名無しさん：04/08/16 03:43

>>92
要するにS2のコミュニティに粘着したいだけだろオマエ
実際にどれだけ触ってるんだ？　オマエの好きなSpringについても
S2の作者より触ってないんじゃねえの？
Springを引き合いに出すなら、具体的な比較とか書いてくれよ
長文の癖に技術的な話が全然ないしうざすぎるよ
そんなに粘着したいならマ板に逝け

95 ：デフォルトの名無しさん：04/08/16 03:47

Springの話題はこちらでどうぞ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/l50

96 ：デフォルトの名無しさん：04/08/16 03:57

>>92は当然これを読んでるんだろうから技術的なネタだしてくれよ

まあ正直この表紙はからかいたくなる気持ちもわかるがな
ttp://www.amazon.co.jp/exec/obidos/ASIN/0764558315/

97 ：デフォルトの名無しさん：04/08/16 04:14

しかし絡んでる奴すごいな。いつもドキュメントかコミュニティのことばかり。
他に何にもないのが気持ち悪い。しまいにはストーカーになるんじゃないか。

98 ：デフォルトの名無しさん：04/08/16 04:22

>>97
実装の大変さを分かってる人は無言実行タイプが多いからここには書き込まない。

99 ：デフォルトの名無しさん：04/08/16 09:54

ひょっとして熱烈なSpringファンが絡んでるのかと
思ったがあまりの内容のなさにそれじゃSpringが
可哀想だと思った

100 ：デフォルトの名無しさん：04/08/16 11:21

100ｹﾞﾄ

101 ：デフォルトの名無しさん：04/08/17 07:11

>>97
モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。

102 ：デフォルトの名無しさん：04/08/17 10:09

>>101
> モノはいいんだから、ドキュメントどうにかしろ、っていってるんだよ。
どのへんがいいのさ？

103 ：デフォルトの名無しさん：04/08/17 12:33

国産でオープンソースなところ

104 ：デフォルトの名無しさん：04/08/17 19:02

質素で日本的なところ。

105 ：デフォルトの名無しさん：04/08/17 23:55

質素というのは言い得て妙かもしれない。
良い意味でDIコンテナ部が全てだしな。

106 ：デフォルトの名無しさん：04/08/18 00:30

コンテナ部のドキュメント書き直されてるじゃん。
2chの無責任な書き込みにもちゃんと反応するのにビックリした。
いい人じゃないか作者さん。S2応援したくなってきたよ。今晩触ってみる。

107 ：デフォルトの名無しさん：04/08/18 00:49

ドキュメントドキュメントっていうけど
PowerPointの奴わかりやすかったけどなあ

108 ：デフォルトの名無しさん：04/08/18 08:11

>>106==>>1==社員乙

109 ：デフォルトの名無しさん：04/08/18 08:47

>108
（´д｀）?

110 ：デフォルトの名無しさん：04/08/18 21:41

>>106
かなりまじめに見てるらしい。
それを知ってるので、厳しいことかいてますよ > ひがっち

111 ：デフォルトの名無しさん：04/08/18 21:49

ひがっちっていうんだ

112 ：デフォルトの名無しさん：04/08/18 23:01

>>110
MLに投げればいいじゃん（ｗ

113 ：デフォルトの名無しさん：04/08/19 18:30

>>112
無責任に書きたいのでな。

114 ：デフォルトの名無しさん：04/08/20 11:12

最近責任のある立場ではっきりものをいえないへたれ日本人が増えてるよな。
２ｃｈが流行るわけだよ。

115 ：デフォルトの名無しさん：04/08/20 12:28

>>114
恥ずかしくない？

116 ：デフォルトの名無しさん：04/08/20 15:36

と無責任に意見をのべる114

117 ：デフォルトの名無しさん：04/08/20 21:11

で、藻前らぼちぼち技術的な話題はできないのか？

118 ：デフォルトの名無しさん：04/08/21 11:07

>>110
なんだ、かまって君だったのか

119 ：デフォルトの名無しさん：04/08/21 12:31

S2のコンテナ部分の特徴の一つにOGNLを使っていて、
SpringのPropertyEditorに相当する部分が不要な点が
あげられると思うんだけど、そのへんどうよ。
<arg>new java.math.BigDecimal(1)</arg>
みたいな。

120 ：デフォルトの名無しさん：04/08/21 14:32

>>119
> <arg>new java.math.BigDecimal(1)</arg>

どの位使う機会があるかわからないけど、便利なのは確か。
こっちの方が自然でわかりやすい。

121 ：デフォルトの名無しさん：04/08/21 17:47

>>119
Springのref,valueタグの役割をOGNLがやってるんだね。

122 ：デフォルトの名無しさん：04/09/02 01:06

EJBが難しくてよくわかんなかった俺でもS2はなんとか使い方がわかった。
くーすってやり方で設計してみたが、なんとか筋の通った設計書（らしきもの）ができた。

さて、あとはこのまま S2 で実装に落とせるかどうか。
自分が書いたシーケンス図を見ると、インターフェースやクラスにのっける機能が
明示されてるようにみえるけど、信じていいのかこれ。

123 ：デフォルトの名無しさん：04/09/02 08:21

>>122
やってから、また書き込め。

124 ：デフォルトの名無しさん：04/09/02 12:52

書いた本人が信じないで誰が信じるんだよw

でも考えてみりゃソフトウェアって書いた人間が一番信じてないことがよくあるな。

125 ：デフォルトの名無しさん：04/09/04 11:01

>>122
よく読むと不思議な文章だな（ｗ
よくわからないけど設計が出来てしまうのか
設計って考えながらやるもんだと思うんだが

126 ：122：04/09/06 22:41

実装始めたけど初手から躓いた。ドキュメントとサンプルを睨みつつ七転八倒。
結局ＤＩを理解してなかったことに２日かかって気づく。頭わるすぎ orz
なんというか、歴史あるクラス先輩に対して「そんな依存性は修正してやる」と殴りかかってる感じ。

で、さぁやってやるぞとS2Dao組み込んだら、Tomcat 起動中に s2containor の Servlet#init() で例外。
原因分からず。先が長そうでちょっと泣けた。

127 ：デフォルトの名無しさん：04/09/07 01:33

ガノタかよ（ｗ

128 ：デフォルトの名無しさん：04/09/07 06:29

>>126
例外が出たなら、トレースを見れば分かりそうな門だが。
diconファイルがどっかまちがってるんでしょ。
kijimunaを使いなさい。
http://sourceforge.jp/projects/seasar/files/?release_id=11157#11157

129 ：122：04/09/08 20:12

Servlet#init() での例外、原因判明。
S2DaoのBEANアノテーションが内部クラス扱いになって別の.classファイルが作られてた。
で、それを JBuilder が war に入れないでやんの。関連チェック、デフォだと外れてるのか orz

そんなこんなで、やっと JBuilderX で S2 + S2Struts + S2Dao が動いた。
これ幸せかも。なんだかソースがとってもキレイ。
もう少し作りこんでからまた。

130 ：デフォルトの名無しさん：04/09/10 00:02

S2Tapestryの情報って無いですね。
ドキュメントもしっかりしてないので苦労してます。

131 ：デフォルトの名無しさん：04/09/10 08:14

ソース嫁っていうポリシーだから。

132 ：デフォルトの名無しさん：04/09/10 08:39

>>131
マンドクセー
そんな時間掛ける気ねーよ。

はやくS2JSFでねーかなー。
そっちならソース読んででも習得したいな。

133 ：デフォルトの名無しさん：04/09/10 11:19

どういうことで苦労しているのかを書けばいいんじゃないの？

134 ：デフォルトの名無しさん：04/09/10 11:20

使い方を調べるのに苦労します・・・とか？

135 ：デフォルトの名無しさん：04/09/10 14:24:29

>>133
つーかさあ、JavaDocで作成したドキュメントぐらいはねーのかよ！

136 ：デフォルトの名無しさん：04/09/10 15:00:17

>>135
コメントもありません。

137 ：デフォルトの名無しさん：04/09/10 18:15:38

S2タペのサンプルなんて足し算するだけじゃねーか！
もっと実用的なサンプルねーのか？

TapestryとS2Tapestryのアプリケーション作成時の違いってこれだけ？
あとはTapestryのドキュメント読んで作ればいいのかな？

　・S2ContainerServletの設定　(web.xml)
　・エンジンをS2用に変更　(*.application)
　・ページ仕様にサービスの定義追加 (*.page)
　・ページクラスにコンポーネントのプロパティを追加して
　　サービスメソッドを呼び出す　(*,java)

138 ：デフォルトの名無しさん：04/09/10 19:02:44

依存性注入、っていうのがやっぱり今ひとつピンとこないんだが、
要は「論理設計（インターフェース設計）先行で開発せよ」ってこと？

くーすでやってると、まずインターフェースを書かないとなにも出来ないんで、
「とりあえず動くものを書け。話はそれからだ」っていうのを禁止してる感じがする。

139 ：デフォルトの名無しさん：04/09/10 21:23:33

>>135
getContainerするくらいだけなんだから
使うだけならJavaDocなくても困らん気がする
漏れはJavaDocが欲しいと思ったことはないな
サンプルは欲しい気がするけど

>>137
S2TapeはTapestryからS2を呼びやすくしてるだけだから
実用的なサンプルはTapestryのスレで聞いたほうがいいと思う

Tapestryについて語ろうよ！
http://pc5.2ch.net/test/read.cgi/tech/1067531714/l50

>>138
くーすは仕様先行で設計しようってだけだろ
別にDIでなくてもこういう考え方はありだと思う

140 ：デフォルトの名無しさん：04/09/10 22:21:02

さんぷるがほしいな。
S2Tapestry ＋ S2Dao
で、フレーム、セッションオブジェクトをバリバリ使ってるやつがいいな。

141 ：デフォルトの名無しさん：04/09/10 22:36:58

>>139
>別にDIでなくてもこういう考え方はありだと思う
それはそうなんだけど。「依存性を注入する」って、注入先を先に用意しないと成り立たない。
その注入先がインターフェース。この場合のインターフェースの役割って、業務システムのフレームワークでしょ？
それってつまり、DI で業務システムを組むってことは、詳細設計なき実装を不可能にする手法なのかな、と思ったわけ。

・・・作った後から仕様書書いたら切腹？

142 ：デフォルトの名無しさん：04/09/10 23:11:36

>>141
詳細設計なき実装が不可能？
おかしくないか？手続きのみの言語じゃあるまいし、設計書が無くても
コード書く前に普通、クラス構造は頭に思い浮かべるだしょ。

143 ：デフォルトの名無しさん：04/09/10 23:44:47

>>141
すまん漏れには何を言ってるのかよくわからん
DI関係なく藻前がどんな風に普段作ってるのか
教えてくださらんか？

144 ：デフォルトの名無しさん：04/09/10 23:46:05

>>140
フレームやセッションオブジェクトをバリバリ使うとS2は関係ないと思われ

145 ：140：04/09/11 00:30:55

>>144
TapestryでのFRAMESETの扱いや（S2とは関係ないけど）、
認証関係でセッションオブジェクト使って、
AOPで認証チェックやってるS2Tapestryのサンプルが見たいです。

ところでS2TapestryにすることでS2Daoの扱いが変わる（使いやすくなる）の？

146 ：141：04/09/11 02:46:18

>>143
Webは Struts で簡単な情報参照系しかやったことないので、
Windowsで作った受注出荷管理のときを例に。

１）システム機能仕様書、ERD、画面仕様書（レイアウトと処理内容、IO先）を同時並行に書く。
２）DB設計。
３）コーディング。複雑なロジックはコメントでクドクドと説明。
　　DBはデータ保障をトリガにおまかせ、SQLで気ままにアクセス。
　　基本的に１画面1クラスで機能を詰め込む。同系画面で継承は使うけど。

こんな感じ。

147 ：デフォルトの名無しさん：04/09/11 11:12:21

>>146
では次は「DI は詳細設計なき実装が不可能」と思った理由の説明を頼む。

ところで 1 画面 1 クラスってのは、どういう構造よ。
Action にビジネスロジック書いてるの？
それとも色々な Action クラスからある 1 画面の機能を詰め込んだサービスを
呼出してんの？

前者は推奨されてないし（10画面くらいのシステムなら別にいいとおも）、
後者はモデルの切り分けがおかしい。

で、同系画面では継承してる？
構造が分からないけど、サービスで切り出すのが綺麗だとおも。
継承では再利用性、メンテナンス性も低い。

148 ：デフォルトの名無しさん：04/09/11 11:39:06

簡単な情報参照系なら、Struts使う必要もないな。

149 ：デフォルトの名無しさん：04/09/11 13:02:27

作者、これまた大きくでたな。
ttp://d.hatena.ne.jp/higayasuo/20040911

------------------------------------------------------
まずは、Nirvanaと組んだS2JSF。JSFは、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、ツールベンダーの思わくが先行し、現場を見てない
結果だと思われます。

しかし、それも変わってきます。HTMLをテンプレートにし、DIコンテナと組みあわせる。
これなら、現場での使用にも十分に耐えられるでしょう。
くさったJSPなんかさよならです。重厚なEJBなんてさよならです。長いこと開発者を苦しめて
きた2つの技術。JSPとEJBに終止符を打ちます。

次は、S2Flex。時期的にはこっちの方が早く出ます。リッチクライアントも、試行錯誤の時期を
終え、いよいよ普及期に入ります。

2004年。これほど開発手法が激変する年は恐らくもうないのではないでしょうか。

150 ：デフォルトの名無しさん：04/09/11 13:32:35

開発手法の激変といっても、Javaローカルな話だね。
処理系依存。

151 ：デフォルトの名無しさん：04/09/11 14:13:21

まずは、DI を組み込んだ SeasarV2。 S2は、リリースされたから結構経つのに、いっこうに
使われる気配がありません。これは、作者の思わくが先行し、初心者に易しいを
ポリシーにしていたものの、実は初心者が理解できる代物ではなかったと思われます。

152 ：デフォルトの名無しさん：04/09/11 14:20:03

>>146
ロバストネス分析やシーケンス図を基にして「インターフェースを作る」ことを”詳細設計”と了解してる。
「設計」って考える作業でしょう。で、インターフェースって考えないと作れないから設計かな、と。
クラスそのままの引き写し構造でつくればいいってもんじゃないんでしょ。

インターフェースさえ作ってしまえば、あとは力仕事的にゴリゴリ書けそうだなと。
実装のうまい・へたはともかく「インターフェースの設計」のおかげで動きは保障されるだろうと。
お前はクラスを考えて作ったことが無いのかと問われると、たぶん頭の中でしかない。
せいぜい、主要部分のヘッダファイルを書くくらい。チームの時は実装担当者にお任せしてた。

んー。うまくまとまんないけど、DIの「構造と実装を分離する」ってのが、
・単なる実装レベルの一手段で、便利ツール的なものなのか、
・それとも設計手法に関わってくるほどのものなのか、
ってのが分かってないのかも。

>ところで 1 画面 1 クラスってのは、どういう構造よ。
勘違いされてるような。前述の例はWin32アプリ。具体的にはC++Builder。
細かい業務ロジックはフォームクラスに配置したUI部品のイベントハンドラに直書き。
重要な処理は private なメソッドに閉じ込めて、イベントハンドラから呼び出し。
たしか５０画面以上あるけど、その画面でやってることが基本的に１ファイルにまとまってて、
ほかの画面からも独立してるから頻発する改造に対応するには手っ取り早い。
Web だと通用しないかもしれないし、相当荒っぽいやり方だとは思うけど。

153 ：デフォルトの名無しさん：04/09/11 14:36:51

S2ﾀﾍﾟの作者もここ見てるね。
はてなに書いてたよ。

要望があれば書いてみれば。
メールしたほうがいいとは思うけど。

154 ：デフォルトの名無しさん：04/09/12 01:04:48

で、結局Springとどう違うの？

155 ：デフォルトの名無しさん：04/09/12 13:17:12

舶来か国産か

156 ：デフォルトの名無しさん：04/09/12 13:19:04

>>150
そうか？　.netだってSpring.netみたいなDI出てくるし
変わってくると思うけど

157 ：デフォルトの名無しさん：04/09/12 13:27:48

>>149に挙げられてるものはすべてJavaローカルなものだし。
.NETの人たちがMS以外のフレームワークを積極的に使うとは思えんし。

さらに言えば、コーディングレベルの話なので、本質的な変化ではないからなぁ。
仕事のやり方がかわるよりは、仕事に携わる人の種類・層が変わることの方が劇的な変化だから。

158 ：デフォルトの名無しさん：04/09/12 14:29:03

>>153
作者じゃないってさ。
ま、メンテナでもいいんだけどね。

確かにどうすれば普及するのかねえ。
なんかS2JSFが出てくると更に普及の可能性が低くなりそうな気がするね。
S2タペというよりはタペの話になってくるのかな。

しかしそのメンテナ曰く

＞＞そもそもドキュメントを読まなきゃ使えんと言うのが問題。

じゃ、どうやって使うんだろう？
今までマニュアルやリファレンス読んで作りながら習得してきたんだけど、
そのやり方には問題ありって事なのか？

もっと手っ取り早く習得できるやり方があるのなら大歓迎だけど．．．

159 ：デフォルトの名無しさん：04/09/12 14:35:28

補完してったらなんとなくわかる、ツールで適当にやってればできる、というのがいいということかな。
ドキュメントを精読しないと使えんというのは問題だろうが、だからといってドキュメントがないのも問題だな。

160 ：デフォルトの名無しさん：04/09/12 15:53:13

補完していくだけでセッション管理やトランザクション管理なんかが分かるフレームワークができればそりゃ普及するだろう。
というか、ウィザードで処理の雛形作ってくれるだけでも全然違うだろうね。。

つーか、そもそも補完する取っ掛かりが分からないからドキュメント見てるんだけど。

161 ：デフォルトの名無しさん：04/09/12 17:04:17

同様に、コメントなしでわかるプログラムが理想だが、だからといってコメントを書かなくてもいいわけではないな。

162 ：デフォルトの名無しさん：04/09/12 17:46:42

>>161
オブジェクト指向で書かれたプログラムでコメントなしってつらくねー？
JavaDocでもなんでもいいからオブジェクトの説明ぐらい要るだろ？

163 ：デフォルトの名無しさん：04/09/12 18:57:54

>>162
だが、クラス名だけで出来る限り分かるようにすべきだ。
たまにコメントがなければ、さっぱり意味の分からないクラスを見かけるが。

164 ：デフォルトの名無しさん：04/09/12 20:13:18

JavaDocは仕様を書くところで、
実装の説明じゃないから、
そこんとこヨロピク

165 ：デフォルトの名無しさん：04/09/12 20:16:38

>>163
英語分からない奴が無理やり英語の名前でクラス名つけたりするとそうなるよな。

わかんねーなら日本語をローマ字記述でクラス名書け！つーの。

166 ：デフォルトの名無しさん：04/09/12 22:00:38

しかし、KensyuとかHuriwakeとかHojyoとか、許せないローマ字はやめてほしい。

167 ：デフォルトの名無しさん：04/09/12 22:12:34

>>166
訓令式は知ってるよな。

168 ：デフォルトの名無しさん：04/09/12 23:30:06

>>166
S2と関係無いと思うんだけど。

169 ：デフォルトの名無しさん：04/09/13 00:32:58

もうね、jyoだけはやめて欲しいよ。

170 ：デフォルトの名無しさん：04/09/13 00:43:55

>>167
英語と混じるとはげしく違和感のあるローマ字記述法ですね？

171 ：デフォルトの名無しさん：04/09/13 13:16:21

>>170
英語と混じれば違和感あるのはどっちも同じ。

172 ：デフォルトの名無しさん：04/09/13 14:18:17

>>151
そんなあなたにEJB

173 ：デフォルトの名無しさん：04/09/13 14:54:00

英語に出来ない業務用語って多くね？

174 ：151：04/09/13 14:57:39

>>172
EJB は問題外です。今更 EJB 3.0 では DI や AOP と取り込んで
すばらしいものになりますってか。しかも 2.0 まで利用者の怒りが怖くて
互換性を残すと。金儲けする人も大変ですね。

175 ：デフォルトの名無しさん：04/09/13 14:58:40

EigoNiDekinaiGyomuYogo?

176 ：デフォルトの名無しさん：04/09/13 20:26:38

>>174
そんなあなたにドットネット

177 ：デフォルトの名無しさん：04/09/13 22:26:30

S2TapestryってAOPで認証チェックとかできるのですか？
そんなサンプルあれば欲しいです。

InterceptorでVisitオブジェクトをgetするために、
MethodInteceptorインターフェースを実装させてBasePageクラスを継承させるの？
なんか変ですよねえ。。。
どうすればいいのか教えてください。
いちいち、Pageクラスで認証チェックするのは手間です。。。

AOPじゃなくてもFilterとかでうまくできるのでしょうか？

178 ：デフォルトの名無しさん：04/09/14 01:28:11

>>173
「領収書」とかね。

179 ：デフォルトの名無しさん：04/09/15 00:24:00

>>178

receipt じゃだめなの?

180 ：デフォルトの名無しさん：04/09/15 00:28:21

>>179
じゃあ、「レシート」は？

181 ：デフォルトの名無しさん：04/09/15 00:36:08

日本語→英語→カタカナ
にしたときに違う意味になってしまうものは困る。

え、スレ違い？
話題ないんだからいいじゃん。

182 ：デフォルトの名無しさん：04/09/15 07:02:51

>>181
だったら>>177に答えてやれよ。

>>177
どうやらS2TapestryのPageクラスではAOPは使えないらしいぞ。
Tapestryは使ったこと無いけど、昨日のひが氏の日記に書いてる。

183 ：デフォルトの名無しさん：04/09/15 07:21:38

Tapestryは内部的にオブジェクトを生成するので、S2でインスタンス生成を握れない。
だからouterでDIを使うことはできるけど、S2AOPは使えない。

認証部分をS2から取ってくるコンポーネントに任せればいけるかも。
やったことないからわからんけど。
それでできるなら、もちろん認証部分のコンポーネントはDI可能。

184 ：デフォルトの名無しさん：04/09/26 23:22:30

そろそろS2JSFでる頃かな？
期待age

185 ：デフォルトの名無しさん：04/09/27 11:41:06

S2JSFは期待したいね。Kijimunaも良くなってきたから楽しみだ。

186 ：デフォルトの名無しさん：04/09/28 09:55:02

そもそものJSFのオープンな実装って出ないのかなぁ。

187 ：デフォルトの名無しさん：04/09/28 09:58:59

ともあれ、こういったコンポーネントはSpringの方が充実していくだろうから、オレとしてはSpringでDICONが使えるようにして欲しい。
今みたいな、同じ役割のメジャー&めんどくさいフレームワークとマイナー&お手軽フレームワークが並列する状況どうにかならんもんか。

188 ：デフォルトの名無しさん：04/09/28 22:03:26

軽いフレームワーク -> メジャーになる -> 要望に応えて重量級になる

189 ：デフォルトの名無しさん：04/09/29 03:56:43

>>188
核の部分は変わらないし、OGNL使ってるから高機能だし、Springに比べてお手軽なのは変わらんと思うよ。
SpringでDICONが使えるようになってほしい。
もしくはSeasarでSpringXXXが使えるようになってほしい。

190 ：デフォルトの名無しさん：04/09/29 06:52:35

>>189
そのDICONってなに?
Spring固有の機能使ってなければ、SeasarでSpringXXXはうごくんじゃないの。

191 ：デフォルトの名無しさん：04/09/29 09:23:06

>>190
Spring固有の機能使うからSpringXXXなんだと思う。

192 ：デフォルトの名無しさん：04/09/29 20:24:15

なんかFlexに力入れてるからS2JSF遅れそうだね

193 ：デフォルトの名無しさん：04/09/30 00:04:59

その分S2Tapeが強化されそうだし気長に待ってもいいんじゃない？

194 ：デフォルトの名無しさん：04/09/30 01:02:37

Tapeなんて使いもはん。

195 ：デフォルトの名無しさん：04/09/30 07:05:56

>>189
その使いたいSpringXXXってどんなやつ?

196 ：デフォルトの名無しさん：04/09/30 15:49:43

>>195
SpringHibernateとかSpringDAOとかJSF Springとか、Seasarでも並行開発されているヤツ。
今後もSpringの方が先行しつつ並行開発されていくヤツ。

197 ：デフォルトの名無しさん：04/09/30 17:41:30

>>196
素直にSpring使うほうがいいんじゃないか？

198 ：デフォルトの名無しさん：04/09/30 19:58:14

>>197
そしたら、Seasarの存在意義が。

199 ：デフォルトの名無しさん：04/09/30 20:59:38

SpringXXXを使いたいならSpringを使うほうがいいだろ。
漏れはS2DaoのためにSeasarを使ってるし。

200 ：デフォルトの名無しさん：04/09/30 21:37:22

S2JSFがそのうち出てくるのに今更S2Tapeやる気は起きない。
YSFとかでも勉強しとくかな。

201 ：デフォルトの名無しさん：04/09/30 22:02:08

お前らの会話は訳が分からん。
今後は文章に含まれる英字の量は全体に対して1%までと
規定するから、厳守するように。

202 ：デフォルトの名無しさん：04/09/30 22:35:29

SeasarのSpringより優れている点ってどこ？

203 ：デフォルトの名無しさん：04/09/30 22:43:17

NirvanaとかMyFacesがあるでしょ　＞186

204 ：デフォルトの名無しさん：04/09/30 22:54:13

＞202
国産・マニュアルが日本語、イベントも国内
今のところ、S2本体のソースがシンプルで追えなくもない
S2DAOが凄い、一方でS2HibernateもありO-Rマッパーの選択肢がある
Flash、Flexといったフロントエンドへの対応が進み出している
blog、MLでダイレクトにひが氏やコミッタにリクエストや質問を投げれる、
且つ、即座に採用されたり、回答がある
今のところ、Springと比較すると学習がお手軽、Spring MVCなんかを
DIって何？ってな新人さんに説明するのは難しいかも
お客さんのオプソ懸念に対して保険として国内での有償サポが準備？
まだ提唱されて間もないが、くーすといった開発方法論が芽生え始めている。

205 ：デフォルトの名無しさん：04/09/30 23:34:25

>204
S2Daoは確かに凄い。SQLを使える人なら間違いなく感激すると思う。
DB周りのコードがほとんど消えてなくなるんで、なんだか騙されてるような気がしてくる。

くーすは考え方はすっきりしてて分かりやすいけど、いざ実装しようとすると困る。
Strutsでいうと、Actionクラス＝くーすのコントロールで実装してみて一応それっぽくなったけど、
「ロジック層が業務フローを制御する」って言われると、コントロールがStruts依存になってるから駄目っぽいし。
でもコントロールをわざわざActionクラスと別に書くなんて面倒くさいし。書けといわれれば書くけどさ。

広く使われるには、誰かがくーす用のFramework的なものを書かんと難しいんじゃなかろうか。

206 ：デフォルトの名無しさん：04/09/30 23:39:47

NirvanaってJSFタグ吐き出すだけだと思ってた。
実装もあるんだ。

207 ：デフォルトの名無しさん：04/09/30 23:49:09

>>204
SpringMVCはWebでは使う必要なさそうだね。
S2DAOとSpringDAOの違いってどうなの？

定数アノテーションっていうのはCayenneと同じでおもしろいと思うけど。
OGNLと定数アノテーションがSpringとの大きな違いなのかな？

WEB+DB PRESSに解説記事が載ってたけど、ムダに大きいデータ構造で、ムダに本質的ではなさそうな部分が長いサンプルに読む気が萎えた。

208 ：デフォルトの名無しさん：04/10/01 00:04:13

それにしても、オープンソースプロジェクトってある程度広まって使えるようになったころに、プロジェクト自体があぼーんするからなぁ。
あまり大きなフレームワークは使いたくないというのが本音だ。
Seasarも、某社が会社の事業としてサポートするような、法人としての取り組みができるようにしたほうがいいと思うな。
そのためにはSeasarで利益が出せるようなしくみが必要になるんだけど。
でも、そうしないと、オープンソースプロジェクトって長続きしないよね。

209 ：デフォルトの名無しさん：04/10/01 12:18:22

>>208
一応、電通国際情報サービスがサポートするらしいね。

ところで、S2Daoでディスクキャッシュ機能があるとか昔日記に書いてあったが、
どうやればできるの？

210 ：デフォルトの名無しさん：04/10/01 12:28:16

>>209
SpringやらSeasarは今後3年くらいかけて浸透するだろうから、機能をあわてて実装するよりも、プロジェクトが5年10年続くようにがんばってほしいな。

211 ：デフォルトの名無しさん：04/10/01 21:22:31

>>210
浸透ってのがどの程度を言ってんのか分からないけど、俺はなんか違うとおも。
例えば Web アプリと言えば、Tomcat や Struts は浸透してるとおもう。
これが 3 年後に Tomcat と Struts、んで DI コンテナは何？ってなことにはならない希ガス。

汎用 DI コンテナはフレームワーク作成者や新しいもん好きが使うものであって
システム構築者には汎用的すぎる。特化してるっぽい S2xxx や Springxxx とか
あるけど、まだ DI 使うとこんなすごいことができるみたいなオモチャに見える。

DI コンテナが浸透するんではなくて、フレームワークやライブラリが DI を
使用するのは当たり前になり（DI は自前でも良いし、cglib、javassist、BCEL、asm
なんでもいい） DI を冠することも無くなり、開発者に意識させないと思う。

212 ：デフォルトの名無しさん：04/10/01 21:37:16

>>211
もちろん、DI+AOPは基盤技術になるわけだから、本来表に出るもんではないと思うよ。
オブジェクト指向のためにJavaを使うんじゃなくて、Javaって便利だけどこれってオブジェクト指向に基づいてるらしいよ、みたいな。
なんかめっちゃ楽なんやけど、これってDIとかAOPっていうもののおかげらしいで、と。

ていうか、使用するのは当たり前ってことは浸透してるということなんじゃないかと。
ただ、そのためには実装とそれに基づいた実用部品が必要で。
その実装として、今はSpringとSeasarがあるわけだ。
あと、DI自体は使うのが非常に楽で、使えば結構自動的にアプリケーションの多層化やら部品化ができるから、やっぱりその利点を認められて広まると思う。
AOPは、末端開発者が積極的に使うものというよりは、コンポーネント提供者が利用して、末端開発者は何も考えなくてよくなる、という仕組みだと思ってる。
AOPこそ、開発者に意識させないものだと思うな。

使う言葉が違うだけで同じことを言ってる気がしなくもないが。

213 ：212：04/10/01 21:56:03

そういえば、誰かDIconファイルを視覚化して編集するツール作ってるみたいだけど、あれってもうちょっと発展させたらなつかしのAPPGALLERYみたいになるね。
ありがちなビジネスロジックの呼び出し仕様を集めたインターフェイスを登録しておけば、そいつを視覚化したものを配置して、メソッドつなぎあわせればアプリケーションになる、と。
呼び出し先の引数と同じ型のプロパティ持ってたらそれを自動的に渡して、みたいな。
ダブルクリックしたらそこのソース編集とか。
よくない？

214 ：デフォルトの名無しさん：04/10/01 22:07:23

>206
スマソ、HTML2JSP、JSFのコンバータだった。

215 ：デフォルトの名無しさん：04/10/01 22:09:25

>209
キャッシュはまだ未実装な筈

216 ：デフォルトの名無しさん：04/10/02 11:52:35

>>213
懐かしいな。そうなるといいな。

217 ：デフォルトの名無しさん：04/10/02 14:11:49

>>205
Actionは、業務ロジッククラスの一つのメソッドを呼ぶだけに白ってことだから
そんなめんどくさいことないだろう。
これまでも、Actionにロジックをおくなって言われてたわけだから、
そんなにかわんないだろう。

218 ：デフォルトの名無しさん：04/10/02 20:13:54

ひが君の日記より

> 実装上は、バウンダリから呼び出されるメソッドは、インターフェースになり、
> コンポーネント内からしか呼び出されないメソッドは、実装クラスのpublicメソッドに
> なります。

> 内部からしか呼び出されないのに、実装クラスのpublicメソッドにするのは、
> テストをしやすくするためです。別にprivateメソッドでもリフレクションを使って
> 呼び出せますが、コンポーネントを使う方は、インターフェースしか見ないので、
> 特にpublicでも問題ないと思います。

内部メソッドを public にか。俺はこれをダサいと思わん神経を疑う。

219 ：デフォルトの名無しさん：04/10/02 20:27:05

ひが君の日記より

> くーすは、というより私は、各開発者のスキルをまったくあてにしていません。
> ドライに聞こえるかもしれませんが、現実のプロジェクトを乗り切るには、
> そう考えざるを得ないのです。そして、どんな人でも一定の品質のものを
> 作り上げるための仕組みを考えるのです。

要は
S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
と。

正論だが、それを公開日記でいうおまえはどうしようもないバカだ。

220 ：デフォルトの名無しさん：04/10/02 20:27:52

このご時世に「ダサい」という言葉を使う神経を疑う

221 ：デフォルトの名無しさん：04/10/02 20:31:48

>>218-219
なんか嫌なことでもあったか？
こんなところで愚痴ってもしょうがないぞｗ

奴の日記読んでるんだったら、
奴が２ちゃんなんか読まないし仮に読んだとしても気にも留めない奴だって分かってるだろ。
ここじゃなくて奴の日記にコメントしろよ。
面と向かって文句言えないから陰口叩くちゃねらーの典型だなｗ

222 ：221：04/10/02 20:33:06

ちなみに私はＤＩコンテナ信者です

223 ：デフォルトの名無しさん：04/10/02 20:37:59

>>221
別に嫌なことなんか無いが、奴は最近方向が少しずれてきた希ガス。

224 ：221：04/10/02 22:09:45

確かにS2もいろいろなところで取り上げられてるしね。
調子に乗るのもわらなくはないけど。。。

まあ周りの取り巻き連中が持ち上げまくってるのかもしれないね。

個人的には調子に乗ってもいいから、S2JSFをきっちり作り上げて欲しい。
それと、S2Dao。
この２つさえきっちり作ってサポートしてくれれば持ち上げまくってもいいよｗ

225 ：デフォルトの名無しさん：04/10/03 01:55:24

別に調子に乗ってるようには見えないけどな。正論なら公開の場で書いてても
いいんじゃないかと思うし間違ったことは書いてない。
そもそもフレームワークってそういうもんだろ。そんなに嫌いなら見なきゃいいのにｗ

226 ：デフォルトの名無しさん：04/10/03 02:09:35

嫌いなら見なきゃいい、みたいな生産的じゃない発言増えたなぁ。板的に。

227 ：デフォルトの名無しさん：04/10/03 02:35:42

嫌々見て２ちゃんで愚痴ってるのが生産的だとも思わないなぁ。漏れ的に。

228 ：デフォルトの名無しさん：04/10/03 02:44:07

既存のRUPなんかで提唱されている手法を実践しようと
して苦しんだことがないから馬鹿にされているように感じるんでしょ。

くーすが嫌なら一般的にいわれているようなユースケース駆動
なんかの設計でやってみればいいじゃない。俺はやってみて
これがだれでもできる方法だとは思えないからくーすの
思想には賛成できるけど。(具体的な手法に関しては置いといて)

229 ：デフォルトの名無しさん：04/10/03 03:15:38

>>224
サポーターはサポートするべきだから。

230 ：デフォルトの名無しさん：04/10/03 08:52:29

>219
>S2 使う側の香具師はバカかアホしか居ねーから簡単に使えるようにしますよ w
バカかアホしか居ねー「と考えないと現実的に回らない」

>バックエンドの難しい仕組みはスキルのある俺様しか理解できないですよ w
バックエンドの難しい仕組み「を全員が意識しなけりゃならない状況は現実的じゃない」

曲解はやめような。

それ以前に、沢山の人を使ったことがあるかってことだな。
沢山の人の能力を全部把握して適切な仕事を振るなんてできやしないんだから、
全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。

231 ：デフォルトの名無しさん：04/10/03 08:54:39

そういう意味ではくーすはある程度の人数を想定した開発・設計プロセスなのかな。
たとえばうちみたいに一人二人で1-3ヶ月やるようなプロジェクトでくーすに従って。。。というのはどうなんだろ。

232 ：デフォルトの名無しさん：04/10/03 09:37:22

>>231
ひとりふたりだと、プロセスがなくてもまわるっちゃまわる。
それでもプロセスの採用は有用だと思うよ。

233 ：デフォルトの名無しさん：04/10/03 11:09:50

>>219
その日記は明らかにプロの現場を指してる。
あの子が欲しい、この子は要らない、相談しましょ、そうしましょ
ってできないし、勝手に配人されるし、何より初めて会った人が
何をどこまで知ってるかなんて分からない。
アレとソレとコレを知ってる人が居ないと回せませんとか言った
ら、それこそ自分自身が要らない子になってしまうｗ

234 ：デフォルトの名無しさん：04/10/03 11:54:24

日記の内容なんて本当は関係ないんだろうな。
粘着したいだけなんだろきっと。口実が欲しいんだよ。
そんなことよりもS2JSF激しくキボンヌ！出してくれたらひが氏ラブｗ

235 ：デフォルトの名無しさん：04/10/03 12:40:10

心配するな。
ひが君は、ちゃんとここ読んでるから。

236 ：デフォルトの名無しさん：04/10/03 12:54:14

なんだひが「君」に釜ってほしいだけか

237 ：デフォルトの名無しさん：04/10/03 14:50:48

ひがたんにカマ掘ってほしいＹＯ

238 ：デフォルトの名無しさん：04/10/03 15:30:17

>>237
喜んで掘りそうな予感。

239 ：デフォルトの名無しさん：04/10/03 15:39:31

何で？　>>237っていい男なの？

240 ：デフォルトの名無しさん：04/10/03 15:40:40

ひがたんが・・・

241 ：デフォルトの名無しさん：04/10/03 16:04:01

ウホッ・・・！！！

242 ：デフォルトの名無しさん：04/10/03 16:42:25

>>230
> 全員が並の能力でも大丈夫な方法を模索するのは正しいと思う。
俺が正論って言ったのをフォローしてるだけか。ってか、おまい、奴の言った

　「各開発者のスキルをまったくあてにしていません。」

に自分が含まれていないって曲解してないか？

　「易しいこと、優しいこと･･･」

一人のサポーターが挙げてくれた S2 の哲学的ともいえるテーマを、
ひが君琉に言うとこうなるのか。本質は同じだが、明らかにひが君はうんこ。
あのファウラーでさえ、自分はまだまだ未熟と言ってるのに（ry

243 ：デフォルトの名無しさん：04/10/03 17:21:02

そんなにひが君のうんこを食いたいのか藻前はｗ
藻前が粘着したおかげで易しさと優しさがサイトから
消えたんだから満足しろよ。ひが君に優しく易しくして
欲しいのか？

244 ：デフォルトの名無しさん：04/10/03 17:47:46

実際易しかったのかもしれんが、優しくはないからな。
使えばわかる、ソース見ればわかる、だもん。

245 ：デフォルトの名無しさん：04/10/03 17:56:40

>>242
半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ

246 ：デフォルトの名無しさん：04/10/03 18:16:39

>>245
あんたよく見てるな
ほんとだ。感動した！

247 ：デフォルトの名無しさん：04/10/03 18:47:34

＞244
使わないと「知った」だけで「出来た」にも「判る」にもならんと思う。
誰もに優しくは努力目標にしても、マニュアルもかなり改変されてるしな。
AOPとS2DAOなんかは更に判り易くなったんじゃなかろうか。

板が荒れるとフォモか巣加戸炉になるな。

248 ：デフォルトの名無しさん：04/10/03 19:44:46

板は荒れてない。荒れてるのはスレだ。
荒れているひとりがいるだけなんだがな。

249 ：デフォルトの名無しさん：04/10/03 23:43:18

>>244
使ってみる。ソースを見てみる。は、技術者として当然の行動文法。

教えてくれるのが当然君は芯でいいよ。

250 ：デフォルトの名無しさん：04/10/04 00:09:45

呼ばれてるぞ。
http://d.hatena.ne.jp/habuakihiro/20041003#1096792907

251 ：デフォルトの名無しさん：04/10/04 00:12:40

まあソースを見ろとまでは言わんけどな。見ると勉強になるのは間違いないが。
ここで粘着してひが君を自分の思うとおりに動かしたい奴がいるってことだろ。
S2とか技術には興味が無いんだよ。興味があるのはひが君そのものなんじゃないの？
だから取り巻きも気に入らないしスキルがどうこう書いてると自分のことを責められてる
気がして可愛さ余って憎さ百倍になってんだな。ホモのストーカーって恐いな。

252 ：デフォルトの名無しさん：04/10/04 00:17:28

>>250
もし>>219が行くなら俺もギャラリーで参加したいｗ

253 ：デフォルトの名無しさん：04/10/04 00:34:08

そうか、見てるのか・・・・・・・
なんか急にこのスレも格調が上がった様な気がしないでもないｗ

254 ：デフォルトの名無しさん：04/10/04 01:31:10

ほらほら新しいバージョンが出ましたよ
S2JSFもちゃんと作るってさ

255 ：デフォルトの名無しさん：04/10/04 02:48:48

なんかなあ
漏れは219でもないし、219を擁護するつもりなんざ全くない（むしろ叩きたry）けど
ここじゃなくて自分のblogで批判つーか「来いや」はな・・・
はぶ氏にどんな事情があってここに書き込まないのかは知らんが、
どっちもやってることのレベルは大して変わらんな

256 ：デフォルトの名無しさん：04/10/04 03:00:44

自分の署名になる自分のブログで書くってのは
意味はあると思いますがどうでしょう。

255さんの意見がハブ氏の（あっカタカナで変換したら
これまた沖縄くさい感じに！）ブログに書かれていたら
結構面白いんじゃないかなあ。

でも2ちゃんで書き捨てる気楽さも確かにあるし
それだけにあけすけに本心も出る面もありますな。

257 ：デフォルトの名無しさん：04/10/04 03:44:31

S2JSF期待age

258 ：デフォルトの名無しさん：04/10/04 04:53:29

ひがひがとはぶはぶは、こんがらがることもあったりなかったりするけど、重さ的にだいぶ違う。

259 ：デフォルトの名無しさん：04/10/04 05:12:03

>>249
そういう考え方は、それはそれでいいと思うけど、それを「優しさ」というのかな、と。

260 ：デフォルトの名無しさん：04/10/04 06:07:45

>>255
いや、ちゃんとそこらへんに書き込んでると思うが。

261 ：デフォルトの名無しさん：04/10/04 06:13:08

なんにせよ、2chの書き込みに反応するのは意味があるにしても得策ではない。

262 ：デフォルトの名無しさん：04/10/04 06:33:34

>259
誰に優しいか、っていうと「ビジネスする技術者に」なんだろう。作者と同種の人が対象なんだよ。
効率的な実装手段を求めてもがいてるような。教えて君や駆け出しの新人は入ってないと思われ。

それに、ソースはうまくいかんときにデバッガで追うくらいで十分。
ソース読まなきゃ使えないほど難しくもないし、声高に叫ぶほどドキュメントがないわけでもない。

263 ：デフォルトの名無しさん：04/10/04 07:03:23

>>262
もう記述は外れてるからどうこういってもしかたないんだけど、「初心者にもやさしい」というニュアンスだったような気がするんだけど。
「ドキュメントが豊富です」と声高に叫ぶほどドキュメントが充実してたわけでもないし。
要は、宣伝文句と実情が異なってたからどうよ、と思ってたわけさ。

264 ：デフォルトの名無しさん：04/10/04 07:14:34

>>263
J2EEとコンテナ、アスペクトの初心者には充分やさしいと思う。

さすがにJava初心者にはやさしくない。ていうか、インターフェースでプログラミングすると
いうことをSQLできます、COBOLやってました。という人々に理解してもらうのは、すげー難しいぞ（W

265 ：デフォルトの名無しさん：04/10/04 07:30:21

まあ、問題は初心者っていったときに、なにか勉強しはじめた人のことではなくて「初心者という生き物」のことを指してしまうことがあるからなぁ。
宣伝文句と実情が異なってたときに、オレとしては実情の方をあわせて「これでどうよ？」となってほしかったのだけど、宣伝の方が取り下げられてしまったのは残念だ。
マンパワーの問題もあるだろうし、しかたないのだろうけど。
実情が伴ってきたときに、またあの宣伝文句を掲げてくれれば、と思う。

266 ：デフォルトの名無しさん：04/10/04 10:06:16

>>255
ここに実名で書き込むヤシはいないだろ。

267 ：デフォルトの名無しさん：04/10/04 10:10:42

>>265
マンパワーの問題というよりも、ここでの粘着振りに
ひが氏がうんざりしちゃったんじゃないのかな
コンテナのドキュメントが急に書き換わったり
意地になってた気がする。

268 ：羽生：04/10/04 11:07:35

羽生と申します。2chで本名で書くのもどうかと思いますけど、けじめはつけておきます。
まず、ここに書き込まない理由は、

１．私は長文になってしまうので「長文ウゼー」って言われるからです。
改行が多すぎて書き込み出来ません、ともなります。

２．誰がどの書き込みをしたのかわからないので、脊髄反射的な会話に
しかならないからです。ハンドル名であっても一貫していれば、書き込みの
流れから行間を読むことで解釈のずれを埋める工夫が出来ますが、
そういう機能がないため「書き手の気持ち」を類推することが出来ず、
結果として言葉尻だけを取り上げることが多いからです。
これは、「私には」しんどいことです。

３．追いかけるのが大変だからというのもあります。自分の発言にレスがあったら、
きちんと返さなければという強迫観念があります。blogの場合は、あくまでも「コメント」ですので、
それに対してレスをしなければという気持ちは大らかでいられるのですが、
掲示板などだと常にウォッチしなければということで、日常に入り込んでしまいます。
忙しいときにはそれが苦痛になるので、控えています。これはMLもそうです。

４．自分が発する言葉は自分の心からしか出ません。ですから匿名であっても
責任が生じます。しかしトリップをわざわざ取ったりなど、仕組みとして「自分の責任」を
表明するのが面倒です（取ったこと無いし取り方を調べるのも面倒^^;）。
ですからここで自分の名前によって書いても、騙りと思われたりする可能性を考えると
blogのほうが確実だと考えています。

以上です。その上で、もう少し書きたいと思います。

269 ：羽生：04/10/04 11:09:45

まず、「優しさ」ということを掲げることについては、誰も反対はしないと考えています。
要点は、これを「理念・目標」と捉えるか、「宣伝」と捉えるか、でしょう。

では、これについて、
「私は宣伝と受け止めた。ついては宣伝に反している。改めるべきだ」
と考えた場合に、意味のある形につながるように取れる行動として、
例えば次のようなことがあるのではないか、と思うのです。

「優しさ、と書いているが、自分には優しさが足りてないように感じる。
ついては、まず、こういうドキュメントを追加してみてはどうだろうか。」　

そして、ほんの少しでも叩き台として出していただければ、それが呼び水となります。
ゼロから1への最初の一歩が大変なのです。マンパワーの問題もありますが、
そもそもご指摘があったように、知ってしまっている人間にとっては、ここが足りてないのか
という最初の気付きは難しいものです。

せっかくオープンソースであり、しかも英語圏に比べれば圧倒的に身近な国産のプロジェクトなのですから、
前向きな小さなはじめの一歩をいただければと思うのです。これをMLに投げてもらうだけでも随分と有効です。
MLも別にyahooメールで書いてもらっても構わないのです。同じ問題意識の発露であった場合に、
少なくとも、ここで汚い言葉でののしるよりもどれだけ有効で、どれだけ他の人の役に立つでしょう。

ですから、私はここで文句を言ってるだけというのは、実はこういう問題意識を持ってのことではなく、
それはポーズであって、実は別の感情が潜んでいるのではないか、という風に感じてしまいます。

このスレに書いたことでさえ、ひがさんはちゃんと受け止めて反映しています。
JavaDocプロジェクトも徐々にですが着実に進んでいるのも、例えばからさわぎで
「2chでも指摘されてますが、JavaDocいる人ってどれくらいいます？」というようなやり取りをして、
そこからちゃんと取り組みが始まっています。拒絶はしていません。
ですから、もっと誰もが受け入れやすい形でご提案いただければすごく嬉しいです。

270 ：羽生：04/10/04 11:11:34

引き続きですみません。

さて、私はこのスレの位置付けというのは初心者にとって大きいため、
ここで不当に貶されるのは、S2へのアンチマーケティングをされていると考えています。
というのは、Seasarで検索するとこのスレがヒットします。知識のないひと（スキルがない
のとは別です）が、ここを見てどう思うか、ということを考えると、必ずしも実情が伝わる
とは思えないのです。

というのは、「優しさ」という言葉尻とその周辺のことばかりが取り沙汰されていますが、
では技術的にどうか、などのことは全然触れられていません。端的に言えば、ひがさんや
取り巻き（この表現の意図もよくわかりませんが）の人格に対する話しかないのです。
ということは、人格に関する情報だけで技術水準を判断されてしまいかねません。

つまり「優しさ」の守り手たらんとしている誰か（誰か、としかいいようがありません）の
発言が結果として、「優しさを必要としている人」の無知識につけ込んでいるようにも感じます。

私たちがやっていることが、全て必要にして十分なレベルにあるなどとは到底いえませんが、
残念ながら客観的に評価されているようには思えません。
こういう部分は優れている、こういう部分はもっと改善が必要だ、というように、要素ごとに
きちんと評価して総合判断を提示するのが、技術者の基本ではないかと私は考えています。

その評価結果が厳しいものであってもそれは謙虚に受け止めてさらに取り組みます。
その意味において、残念ながら非常に一方的な負の感情のみで書かれているようにしか
見えないものが多いのです。ここでまた、S2そのものに対するのではなく別の感情が潜んで
いるのではないかと考えたりもします。

271 ：羽生：04/10/04 11:16:01

とりあえず最後です。

このようなことを踏まえた上で、他人を「うんこ」だの何だのという言葉を使うというのはどうなんですか？
実名で「これを書いたのは私です」と胸を張って公の場でいえますか？　いえるのであれば結構です。
是非、私と会いましょう。いえないのであれば、それは後ろめたいという気持ちを持っているのです。
後ろめたさを自分で作って抱え込んでどうするのですか。匿名であろうとなかろうと、言葉は自分の心からでるものなのです。
その負の感情をなだめようとして匿名でさらに汚い言葉を使っても、それは悪循環に陥るだけです。

その負の感情の源泉が、Seasarプロジェクトの不出来さに起因するのであれば、わざわざ自分の気持ちを
痛めつけるのではなく、お持ちのスキルとその問題意識を良い方向に発揮してください。歓迎いたします。
もし、Seasarプロジェクトに起因しているのでないなら、それは申し訳ありませんが八つ当たりに過ぎません。
自分の心で解決していくことです。ただそれも、例えばからさわぎのような場所で、普段会わないような
広い範囲の方々と話をするだけでも、何かが見えてくるかもしれません。

実際、からさわぎはJavaは殆どわからないという方も多く参加されています。
そして宴会の場で、技術ではないことでも意見交換が出来て非常に役に立ったという感想を
お持ちの方も多くいらっしゃいます。

「来いや」は確かに言葉が乱暴かもしれませんが、本心です。多くの方が前向きに（S2に対して、ではなくて、
自分の将来に対して）取り組んでいる場に触れるだけでも全然気持ちが変わります。
私も別に年中元気なわけではありません。しかし皆さんとお会いすると元気をいただけます。
私も少しでも皆さんの元気のお役に立てるようになりたいと思ってます。
是非、お会いしましょう。前向きなケンカは必ず第3の素敵なアイディアを生み出します。別にケンカしなくてもいいんですけどね(^^)
今後ともS2およびSeasarプロジェクトへの叱咤激励をよろしくお願いいたします＞all

尚、やっぱり恐いので基本的にここでは書きません。2chで実名出すのはやっぱりドキドキしますよ（ｗ

272 ：デフォルトの名無しさん：04/10/04 11:21:18

心配しなくても、実名の人に対して叩くほどの度胸はもちあわせておりませんよ。
トリップは適当に「羽生#seasar2004」みたいな#のあとに何かつけたらMD5かなんかの文字列になるだけなので、つけたほうがよさげです。

273 ：デフォルトの名無しさん：04/10/04 11:26:44

>>268-271
長文乙

274 ：デフォルトの名無しさん：04/10/04 11:37:14

長文ｳｾﾞｰ

275 ：デフォルトの名無しさん：04/10/04 11:40:58

>>268-271
ﾈﾀﾆﾏｼﾞﾚ(ry

276 ：デフォルトの名無しさん：04/10/04 11:49:43

ハブカブアガル。微妙に。ちょっとだけ。

277 ：デフォルトの名無しさん：04/10/04 13:18:10

つか、
>>242
>>に自分が含まれていないって曲解してないか？
含まれてるのを前提として>>230を読み直しても、全然問題ないんだけど。
どう読んだら>>230がそういう曲解に見えるんだ！？

おまい、ひがさんの直下のプロジェクトやったことあるんだろ。
うらやましいなぁ。漏れは馬鹿にされるぐらいの勢いでケアしてもらった方が、安心できるけどな。

11月のからさわぎには絶対参加しよう。

278 ：デフォルトの名無しさん：04/10/04 13:33:53

>>277
はぶたんには、長文乙と伝えてくれ。
ひがたんには、うほっと(ry

279 ：デフォルトの名無しさん：04/10/04 13:59:55

それよりオマエら、S2のSがSpringのSとまぎらわしいと思ったことはないか？
オレはある。
プレフィックスはまぎらわしくないものにするべきだ。
ここは「夜の」をつけることにして大人の雰囲気を醸し出すようにするのはどうだろう？
つまり「S2Struts」「S2Hibernate」「S2Dao」を「夜のStruts」「夜のHibernate」「夜のDao」とするのだ。
これでSpringより大人な感じが伝わるのではないかと思う。

280 ：デフォルトの名無しさん：04/10/04 15:13:19

それは素敵な案だが少し淫靡な香りが漂う気がする。
そこで大衆の支持を得るために「冬の」をプレフィックスに
するというのはどうだろうか。春（Spring）に対抗するのだ。
「冬のStruts」「冬のHibernate」「冬のDao」とするのだ。
これでSpringよりも婦女子の人気もバッチリだろう。

281 ：太田＠会社：04/10/04 15:22:57

私はどちらかというと方法論者(Methodologist, 社内でRUPとかの推進をしています)で，その立場からSeasarを応援(期待)しています。

理想的には純粋なOO分析，設計でRUPなのですけど，スキルやリソース，コストの観点からは最低レベルの技術者でも一定の枠組みに従って開発できる仕組みと方法論が必要というのが現実のところです。Seasarと「くーす」はその一つの回答となっていると考えました。

こちらでもはぶさんのおっしゃられているようにもう少し建設的な意見があると良いかなと思うのですがどうでしょうか。

282 ：デフォルトの名無しさん：04/10/04 15:40:36

>>280
冬ソナかよ！

283 ：デフォルトの名無しさん：04/10/04 16:20:52

>>281

そんなに否定的な意見ばっかりかなぁ？

否定的意見に対する反論もあるし、後は読んだ人が自分で判断することなのでは。

284 ：デフォルトの名無しさん：04/10/04 16:24:41

>>281
匿名の場合、ネガティブな部分が大きく出て、建設的な意見は出にくいと思う。
ナイスアイデアは名乗ってから言いたいからな。
逆に、否定的な意見をここで拾えばよろしい。
>>279-280のようなとても建設的な意見もあるが。

っていうか笑わせるな。ひさびさ腹いたくなった。

285 ：デフォルトの名無しさん：04/10/04 16:33:30

否定的なことを建設的に書けばいいんじゃないかな。
特定個人をとやかくいうんじゃなくて例えばJavaDocがない
とかならS2DaoのここだけでもJavaDoc書けやゴルァとかな。
何をやればもっと良くなるのかを指摘してやればいいんじゃないかな。

286 ：デフォルトの名無しさん：04/10/04 17:00:55

全体的な指摘だと、こうするべきっていうのは書きにくいからなぁ。
現状サイトが貧弱だし、最初の入り口になるナビゲーションが非常にとぼしい。
最初になにをすればいいかわからないしな。
何度も言ってるけど、使ってみないとなにができるかわからない。
DIやAOPがなんであるかを知っていないと、使おうと思わないだろうな。
こういうのは、「ここをこう」みたいなヒトコトじゃ指摘できないんだよね。
ま、とりあえずホームページの体裁を整えて欲しい。

作者のブログとはいえプロダクトとはあまり関係ない話題を引用してきてどうこういうのはどうかと思うが。

287 ：デフォルトの名無しさん：04/10/04 17:35:04

トップページは何の更新もないし、タイムスタンプで新しくなったのがわかっても、ダウンロードするまで何がかわったかわからないし。
で、よくみたらブログにはちゃんと書いてあったりする。

288 ：デフォルトの名無しさん：04/10/04 19:26:46

>>287
それははなからブログをチェックするのが正解かと。

289 ：デフォルトの名無しさん：04/10/04 19:34:44

>>281
２ちゃんのスレは「小さなはじめの一歩」次第でどうとでも変わります。
一旦方向性をみつけると、良くも悪くもそちらへ爆走します。
どちらに向いて爆走するかは「小さなはじめの一歩」次第です。

太田氏が「方法論者(Methodologist, 社内でRUPとかの推進をしています)」であるなら
その現場で培われた成功例(例えば、知識のない人にどう啓蒙していったのか、どうや
って教育したのか、何を見せどう説明したのか等など)を書き込んでもらえると、このス
レにとって「前向きな小さなはじめの一歩」に成り得ると思うんですが・・・・・・・・

勿論、ただの要望で「もしよろしければ」という話です。

290 ：デフォルトの名無しさん：04/10/04 19:56:47

>>288
そういう情報は、「公式サイト」には書いてないからねぇ。
別に広めるつもりがないならかまわないけど。
雑誌なんかでSeasar知った人が、ブログをチェックしないといけないとは考えないだろ。
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。

291 ：デフォルトの名無しさん：04/10/04 21:59:47

国産じゃデファクトスタンダードには間違っても為らないワケで。
国産唯一の利点は「ドキュメントに読みやすい日本語が期待できる」だが、
それも無いし。

結論：ｲﾗﾈ

292 ：デフォルトの名無しさん：04/10/04 22:23:32

デファクトスタンダードは難しいだろうけど、ニッチでもいいじゃん。
世の中みんながトヨタやフォードに乗ってるわけでもなければ、
OracleやDB2を使ってるわけでもないんだから。
つーか、デファクトはEJB3.0なんじゃないの？

実際の小さい仕事で使ってみて今、基本部分が出来上がったとこ。
業務ルールとそれのつなげ方を分けて管理できるライブラリ、って感じで使ってみたけど
なかなかイイよ。俺は手抜きしてついつい業務ロジックを大きく作っちゃうんだけど、
単純なクラスをDICONで連結する構造が、結構自然に簡単にできた。

慣れるまで１週間くらいはかかったけど。さすがに１時間じゃ無理ぽ。
あと、バックエンドが簡単になったらフロントの Struts の辛さ倍増。
はやくS2JSF使わせてけろ。

293 ：デフォルトの名無しさん：04/10/04 22:37:47

>>292
使ってみれば、いいことはわかるんだよ。
そのための情報が少ないのが問題だね。
ブログ騒ぎで「ここだけの話」を見てみたら、リリース情報が逐一載っていた。
唖然とした。
公式サイトのチェックはしてて、新しいもののリリースは最近ないものだと思っていた。

294 ：デフォルトの名無しさん：04/10/05 00:05:04

公式サイトのwhat's newが欲しいってのはわかるなー。

295 ：デフォルトの名無しさん：04/10/05 00:35:33

MLでは逐一リリース告知されているわけだが

296 ：デフォルトの名無しさん：04/10/05 01:04:23

sourceforgeにも、リリースメモがあると思うが。

297 ：デフォルトの名無しさん：04/10/05 01:09:10

要するに興味ないくせに文句だけは言いたいわけだ

298 ：デフォルトの名無しさん：04/10/05 02:21:15

>>293-294
ttp://sourceforge.jp/projects/seasar/news

299 ：デフォルトの名無しさん：04/10/05 03:09:38

探さないのが問題だとも言えるし、探さないと見つけられないようなのが問題だとも言えるかも。

300 ：デフォルトの名無しさん：04/10/05 07:09:43

>>295-298
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。

301 ：デフォルトの名無しさん：04/10/05 07:16:45

とりあえず、公式サイトは吉田カバンなみ。

302 ：デフォルトの名無しさん：04/10/05 09:17:27

ていうか、Seasarに文句言ってるヤシは、Springを使ってるの？

303 ：太田＠会社：04/10/05 10:31:46

289さん>
とりあえず社内外で

http://patterns-wg.fuka.info.waseda.ac.jp/study/8th.html

なことや，社内でのRUP研修で紹介して興味を持ってもらっている段階です。
私は開発ではなくテストが専門なので，その分野から攻めていって「テストが効率が上がる」というと興味を持ってくれるSEが多いです。

304 ：太田＠会社：04/10/05 10:36:55

あとはオブジェクト指向分析・設計の研修ですと，
やはりみなさまオブジェクト協調関係の生成をどのオブジェクトがどういったタイミングですべきかについて悩むが多いです。
そこで，Robert C. Martinのオブジェクト指向の基本原則などとからめて，DIコンテナを説明し，
もっともとっつきやすい(私の主観ですが)，Seasarを紹介するという形です。

305 ：デフォルトの名無しさん：04/10/05 11:22:56

モノ自体の仕組みとしてはとっつきやすいと思う。
SeasarのBean定義はSpringより少ない記述量でできる。
だから、わかってる人が近くにいれば、とっつきやすいと思う。
問題はわかっている人が近くにいないとき、Springの方が情報が得やすいということ。

306 ：デフォルトの名無しさん：04/10/05 12:57:39

>>305
>Springの方が情報が得やすいということ。
そうか？

Springは機能やら専門用語が多すぎて、わけわからん。

307 ：デフォルトの名無しさん：04/10/05 14:08:15

>>306
書籍に記述もあるし、網羅したリファレンスもあるし、そのモノが難しいというのは置いておいて、情報は得やすいと思う。
AOPのための記述とか、Seasarに比べるとアホみたいにめんどい。
もっと簡単な記述があるのかもしれないけど。

308 ：デフォルトの名無しさん：04/10/05 14:58:08

S2のJavadoc、@authorの下の行にコメント書いてある。
作者はJavadoc使ったことねぇのかな？少し笑えたぞ。

309 ：デフォルトの名無しさん：04/10/05 18:10:02

「2chに悪意を持って書き込む奴がいる」って何をいまさらｗ

310 ：デフォルトの名無しさん：04/10/05 18:59:41

善意がないだけで、悪意もないと思うんだけどね。
無責任なだけで。
「Seasar2はインストールするだけでシステムが不安定」とか事実ではないこと書けば、それは悪意があるんだろうけど。

311 ：デフォルトの名無しさん：04/10/05 19:00:08

>>309
ところで、どこに書いてあるの？
それ。

312 ：デフォルトの名無しさん：04/10/05 19:34:49

なんか、サイトの構築始まってるね。
左側のメニューにWhat's newが欲しい、とか、ロードマップが欲しいぞな、とかは思うが。
まあとにかく要望は出せばキリがないからほっといて、早いトコサイトインできるようにがんばって欲しいね。
せっかくWEB+DB PRESSに寄稿したり、JAVA PRESSに記事が載ったりしてんだからね。
記事みてサイトにアクセスして迷子になってあきらめる人がいるだろうから。

313 ：デフォルトの名無しさん：04/10/05 19:55:27

307を書き込むときに、AOPのドキュメントってこんなに充実してたかなぁと思ったんだけど、やっぱり書き直されてたのね。
サイトの更新履歴も欲しいぞな。
ブログベースってことで、どうなるのかしらんけど。
まあ、関係者のブログの関連するネタを整理して、アイドルネタを省いたものになるという感じか。

314 ：デフォルトの名無しさん：04/10/05 21:38:25

EJB以外を使う香具師は、厨房。

315 ：デフォルトの名無しさん：04/10/05 21:45:06

>314
そんな餌（ｒｙ

316 ：デフォルトの名無しさん：04/10/05 22:05:08

というか、厨房でもなんでもいいから、動くものを早く手軽に、ってことだな。
いくら高尚で美しい設計でも、利用開始に間に合わないんじゃ仕方ない。

317 ：デフォルトの名無しさん：04/10/05 22:18:29

>316
他のコンポーネントやテーブル設計を待たずに実装とテストのフェーズに入れる＞S2Unitによるリードタイムの短縮

S2OpenAMFやS2FlexみたくWebベースでHTML以外のUIの選択肢でも連携する手立てが用意されてるのもS2の良いところかもな。

318 ：デフォルトの名無しさん：04/10/05 22:24:55

>317
他のコンポーネント→他の’関連する’コンポーネント’の実装’

>313
S2DAOのドキュメントも刷新されてますね。

319 ：デフォルトの名無しさん：04/10/05 22:30:46

真剣に「くーす」で設計してみようと思って、ひがさんの↓
　ダイコン事態の設計手法と、その２
を読んだ。

最後の「何か合コン誘われたから行ってくるわ」が気になったので読んで見た。
関係ねーじゃねぇか＞くーす
もう帰る。ｳﾜｧｧｰﾝ

320 ：デフォルトの名無しさん：04/10/05 22:37:44

>316
御意＞いくら高尚で美しい設計
美しい設計はあくまでメンテナンス性の為の一手段に過ぎない。
そうありたいし、心掛けてるが納期に間に合って、利益を生むのが大々前提。

で、プロジェクトには新人さんも（使用するテクノロジーに）不慣れな人間も居るのが当たり前。
彼らが、この先淘汰されるかどうかは知ったことでは無いが、現実の案件をデスマらせない
には、個々のスキルに任さないのは一つの立派な考え方。

数を集めるより少数精鋭の方がコストメリットもあるとは思うけど、愚痴をたれても仕方無い。
というわけでS2が選択肢としてあって、使ってるんだが。

321 ：デフォルトの名無しさん：04/10/05 22:41:10

>319
御愁傷様（藁。くーすについては大阪のからさわぎの資料がテンプレも付いてるので興味深いな。

322 ：316：04/10/05 23:03:41

じゃあDIは美しくない設計なのか、というと、そうじゃないんだよね。
むしろ、DIだと設計をしなくてよくなるので、美しいとか美しくないとか判定する必要もない。
各機能各層について独立したクラスを作って、ゴンゴン組み立てればいいわけだから。

どこでオブジェクト生成してどこに保持してどうやって受け渡すか、それをいかに美しい設計で実現するかなんて考える必要はないんだから。
もちろんミクロやマクロの設計はしないといけないけど、それはEJBだって助けてくれるもんじゃない。
それにミクロやマクロの設計は楽しいし。

323 ：デフォルトの名無しさん：04/10/05 23:19:30

without hairとか、禿げ本、禿げ会とかさー、言語の壁を隠れ蓑にして、
先人（Rod）をリスペクトしない姿勢が、鼻につくんだよ。

お前ら、Rod本人に向かって、禿げって言えんのかよ。

324 ：デフォルトの名無しさん：04/10/05 23:25:07

他者に優しいのが、XPのペアプロに代表される少数精鋭の徒弟制度。

「スキルの無い奴」とか
「彼らが、この先淘汰されるかどうかは知ったことでは無い」とか、
結局お前、自分に優しいだけちゃうんかと。

325 ：デフォルトの名無しさん：04/10/05 23:33:39

>>324
それ作者にも言ってやれ。

326 ：デフォルトの名無しさん：04/10/05 23:39:53

>324
少数精鋭のXP、って時点でスキルの無い奴がはじき出されてるぞ。

仕事なんだから、最低水準の質を確保する仕組みってのは求めて当たり前でしょ。
そこから先、どう仕事に取り組むかは個人の問題なんだから。

327 ：デフォルトの名無しさん：04/10/05 23:43:41

>323　
コミッタでも近しい関係者でも無いよ。確かにイクナイ　＞お前ら、Rod本人に向かって、禿げって言えんのかよ。
禿しく同意だ。が、ひが氏本人が言い出した訳でもあるまい。

323本人の発言ではないと思うが、かといって逆にウンコ呼ばわりしたら同じ穴の狢でしょ？

>324
少数精鋭の徒弟制度がすくすくと育てば、ある意味で素晴らしいと思う。
で、’まず’自分に優しいのは当たり前だろ？社内のみならず協力会社を含めた遍く全ての他者が
今後、どう身を振るかまで慈悲深く’優しく’すんのかい？

328 ：デフォルトの名無しさん：04/10/06 00:48:38

>>323
Rodにハゲと言える仲になりたい。

329 ：デフォルトの名無しさん：04/10/06 02:12:53

つーか難癖つけすぎ。
粗探しばっかりでは面白くない。

330 ：デフォルトの名無しさん：04/10/06 02:24:16

まぁ、１のことを１０の言葉で語る人のことはさておき
（cocoon本のころは良かったのになぁ）、ちょっと本質的なネタを
振ってみたいな。

(1) S2を使うと、本当にテストがしやすくなるのか
(2) S2を使うと、本当によいものができるのか
(3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
(4) S2を使わないと、上記のようなことはできないのか
(5) 成果物全体がS2に汚染されるけど、それはOKなのか

まぁこの際S2をDIコンテナと言い換えてもいいや。

いくつかモノを作ってみたが、(1)はまぁ同意できる。
EJB使ってるとFactory駆使しないと結合を切れないが、
その辺をフレームワークとして統括できるのは便利。
(2)～(3)は、ツールで解決するものか？という気がぬぐえない。
あと、テストパターン研究会でも話題になったが、ソースコード
トレースがし難くなるのは避けられないという問題もある。
(4)は程度の問題か。(5)はメリットとの天秤になるのかな。
インテグレーションクラス周辺だけ使う、というのが現実的か。
ところで、S2が正しくinjectionしてくれるかどうかの
テストはどう書けば？（汗）

というわけで皆の意見を聞きたい。

331 ：デフォルトの名無しさん：04/10/06 03:11:04

似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。

332 ：sage：04/10/06 05:47:27

>>330
>ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？

モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。

開発者もメンテナもくーすに従えば解決するのだろうか？

333 ：332：04/10/06 05:49:57

sage間違えて恥ずかちぃ

334 ：デフォルトの名無しさん：04/10/06 06:27:38

>>323
何だSpring派がS2叩きしてるだけか

335 ：デフォルトの名無しさん：04/10/06 06:29:10

>>324
少数精鋭をどう育てるの？

336 ：デフォルトの名無しさん：04/10/06 06:32:15

>>324
スキルのない奴が淘汰されるのは当然だろ？

337 ：デフォルトの名無しさん：04/10/06 06:33:15

>>323
で、オマエはRodの言ってることどれだけ理解して実践してるの？

338 ：デフォルトの名無しさん：04/10/06 06:36:42

で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？

339 ：219：04/10/06 06:38:27

俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！

340 ：デフォルトの名無しさん：04/10/06 06:55:09

羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！

341 ：デフォルトの名無しさん：04/10/06 07:17:30

>323
Spring派とかいうわけでも無いんじゃね？

>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが

>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？

(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない

342 ：デフォルトの名無しさん：04/10/06 07:19:48

>340
ID表示が無い板だからといって朝から釣りはやめような

343 ：デフォルトの名無しさん：04/10/06 07:25:08

＞＞３４２オマエ羽生だな（ｗ

344 ：デフォルトの名無しさん：04/10/06 07:25:54

羽生氏ね（藁

345 ：デフォルトの名無しさん：04/10/06 07:29:44

219頑張れ！219は正しい！219はネ申！羽生氏ね！

346 ：デフォルトの名無しさん：04/10/06 07:34:43

>343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。

>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。

diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。

347 ：デフォルトの名無しさん：04/10/06 08:59:40

>>330
全て、S2やSpringを使えば無条件にというわけではないというのは前提。

> (1) S2を使うと、本当にテストがしやすくなるのか

コンポーネントが独立するので異なる環境で動かしやすくなる。

> (2) S2を使うと、本当によいものができるのか

よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも

> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか

スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。

> (4) S2を使わないと、上記のようなことはできないのか

DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。

> (5) 成果物全体がS2に汚染されるけど、それはOKなのか

設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。

と思う。

348 ：デフォルトの名無しさん：04/10/06 09:02:27

ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ

ただ、インターフェースの設計をかっちりやらないとダメなのは同意

くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが

349 ：デフォルトの名無しさん：04/10/06 11:28:08

今更だが。

>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ

スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w

350 ：デフォルトの名無しさん：04/10/06 12:21:09

>>349
いや、キミを判別しやすくて便利だから構わんのだけど。

351 ：デフォルトの名無しさん：04/10/06 16:19:56

>んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。

クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。

352 ：デフォルトの名無しさん：04/10/06 17:59:54

要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。

きちんとドキュメントは残しましょうって事ですかね。

353 ：デフォルトの名無しさん：04/10/06 18:01:39

ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。

354 ：デフォルトの名無しさん：04/10/06 18:48:42

そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。

355 ：デフォルトの名無しさん：04/10/06 18:57:14

>ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。

diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？

まあくーすとは路線が違うのかもしれんが。

356 ：デフォルトの名無しさん：04/10/06 19:14:53

DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。

357 ：デフォルトの名無しさん：04/10/06 19:19:09

>>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。

オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。

くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。

358 ：デフォルトの名無しさん：04/10/06 19:30:30

あー、見積りは嬉しいかも

359 ：デフォルトの名無しさん：04/10/06 20:16:01

くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。

360 ：デフォルトの名無しさん：04/10/06 20:22:12

結論：EJB3.0 >>> Spring >>>>> S2

361 ：デフォルトの名無しさん：04/10/06 20:30:32

EJB3.0が本当に良いならS2EJBが出るような気もするがな

362 ：デフォルトの名無しさん：04/10/06 21:18:38

SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。

363 ：デフォルトの名無しさん：04/10/06 21:56:25

>360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。

364 ：デフォルトの名無しさん：04/10/06 22:04:01

>360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。

365 ：デフォルトの名無しさん：04/10/06 22:13:01

是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい

366 ：デフォルトの名無しさん：04/10/06 23:24:06

ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々

367 ：デフォルトの名無しさん：04/10/06 23:35:52

はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。

もちっと余裕があるサイトに引っ越したほうがいいような。

368 ：デフォルトの名無しさん：04/10/06 23:48:29

ロジックとデータの分離って、やりにくくね？

369 ：デフォルトの名無しさん：04/10/06 23:54:26

>>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。

370 ：デフォルトの名無しさん：04/10/07 00:07:47

>>368
やりにくい部分もあるけど、やれる部分のほうが多くない？

371 ：330：04/10/07 00:25:56

みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。

330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。

個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。

というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。

372 ：デフォルトの名無しさん：04/10/07 00:27:23

>>370
「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。

問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。

373 ：330：04/10/07 00:27:49

あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。

テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。

というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。

374 ：デフォルトの名無しさん：04/10/07 00:33:41

・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。

・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。

375 ：デフォルトの名無しさん：04/10/07 00:48:22

Web層　フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層　DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層　ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層

こんな感じか。

376 ：デフォルトの名無しさん：04/10/07 00:51:41

戻り値にDIするインターセプタかな。

377 ：デフォルトの名無しさん：04/10/07 01:12:22

>372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？

>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。

>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。

378 ：デフォルトの名無しさん：04/10/07 01:33:48

>>377

Picoについては
http://www.picocontainer.org/Two+minute+tutorial
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。

>>367

ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。

まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。

379 ：デフォルトの名無しさん：04/10/07 01:38:17

>>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
　単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。

・他エンティティとの関連
　User.isMemberOf(Group)みたいなメソッドが欲しい。
　ロジック層でisMember(Group, User)ってなるとヤだなって思う。

ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。

380 ：デフォルトの名無しさん：04/10/07 01:41:39

>>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。

そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。

XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。

381 ：デフォルトの名無しさん：04/10/07 01:47:54

それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。

382 ：デフォルトの名無しさん：04/10/07 01:48:36

記述の選択肢が少ない、というのが肝ね。

383 ：デフォルトの名無しさん：04/10/07 01:55:40

S2はマンセーだけどくーすは疑問

DI（IoC）に関しては >380の言うエントロピーの軽減が目的ってことでFA。
どのコンテナがいいか。
SpringやPicoと比べると、設定の手軽さと機能の豊富さでS2が一番だと思う。
欲しい機能があったとき、Rod Johnsonにメール出すより、ひがさんのblog
にコメントする方が敷居が低いし、レスポンスも速い。
Springはクドい。

くーすは、今公開されているサンプルやトライアル程度では、実際のプロジェクト
になったときに上手くいくか判断しかねる。
本を執筆中ということだけど、付録CDに実装までのサンプルでもあればいいのだが。
今までの開発手法（ユースケース駆動とか）も、本では上手く言ってるけど、
実際大変じゃんってことで、くーすを考案中なんだし、くーすも同じ轍を踏まない
とも限らんすね。

384 ：デフォルトの名無しさん：04/10/07 02:29:30

おれはDIコンテナってのは、ファクトリを自前でがりがり書く代わりにコンテナに
お願いできる（ファクトリ機能の外出し）ってことで理解してる。
それ以外の部分（Hibernate連携とか）はあくまでオプションだと思ってる。
くーすはよくわからん。資料がたりん....

385 ：デフォルトの名無しさん：04/10/07 02:53:44

くーすの内容をみずにレス
よくある開発手法は、一般的にやろうとしてたり、実装と独立しようとしてて、使えなくなってると思われ。
くーすの場合は、業務システムをSeasar使って作るという具合に、用途を限定しているから、変に一般化しようとしなければ問題ないんじゃなかろうか。

386 ：デフォルトの名無しさん：04/10/07 02:55:05

>>385
資料っていうか、資料へのリンクがない気がする。
たぶん、探せば資料はきっとある。

387 ：デフォルトの名無しさん：04/10/07 02:55:10

くーすは特にSeasar2に限定されるものではなかったような。

388 ：デフォルトの名無しさん：04/10/07 02:56:07

限定じゃなくて、前提だね。

389 ：デフォルトの名無しさん：04/10/07 03:04:20

ごめん、はてなの解説を「Diconを使ったときの・・・」と読み取ってしまってた。
あのへんのブログをぐるぐる回ったけど、くーす自体にはたどり着けなかった。

390 ：デフォルトの名無しさん：04/10/07 03:06:06

もうこういうの飽きた

391 ：デフォルトの名無しさん：04/10/07 03:07:58

っていうか、くーすってどこにあるの？

392 ：371：04/10/07 03:10:42

>>380
大筋で同意。うまく言葉にできなかったことを、シンプルな言葉でまとめてくれてありがと。

オブジェクト指向はデータとアルゴリズムをバインドさせることで、エントロピーを低減させた
と考えることができるが（C++普及前夜に、関数ポインタを構造体に持たせたコードが増えたのが
なつかしいな）、そういう視点でのブレイクスルーがあるの？ということを
言いたかった。

自由度が小さい記述方法を使うことで局所的なエントロピーは下がると思うが、
全体的にはどうなんだろ。フレームワークと、その根底に流れる思想を理解するための
情報量の扱い、という意味で。

「くーす」という哲学を理解というか納得した者同士は、下げられるって
ことなんだろうな、たぶん。

393 ：デフォルトの名無しさん：04/10/07 03:25:19

>>391

弟子による「くーす」教本
http://marrow.strnet.com/wiki/pukiwiki.php?%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%BC%EA%CB%A1%A4%AF%A1%BC%A4%B9

ひが尊師やその弟子たちによる教えへのポインタ
http://www.wikiroom.com/tpircs/?higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1

「ダイコン時代５秒前」くらいまでは読んでみてから、
拾い読みするといいかも。少なくとも修羅場突破用
割り切り基準としては優れている。

394 ：デフォルトの名無しさん：04/10/07 03:32:03

クレクレ君ばっかだね

395 ：デフォルトの名無しさん：04/10/07 03:36:29

>>393
ありがと。

396 ：デフォルトの名無しさん：04/10/07 03:37:57

>>394
あなたみたいに頭よくないからね。

397 ：デフォルトの名無しさん：04/10/07 03:53:58

>>383
> 設定の手軽さと機能の豊富さでS2が一番だと思う。
設定の手軽さで一番、というのは理解できん。
XMLのvalidation考えると特に。
ある程度大きな、例えばconstractor injectionの
インスタンス数が100とか言い出すと、コストが逆転する
かもしれんけど（まぁそこまでいくとXMLも専用エディタ
使わんと苦しいな）。
フィーリングとしてどれくらい？＞リーズナブルな規模

機能の豊富さはXMLの表現力と等価なわけで、情報量が（略）。

相手が日本人だと楽、というのは同意。自分も含めて
技術者として情けないがな……。一時期、Xalanコミュニティ
とかに顔つっこんでみたことがあるけど、やっぱりスケール
の違いを感じた。ロシア人の英語はよめねー。

>>384
そうね。個人的にもそこがコアだと思う。
AOPはそれを効率よく実現するための手段という考え。
そもそも「FactoryやAFactoryはDIコンテナで代用
できます！」ってのは、DIがFactoryの一流派だけ
なんじゃないかと小一時間（略

398 ：デフォルトの名無しさん：04/10/07 10:26:57

>>367

鯖提供者募集中だそうです。

399 ：デフォルトの名無しさん：04/10/07 11:07:16

しかし、こういうリフレクション全開のしくみが定着すると、いままで語られてた
「型安全性」だとか「コンパイルによる事前検証」のメリットってどうよ？と思わないでもない。

400 ：デフォルトの名無しさん：04/10/07 14:10:56

>>399
大いにそう思う。
いままでだと、型の安全性ってのは基本的にコンパイラが
あるていどの保証(とはいってもぴんきりだが)を
してくれていたわけだが、そういった部分に頼れないと
いうことだからね。

401 ：デフォルトの名無しさん：04/10/07 16:46:22

強い型付けはJavaのウリでもあるけども、オブジェクト指向的な利点を
徹底利用しにくいところもあったね。たとえばListnerを使ったコールバック的な
委譲モデルでも、おれはListnerインターフェイスをimplementsするんじゃなくて、
モデル側にMethodオブジェクトを渡してやるほうがなんぼかましじゃないかと
思ったりもするし。
たとえばThreadにRunnableオブジェクトを渡すんじゃなくて、実行して
ほしいMethodを渡して、Thread側ではinvoke()するとかのほうがもっとフレキシ
ブルなんじゃないかと。Runnableをimplementsする必要すらなくなるし。
こういう、型なんて関係ない、メソッドがあればいい、という使い方は本来、
オブジェクト指向ならではだったわけで。

DIコンテナの場合、利用側ではインターフェイスをもとにしたプログラミングを
行なうわけで、型安全性も十分保証できてると思うし。

402 ：デフォルトの名無しさん：04/10/07 17:14:14

キャストごりごりのコードになるよね？

403 ：デフォルトの名無しさん：04/10/07 17:28:17

>>401
C#のデリゲート、MSがJavaの仕様に入れようと提案したら
Sunに断られたそうで。

404 ：デフォルトの名無しさん：04/10/07 17:29:09

そうだな、DIコンテナ使うとキャストは増える。Object型返すしなあ。
たしかにそこでの型安全性は低くなってると思う。Cast例外って
実行時例外だったよなあ。

405 ：デフォルトの名無しさん：04/10/07 17:39:34

キャストは増えない。setter使えば勝手に入れてくれるから

406 ：デフォルトの名無しさん：04/10/07 18:37:15

最初の入り口さえどうにかすれば、あとは大丈夫という感じだね。
そういえば。
オブジェクトの遅延生成ができるともっといいね。
遅延というか、オンデマンド。
getXxx使ったときに生成されるような。
じゃないとイモヅル式にオブジェクトが生成されてしまう。

できるんだっけ？

407 ：デフォルトの名無しさん：04/10/07 19:26:43

>>405
いやコンテナ内のオブジェクトはいいんだよ。増えるところは

S2の例：
Hello hello = (Hello) container.getComponent(Hello.class);

この部分ね。まあ対した問題じゃないんだけどね。文法上
cast失敗を気にする必要もないだろうし。

408 ：デフォルトの名無しさん：04/10/07 19:58:36

使うとわかるけどcontainerの外でcontainerを使う方が珍しいと思う

409 ：sage：04/10/07 20:27:27

まー依存性注入するところでcontainer使うんだから、
奇麗に設計できている場合はそうね。

410 ：デフォルトの名無しさん：04/10/07 20:43:38

インスタンスがいもづる式に生成されまくるという問題ってないの？

411 ：デフォルトの名無しさん：04/10/07 20:57:04

インスタンスはcontainerが保持しているから問題なし

412 ：デフォルトの名無しさん：04/10/07 21:15:04

そのメモリはどこから出てくるの？

413 ：デフォルトの名無しさん：04/10/07 21:24:48

>>380はエントロピーって言葉に何か間違ったイメージを持ってるな

414 ：デフォルトの名無しさん：04/10/07 21:34:59

>410
基本はSingletonだ

415 ：デフォルトの名無しさん：04/10/07 21:36:14

ソフトウェアにおけるエントロピーの定義を教えてくれませんか？

416 ：デフォルトの名無しさん：04/10/07 22:09:49

>>414
そうすると、ソフトウェア中で必要なオブジェクトがすべて生成されてしまうことにならないかな。

417 ：デフォルトの名無しさん：04/10/07 22:13:33

>>415
これぐらいは自力で調べる癖をつけようね。
http://ja.wikipedia.org/wiki/%E3%82%A8%E3%83%B3%E3%83%88%E3%83%AD%E3%83%94%E3%83%BC
これの「情報理論におけるエントロピー」のところにある。
> ある確率分布 p(x) をもつ確率変数 X が与えられたとき、
>
> H(X) = -Σ_{x∈X}{p(x)log(p(x))}
>
>この量 H を確率変数 X のエントロピーという。

418 ：デフォルトの名無しさん：04/10/07 22:20:41

>>413
その言葉のもつ本来の意味を知らず、また、知ろうともせず、
単に語感やニュアンスだけでカッコいい言葉を使ってみる、
というのはどこに行ってもありがちだけどね。
>>380の言わんとしていることは分かったけど。

419 ：デフォルトの名無しさん：04/10/07 22:23:27

>>415
ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。
整理されてなく、どこになにがあるかわからないソフトウェアはエントロピーが高い。
Javaのコードは選択肢が多いから、一行の情報量が多い。
対して、SeasarやSpringなどのBean定義ファイルは選択肢が少ないので情報量が少ない。
また、規模の大きいソフトウェアも、行ごとの情報量が大きくなる。

系が閉じているときのエントロピーの総和は一定なので、どこかのエントロピーを下げようと思うとどこかにエントロピーを押し付ける必要がある。
整理してどこになにがあるか推測しやすい状態で、選択肢の少ないコーディング技術を使って、コード量を少なくすると、エントロピーが低くなる。
作成するソフトウェアのエントロピーを下げようと思えば、ライブラリやフレームワークを使うことのほかに、開発管理がある。
管理された成果物のエントロピーは低いけど、管理作業自体のエントロピーが高いから。

420 ：415：04/10/07 22:35:34

>>417,419
ありがとうございました。勉強になりました。

421 ：デフォルトの名無しさん：04/10/07 22:58:07

くーすを実案件に適用した例ってあるのかな？

422 ：デフォルトの名無しさん：04/10/07 23:05:47

いまオフショア開発でやってるんじゃなかったっけ？

423 ：デフォルトの名無しさん：04/10/07 23:08:14

>>420
-log(p(x))っていうのが情報量ね。確率の対数。で、エントロピーは情報量の平均(期待値)

424 ：デフォルトの名無しさん：04/10/07 23:17:48

×確率の対数
○確率の逆数の対数

文法のルールが多いほどコードのエントロピーは低くなる。
だから、Javaのコードは型の緩い言語よりエントロピーが低くなるんだね。
そのかわり、文法を勉強するためのエントロピーが高くなる。

425 ：デフォルトの名無しさん：04/10/08 01:13:25

>>416
すべて生成したとしてもデータを持たないオブジェクトという前提ならそれほど問題ないのでは？

426 ：デフォルトの名無しさん：04/10/08 01:15:39

>416
ソフトウェア中で必要なすべてじゃなくて、DIContainerに登録されているものすべて。
prototypeとouterを除く。

なんでもかんでもDIContainerに登録するわけじゃないよ。
多分416が思ってるほど多くはない。

427 ：デフォルトの名無しさん：04/10/08 01:23:41

JFrameとかを登録する方針にしたら、えらいことなりそうだけど。

428 ：デフォルトの名無しさん：04/10/08 01:35:41

VBとかDelphiで起動時に全フォームクリエイトしておいて
使うときにはShow()するような感じ？

Delphiでちゃんとしたアプリ作るときはちゃんと生成・消滅を管理するけど(VBはシラネ)、

429 ：デフォルトの名無しさん：04/10/08 01:45:53

そう、そんな感じ。
JFrameはシングルトンにしなければいいのかな。

430 ：デフォルトの名無しさん：04/10/08 03:27:40

＞ソフトウェアにおけるもなにも、エントロピーは情報量の平均だよ。

…ヲイヲイ…。

431 ：デフォルトの名無しさん：04/10/08 03:43:00

JFrameをDIContainerに登録するなら、prototypeになるはずだから
問題なしだ。VB、Delphiは良く知らんが、一つだけインスタンスを
生成しておいて、必要な時はコピーを生成してShow()するようになる。

これくらい分からんような奴らが、「ドキュメントすくねえ」とか
「全然優しくねえ」とかほざいてるのであれば、ひが氏は気に留める
必要ない。ドキュメント整備した所で使えねーよ。
S2Daoの機能強化やS2JSFの方に注力して欲しい。

432 ：デフォルトの名無しさん：04/10/08 05:12:15

前に羽生さんに粘着してた香具師がいたような。。。
ここにもいたりしてw

433 ：デフォルトの名無しさん：04/10/08 09:14:31

>>430
じゃエントロピーってなに？

434 ：デフォルトの名無しさん：04/10/08 09:45:49

>>417の定義のままだと思うのだが。

435 ：デフォルトの名無しさん：04/10/08 09:51:35

>>433
俺≠430だけど、こんな感じじゃない。

持ちうるデータのバリエーションの許容量⇒情報量
それの系全体(平均)⇒エントロピー

あるいは、バリエーションの許容量ではなく
絶対量そのものを指す人も多いかも。
どちらにせよ、Wikipediaのと違いはないと思う。

436 ：433：04/10/08 10:00:18

>>435
実は、情報量と書いてる部分も、エントロピーと書くべきだった気がする。
情報量っていうのは、たとえばJavaコードを1行取り出したときに
S2Container container = S2ContainerFactory.create(PATH);
だったときにどれだけ意外性があるか、という、それぞれの事象に対する量だからね。

437 ：デフォルトの名無しさん：04/10/08 10:06:07

>>431
こういう、足りない点を指摘するやつをバカにする方が、スレを荒らしてるわけだが。
こうやって評判落とすようなマネするのって、ヒガさんに実は恨みがあるから？

438 ：デフォルトの名無しさん：04/10/08 10:55:14

>>432
そりゃいるだろ。2chだからな。

439 ：デフォルトの名無しさん：04/10/08 10:57:34

>>437
恨みはないかもしれないが
妬みややっかみを持っている
ヤシはいるんだろうな。

440 ：デフォルトの名無しさん：04/10/08 10:58:46

>>438
羽生さんもいるくらいだからな。

441 ：デフォルトの名無しさん：04/10/08 11:00:56

>>439
で、ひがさんを擁護するフリをして、Seasar2は敷居が高い、とか、欠点に対する指摘を受け付けない、とかそういう逆宣伝をしてるわけか。

442 ：デフォルトの名無しさん：04/10/08 11:03:29

>>440
羽生さんがいるところには常に粘着するわけか。
大変だな。羽生さんも追っかけもｗ

443 ：デフォルトの名無しさん：04/10/08 11:04:03

恨みを買ってもしょうがないようなところあるからな。
人の話を遮って自分だけ延々と喋るし。
たいていは人の話に耳を貸さないくせにそれは相手によるし。
嫌いなやつは多いだろう。

444 ：デフォルトの名無しさん：04/10/08 11:07:09

>>443
まあそういう話はスレ違いってことで。
呼び出しくらうよ。

445 ：デフォルトの名無しさん：04/10/08 11:08:04

>>443
何だオマエ知り合いなのか。
本人に直接言ってやれよｗ

446 ：デフォルトの名無しさん：04/10/08 11:12:59

直接言えないから粘着してるんだよｗ

447 ：デフォルトの名無しさん：04/10/08 11:15:20

それにしても、よく観察してるね。

448 ：デフォルトの名無しさん：04/10/08 11:22:09

DIの利点って、分からん奴らにはメソッドの仕様だけ渡して、
その部分だけ他に影響を与えずに作らせることができるという
ことだと思います。
Rodの本なんかを読んだり、ソース調べたり、自分で試したり
できる人とできない人で、Seasarに関わる人は分化されるのです。
S２を作る人、使う人、使われる人の３種類になるのでしょう。
それぞれのスキルにあった役割を与える。これも優しさです。

使われる人は、他に問題を波及させずにとりあえず、与えられた
メソッドの実装を行えばよくなります。
使う人は、実装を外注しやすくなり、Springと比べてもテストや
設定が格段に楽になります。

その点の説明が公式サイトにないので（日記にはあるが）使われる人が
勘違いして、ちょっと調べれば分かることをここでゴチャゴチャ騒いで
いることでしょう。

ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。

449 ：デフォルトの名無しさん：04/10/08 12:01:27

何だ羽生氏に話を聞いて欲しい奴が騒いでるだけなのか？
ひが氏もいい迷惑だな

>>448
＞ドキュメントの整備は大歓迎です。ただ他の方に注力して欲しい。
禿同
ひが氏にはどんどんS2を磨いていってもらいたい
とりあえず2.1期待ageだ

450 ：デフォルトの名無しさん：04/10/08 12:38:41

>>449
話をさえぎられて自分の出番を取られてしまった人じゃないの？

451 ：デフォルトの名無しさん：04/10/08 15:00:40

やられたらやりかえせｗ

452 ：デフォルトの名無しさん：04/10/08 15:17:48

>分からん奴らにはメソッドの仕様だけ渡して、
>その部分だけ他に影響を与えずに作らせることができるという

ちゃんと詳細設計ができてれば普通のOOPどころか構造化設計でもそうです。

ドキュメントがどうとかは(俺は言ってないけど)せっかく匿名で本音を吐いてくれてるのに
それを粘着呼ばわりする被害妄想は止めて欲しい

453 ：デフォルトの名無しさん：04/10/08 15:37:25

DIだと、影響を与えないための労力が少ない、ってことじゃね？

454 ：デフォルトの名無しさん：04/10/08 16:37:56

枠組みとして用意されているのでいろんなスキルの人がまざっても
平準化しやすい、という事なら納得できるけど。
というか詳細なインターフェース設計をしてからじゃないと実装始められないよ、
ということか。それはいいかも。でも実装し始めてから設計ミスを直すのが
めんどくさそうな肝汁

strutsがMVCモデルを強制してもActionにビジネスロジック書く奴がいて、
結局ちゃんとOOAしないとMVCのメリットがでない
↓
ちゃんとOOA出来る人がいたらstrutsの仕組み必要ない
(設定ファイルの手間が増えるし。taglibは便利だけど)

みたいな事にはならないのかな？全然Seasarの話じゃなくて申し訳ないが

455 ：デフォルトの名無しさん：04/10/08 17:04:12

DIというか、クラス名やらメソッド名を外部設定ファイルに埋め込むと、リファクタリング機能が効かないから不便かも。

strutsのMVCはアプリケーション全体でいえばVの中のローカルなMVCだからしかたないね。

456 ：デフォルトの名無しさん：04/10/08 18:15:12

>>453
YES

>>454
だからくーすを作ったんじゃないかな

457 ：デフォルトの名無しさん：04/10/08 19:38:28

>>448
>使う人は、実装を外注しやすくなり、Springと比べてもテストや
>設定が格段に楽になります。

まじ参考までに教えて欲しいんですけど、Seaser2がSpringと比べて
テストや設定がしやすい部分ってどういうところなんでしょうか？
SpringとSeasar2の比較をいろいろ探したんですが、どれもいまいち
ピンと来ないもので。

458 ：デフォルトの名無しさん：04/10/08 21:32:42

>>452
人をうんこ呼ばわりしてあげつらったヤシが
いるんだから被害妄想もある程度仕方ない
と漏れは思う。ひが氏の日記が大人しくなって
しまったのが個人的には残念だ。

459 ：デフォルトの名無しさん：04/10/08 21:39:32

議論のアンチパターン～不毛な議論を避けるために～
ttp://homepage1.nifty.com/fujiwo/develop/oo/dscsnptn.html#chapter4

460 ：デフォルトの名無しさん：04/10/08 22:59:10

外注というと書かれるコードの中身は汚くてもいいという印象があってよくない

461 ：デフォルトの名無しさん：04/10/08 23:06:46

外注はよくないけど、とりあえずS2について言うと、
欲しい機能を（Javaでやるという前提であるならば）考えられうる限りできるだけシンプルに実装できるもので
割と好印象。

462 ：デフォルトの名無しさん：04/10/08 23:10:56

少なくともJ2EEを作った香具師より頭いいのは確かだ

463 ：デフォルトの名無しさん：04/10/08 23:13:14

先にinterfaceありきと考えると
仮にコードが汚くてもUnitテストさえ
クリアしていれば安心が得られると
いう利点があるかなと思うけどどうかな？

464 ：デフォルトの名無しさん：04/10/08 23:18:59

>>463
テストをするのは当然で
汚いのはリファクタリングの原則に反するのでよくない

465 ：デフォルトの名無しさん：04/10/08 23:22:32

もちろんそうなんだけど
外注に出して汚いコード
だったとしてもまだ安心度が
保てるように思うんだが

466 ：デフォルトの名無しさん：04/10/08 23:27:35

設計は変わるもんだ。外注にやるとプログラマからのフィードバックが得られない。
S2は外注向けと考えるならそれは間違い。もともとソフトウェア開発はそういうものじゃない。

467 ：デフォルトの名無しさん：04/10/08 23:38:23

ほんとはみんなデスマが好きなのさ。
どっぷりとデスマに浸かることで、
自分は仕事をしているんだ！
という満足感が得られるからなのさ。

さらに、デスマを解消したり
回避する方法を考えるのは
もっと好きなのさ。
なんでかというと、
自分はこんなすごいことをやったんだ！
という優越感が得られるからなのさ。

Seasarってのはそうやって生まれたの。

468 ：デフォルトの名無しさん：04/10/08 23:39:03

外注に出さないプロジェクトって、小さなプロジェクトか小さな会社くらいでは？

469 ：デフォルトの名無しさん：04/10/08 23:45:27

>464
汚いのはリファクタリングの原則に反する、ってのはどういう意味？
リファクタリングの対象になる、ならわかるけど。
ついでにいうとユニットテスト通ってるならリファクタリングも気楽にできるね。

470 ：デフォルトの名無しさん：04/10/08 23:45:59

>>468
S2の話とはもう違うだろ。
外注に出すところのコスト構造って本当に酷いよ。

471 ：デフォルトの名無しさん：04/10/08 23:49:42

DI 使うとデバッガ使えないの？テストうんぬんではなく、
ステップ実行とかできないの？

472 ：デフォルトの名無しさん：04/10/09 00:02:32

>>467
おかげでデスマにならずに済むなら漏れはありがたい。

>>471
S2のコードも全部放り込んでおけばいいんじゃない？

473 ：デフォルトの名無しさん：04/10/09 01:51:38

>>472
デスマはなくならないよ。

まず>>467でいう満足感と優越感がなくなっちゃうからね。

それに、新たな方法論を導入して解決するのは
「今までのステージにおけるデスマ」であり、
「次のステージにおけるデスマ」が控えているんだよ。

デスマあってのSeasarであり、
デスマある限りSeasatは進化し続け、
そしていつまで立ってもデスマはなくならない。

しかし、これがみんなの幸せにつながる。

474 ：デフォルトの名無しさん：04/10/09 02:18:01

＞デスマあってのSeasarであり、

(　ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　
(；ﾟдﾟ)

(つд⊂)ｺﾞｼｺﾞｼ
　　_, ._
（；ﾟ Дﾟ） …?!

'`,､'`,､('∀`) '`,､'`,､

475 ：デフォルトの名無しさん：04/10/09 02:58:52

>> 457
設定ファイルやテストコードを書くためのタイプ量がS2の方が少ない。
DIを使うと、これらの煩雑さが問題となってくる。

476 ：デフォルトの名無しさん：04/10/09 07:44:22

>471
DIは問題ない。初期化より後は普通だから。
でもAOPを使うとデバッガで追えない。
バイトコードいじってるやつ全般に言えることだけどね。

477 ：デフォルトの名無しさん：04/10/09 08:49:04

>>476
AOPを使っても追えるよ。
意味不明なクラスに行くけどそこもトレース実行すればその後は問題なかった。

478 ：デフォルトの名無しさん：04/10/09 14:05:50

>>476
デバッガで追えないのは、AspectJ。
S2は普通に追える。

479 ：デフォルトの名無しさん：04/10/09 15:42:43

>>462
J2EEっていうかEJB？
後だしじゃんけんだからなぁ。
DynamicProxyのおかげの部分もあるし。

480 ：デフォルトの名無しさん：04/10/09 16:24:41

>>479
S2はDynamicProxyは使ってないけどね。
cglibでバイトコードいじっているから同じようなものだけど。

481 ：デフォルトの名無しさん：04/10/09 16:54:24

・・・そうなんだね。
cglibのページの「Open source projects use cglib」に載ってないのが寂しいけど。

482 ：デフォルトの名無しさん：04/10/09 23:49:20

バイトコード操作してる地点で実案件に使えるのかなぁ。。
とても使わせてもらえなそうだが。。

483 ：デフォルトの名無しさん：04/10/10 01:01:18

オイオイ、どういう判断基準なんだ？
といことはcglib使ってるモノはすべてだめなんだね。
HibernateとかSpringとかも。

484 ：デフォルトの名無しさん：04/10/10 01:37:22

>>483
コンテナ部分は使ってないぞ。Spring。readme.txtに書いてある。
なので、AOPやDAO機能を捨てれば非バイトコード操作なDIコンテナとしては使える。
あと、PicoContainerも非バイトコード操作なDIコンテナだよね。

>>482
なので、あくまでもDIコンテナが使いたいならS2以外の選択もある。
AOPを利用したい時にはS2のほうが簡単だと思うけどね。

485 ：デフォルトの名無しさん：04/10/10 01:45:20

AOPなければ、意味がかなり減るんだけども。
SpringのAOP定義はめっさめんどり。

486 ：デフォルトの名無しさん：04/10/10 04:53:02

>>403
偉いなMS。蚊帳の外でもコミットしようとするなんて。
これだけ見るとSUNだめだな。
空のインプリメソッドがゴミのようにある俺のソース…。何とかしてくれ。

487 ：デフォルトの名無しさん：04/10/10 05:05:49

いろいろ考えたんだけどさ、EJBとかDIコンテナとか
やっぱりなんかくだらない気がしてきた。

アプリケーション毎に必要な機能って違うじゃんか。
（負荷分散・クラスタリング・動的再配置・トランザクション・必要になるパフォーマンス、とかいろいろ）
シンプルな実装をアプリケーション毎に作ったほうが、ムリヤリ共通して使える実装を探さなくてもいい。

488 ：デフォルトの名無しさん：04/10/10 05:07:32

シンプルに構造を分割する考え方（～層、とかいろいろ）の話を延々としているほうがいいと思うよ。
実装はアプリケーション毎に行こう。

489 ：デフォルトの名無しさん：04/10/10 05:15:47

>>455
リファクタをキジムナに期待age

490 ：デフォルトの名無しさん：04/10/10 05:23:48

>>487
それはアプリ毎に必要な機能じゃなくシステムの構成・設定。
487の言う「いろいろ」こそ共通して使える実装部分じゃろ。

491 ：489：04/10/10 05:56:56

>>330
> ところで、S2が正しくinjectionしてくれるかどうかの
> テストはどう書けば？（汗）
キジムナ使へば下に出るぞ。singletonだけかもしれんが。
それをキャプチャしたのをテスト結果とすると良いかも。

>>399
>>400
キジムナ使え。事前検証バリバリだぞ。

>>作者
コード補完機能ｷﾎﾞｿ

492 ：デフォルトの名無しさん：04/10/10 08:16:10

>>487
だから、アプリケーションごとに違う非機能要件をAOPを
使って処理するんじゃん。

493 ：デフォルトの名無しさん：04/10/10 08:30:30

>>486
俺もMSの態度は偉いと思う。
片思いなのがこれまた哀愁がただよってて
ヘンに共感してみたり。いやそりゃヨタだけども。

でもコーディング量が増えても
インターフェイスという考え方で統一したいって
気持ちもちょっと判るんだよねー。

494 ：デフォルトの名無しさん：04/10/10 08:36:10

>>490

トランザクションの基盤なんて単純なものならほんの数行のコードで実装できるし、
動的再配置するためのライブラリ（ちょっとしたネームサービス）あればいい
クラスタリングや負荷分散となると、それはアプリケーション毎にかなり違うもんだと思う

あんまり仰々しいフレームワークを用意されても、結局複雑にしてしまうだけではなかろうか

495 ：デフォルトの名無しさん：04/10/10 09:05:12

>>487
そんなこといったらJDBCもいらんってことにならんか？
何を持ってシンプルな実装というかだな。

496 ：デフォルトの名無しさん：04/10/10 09:41:42

>>494
ぎょうぎょうしいフレームワークって何。
S2はシンプルだと思うけど。
POJOが基本で、コアはDIとAOPの機能だけ。

コア以外の機能もいろいろあるけど、
使えるものは使えばいいし、無理に使わず自前で実装しても良い。

ただ、クラスタリングや負荷分散を自前で実装するやつは、
よっぽどのツワモノだと思う。

497 ：デフォルトの名無しさん：04/10/10 10:39:55

>>487
EJBはくだらないが、DIはくだらなくないよ。
アプリケーション毎に、というより、アプリケーション内で必要な機能をアプリケーション内で共通して使うためにDI+AOPが有効だと思われ。

498 ：482：04/10/10 12:58:13

>483

SpringもHibernateもDynamicProxyで代用できませんでしたっけ？
#フル機能使えなくてもさ

DIコンテナってテストが簡単とか、複雑じゃないとか利点ばっか挙げられてるが，
商用EJBコンテナが提供するような分散・スケールアウト手法は確立されているの？

499 ：デフォルトの名無しさん：04/10/10 13:02:41

>496
毎回毎回自分で実装できるような奴ならいらんのでしょ。
負荷分散・クラスタリング・動的再配置・トランザクションをシンプルな実装で
アプリケーションごとにバグ少なく作成できるような凄い人はうちの周りには
いないけどね。

500 ：デフォルトの名無しさん：04/10/10 13:10:21

>>499

負荷分散・クラスタリングって、パフォーマンスとの兼ね合いでいろいろ調整いるだろうから、
自分で実装っていうのが基本では。
それを補助く小さなライブラリ（タプルスペース扱うやつは便利だ）があれば満足。

501 ：デフォルトの名無しさん：04/10/10 13:18:19

>>500
スーパーな人発見。
釣りじゃないならすごいね。
そういうのは、アプリケーションサーバか負荷分散装置だとかに
任せるものだと思っていたよ。

502 ：デフォルトの名無しさん：04/10/10 13:21:07

まぁ、EJBとかに比べると仰々しくは無いのだけど、
Lightweightなプログラミング言語を使っているとどうしても大げさに感じてしまうのよね。

503 ：デフォルトの名無しさん：04/10/10 13:24:26

>>500
バイトコードいじくるものより、自分で組んだ負荷分散やらクラスタリングのほうがあてにならんなぁ。
トランザクションも、基盤は数行でも、いろいろなところに埋め込まれて、そっちの方があてにならんなぁ。

504 ：デフォルトの名無しさん：04/10/10 13:27:27

Lightweightなプログラム言語使ってる人って、ライブラリやフレームワークを勉強して数行でまとめて書けるコードを、頭使わず勉強せず数十行あっちこっちに書くほうが手軽だと思いがちだよねぇ。

505 ：デフォルトの名無しさん：04/10/10 13:31:12

>>501
貧乏人は自分で作るんですよ。多分。

506 ：デフォルトの名無しさん：04/10/10 13:32:18

スケールアウト、負荷分散いらないんじゃそもそもEJB使ってねえぞ。
これらの機能提供しないのに，EJBの代替物と歌われてもねぇ、、、

507 ：デフォルトの名無しさん：04/10/10 13:33:55

>>505
作っているものによると思うけどね。
一体どういうものを想定している？

HTML文章返すだけのウェブサーバとネットワークゲームのサーバではそりゃ負荷分散の手法は違ってくる

508 ：デフォルトの名無しさん：04/10/10 13:40:01

基本的に業務システム以外は対象外だからねぇ。

509 ：デフォルトの名無しさん：04/10/10 13:40:48

というか、ネットワークゲームのサーバーでEJBがどうのこうのいうほうが間違ってる。

510 ：デフォルトの名無しさん：04/10/10 14:26:38

>>509
そこはそれ、アプリ層のインプリだけ構造を統一するためにEJBの
スタイルを借りて、サーバー部分は最適化したものを自作、デスよ。

…ほんまかいな。

511 ：デフォルトの名無しさん：04/10/10 14:38:02

ネ申？

512 ：デフォルトの名無しさん：04/10/10 14:40:51

自ｲ乍ﾈ申

513 ：デフォルトの名無しさん：04/10/10 14:48:56

どの層で分散がいるかなんて、これはアプリケーション毎に違うでしょ？
どでかいコールセンターで検索したい人が多いなら単にデータベースを大量に水平に並べればよい。
核爆発シミュレーション計算の分散も基本的にはコンピュータ並べるが、自作率は後者のほうが多くなるだろうな。

514 ：デフォルトの名無しさん：04/10/10 15:03:27

>506
EJBの代替物とは謳ってないんじゃない？
J2EEの機能を使いやすくする、でしょ。

J2EE=EJBだと思ってるなら間違い。
ついでに言うとまだ発展途上なのに「全部無いなら使わん」とかいうならご自由に。

使いたいとこ、使えるとこだけ使えばいいんだ。
あとは自作なり他製品と組み合わせるなり。

515 ：デフォルトの名無しさん：04/10/10 15:06:12

語尾に「なり」をつけるやつは嫌いだ。

516 ：デフォルトの名無しさん：04/10/10 15:07:29

>>513
とりあえず対象となってない分野をもってきて、使えないとかわめくのって、悲しいね。

517 ：デフォルトの名無しさん：04/10/10 15:13:06

>>506
いつからEJBの主目的が負荷分散になったんだ？

518 ：デフォルトの名無しさん：04/10/10 15:14:39

EJBの代替物にもなってないしねぇ。

519 ：デフォルトの名無しさん：04/10/10 15:16:13

いや、当初から主要な目的の一つではあったが…。
負荷分散しないのにEJB使っても今ひとつ甘みが無い。

520 ：デフォルトの名無しさん：04/10/10 15:16:25

>>516
クラスタリング・負荷分散に共通して使える対象なんてありえないってことを示す例

521 ：デフォルトの名無しさん：04/10/10 15:18:24

業務システムに絞れば、共通して使えるしくみはあるんだけども。
で、とりあえずS2が話題にしてるのは業務システムなんだけども。

522 ：デフォルトの名無しさん：04/10/10 15:20:57

S2に限らずDIな連中が言ってるのは
EJBを使うのは大袈裟なシステムが
世の中には多いんだから別の手を
使おうぜってことでしょ。EJBが必要な
人はそっちを選べばいい。

523 ：デフォルトの名無しさん：04/10/10 15:21:36

まずは軽快なJavaを読めということでFAだな

524 ：デフォルトの名無しさん：04/10/10 21:28:23

それは負荷分散をしないって手？

525 ：デフォルトの名無しさん：04/10/10 21:35:31

負荷分散なんて、DBやアプリケーションサーバーにまかせればいいから、プログラムでは考えなくていい。
いくつかの注意点はあるけども。

526 ：デフォルトの名無しさん：04/10/10 22:39:39

APサーバに任せるメジャーな手段が、EJ(r

527 ：デフォルトの名無しさん：04/10/10 22:58:32

つか、なんかどーでもよいことに話がいってない？
負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
（てか、んなことまでサポートしだしたらLightweightなコンテナじゃなくなるじゃん）

もう少しS2自体の話があるとうれしいのだけど。

528 ：デフォルトの名無しさん：04/10/10 23:11:40

>>520

フレームワーク外の作りこみ一切禁止なんて縛りがあるわけでもないのに、
なぜそこで完璧を目指す必要があるのか理解できない。
パレート原則で言う8割の側を押さえるだけで十分では?

529 ：デフォルトの名無しさん：04/10/10 23:23:01

しってる難しそうな言葉をならべて賢くなった気になる遊びですた。

530 ：デフォルトの名無しさん：04/10/10 23:53:24

>>529
理解できない会話に無理に加わる必要はないよ、坊や。

531 ：デフォルトの名無しさん：04/10/10 23:56:29

2chだな～

532 ：デフォルトの名無しさん：04/10/11 01:57:15

>>527
> 負荷分散やらクラスタリングなんかDIコンテナで解決する問題じゃないし。
だってDIコンテナの作者らがEJBｲﾗﾈって言ってんだもん。

533 ：デフォルトの名無しさん：04/10/11 02:28:34

J2EEを使った業務システムで、そこまで必要なシステムって多くないし
その程度のシステムでEJBはイラナイだろ。

534 ：デフォルトの名無しさん：04/10/11 03:05:48

>532

DIコンテナの長所挙げるとき散々*EJB*と比較して、
難しいとか、テストが大変とかEJBの短点ばかり挙げるのにな（ｗ

535 ：デフォルトの名無しさん：04/10/11 04:37:42

遡ると、なぜJavaを選択するのかという話にならないか
短いコードで表現力の高いプラットフォームなら他にあるだろうに

536 ：デフォルトの名無しさん：04/10/11 07:14:54

>>532
負荷分散やクラスタリングは、ロードバランサや
HttpSessionでやった方が良い。
EJBでやるよりよっぽど実績がある。

537 ：デフォルトの名無しさん：04/10/11 07:38:11

>>536
HTTPって、それは単にウェブサーバの負荷を分散ではなかろうか。

素人なんだけど、業務アプリの場合、データベースのバックアップも兼ねた
クラスタリングが重要になるのでは？

538 ：デフォルトの名無しさん：04/10/11 08:13:38

>>537
C-JDBC使えば？

539 ：デフォルトの名無しさん：04/10/11 08:24:57

>>537
業務ロジックは、Servletコンテナと同一VMで動かすのが
パフォーマンス的には良い。
スケーラビリティがなんて言うやついるけど、
業務ロジックよりもWebの部分が先にボトルネックになる
ケースの方が多い。

データベースへの接続も負荷分散装置使えるよ。

EJBコンテナで負荷分散やクラスタリングしているシステムなんて
ほとんど見たことないけど。

540 ：デフォルトの名無しさん：04/10/11 09:05:44

>>539

いや、しかし、世間的にはどうか知らんが、
漏れの経験では業務アプリでウェブベースなほうがむしろ稀だった。

ウェブベースなのは補助的な用途の場合が多い。
そういうときって、やはりクラスタ機能ある常駐プログラム
作る必要あるわけで、それはJavaで作るならばejbかdiコンテナか選択するんだろうな。

業務アプリに必要なのって、サービスを管理するライブラリだよね。
インストールはコマンド一発。
DHCPでIP振られたら自動的にデータベース起動して、アプリサーバ起動して、
クライアント探して・・・　っていうのを自動でできるようにしなきゃいけない。
（でないと導入コスト高いんだ）

541 ：デフォルトの名無しさん：04/10/11 09:37:23

>>540
S2の用途は539の言うとおりだと思う。
S2が自分の用途に向かないなら他を探すのが良いと思う。

542 ：デフォルトの名無しさん：04/10/11 10:28:32

今のトレンドはStatelessだよな。EJBを使うにしてもだよ。
ということは負荷分散をEJBコンテナがやらなければならない
ケースは少ないといえるんじゃないのか。しかもHTTPだろ。
俺ならロードバランサを前に挟むけどな。

543 ：デフォルトの名無しさん：04/10/11 10:30:16

>>537
そういう場合は、DBの機能を使うよ普通。
OracleならRACとかな。EJB使うほうが当てにならん。

544 ：デフォルトの名無しさん：04/10/11 10:38:24

>>532
実際要らないシステムが多いだろ。デプロイが楽だからWeb使うだけで
大したトランザクション量じゃないシステムも多いよ。

>>534
そりゃそうだろ。DI自体がEJBに対するアンチテーゼだからな。
インコンテナのテストなんて面倒だろうに。
当のEJBだってPOJOに方向転換じゃないか。

EJB*だけ*がスケーラビリティ確保の手段だと本当に思ってるのか？
PHPで大規模やってる連中だっているだろ。そいつらが
どうやって負荷分散やフェールオーバを実現しているのかを見れば
EJBのレイヤーでなくてもやれることがいっぱいあるのはわかるだろ。
頭が固いか不勉強か単なる言いがかりかのどれかに見えちゃうぞ。

545 ：デフォルトの名無しさん：04/10/11 10:49:08

>>534
EJBの長所が負荷分散だというなら
それはEJBでなくても他に汎用的で
実績のある代替手段を使えばそれで
済むんだからEJBｲﾗﾈってことになるな。
EJBのテストが面倒なのは事実。
性能が出なくて変なテクニックばかり
横行するO/RマッピングもHibernateや
S2Daoのほうが便利で性能がいい。
EJB-QLなんて何の意味がある？
EJBの長所は何があるんだ？
DIがなくてもEJBにはウンザリしてるよ。

546 ：デフォルトの名無しさん：04/10/11 10:50:42

EJB擁護派はこちらで論破してきてください。

EJBは終わってる
http://pc5.2ch.net/test/read.cgi/tech/1036481443/l50

547 ：デフォルトの名無しさん：04/10/11 12:42:54

>>537
フェールオーバとロードバランスは別だよ。
でもってどっちもDIとかEJBとか関係なく
考えるべきものだから。クラスタリングは
EJBの専売特許ではない。

548 ：デフォルトの名無しさん：04/10/11 13:41:47

>540
「DIコンテナ」部分だけ使うなら、他を自作しても邪魔にはならないよ。
S2開発者が主軸に考えてるのがWebだってだけ。
周辺プロダクトはそれに合ったものからでてくるけど、別に必須ってわけじゃない。

業務機能と非業務機能を全部自作するにしても、DIコンテナで管理できると楽だ。

549 ：デフォルトの名無しさん：04/10/11 14:05:45

>>540
なんか、もっとすっきりできる気がするが・・・

550 ：デフォルトの名無しさん：04/10/11 14:52:49

diconファイルはシンプルだけど、それでもいろいろ書き間違える。
Kijimunaがないとやってられない。
Kijimunaってどれくらい使われてるんだろう。
SpringIDE(?)と比べるとどう?

551 ：デフォルトの名無しさん：04/10/11 15:02:57

>>550
「どれくらい使われているか」より「どれくらい使いやすいか」の方が大事

552 ：デフォルトの名無しさん：04/10/11 15:22:36

>>551
最新バージョンは使いやすいよ。
何が自動インジェクションされているかも分かるし、
コンポーネントの定義からソースにも飛べる。

553 ：デフォルトの名無しさん：04/10/12 01:45:36

Strutsでページ遷移の単体テストにS2Struts使うと楽になりますかねぇ？

554 ：デフォルトの名無しさん：04/10/12 07:30:29

>>553
なるよ。

555 ：デフォルトの名無しさん：04/10/12 21:58:53

JBossで座絶したんだけどこれ結構使える？

556 ：デフォルトの名無しさん：04/10/12 22:14:53

ちょっとずつ始めれるので、挫折しにくいよ。

557 ：デフォルトの名無しさん：04/10/13 00:04:53

何に挫折したのかを書くと世話焼きが相手をしてくれるぞ
Servletで挫折したならそれはJBossのせいじゃないからな。

558 ：デフォルトの名無しさん：04/10/13 02:59:31

インストールで挫折しますた。

559 ：デフォルトの名無しさん：04/10/13 03:04:47

ダウンロードに挫折しますた。

560 ：デフォルトの名無しさん：04/10/13 10:51:27

はぶにっき、訳分からん。突然切れチョル。
日記だからっちゅうても、雑誌に「S2はblog駆動」とか書いてるん
だから、何について言ってるんかハッキリするか、非公開にするか
せんと。
自分、さんざん内向きにアピールしちょるやないけ。
ひが氏が２chの戯言にまで耳を貸して、開発やドキュメント整備に
尽力しとるのを、足ひっぱっとりゃせんか？

車やコンピュータや家電だけが産業と違うじゃろ。
ハードウェア屋がコスト削る部分なんざ、ソフトでいえばコンパイル部分よ。
ここがこれ以上ないぐらい最適化されとるんやし、全品オーダーメイド
で、掛かる費用ほぼ人件費な状態を、車と一緒に考えられんわい。

「客に向け」「この業界に先はない」っちゅうんは至極まっとうだと思うが。
ttp://d.hatena.ne.jp/habuakihiro/

561 ：デフォルトの名無しさん：04/10/13 10:53:23

メインフレーム時代からコストどれだけ下がったか。

562 ：デフォルトの名無しさん：04/10/13 10:59:26

>>560
あれは基本的に経営側の人間であって開発側の人間ではないのよ。
だから、経営の視点で開発の人間を判断して、当人としては歯がゆい思いを感じているんだろう。
といって、偉そうなこと言う割にはべつに経営で成功しているわけではないあたり、
文句たれている相手と同じ程度の人間であることをさらしてしまってるのだが、
それに気付いていない無知の無知がちょっとイタい。

563 ：デフォルトの名無しさん：04/10/13 11:16:17

>> 562
人格はどうでもいい。

564 ：デフォルトの名無しさん：04/10/13 11:27:28

つうか、はぶ氏個人の評価はスレ違い。

565 ：デフォルトの名無しさん：04/10/13 11:40:43

「経営側に回れるだけレベルは上」と考えてるんだろう、ある意味間違ってないが

566 ：デフォルトの名無しさん：04/10/13 12:00:24

>>560
http://capsctrl.que.jp/kdmsnr/diary/20041012.html#p05
ここへのコメントの続きじゃないの？

ここの人、若いんだけど、いっつも歯に衣着せぬ物言いなんで
（あ、若いからか）、いっつも微笑ましく読んでたんだけど
さすがはぶたんですなー、容赦せんもん。

上記サイトの人、今会計の仕訳の勉強とかしてるみたいで、
そういう勉強中の人に「DOAなんて否定的な表現」うんぬん言われると、
むちゃくちゃ厚い債権債務帳票とか出したり、
やったらきっつくて頭の切れる、出禁とかすぐ口に出すお客さんと
仕事した事あるのかなあ、と思ってたので、
ちょっとだけ溜飲が下がったよ。

はぶたん徹底して「顧客」って言わないね。お客様、と言う。
ちょっと気持ち悪くは感じたけど、プロなんだなとは思った。

567 ：デフォルトの名無しさん：04/10/13 12:38:18

まあなんつーか、たまに余人に見えないモノが見えてるヒトではあらぁね、
ソレが天才だからなのかデムパ受信してるのかはむろん余人に分かろうハズは無く…

ナニが言いたいかつーともーすこし他人の目を意識して書いてくださいと

＞金持ちに寄生して搾取してるだけじゃん。狭い世界の中で偉そうにしてるだけですよ。
＞OOもDOAも構造化も全員そうだよ。コバンザメでしかないよ。世界中が腐ってる！

568 ：デフォルトの名無しさん：04/10/13 13:02:47

コメント化って空のコメントがあるだけなんだけど
なんか書いてあったの？

569 ：デフォルトの名無しさん：04/10/13 13:14:31

相変わらず個人ネタか。

570 ：デフォルトの名無しさん：04/10/13 13:39:38

でも、お客にとっちゃOO分析だろうがER分析だろうが
知った事ではないだろうってのは、
くーすのよってたつ所なのではないかなあと思った。

だから本がどんなんなるか楽しみな訳で。
前に、見積もりの提示の仕方についても盛り込んでくれたらなーって
ここに書いたんだけど、それも上記が理由。

571 ：デフォルトの名無しさん：04/10/13 14:24:45

> 方法論がエンジニアにとって癒しにしかなってないじゃん、って思うんですよ。そりゃね、
> みんな賢いからさ、そういう人間が集まって膝突き合わしてそういうやり取りしてれば、
> 自分だけじゃない、って思えるしそりゃ楽しいでしょう。

> 別にS2でなければならない、ってこともないんですよ。EJBでも構わない。
> PHPでもRubyでもいいんですよ。

> 幾ら優れたことをやっても、根本的に「で？」としかならない。自分が一顧客として金を
> 出すとしたら、って考えると、欲しいのはそんな裏方の話じゃないっしょ。

これまた正論だが、日記でよく言うね。だが、あんたが自分でも気づかないフリしてる
心境は「確かに S2 は良いかもしれない。ひがが目立つのはうれしいが、俺のほうが
できる人間なのにが影に隠れてるのはくやしい。」だろ。

だいたい、客に伝わらんのはあんたの営業能力不足だろ w
古い言葉で言えば「バカの壁」だな。規模が違う話して悪いが、例えば IBM の研究所の
人間でもあんたは「方法論ばかり言ってないで少しは経営のことを考えろ」って言うか？

類稀な経営手腕を持ってんだったら、開発者に対してやる気なくすこと言わずに
気持ちよく駒として動かすことに専念すれば？くーすﾏﾝｾｰとか言ってやれば
ドーパミン全開で土木作業してくれるよ w

多少、建設的なネタを。ひが君「cglib 遅せーから Javassist 使う」とか言ってないで
直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
思うけどな。

　性能： ASM ＞ Javassist（初心者向け）＞ cglib(初心者向けASMラッパー)
　　　　　　　＞ BCEL ＞ SERP

572 ：デフォルトの名無しさん：04/10/13 14:56:42

日記への反応は日記に書けば？あっちでも匿名で書けるんでしょ？

573 ：デフォルトの名無しさん：04/10/13 14:58:46

もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。
システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに
OOPLを導入してもその壁をうまく越えられてない人が結構いる。
くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら
壁を越えられない人たち向けには良い指針になるかもしれない。

前に使ったある外注は顧客クラスがあるにもかかわらず、
パスワード変更クラスとメールアドレス変更クラスをつくりやがった。
OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。

あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、
顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな
変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが
重要になってくると思うんだけどお前らはどう思い松か？

574 ：デフォルトの名無しさん：04/10/13 15:37:37

別にさあ、日記に何かいてようがいいじゃん。
少なくとも、ここでどうこういう話じゃない。
プロダクトやプロモーションに関わることなら別として。

また呼び出しくらうよ？

575 ：570：04/10/13 15:37:50

>>573
「くーすが知ったこっちゃない」んじゃなくて、
くーすは「お客さんはそんなこと知ったこっちゃない」って
前提で考えられてるんじゃないかなーって
思ったの。

後半の、「顧客が納得できるモノは画面イメージだけって
いうのには諸手を挙げて賛同するけど」と同じでっす。

ちょっと言葉足らずでしたかすんません。

576 ：デフォルトの名無しさん：04/10/13 16:09:04

>「お客さんはそんなこと知ったこっちゃない」って前提で
なるほど。そうかも

その他の部分はひが氏の日記を拾い読みした記憶から勝手に脳内保管して
書いているので、見当違いだったらごめん、っていうか指摘してくだちい

577 ：デフォルトの名無しさん：04/10/13 19:01:57

しかしみんないろんな日記よく読んでるねえ。

みんななんだかんだいってもS2が気になってしょうがないんだね。

578 ：570：04/10/13 19:24:45

>>577
まさにそのとおり。からさわぎいくどー。

579 ：デフォルトの名無しさん：04/10/13 21:03:02

S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...

580 ：デフォルトの名無しさん：04/10/13 21:09:02

>>579
あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。

581 ：デフォルトの名無しさん：04/10/13 21:33:58

うちなーんちゅ記念ｶｷｺ

582 ：デフォルトの名無しさん：04/10/13 23:19:53

>> 580
コアな部分は全部１人でやってるよ。

583 ：デフォルトの名無しさん：04/10/13 23:43:03

S2Dao使うにはMySQLは不向きだな。

584 ：デフォルトの名無しさん：04/10/14 00:05:05

>>579
オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような

585 ：デフォルトの名無しさん：04/10/14 00:07:17

コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。

586 ：デフォルトの名無しさん：04/10/14 06:56:40

>>573
> パスワード変更クラスとメールアドレス変更クラスをつくりやがった

これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。

587 ：デフォルトの名無しさん：04/10/14 06:57:10

顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん

588 ：デフォルトの名無しさん：04/10/14 07:22:10

ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？

589 ：デフォルトの名無しさん：04/10/14 16:25:45

顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。

わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。

是非俺にも納得できるように説明して欲しい

590 ：デフォルトの名無しさん：04/10/14 16:36:32

誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、

という無法状態を放置しているのがそもそもの間違い。

591 ：570：04/10/14 17:11:30

>>589
データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。

ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。

592 ：デフォルトの名無しさん：04/10/14 17:54:51

>無法状態を放置しているのがそもそもの間違い。

まあそりゃそうなんだが。

>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか

ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。

で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。

593 ：デフォルトの名無しさん：04/10/14 20:34:50

>>592
顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。

>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・

594 ：デフォルトの名無しさん：04/10/14 21:09:20

>顧客情報と認証情報を別個に分けて管理したい時

そのために内部の実装を分けないといけないようなケースがそんなにあるの？

>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・

誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど

595 ：デフォルトの名無しさん：04/10/14 21:21:04

>>592
>ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
>daoCustomer.setData(this);
>dao.update(connection);
>みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
>渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
>使えば楽になるのかなあと思って興味を持ってるわけだけど。

S2Dao使うと、dao.update(customer);で済む。
複数のdaoでconnectionを共有するなんてのは、まさにDIの使いどころ。

596 ：デフォルトの名無しさん：04/10/14 21:38:20

>>591
データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？

597 ：デフォルトの名無しさん：04/10/14 22:00:15

>596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。

白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。

598 ：デフォルトの名無しさん：04/10/14 22:07:20

下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。

599 ：デフォルトの名無しさん：04/10/14 22:16:47

データとロジック分けるメリットって？

600 ：デフォルトの名無しさん：04/10/14 22:48:16

>>599
メリットは597が言ってる。

でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。

なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。

S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？

601 ：デフォルトの名無しさん：04/10/14 22:48:26

ValueObjectに処理を持たせるという話をしてるの？

602 ：デフォルトの名無しさん：04/10/14 23:01:23

>599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。

ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。

603 ：デフォルトの名無しさん：04/10/14 23:09:27

業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。

604 ：デフォルトの名無しさん：04/10/14 23:16:36

S2JSFまだぁ？

605 ：デフォルトの名無しさん：04/10/14 23:21:26

>> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。

606 ：デフォルトの名無しさん：04/10/14 23:40:01

601ハ、ValueObjectノ意味ヲハキチガエテマス。

607 ：デフォルトの名無しさん：04/10/15 00:33:00

>603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。

ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。

だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。

うまくいけば楽にならないかなぁ。

608 ：デフォルトの名無しさん：04/10/15 00:55:06

>>607
ふつーうにS2の実装ってそんな感じじゃないの。

609 ：デフォルトの名無しさん：04/10/15 03:00:24

ビジネスルールがSQLに分散するんじゃね？

610 ：デフォルトの名無しさん：04/10/15 09:44:02

ビジネスルールって言葉が曖昧だよな

611 ：デフォルトの名無しさん：04/10/15 13:35:54

>>609
どーせ、SQLは山ほど書くんだから問題なし。

612 ：デフォルトの名無しさん：04/10/15 14:09:21

>>611
山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。

613 ：デフォルトの名無しさん：04/10/16 04:31:40

S2Ayaya を使えばあややのどこにinjectionできますか。

614 ：デフォルトの名無しさん：04/10/16 04:55:10

もちろん大事なところでしょう。

615 ：デフォルトの名無しさん：04/10/16 12:56:46

メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？

616 ：デフォルトの名無しさん：04/10/16 14:25:56

>614

RejectedRuntimeExceptionが発生します。

617 ：デフォルトの名無しさん：04/10/16 21:29:13

>>591
>データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。

やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。

おまいら、以下を読んで目を覚ましてくれ。

----
ドメインモデル貧血症
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----

618 ：デフォルトの名無しさん：04/10/16 21:50:51

そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。

619 ：デフォルトの名無しさん：04/10/16 21:57:31

>やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。

617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。

620 ：デフォルトの名無しさん：04/10/16 22:49:27

構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？

621 ：デフォルトの名無しさん：04/10/16 23:09:46

591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。

世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。

大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。

で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。

そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。

622 ：デフォルトの名無しさん：04/10/17 00:13:43

> OOってまだそこまで大成功は収めていない手法にも関わらず

ぽかーん。
まるで、親にメシ食わせてもらいながら「親なんて必要ない」とほざいてる中学生みたいだな。

623 ：デフォルトの名無しさん：04/10/17 00:15:16

>>620
>OOってまだそこまで大成功は収めていない手法にも関わらず、

ΣΣ(ﾟдﾟlll)ｶﾞｶﾞｰﾝ!!

624 ：617：04/10/17 00:30:58

>>621
> 591だけど、ドメインモデル貧血症の事は知ってます。
> だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
> 別の流れも最近よく目にします、っていう意味ですよ。

寡聞にして知らないのですけど、どのへんで見たのか教えていただけませんか?

> 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
> ってだけなのは、ちょっとお寂しいですね。

いや、

ファ> ドメインモデル貧血症問題の本質は、ドメインモデルのベネフィットを何も得ず、
ファ> コストだけをすべて被ってしまうという点です。

とも仰ってます。
もちろん「ドメインモデルなんて使わないで TransactionScript一本」っていうプロジェクトであれば、
ドメインモデル貧血症に該当してもなんの問題もないとは思いますけど。

> そもそもその貧血症だのなんだの、
> 純血種しか許さない態度が俺は好かん。

これはそうですな。反省してます。

625 ：617：04/10/17 00:39:55

>>612
> >>611
> 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
> SQLバリバリの人だったら、その辺問題ないのかなあ。

SQLバリバリだろうがなかろうが問題ありありだと思うよ。DRY原則に反してるわけだから。
# DRY原則は数あるソフトウェアの原則の中でも、最も尊ぶべき原則だと思うなぁ

626 ：デフォルトの名無しさん：04/10/17 01:50:08

DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。

これがすばり貧血症にあたるかわからないけど
tp://www.relaxer.org/process/sample/library/LibrarySystem1.1.1/LibrarySystem_s4.html
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。

あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。

でもそんな違いは誤差だとかってまた言われそうだ。

627 ：デフォルトの名無しさん：04/10/17 02:07:30

あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。

628 ：デフォルトの名無しさん：04/10/17 02:25:12

まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。

業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。

浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。

VB + OCXが割と正解だったってことかな。

629 ：デフォルトの名無しさん：04/10/17 03:37:46

626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。

完全にスレ違いになってしまいました。

630 ：デフォルトの名無しさん：04/10/17 09:05:34

>>629
どこが、常人に難しそうなの。

631 ：デフォルトの名無しさん：04/10/17 10:40:20

最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。

ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。

DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。

これがくーすの考え方なんだと思う。

それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。

632 ：デフォルトの名無しさん：04/10/17 11:06:45

> DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。

これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)

633 ：デフォルトの名無しさん：04/10/17 11:19:55

>>632
必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。

634 ：デフォルトの名無しさん：04/10/17 11:33:13

システムを層に分ける。
データストレージ―(1)―ビジネスロジック―(2)―プレゼンテーション

ここを流れるデータを分類する。
(1)は DTO<->ドメインモデル
(2)はドメインモデル->View用モデル(左から右のみ)

ドメインモデルをDTOと同じ構造にすることができるのは、
データストレージ層を新規に設ける場合のみ。
DBスキーマを新規にゼロから構築するケースがどのくらいあるだろうか。
ほとんどないのが実情だ。

ドメインモデルとDTOを一緒にしたいという方向から考えると、上記モデルとは矛盾する。
俺は上記モデルから考えるからこそ、ドメインモデルとDTOは一致しないという立場にたつ。

実際、(1)と(2)で別クラス(実際には別インタフェース)を作ってから実装させたことがある。
DB操作、ビジネスロジック、プレゼンテーションを綺麗に作業分担させられたよ。

635 ：デフォルトの名無しさん：04/10/17 11:44:16

>>628
> 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
> 前提に、ICONIXやくーすってあると思う。

くーすはそうかもしらんが、ICONIXはそんなこと言ってないと思うんだが?
Use Case Driven Object Modeling with UML(ユースケース入門)で読んだ知識しかないんだけどさ。

636 ：デフォルトの名無しさん：04/10/17 12:04:21

>>634
ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。

きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。

内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。

637 ：デフォルトの名無しさん：04/10/17 15:42:09

まず前提。Domain ObjectとDTOの相互変換はめんどくさい。

FowlerのPofEAAのService Layerの説明のところに確か
「DTO変換のコストを過小評価するな。オブジェクトのツリーが
深くなるとすげー辛い」みたいなことが書いてあったはずだ
(いま本が手許にないので正確な表現はわからん)。

俺も「Presentation層のコントローラ(この時はStrutsのAction)は
Service Layerを介してDTOを受け取り、Domain Objectには絶対
直接触らない」ってポリシーで設計したけど結局実装とテストが
やたらしんどくなって方針転換したことがある。

んで、DTO変換をしないとなると、Domain Object側に巻き込むか、
DTO側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。

# ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686 とか

ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。

# ひが氏はロングキャッシュは知らんとか言ってるけど。
# ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710

638 ：デフォルトの名無しさん：04/10/17 16:43:55

>>633
業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
　・業務ロジックを起動するための情報を収集する(=入力画面)
　・業務モデルに関する情報を提示する(=参照画面)

639 ：デフォルトの名無しさん：04/10/17 17:35:07

>>637
よくわかる説明だけど、わかるやつにしかわからんってなってるかも。

640 ：デフォルトの名無しさん：04/10/17 18:18:33

>>638
それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？

業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633
こっちの方が正しいんじゃない？

641 ：デフォルトの名無しさん：04/10/17 18:49:29

>>640
>>638の1行目を穴が開くまで読むべし。

642 ：デフォルトの名無しさん：04/10/17 18:56:47

>>641
穴があいたら、次はどうすればいいですか？

643 ：デフォルトの名無しさん：04/10/17 19:01:05

>>642
入るしかないでしょ。

644 ：デフォルトの名無しさん：04/10/17 19:52:07

入れるしかないよ。

645 ：デフォルトの名無しさん：04/10/17 20:19:25

入れるから穴があくんだろ。逆転してるぞ。

646 ：デフォルトの名無しさん：04/10/17 23:33:54

はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。

647 ：デフォルトの名無しさん：04/10/17 23:59:45

俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。

ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。

DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！

648 ：デフォルトの名無しさん：04/10/18 00:09:33

まったく同意。本当、からさわぎ楽しみ。

でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。

649 ：デフォルトの名無しさん：04/10/18 00:10:53

リファクタリングして説教して来いｗ
みんなが>>646に期待してるぞ

650 ：647：04/10/18 00:30:39

>>648
>やっぱファウラーの文章とか読むとワクワクするんだよね。

その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。

651 ：デフォルトの名無しさん：04/10/18 00:45:33

>650
ありがとう、なんか気が楽になりましたよ。

気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w

652 ：デフォルトの名無しさん：04/10/18 00:47:45

まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。

653 ：デフォルトの名無しさん：04/10/18 00:59:42

書籍代なんて誤差の範囲だよ。

プププ

654 ：デフォルトの名無しさん：04/10/18 02:34:48

結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?

655 ：デフォルトの名無しさん：04/10/18 02:46:23

>. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。

って、所詮2chか。S2にもフォーラムが欲しいな。

656 ：デフォルトの名無しさん：04/10/18 04:21:56

>>655
みんな各自のblogで満足してるから、実現性は低いね。

657 ：デフォルトの名無しさん：04/10/18 07:58:24

>>637
ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。

むきだしのドメインオブジェクトなら、画面では激しく使いづらい。

658 ：デフォルトの名無しさん：04/10/18 09:28:58

>>655MLじゃ駄目なの？

659 ：デフォルトの名無しさん：04/10/18 15:53:43

>655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？

はぶか？

660 ：デフォルトの名無しさん：04/10/18 16:07:11

「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」

文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。

661 ：659：04/10/18 16:08:44

どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません

662 ：デフォルトの名無しさん：04/10/18 18:00:26

じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。

663 ：デフォルトの名無しさん：04/10/18 18:56:32

納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。

664 ：デフォルトの名無しさん：04/10/18 19:08:31

> 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。

という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。

665 ：デフォルトの名無しさん：04/10/18 19:14:28

>>663
それははぶについてでなくて一般論だよね？

はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。

ほっときゃ本人があっちに書くか。楽しみにしていよう。

666 ：デフォルトの名無しさん：04/10/18 19:18:17

今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？

って、所詮2chかｗ

667 ：デフォルトの名無しさん：04/10/18 19:34:01

俺はそんなにスレ・板違いにも思えないんだな。

S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。

ムだのマだのでがっつり分けたがる方が
所詮2ch。

668 ：デフォルトの名無しさん：04/10/18 20:02:15

>>666
前向きもうしろ向きもなく、雑談。

669 ：デフォルトの名無しさん：04/10/18 20:03:18

マ板は、ネタスレ用隔離板ですよ。

670 ：デフォルトの名無しさん：04/10/18 20:04:47

現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。

671 ：デフォルトの名無しさん：04/10/18 22:29:15

ｽﾙｰしる

672 ：デフォルトの名無しさん：04/10/18 22:45:41

そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗

673 ：デフォルトの名無しさん：04/10/18 23:39:08

OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。

674 ：デフォルトの名無しさん：04/10/19 02:32:25

はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。

675 ：デフォルトの名無しさん：04/10/19 03:31:31

おお、すずめかあ。懐かしいなあ。

でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。

676 ：デフォルトの名無しさん：04/10/19 03:50:38

いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。

で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。

677 ：デフォルトの名無しさん：04/10/19 13:18:16

>673
そうだね。一応outer定義してinjectDependencyという手段はあるけど、
メリットのあらかたを享受できないからね。
DIを考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。

678 ：デフォルトの名無しさん：04/10/19 20:57:03

業務アプリケーションをそんなに急いで作りたいなら、一番確実な方法としては
「あらかじめ作る」しか無い。

つまり、業務アプリでEclipseみたいにプラグインで拡張可能なソフトを作ることだと思うよ。
（この設計は極めて難しいものになるだろうけど。）

679 ：デフォルトの名無しさん：04/10/19 20:59:44

業務アプリとはいえ、プラグインプログラミングをやらうとするなら、
ソース公開されていることは必須条件。別にGPLじゃなきゃだめというわけじゃないけど。
（ソース読まずにプラグインだけ作ることは無理だ）

680 ：デフォルトの名無しさん：04/10/19 21:23:49

>>678
StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。

681 ：デフォルトの名無しさん：04/10/19 23:15:00

この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？

682 ：デフォルトの名無しさん：04/10/19 23:31:44

3.14人くらい？

683 ：デフォルトの名無しさん：04/10/20 00:10:39

S2というか、そもそもJavaで実装すること自体やめたほうがいい

684 ：デフォルトの名無しさん：04/10/20 01:06:05

なんで？

685 ：デフォルトの名無しさん：04/10/20 01:27:24

Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。

686 ：デフォルトの名無しさん：04/10/20 01:29:31

S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。

何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。

# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。

くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。

687 ：デフォルトの名無しさん：04/10/20 01:41:00

スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。

688 ：デフォルトの名無しさん：04/10/20 02:04:06

S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。

所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。

689 ：デフォルトの名無しさん：04/10/20 06:33:55

>「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。

690 ：デフォルトの名無しさん：04/10/20 06:39:58

>>686
TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。

なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。

あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。

691 ：デフォルトの名無しさん：04/10/20 09:19:09

S2Quartz!!!
http://d.hatena.ne.jp/khi/20041020

692 ：太田＠会社：04/10/20 12:05:09

686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。

693 ：デフォルトの名無しさん：04/10/20 13:08:35

>>686
>2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆

694 ：デフォルトの名無しさん：04/10/20 19:20:59

比嘉氏・取り巻き・羽生氏ときて今度は若手か。
徹底的に人に絡んでくるな。

695 ：デフォルトの名無しさん：04/10/20 19:25:28

つうか、取り巻きって誰かが明示されてないし。

イタい取り巻きの例示きぼん>>686

696 ：デフォルトの名無しさん：04/10/20 19:26:14

s/取り巻き/若手

697 ：デフォルトの名無しさん：04/10/20 19:34:42

んなこといいけど、S2JSFって進んでるのかな？
なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。
S2JSFのためにS2のバージョンアップが必要なのだろうか？

698 ：デフォルトの名無しさん：04/10/20 19:48:08

S2JSFのためのS2.1化だろ。

699 ：697：04/10/20 19:49:30

う～～待ちきれない

700 ：デフォルトの名無しさん：04/10/20 20:04:00

そこでJSF-Springですよ

701 ：デフォルトの名無しさん：04/10/20 20:30:58

>>695
やめれ。これ以上個人名を出す必要はないよ。
比嘉氏や羽生氏はともかく他の人は関係ない。

702 ：デフォルトの名無しさん：04/10/20 23:09:40

ひがさんやはぶさんの名前を出す必要もないけどな
S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。

703 ：デフォルトの名無しさん：04/10/20 23:12:53

やっぱりからさわぎはくーすのトラックが人気なのかな？
俺もデザイントラックにしようかと思ったんだけど
くーすは本が出るからそっち読むとして
今回はビジネストラックにしようかなとも思って。
マジカ面白かったし。

704 ：デフォルトの名無しさん：04/10/21 00:08:30

S2JSF いつ頃だろうか。
前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz

705 ：デフォルトの名無しさん：04/10/21 00:11:39

>>704は>>700に助けてもらえ

706 ：デフォルトの名無しさん：04/10/21 00:33:30

今のうちにS2に乗り換えてしまくて。
WW2かTapestry試そうかと思ったが、本命はS2JSFなんだよな。
タイミング的に微妙.....

707 ：デフォルトの名無しさん：04/10/21 00:52:05

何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。
そんな２７歳の秋。

708 ：デフォルトの名無しさん：04/10/21 01:22:30

この板以外、どこのブログ見りゃいいんじゃいの？押さえどころ

709 ：デフォルトの名無しさん：04/10/21 02:45:56

ドメインロジックとSQL
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

くーすマンセーな人は、一度↑を読んでみて欲しい。
それで、TransactionScriptと DomainModelの長所短所を理解した上で
TransactionScriptを使っていただきたいなー。

710 ：デフォルトの名無しさん：04/10/21 06:08:00

大田@会社さんへのレスというわけではないのだけど。

>>692
> 理想は，でも現実的には，だったらどうしたらよい
> という前向きな人たちの集まりだと思うのだけど。

傍から見てると
「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
って言っているように見えちゃうのは俺だけ?

# TransactionScriptが最適解である状況が存在することは否定しないけどさ

711 ：710：04/10/21 06:19:20

間違えた。
以下のとおりに修正。

>ひがさんとはぶさんを傍から見てると
>「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
>って言っているように見えちゃうのは俺だけ?

712 ：デフォルトの名無しさん：04/10/21 09:08:50

はぶ氏がRDB大好きだというのはblog見てるとわかる。
ひが氏はもう少しニュートラルというか使いやすい
ORマッピングを考えてのことなんじゃないかな。
ふたりともTransactionScriptマンセーというのとはまた違う気がする。
ER分析マンセーなのかも知れないが。

713 ：デフォルトの名無しさん：04/10/21 10:03:23

RDBをRDBとして使う限りにおいては、ER分析マンセーみたいね。
俺も同意。つーか当たり前だと思う。

RDBをただのストレージとして使うやり方は俺には合わんかったんでｼﾗﾈ。

714 ：太田＠会社：04/10/21 10:37:12

710さん>
幻想というより西方浄土でしょうか。ひがさんにダイレクトに聞いてみると分かりますが，
TransactionScriptマンセーじゃないですね。僕も今は教育側にいるときがありますけど，
理想のOOA/Dは現時点ではあまりに属人性がありすぎて，Martin Folwerのいる会社のような
よほどつわものがそろった組織でないと難しいです。つわものがそろっていれば，理想の
OOA/Dも不可能ではないと思います。

>http://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL

既読です。読書会でも話題になりました。これをたたき台にして，トレードオフについても
かなり議論になりました。理想のOOAD対ER分析というよりはメンテナンス性対パフォーマンス
というところでしょうか。

715 ：デフォルトの名無しさん：04/10/21 11:11:11

単に選択の問題であるだけでしょう。

私が今携わっているプロジェクトでは業務ロジックがさほど多くなかったので、
Springを使ったTransactionScriptな設計にしてありますが、
明らかにサービス層の肥大化が予想される場所にはDomainModelを適用しています。
別にどちらが正解であるということもありませんが、OOエキスパートが少ない
環境ではTransactionScript寄りになってしまうことは避けられないでしょうね。

ちなみにくーすはTransactionScriptの発展的なアプローチだろうと思います。
ひがさんは否定しておられるようですが、サービス層と永続化層を分離した
パターンの中で、大別して上記２つ以外に思いつくものはありません。
というか何がどう違うのかもうちょっと説明して欲しいかも。

Entity層にビジネスロジックを含めないって時点で、少なくとも
DomainModelではないし。

今日は風邪で休んでるんで自宅からカキコ。
直に書きに行こうかともおもったけど私なんかの出る幕はではなさそうだし、
この場で失礼。

716 ：デフォルトの名無しさん：04/10/21 11:15:59

ビジネスロジックって表現がそもそも曖昧だよな

717 ：715：04/10/21 11:24:03

>>716
> ビジネスロジックって表現がそもそも曖昧だよな
そうかも。

私の中では一連の"業務仕様"ってところで理解してます。
売上げ本数の計上ルールとか？いい例えが思い浮かばん。

永続化処理とか、メールやCSV取込とかはビジネスロジックとは
呼べないでしょうね。

718 ：715：04/10/21 19:00:45

本当に答えて貰ってたんで、ちょっと感激してしまった。
私自身、2chにもカキコすることなんて滅多にないから。

なるほど。
というところですが、時間があればひがさんにもPofEAAの一読をお勧めしたいです。
文章を読む限り、原書の方にはまだ目を通されていないような印象でしたので。

リッチなSQLはDomainModelにもTransactionScriptにも適用されます。
そこでの問題はロジックがSQL内に分散することですが、これがパフォーマンスとの。
トレードオフだと言っているわけで、それはDomainModelにしろTransactionScriptにしろ
同じことです。

ところで、このスレのちょっと上のあたりでDomainModelとDTOとの相互変換云々って
話で盛り上がってたようですね。
私はよく、DomainModelをDTO(テーブルと同じ構造)を内部に複数持ち、
各層に公開するインターフェースを実装したオブジェクトとして定義することがあります。
というか大体これです。
相互変換の必要がないインチキ手抜き設計なので、当然無駄なプロパティや処理が
増えることになりますが、要の部分はインターフェースを介して隠蔽されているため、
実際に問題になるような事は滅多にありません。
Springの各種DaoSupportやS2Daoもそのままの形で適用出来ます。まあ参考までに。

純粋なDomainModelはO/RMapperの発展に合わせて、今後少しずつでも浸透して行くでしょう。
と願ってみる(希望的観測)

719 ：デフォルトの名無しさん：04/10/21 20:37:11

結論：OO厨は邪魔なだけ。

720 ：デフォルトの名無しさん：04/10/21 21:44:57

ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。

721 ：デフォルトの名無しさん：04/10/21 22:00:20

ここんところの話が英単語ばっかりでよくわかんにゃい。

くーすの考え方の肝ってどっかに載ってる？
「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。

OOは部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。
自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が１人いただけで設計が崩壊しかねない。
それが自分だったりして鬱になる。

例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、
芸が無いグラマンでデスマから生還したほうがいい。

722 ：デフォルトの名無しさん：04/10/21 22:14:52

その例えだと、グラマンはいかにも燃費が悪い。
ぜいたくに出来た飛行機だと松本零二も言ってます
↑
ここ笑うところ

723 ：デフォルトの名無しさん：04/10/21 22:58:25

>>721
その、グラマンたるライブラリがSeasar2なんだよ！

POJO書いて、設定ファイルを書くだけ。
S2で欲しい機能があれば、はてなでｷﾎﾞﾝﾇするだけでOK。

724 ：デフォルトの名無しさん：04/10/21 23:48:09

ひが氏にお願いです。
商用サポートもドキュメント見直しもFlexも
くーす本もからさわぎも全部後回しでいい。
頼むからS2JSFを早く出してください。おながいします。

725 ：デフォルトの名無しさん：04/10/22 00:28:45

>>724

S2JSF ＞くーす本＞＞＞＞＞＞その他

726 ：デフォルトの名無しさん：04/10/22 00:41:18

開発するより宗教論争が好きな人って結構いるね。

727 ：デフォルトの名無しさん：04/10/22 00:52:30

2chに書いてるﾔｼなんざ大抵そうだな

728 ：デフォルトの名無しさん：04/10/22 01:04:27

つか、2ちゃんだから出来るんだよ。
現場でやる奴よりは全然いい。

大体宗教論争ってのは、スプーンに天使は
何人乗る事が出来るかとか
そういうアホで無意味な事を議論する事で、
ここでの話はわりと意義はあると思うよ。

729 ：デフォルトの名無しさん：04/10/22 01:04:56

>>726
開発なんかするより他人を論破することが楽しいですが何か？

730 ：デフォルトの名無しさん：04/10/22 01:20:59

>>729
hub。

731 ：デフォルトの名無しさん：04/10/22 01:32:03

>>721

> ここんところの話が英単語ばっかりでよくわかんにゃい。

http://www.martinfowler.com/eaaCatalog/

> くーすの考え方の肝ってどっかに載ってる？
> 「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。

http://www.wikiroom.com/tpircs/?cmd=read&page=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1&word=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1

732 ：デフォルトの名無しさん：04/10/22 01:45:02

ttp://d.hatena.ne.jp/higayasuo/20041021#1098336935

うそーん。ぜんぜん問題わかってないじゃん。

だまされたと思って一回原典読んでみてください。お願いします。

733 ：デフォルトの名無しさん：04/10/22 01:51:36

ttp://d.hatena.ne.jp/higayasuo/
> 良く使われると思われるドキュメントを見直しました。
> すべて、概要、リファレンス、Exampleの3部構成になっています。
> どうでしょう。2chの人

おぉ、こぎれいに、丁寧になってる。
くるしゅうないぞよ。

あとは、www.seasar.orgにそういった改変情報が載るようにすることですね。
それから、ソースと実行結果はスタイルを変えたほうが。
実行結果は黒地白文字とか。

734 ：デフォルトの名無しさん：04/10/22 02:04:34

733のような奴の言うこと真に受けて、がんばってらっしゃる。
ひがさん、尊敬します。
733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動くプログラムを作ることすらできないですから。残念！

735 ：デフォルトの名無しさん：04/10/22 02:17:22

>>734
> 733のような奴の言うこと真に受けて、がんばってらっしゃる。
> ひがさん、尊敬します。

>>733って、文体は2ch的で一見失礼だけど、ひが氏のモチベーション向上+
前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。

> 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、
> ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動く
> プログラムを作ることすらできないですから。残念！

こういう非生産的なラベリングはやめようよ。つーわけで>>733気にするな。

って、>>733の自演扱いされるのがオチか。

736 ：デフォルトの名無しさん：04/10/22 02:19:11

>> バウンダリで、直接ドメインオブジェクトを使うのも、かなり困難だと思います。
これって理由は何でだっけ？

737 ：デフォルトの名無しさん：04/10/22 02:35:11

>>735
>ひが氏のモチベーション向上+
>前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。

ドキュメント的には、「今の段階で」十分すぎるほど揃ってると思う。
日本語ということも含めると、他のオープンソースプロジェクトなんかより
断然素晴らしい。

失礼な文体、普通はモチベーション下がるって。成果物改善支援？大きく出たな。
物は言いようか。好レス？？笑けた。ネタ？

738 ：733：04/10/22 02:37:38

>>735
ありがとー。
あーだこーだ言うだけ言って、作業に手は貸さないわけだから、そこに対して改善が図られた場合には、ちゃんと気づいて反応するようにしてるです。

739 ：デフォルトの名無しさん：04/10/22 02:40:58

「今の段階で」というなら、「揃っている」じゃなくて「揃った」、の方があてはまるんじゃねぇの？

740 ：デフォルトの名無しさん：04/10/22 02:50:08

>>736
あとで仕様変更があってバウンダリとドメインオブジェクトの間にロジック（サービス）を
挟まなくちゃいけなくなった時に困るからじゃなかったっけ。

741 ：デフォルトの名無しさん：04/10/22 03:06:07

「今の段階としては」だな。

742 ：デフォルトの名無しさん：04/10/22 06:11:18

http://d.hatena.ne.jp/higayasuo/20041021#1098310525
> リソース層にRDBMSを使う限り、SQLの知識は必須です。
> デザインパターンやP of EAAの習得には熱心だけど、
> SQLには興味ないなんて人がいるなら、知識のバランスに
> かけてます。

http://d.hatena.ne.jp/habuakihiro/20041021#1098369060
> JSPバリバリですぅ～。でもServletはわかりませ～ん。ってのと、
> ORマッピングツールバリバリですぅ～。でもSQLはわかりませ～ん。
> っていうのは、似たり寄ったりだと思うんだが、

お二人とも勘違いなさっているようですけど、
DomainModelを推している人たちは

「SQLが分からないから使わない」

んじゃなくて

「SQLにビジネスロジックを入れたくないから使わない」

んです。

RDBMSを使っている限りはSQLの知識が必須なのは当然でしょう。

743 ：デフォルトの名無しさん：04/10/22 06:50:50

>>732
問題と思うことをきちんと指摘したら。
人にいわれる本を全部読むような時間のあるひとはいないだろ。

744 ：デフォルトの名無しさん：04/10/22 07:09:24

>742
推している人たちって誰のこと？
DomainModelいいよ！って言ってる人全部ってわけじゃないでしょ？

SQL書きたくないから～って人は確実にいる（何人か知ってる）し、
そういう人を想定して言ってるんじゃないかな。
SQLばっちり分かっててかつDomainModelを推してる人よりは多いと
感覚的には思うが、どうだろね。

745 ：デフォルトの名無しさん：04/10/22 07:52:08

>>742
DomainModelを推している人は、
「SQLが分からないから使わない」
と思っているとは、書いてないと思うけど。

それは、被害妄想。

746 ：デフォルトの名無しさん：04/10/22 08:27:37

>>735
我田引水

747 ：デフォルトの名無しさん：04/10/22 08:30:03

>>742
なあビジネスロジックって何？
ほんとにわかんねえんだよ。
SQLで平均とか一発で出せても
使うなってことか？平均何とかも
ビジネスロジックだと思うんだけど。

748 ：デフォルトの名無しさん：04/10/22 08:34:15

何でこのスレはageる人が多いんだ？

749 ：デフォルトの名無しさん：04/10/22 09:00:30

>>732
ひがたんはそんなの読まなくてもいいからS2JSFを先に作って欲しい。
正直漏れはくーすはどうでもいい。便利な道具としてのS2が気に入ってるんだ。
もしひが氏が真面目に原典とやらを読んだ結果S2JSFのリリースが遅れたりしたら
>>732ぬっころす

750 ：デフォルトの名無しさん：04/10/22 09:20:50

そこまで粘着すると、キモいね。

751 ：デフォルトの名無しさん：04/10/22 09:32:31

2chに書いてるだけでキモいけどね
とりあえずこのスレは粘着のスクツということでFA

752 ：デフォルトの名無しさん：04/10/22 10:35:49

>>747
そういうことみたいだな。

複雑な会計の帳票とか出すとき
どうするんだろうって思うよ。

UNIONとかFROM句にサブクエリとか
ガンガン書いてやっとまともなレスポンスで
出るようになる帳票とか山ほどある。

だからS2Daoは、最初見たとき霧が晴れた気分でした。

753 ：デフォルトの名無しさん：04/10/22 10:42:12

ドキュメントがいくつか更新されたみたいです。
・DIContainer
・AOP
・テスト技法
・S2DAO
の4項目かな？

どこの項目が更新されたかわかるように印をつけて（updateとかnewとか）
くれるとありがたいなあ･･･

754 ：デフォルトの名無しさん：04/10/22 10:59:46

>>753
>>733で既出。そこのブログにリリースノートが。

755 ：デフォルトの名無しさん：04/10/22 11:02:18

>>754=>>733様

756 ：753：04/10/22 12:41:35

ぐあっ・・・ほんとだ　orz
駄ﾚｽでした。重複ｽﾏｿ

757 ：デフォルトの名無しさん：04/10/22 14:05:19

>>732

>だまされたと思って一回原典読んでみてください。お願いします。

オマエが騙しそうだなー

>>742
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
読んでみたんだけどなー

> 「SQLが分からないから使わない」
>
>んじゃなくて
>
>「SQLにビジネスロジックを入れたくないから使わない」
>
>んです。

リッチなSQLの例が、SQLの入門書レベルだからなー
勉強したくないだけだろうと思われても仕方が無いなー
VB厨でもPHPerでももっと複雑なSQLを普通に書くと思うなー

>>752
そうだなー
PoEAAが具体的にどういうシステムを想定しているのかを知りたくなるなー

758 ：デフォルトの名無しさん：04/10/22 14:25:16

>>757
> リッチなSQLの例が、SQLの入門書レベルだからなー

同意

759 ：デフォルトの名無しさん：04/10/22 15:02:33

SQLの中身については、いやまあサンプルって事で。

それいったら、過去実績である注文データに対して
ディスカウントキャンペーンを適用するようなつくりになってて
蓄積された実績を何時でも恣意的に改変できる形になってるじゃん。

注文ってエンティティの構造は捉えられていても
その意味というか本質というか、全然考慮されてない。
その理由は、勿論サンプルだから、でしょう。

まじボケだったらファウラー、おちゃめさんです。

つっこみ始めたらきりがないから、ここは
「SQLに業務ロジックを入れる」って事のだけ
見ればいいよ。

760 ：デフォルトの名無しさん：04/10/22 15:42:20

>ただ、アプリケーション開発者はこれくらい複雑なだけでも避けちゃうんだよね。

これくらい↓
複雑↓

SELECT DISTINCT MONTH(o.date) AS month
FROM lineItems l
INNER JOIN orders o ON l.orderID = o.orderID
INNER JOIN customers c ON o.customerID = c.customerID
WHERE (c.name = ?) AND (l.product = 'Talisker')
GROUP BY o.orderID, o.date, c.NAME
HAVING (SUM(l.cost) > 5000)

確かにおちゃめだ。Fowler氏自身はSQLを使いこなしているようだが。
このレベルを避けちゃうようなﾔｼと仕事してるのかと思ったら不憫に
感じるというか親近感が湧いたYO

761 ：759：04/10/22 15:54:39

一人いたな、簡単なJOINのSQLでも
全部Accessで作ってからちょこちょこ直す人。

結構経験あって、Win32APIとかすごく詳しかったけど、
業務系はあまりやってこなかったみたい。
帳票のSQLとかほとんど俺が書いて、メールで渡してたなあ。

しかもその人がテーブル設計やったもんだからもう、
俺も不憫に思ってくれい。

そのSQL書ける人が書いてメールで渡すってのを
メール経由でコピペとかじゃなくて、
きちんと組み込めるのがS2Daoな訳ですな。

762 ：デフォルトの名無しさん：04/10/22 15:55:38

・・・普通の集計にしか見えんのですが。

763 ：デフォルトの名無しさん：04/10/22 16:11:53

その普通の集計をわざわざコードでやるがいいと
おっしゃっておるのでつよ。

これがリッチSQLなのでつ。リッチクライアントも決して

普通のVBの画面にしか見えんのですが。

などといってはいかんのでつ。

764 ：デフォルトの名無しさん：04/10/22 16:25:34

しょぼいSQLで済むことにあれだけコード書くようだと
複雑なクエリーが必要な場合にどれだけコードを書くんだ？
いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ
あるかないかわからない移植のことを考えるよりもさっさと作って
リリースするほうが重要なんじゃないか。いるものだけ作るという
原則に反している気がする

765 ：デフォルトの名無しさん：04/10/22 16:39:18

つまりあれだ。
S2Daoﾏﾝｾｰってことだな。

766 ：デフォルトの名無しさん：04/10/22 17:14:54

だな！

767 ：デフォルトの名無しさん：04/10/22 21:55:24

>>763
> リッチクライアントも決して
> 普通のVBの画面にしか見えんのですが。
> などといってはいかんのでつ。

比較対象がHTMLフォームだから。

768 ：デフォルトの名無しさん：04/10/22 21:58:01

あのドキュメントは社員さんが書いたのか。
サイトの運営も社員さんにやってもらったほうがいいね。
なんにしろ、組織的なサポートは心強い。

769 ：デフォルトの名無しさん：04/10/22 23:55:07

>ビジネスロジックとは
意味わかんね。
だれかかいつまんで説明して

770 ：デフォルトの名無しさん：04/10/23 00:39:25

>>764
問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。
とくに問題になる点は
・更新性「EAはこれからめちゃくちゃ変わる」
・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
だろう。
まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。

771 ：デフォルトの名無しさん：04/10/23 00:50:40

結局規模が違えば考え方も違うってことだね。
もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。

772 ：デフォルトの名無しさん：04/10/23 00:57:52

>>770
EAはむちゃくちゃ変わるってのは
日本で業務系に携わってても
正直そこまで実感が湧いてこないんですが

それは私の経験不足と言う事でさておいて

大体リッチなSQLを使う所って、経営分析データだとか
会計帳票とかになりますよね。
そういう所はEAとかいう部分と関係なくて
逆に安定しまくっとる所なわけで、
そこにSQL一発ですむものを複雑なコーディングに
置き換えるのはやはり気がひけます。

やっぱりいいとこどりが一番って事でしょう。
議論としちゃつまらん結論ですけどのう。

773 ：デフォルトの名無しさん：04/10/23 01:35:27

全体を捉えた議論の結論としては
「やるべきことをやる、使うべきところで使うべきものを使う」
ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？
つまり、その手法のメリットデメリットはなにか、と。
マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？

774 ：デフォルトの名無しさん：04/10/23 02:33:35

775 ：デフォルトの名無しさん：04/10/23 03:05:17

S2JSF間近aga!!!

776 ：デフォルトの名無しさん：04/10/23 03:07:08

>>770

> ・更新性「EAはこれからめちゃくちゃ変わる」

だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？

> ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」

データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？

云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。

777 ：デフォルトの名無しさん：04/10/23 03:51:27

ファウラーのblikiを翻訳してる方によると
やはり日本とアメリカの事情の違いってのがあるそうで、
日本にくらべてあっちはアプリ開発とDB開発の分業が
相当徹底されているらしいですね。

で、

> ・カプセル化「ビジネスロジックを担当するコードが
>データベース設計変更時に影響を与えられることはない」

ってのは、776の言う通り、設計変更っていや
ビジネスロジックの変更の事だろう、って気分に私もなりましたが
もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ
と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。

あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら
うそつけバーカとか書いちゃって下さい。

あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、
やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。

778 ：デフォルトの名無しさん：04/10/23 04:00:15

773の意見にまったく同意です。

でもまあ、総論みたいな所も、答えは「いいとこどり」に
落ち着く事は判っていても、喧々諤々やっといた方が
いいと思うんですよ。

その事で、双方の「いいとこ」の範囲が、
前より広く感じられて来たりしたら良いと思うし。

ここ、読んでて大変面白いですよあたしゃ。
2ちゃんのOO関連スレじゃ一番じゃないですか？

779 ：デフォルトの名無しさん：04/10/23 04:13:28

関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。
結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。

780 ：デフォルトの名無しさん：04/10/23 04:49:47

言語とRDBMSと、どちらが変更される可能性が高いか。
どちらとも言えんと思う。

言語が変わる場合：
C/S からWEB系への移行
Unixに乗り換えで、ASPからJavaへ移行

RDBMSが変わる場合：
パッケージもの。お客様によってRDBMSが異なる
辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。

他にどんな場合があるかな？

781 ：デフォルトの名無しさん：04/10/23 05:18:03

言語は変わる場合より併用の方が多いんじゃないかな。
たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
# 実際はサーブレット呼び出すようにしてJavaで処理させたりするが。James？なにそれ。ｗ
部分的にPHPで組むことも考えられる。

RDBMSで言えば、最初はPostgreSQLで運営してたけどサービスが成長したからOracleに移行とか。
Windows上のSQLServerで運用していたけど、大人の事情でUNIX使うことになって、Oracleへ、とか。
PostgreSQL→Oracleのようなスケールアップはありがちなんじゃないかと。
逆に、移行しやすいように作っておくことを前提に当初はPostgreSQLで運用開始とか。

782 ：デフォルトの名無しさん：04/10/23 09:23:30

>>781
> たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか

いろんな言語を組み合わせるのはどうにも気持ち悪い。メンテナンスしづらいでしょ。
開発環境そろえるのに時間かかりそう。環境によってあーだこーだ言うのは最悪。
バージョンがこうだとか、ディレクトリ構成がこうだとか。ウザい。

シンプルが一番。
アプリケーション毎に常駐プログラム作ってそこでデータベースなりメールの処理するとかするでしょ普通。
ポータビリティが重要だと思う。
CVSのモジュールを引っ張り出すだけで自前の環境でシステムの自動テストができるような単純さが開発では重要。

加えると、Javaって面倒だ。
全部スクリプトで作ってしまえばいいと思うのだが。

783 ：デフォルトの名無しさん：04/10/23 11:13:19

>>777
だからコミュニケーションの重要性が
日本以上に言われるのかな＞分業の徹底

784 ：デフォルトの名無しさん：04/10/23 11:40:46

>>783
うん、そうみたいですね。
blikiの翻訳者さん、こんなのも翻訳してまして
tp://capsctrl.que.jp/kdmsnr/wiki/agiledata/
ここみると、「なぜ一緒に働くことが現在困難なのか」とか
なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、
日米の文化の違いはかなりのもんの様です。

でもアメリカさんだから、ジョークというか
比喩かも知れないですけどね。

785 ：デフォルトの名無しさん：04/10/23 11:47:58

seasarの良いところがいまいち分からんなー。

インターフェース書いて、ダイコンファイル書いて
ってめんどくせーって思っちゃう。
サービスに新しい機能付けようと思ったら、インターフェース
とImplクラスの２つを変更しなきゃいけないし。
インターフェースはImpl挿げ替えるだけで、動きを変えられるって
メリット（多態性）で使うんであれば良いし、よく使うんだけど
seasarのためにインターフェースガンガン書くって気にはどうも慣れん。

ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。

漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？
なので私はseasar使うようになったよ」って意見を聞きたいです。
あとEJBはseasarよりさらにダルイっておもっとる。

786 ：デフォルトの名無しさん：04/10/23 11:59:55

別に無理してまでインターフェース用意することも無いでしょう。
必要に迫られたときにインターフェースを抽出することは
IDEなんかのツール使えば一瞬で出来るんだし。

787 ：786：04/10/23 12:01:40

ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。
不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。

788 ：785：04/10/23 12:21:54

レスありがとう。

>別に無理してまでインターフェース用意することも無いでしょう。
seasarってインターフェース必須ではないんだー。誤解してました。

>不必要なメソッド呼び出しを隠蔽できたり、
これは、漏れのやる仕事のに依存してるのかもしれないけど
APIのようなクラスを作るときは、隠蔽って重要だと思います。
でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に
出くわさないんですね。

>Mock使ったテストが容易になったり。
これはもう少し詳しく聞きたいです。seasarのドキュメントにも
テストが容易って書いてありますが、EJBに比べてって事ですか？
struts+Hibernateでテストしにくいって感じた事無いんですよね。

789 ：デフォルトの名無しさん：04/10/23 12:28:07

>>785
seasarというより、インターフェースと実装を分離するということは、
OOの重要な部分だと思うけど、分業するときに、
インターフェースを先に決めておけば、実装が追いつかなくても、
Mockとかを使って作業を並行して進められるというメリットがあるね。

実装クラス同士が直接依存しあうことが少なくなるから、
個々のクラスの個々のメソッドを単独で実装・テストしやすい。
直接依存してると、依存しあっている部分を全部コーディングしないと
テストできないから。

790 ：デフォルトの名無しさん：04/10/23 12:32:00

>>788
ふだん、どんなテストしてるの。

791 ：785：04/10/23 13:10:24

>>789
>Mockとかを使って作業を並行して進められるというメリットがあるね。
でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも
同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら
インターフェースがある方ですが。。。

>依存しあっている部分を全部コーディングしないと
>テストできないから。
うーんseasarもダミーの実装をダイコンファイルに書いてるだけ
なんだよなと。Implクラスにダミーの戻り値を書いておく方が
楽と感じてます。

>>790
普段は下層のDAOから実装していくって感じなんで
（階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。
サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。
相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。
他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。

792 ：デフォルトの名無しさん：04/10/23 13:34:02

>>791
それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。

でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。

あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。

ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。

793 ：デフォルトの名無しさん：04/10/23 13:57:33

まさか、自動テストの一括実行をやってないとか。

794 ：785：04/10/23 14:32:12

>>792
ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。

その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。

>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。

上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。

795 ：デフォルトの名無しさん：04/10/23 14:38:34

>自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？

796 ：デフォルトの名無しさん：04/10/23 16:59:16

デバックってゆうな～

797 ：デフォルトの名無しさん：04/10/23 18:00:15

>おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。

モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。

ちなみにdebugなんでデバッ"グ"

798 ：デフォルトの名無しさん：04/10/23 18:24:12

OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。

新参者は空気を読め、空気をという話である。

799 ：785：04/10/23 18:58:14

デバッグですね。お恥ずかしい。。。

>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。

逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ　

800 ：デフォルトの名無しさん：04/10/23 19:10:45

>>798
何のコピペ？

801 ：デフォルトの名無しさん：04/10/23 19:36:39

はぶ氏もひが氏もここの話題に反応してくれてますな

っと、話ふり逃げに思われると残念なので書いとこう

802 ：デフォルトの名無しさん：04/10/23 21:45:01

>>800
これだろうな。
ttp://d.hatena.ne.jp/hyoshiok/20041022

803 ：デフォルトの名無しさん：04/10/23 22:08:24

ttp://d.hatena.ne.jp/akon/20041023#p2

こんな未来は嫌だ。

804 ：デフォルトの名無しさん：04/10/23 23:03:29

どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。

805 ：デフォルトの名無しさん：04/10/23 23:05:49

> Stateless BusinessLogicパターンのメリット
> ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617

上記サイトの内容で疑問点がありまして。

ひがさんは

「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」

と仰っています。

ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。

このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。

806 ：デフォルトの名無しさん：04/10/23 23:27:38

>>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。

807 ：785：04/10/23 23:35:51

>>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。

よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。

でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。

808 ：デフォルトの名無しさん：04/10/23 23:44:01

statelessって「実装に依存しない」って意味なんじゃないですか？

依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。

stateless
【形-1】国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっかとうちけん｝］のない
【形-2】《コ》処理状態｛しょりじょうたい｝を把握｛はあく｝しない～◆【対】stateful

って辞書にあるそのまんまの意味だとばっかり思ってました。

809 ：デフォルトの名無しさん：04/10/23 23:48:50

http://d.hatena.ne.jp/higayasuo/20040805#1091664617

810 ：デフォルトの名無しさん：04/10/23 23:51:34

>>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？

> 処理状態｛しょりじょうたい｝を把握｛はあく｝しない

そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ

811 ：デフォルトの名無しさん：04/10/23 23:52:33

>>808
かなり根本から間違ってるな。State が lessなんだぞ。

812 ：デフォルトの名無しさん：04/10/23 23:57:32

>>808
SLSB/SFSBの違いを思い出せ。

813 ：デフォルトの名無しさん：04/10/23 23:58:14

オブジェクトが状態をもたない。

814 ：デフォルトの名無しさん：04/10/23 23:59:14

class Foo {
int s;
int method(int x);
}
があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく
sの値にも依存すればstatefulで、
xの値のみに依存すればstatelessなんじゃね？

だから
＞Statelessといっても、すべてスタティックメソッドにすれば良いという
っていうことになるんだと思ったけど

815 ：デフォルトの名無しさん：04/10/24 00:01:29

>>814
statelessでもポリモフィズムは使いたい。

816 ：デフォルトの名無しさん：04/10/24 00:03:16

>>814
>すべてスタティックメソッドにすれば良いという

ポリモーフィズムが使えるところが違うっていうところだな。
システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。
これやるとプログラマのシステムの意図の理解に役に立つし。

817 ：805：04/10/24 00:07:34

>>807
> >>805
> ステートSがオブジェクト変数だとMaかMbからのみ変更される
> って事だからだと思うよ。
> ステートSをクラスの外に出すと、MaやMbはステートSに依存
> はするけれど、MaとMbの依存関係は無くなるんだね。

そうかな?

「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」
なら
「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」
と言えると思うんだよね。

818 ：デフォルトの名無しさん：04/10/24 00:09:28

>>804
ポインタ希望

819 ：785：04/10/24 00:33:53

>>817
じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
いないのに、MbはMaに依存しているっているって言える？
あくまでステートSに依存しているだけだよね。

あとは、ステートSの場所についてだけどこれは　>>813
って事だね。

820 ：805：04/10/24 00:37:11

メソッドの処理がステートに依存するクラスの例として
以下のクラスがあったとする。

class File
void open();
void close();
int read();
}

これが以下のようにStatelessになったところで
open、close、readの依存関係がなくなったとは言えないと思うんだよね。
例が悪いのかな?

class File {
void open(FileState state);
void close(FileState state);
int read(FileState state);
}

821 ：デフォルトの名無しさん：04/10/24 00:47:37

だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。

810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。

状態を持たないだと判りにくいか、
状態の変化を管理しない。

S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。

結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。

822 ：デフォルトの名無しさん：04/10/24 00:47:53

ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。

この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。

823 ：デフォルトの名無しさん：04/10/24 00:50:36

ああでもよくわかんねぇ

824 ：デフォルトの名無しさん：04/10/24 00:50:40

class File {
static int read(String filename, int position);
}
これは？

825 ：デフォルトの名無しさん：04/10/24 00:52:15

なんか俺も混乱してきたのでひがさんきぼんぬ

826 ：デフォルトの名無しさん：04/10/24 00:54:09

ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。

あ、821=823です、
まぎらわしくなっちゃってすみません>822

827 ：デフォルトの名無しさん：04/10/24 00:54:10

>>820
オブジェクトをステートレスにしろって事じゃないの？

下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。

上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。

828 ：785：04/10/24 00:58:40

>>820
何に対して、誰から見るとStatelessなのか、Statefullなのか
って事だよー。
上のFileクラスは、使う側から見るとopen、close、readのメソッドが
Statefullなんだけど、下のFileクラスは、引数のstateに対して
statefullであって、open、close、readの関係はStatelessだよ。

ようは、stateだけ考えてれば、良いって事。

ん？漏れはコアなseasar利用者じゃないんだが。。。
モンキーターン見てくる

829 ：805：04/10/24 01:00:19

>>819
> >>817
> じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
> Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
> いないのに、MbはMaに依存しているっているって言える？
> あくまでステートSに依存しているだけだよね。

今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。
Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。

へんなこと言ってるかな?

> あとは、ステートSの場所についてだけどこれは　>>813
> って事だね。

そうです。

830 ：805：04/10/24 01:05:18

>>828
> >>820
> 何に対して、誰から見るとStatelessなのか、Statefullなのか
> って事だよー。
> 上のFileクラスは、使う側から見るとopen、close、readのメソッドが
> Statefullなんだけど、下のFileクラスは、引数のstateに対して
> statefullであって、open、close、readの関係はStatelessだよ。
>
> ようは、stateだけ考えてれば、良いって事。
>
> ん？漏れはコアなseasar利用者じゃないんだが。。。
> モンキーターン見てくる

混乱させてごめんなさい。
レスは、今日はもう寝ちゃうので、また明日以降に。

831 ：デフォルトの名無しさん：04/10/24 02:51:26

ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。

832 ：デフォルトの名無しさん：04/10/24 03:14:28

ドメインモデル->実世界の構造のウツシミ

833 ：デフォルトの名無しさん：04/10/24 03:17:11

結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。

834 ：デフォルトの名無しさん：04/10/24 03:20:59

モデリングの本とかで問題領域とかいわれてる部分。

簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。

835 ：デフォルトの名無しさん：04/10/24 03:23:09

あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。

836 ：デフォルトの名無しさん：04/10/24 03:44:42

なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。

837 ：デフォルトの名無しさん：04/10/24 04:01:43

児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。

釈然としない所もあるけどさー。

838 ：デフォルトの名無しさん：04/10/24 04:08:57

> 釈然としない所もあるけどさー。

どういうところ？

839 ：デフォルトの名無しさん：04/10/24 04:19:41

2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。

でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。

こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？

840 ：デフォルトの名無しさん：04/10/24 04:30:49

>>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。

その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。

841 ：デフォルトの名無しさん：04/10/24 04:32:09

>>839
マジカの出番かな？

842 ：デフォルトの名無しさん：04/10/24 04:59:47

マジカ？

843 ：デフォルトの名無しさん：04/10/24 05:01:25

>>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。

844 ：デフォルトの名無しさん：04/10/24 10:31:16

結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。

845 ：デフォルトの名無しさん：04/10/24 10:48:45

Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。

ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。

S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。

>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。

この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。

846 ：デフォルトの名無しさん：04/10/24 10:58:45

>>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。

847 ：デフォルトの名無しさん：04/10/24 11:00:29

>>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。

848 ：デフォルトの名無しさん：04/10/24 11:04:19

>>846
俺は>>845じゃないけど

「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した

っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。

849 ：デフォルトの名無しさん：04/10/24 11:11:58

ttp://nekop.programmers.jp/diary/?date=20041024
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz

850 ：デフォルトの名無しさん：04/10/24 11:12:46

>>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。

851 ：デフォルトの名無しさん：04/10/24 11:18:07

>>849
うちの会社の競争相手は中国人 orz..

852 ：デフォルトの名無しさん：04/10/24 11:25:51

>>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。

853 ：デフォルトの名無しさん：04/10/24 11:26:46

先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz

854 ：デフォルトの名無しさん：04/10/24 11:47:18

>794

>>漏れ的には、迷ったらメンバーで相談する。

これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。

そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。

855 ：デフォルトの名無しさん：04/10/24 11:53:57

段々と下請の悲哀を語るスレと化してきたな

856 ：デフォルトの名無しさん：04/10/24 11:56:26

結局、ソフトウェア開発の本質的で構造的な問題だからな。

857 ：デフォルトの名無しさん：04/10/24 12:09:28

要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。

858 ：デフォルトの名無しさん：04/10/24 12:20:20

>>857が投資していいチームを作って漏れをやとってくれYO

859 ：デフォルトの名無しさん：04/10/24 12:29:31

問題は>>858が良いメンバーか、ということだが…

860 ：デフォルトの名無しさん：04/10/24 12:51:24

>>857
その投資の原資はどこからもってくれば良いのでしょうか？

861 ：デフォルトの名無しさん：04/10/24 12:57:45

資本金。

862 ：デフォルトの名無しさん：04/10/24 13:09:16

>>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁

863 ：デフォルトの名無しさん：04/10/24 13:11:12

データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。

864 ：デフォルトの名無しさん：04/10/24 13:12:02

>>862
競争力。

865 ：858：04/10/24 13:13:24

>>859
漏れはいいメンバーになるYO
頑張るから入れてください

866 ：デフォルトの名無しさん：04/10/24 13:18:14

>>864
わけわからん

867 ：デフォルトの名無しさん：04/10/24 13:20:53

>>853
そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…

868 ：デフォルトの名無しさん：04/10/24 13:21:18

>>849
> ttp://nekop.programmers.jp/diary/?date=20041024
> これ読んだらEAは俺には縁のない世界だと思った。

ttp://d.hatena.ne.jp/habuakihiro/20041024#1098575922

はぶ氏も似たようなこと言ってる。

869 ：デフォルトの名無しさん：04/10/24 13:24:51

>>844
手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。
オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も
オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。
オブジェクト内の手続きを再利用する方法として継承を使うことができるが、
継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する
ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって
しまうためよくない。

これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。
これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように
見えるかもしれないが、そうではない。

ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の
手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する
ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。
従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の
インタフェースをデータ型から抽出することが、ジェネリックプログラミングを
実現する第一歩となる。

870 ：デフォルトの名無しさん：04/10/24 13:41:33

>>844
>結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。

ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。

871 ：デフォルトの名無しさん：04/10/24 13:48:36

>>890

>587
>顧客クラスにパスワード変更メソッド付けるなんてアフォ

つまり、データはハッシュマップなりで適当なもので表現して
（実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして
定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは
よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく）

872 ：デフォルトの名無しさん：04/10/24 13:52:04

>>871

データを一番シンプルに扱えるのがハッシュマップである以上、
無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。
型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない
っていう仮説はどうかな。

873 ：デフォルトの名無しさん：04/10/24 13:52:20

>869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない

結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。

874 ：デフォルトの名無しさん：04/10/24 13:53:31

「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。

データと処理が分離されたCollection API

ｺﾜｰｲ…。

875 ：デフォルトの名無しさん：04/10/24 13:56:18

ttp://sumim.no-ip.com:8080/wiki/710

視点の違い

876 ：デフォルトの名無しさん：04/10/24 13:56:32

データと処理が分離されたデータベース

877 ：デフォルトの名無しさん：04/10/24 13:58:43

>>873
結局メソッドを呼び出すのがＯＯ。
オブジェクト指向の肝はポリモーフィズムで、
それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現
するっていう、ただそれだけ。

878 ：デフォルトの名無しさん：04/10/24 13:59:31

>>872
Java5で解決ですが。。

879 ：デフォルトの名無しさん：04/10/24 14:02:18

>>878
漏れには解決しているようにはとても見えへんのよ

880 ：デフォルトの名無しさん：04/10/24 14:13:32

だれか、>>863について斬ってくれ。

881 ：デフォルトの名無しさん：04/10/24 14:15:50

ORマッピングで継承って一体なんなんだ？　意味不明。
データはデータ。処理は処理だろ？

882 ：デフォルトの名無しさん：04/10/24 14:20:09

処理の切り替えって、やりたきゃやればいいんじゃないの？

883 ：デフォルトの名無しさん：04/10/24 14:36:40

>>881
こういうののことでつ。
ttp://objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html

884 ：デフォルトの名無しさん：04/10/24 14:44:58

処理の切り替えが沢山あるなら、

処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)

みたいのを作って

Manager#addHandler(handler)

てなことやると分離できるな。これが適切なときもあるにはあるだろう

885 ：デフォルトの名無しさん：04/10/24 14:54:13

>>871
>>872

そんなお前らはDbUtilsでも使ってろ。

まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。

886 ：デフォルトの名無しさん：04/10/24 15:57:59

Ruby最高ってことでFA

887 ：デフォルトの名無しさん：04/10/24 16:11:53

>>845
「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。

>>884
そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？

888 ：デフォルトの名無しさん：04/10/24 16:13:34

>>887
「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。

889 ：デフォルトの名無しさん：04/10/24 16:15:11

>>888
だね。最後の方良く読んでなかった。ｽﾏｿ。

890 ：デフォルトの名無しさん：04/10/24 16:16:15

>>871

890ゲット！！

データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。

891 ：デフォルトの名無しさん：04/10/24 16:21:15

ER図と照らし合わせながらでしか解読できんコードになるぞ。

892 ：デフォルトの名無しさん：04/10/24 16:35:46

なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。

間違っていたらご教授願います。
以下 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用

アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。

ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。

ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。

893 ：887：04/10/24 16:53:26

>>892
なんだ、わかってたのね。

つまり、

[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層

[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層

こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。

894 ：デフォルトの名無しさん：04/10/24 16:55:07

>>892
> なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。

895 ：デフォルトの名無しさん：04/10/24 16:58:47

OO厨なんてこんなもん

896 ：デフォルトの名無しさん：04/10/24 17:32:46

と、OOがわからなかったCプログラマーが申しております。

897 ：デフォルトの名無しさん：04/10/24 17:42:11

フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。

898 ：デフォルトの名無しさん：04/10/24 17:45:23

>>893
>ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。

プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

899 ：デフォルトの名無しさん：04/10/24 17:55:05

>>898
> プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。

ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。

900 ：デフォルトの名無しさん：04/10/24 17:58:36

ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。

901 ：デフォルトの名無しさん：04/10/24 18:03:10

>>900
StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。

902 ：デフォルトの名無しさん：04/10/24 18:03:41

ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。

分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。

903 ：910：04/10/24 18:12:38

説明が悪いのかな。
900氏の言うように「普通にデザインしてたら」、
StrutsのActionなどに提供される業務ロジックインターフェースの
メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。
でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？
多くないならいきなりActionから業務ロジックのインターフェースで提供されてる
メソッド呼び出すほうが素直じゃないの？って思ったんですよ。

904 ：デフォルトの名無しさん：04/10/24 18:13:33

>>869
それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。

905 ：デフォルトの名無しさん：04/10/24 18:18:01

>>903
必要ないでしょ。ケースバイケース。

906 ：デフォルトの名無しさん：04/10/24 18:28:51

かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。

あるプロジェクトでは、人に業務機能を割りあてました。
データベース設計はある一人が担当し、
他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、ある程度のレベルまで上昇しました。
メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。

あるプロジェクトでは、人にシステムの機能を割りあてました。
データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。
メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。

誰が幸せなのでしょう。

907 ：デフォルトの名無しさん：04/10/24 19:22:17

>>906
> 誰が幸せなのでしょう。
俺俺！

908 ：デフォルトの名無しさん：04/10/24 19:25:02

綺麗な設計を手に入れたお客さん。

909 ：デフォルトの名無しさん：04/10/24 19:34:41

>>897
S2で作れ！期待してます！

910 ：デフォルトの名無しさん：04/10/24 20:12:08

>>909
その前にくーすで設計だろ？

911 ：デフォルトの名無しさん：04/10/24 20:32:39

そうこうしている間に.Netが主流に。

912 ：デフォルトの名無しさん：04/10/24 21:01:43

Ruby.netが最強だと。

913 ：デフォルトの名無しさん：04/10/24 21:05:27

薄いサービス層 ⇒ ドメインモデル
とか
薄いサービス層 ⇒ リッチな業務ロジックモデル

これ、何いうてるんですかね。
どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、
この２つを分ける理由は謎。

914 ：デフォルトの名無しさん：04/10/24 21:09:50

>>913
...これまでの流れ、分かってます？

915 ：デフォルトの名無しさん：04/10/24 21:21:37

Ruby最強・・・かな？

916 ：デフォルトの名無しさん：04/10/24 21:21:50

正直、ドメインモデル　リッチな業務ロジックモデル

の違いも分からん

藻前ら難しく考えすぎだ

917 ：デフォルトの名無しさん：04/10/24 21:41:30

>> 916
お前は、きっちり分割されたシステムの一部を仕様通りに
月１５万でコーディングすればいいだけだから、気にするな。

918 ：デフォルトの名無しさん：04/10/24 21:56:07

>>917
月１５万でコーディングしてくれるの？
だったらうちで働いてよ。

919 ：デフォルトの名無しさん：04/10/24 21:58:55

2人日の価格で1人月か。お徳だ。うちにぜひこないか

920 ：デフォルトの名無しさん：04/10/24 22:14:18

うほっ！

か　か　な　い　か　？

921 ：デフォルトの名無しさん：04/10/24 22:16:11

>>919
あんたのところ高すぎ。
コーダーで月１５０万かよ！

うちの倍とってるじゃん。。。

922 ：デフォルトの名無しさん：04/10/24 22:16:47

じゃあRubyのDIコンテナに期待しよう
あるのかな

923 ：デフォルトの名無しさん：04/10/24 22:33:31

そろそろ新スレ立ててもいいんでない?

924 ：デフォルトの名無しさん：04/10/24 22:38:28

今の流れだと、次スレは必要なさそう。

925 ：デフォルトの名無しさん：04/10/24 22:39:14

盛り上がっているところに水を指すのは申し訳ないが
正直S2ネタが殆どないのにS2の名前で新スレ立てる
意味がないような気ガス。どう見ても単なるOOネタ。
こっちのスレのほうが適している気がする

【OO?】オブジェクトオリエンテッド総合【非OO？】
http://pc5.2ch.net/test/read.cgi/tech/1041658161/l50

926 ：デフォルトの名無しさん：04/10/24 22:45:08

そうだな。
PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？
S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ

927 ：デフォルトの名無しさん：04/10/24 22:52:43

>>917
>お前は、きっちり分割されたシステムの一部を仕様通り

そんなシステムあるわけないだろボーケー

928 ：デフォルトの名無しさん：04/10/24 23:02:45

>> 927
まず日本語から勉強しましょうね～。

929 ：805：04/10/24 23:05:07

>Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、
>実は間違ってますね。m(_ _)m
>ここでいっている依存関係とは、呼び出し順序の依存関係です。
>
>状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。
>しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、
>MbはMaに依存しているということになります。

Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。

Maの呼び出しによって、ステートS => ステートSa となるとして、
Mbが当てにしているのは「事前のMaの呼び出し」ではなくて
「Ma呼び出しによってセットされるステートSa」なんじゃないかな?

よって、ステートSを外に出したところで MbがステートSaを前提にしていることには
なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。

930 ：805：04/10/24 23:06:15

>>929

ごめん、ソースは
http://d.hatena.ne.jp/higayasuo/20041024#1098580377
ね。

931 ：デフォルトの名無しさん：04/10/24 23:13:31

OOネタはS2というかくーすから転がっていって
ひがさんのブログでの反応とあいまって
こうなったんで、このままここでいいよ。

932 ：デフォルトの名無しさん：04/10/24 23:16:36

普通はスレ違いなんだがな。
このスレには優しい人が多いということか。

933 ：デフォルトの名無しさん：04/10/24 23:19:16

このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。
そうすれば、今までのこともスレ違いではなくなる。

934 ：デフォルトの名無しさん：04/10/24 23:20:03

ダサッ！

935 ：デフォルトの名無しさん：04/10/24 23:46:17

>>929
　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
したりできて便利になるような気がするんだけど。

もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な
ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが
必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう
可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。

936 ：デフォルトの名無しさん：04/10/24 23:53:55

比嘉氏はStateはPresentation層に持つって言ってるので>>935は同じ事を言ってる気がするのだが

937 ：デフォルトの名無しさん：04/10/25 00:00:23

>>933-934
「S2のソナタ」にでもしておけばよかろう
正直漏れは次スレいらん気がしてるが

938 ：デフォルトの名無しさん：04/10/25 00:03:48

>933
人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて
開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて
じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。

>936
Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら
Presentation層で保持するのでやり易いだろう。
HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど

939 ：デフォルトの名無しさん：04/10/25 00:13:28

>> 938
そこでS2JSFですよ。

940 ：デフォルトの名無しさん：04/10/25 00:15:06

>938
おれ今までsessionとかrequestってプレゼン側領域だと思って
状態の管理にも使ってたんだけど、世間じゃ違うのかな。
小細工ってどんなの？

941 ：デフォルトの名無しさん：04/10/25 00:19:59

OOPの話がしたければ、それなりのスレへ。
新しい別のスレをたてる必要はない。
そこではSeasarの話はスレ違いだがね。
Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。

942 ：デフォルトの名無しさん：04/10/25 00:25:20

禿同
長文多いしage多いしスレ違い多いし
ハッキリ言ってウザイ

943 ：805：04/10/25 00:26:53

>>935
> >>929
> 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
> ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
> したりできて便利になるような気がするんだけど。

ドメインロジックを含んだクラスをステートレスにすると、
SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの
テクニックの大半が使えなくなります。
# 数少ない経験に基づいてるので嘘かもしれませんが。

そんな強烈なデメリットを負ってまでステートレスにして得られるものが、
「サービスオブジェクトのプーリング」というのは、
*個人的には*、割に合わないと感じています。

# もちろん、必然性のあるステートレス化には賛成ですが。

944 ：デフォルトの名無しさん：04/10/25 00:29:27

「ダイコン時代のスレ」でいいんじゃない？

945 ：デフォルトの名無しさん：04/10/25 00:34:31

もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。
アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。
もう漏れは飽きた。寝る。

946 ：デフォルトの名無しさん：04/10/25 00:35:59

seasarの話、くーすの話、OOの話、業務の話、
全てはひが様のもとへ、じゃ。
よってこのまま続行。

つか、ここの住人が杓子定規なスレタイ重視によって
分散してしまうのは、しじょーにもったいなく思いまーす。

947 ：デフォルトの名無しさん：04/10/25 00:38:14

では違うところに集うが良かろう。
でなければまずはsage進行で頼む。

948 ：デフォルトの名無しさん：04/10/25 00:48:11

>943
Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。
勿論、仕方無しにPresentationの役割と思ってやってるんだけど

>941、942
見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？
大半の香具師はアンチうざいのでsage進行だと思うしさあ。
とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。

>944、946
禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。
J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。
あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので
宗教論争ならくだらん。

949 ：デフォルトの名無しさん：04/10/25 00:59:23

しょっちゅうageてるじゃねえか。
上にくりゃ見えちまうだろうが。
sageくらい覚えろよ。
あと変なポインタ振るな。
長々書き込むな。
正直このスレの住人ウザイ。
2ちゃんにくんな。

950 ：デフォルトの名無しさん：04/10/25 01:10:48

J2EEに疲れてませんか、ではくーすの話はスレ違いだね。

951 ：デフォルトの名無しさん：04/10/25 01:29:23

>>949
N速にでも逝って２ちゃんらしさを存分に味わっとけ。
次スレはsage進行でマターリと語りたいね。

952 ：デフォルトの名無しさん：04/10/25 01:30:13

>>945みたいなアゲにげするやつがいるからねぇ。

953 ：デフォルトの名無しさん：04/10/25 01:32:45

じゃ、次はS2JSFでてからってことで解散。

954 ：デフォルトの名無しさん：04/10/25 01:33:08

分析から実装まで
開発を見つめるDICON

955 ：デフォルトの名無しさん：04/10/25 02:17:15

もはや広告が撲滅された以上、sageと入れるのは馬鹿。
そもそも同人板のヲタ女達が始めた風習だし。

956 ：デフォルトの名無しさん：04/10/25 02:24:08

風習の起源とか目的とか、どうでもいいだろうが。
いまそういう風習なんだから。

957 ：デフォルトの名無しさん：04/10/25 02:38:26

Stateless化することで見込まれているメリットの肝は、実は分業の徹底では
ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、
かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して
しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。

そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって
しまうのが悲しい現状だ。

そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。

958 ：デフォルトの名無しさん：04/10/25 08:06:05

次スレ立てるんなら>>1はガイドラインよろ
sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな
せっかくいい感じになってきたのでﾀﾉﾑ

959 ：デフォルトの名無しさん：04/10/25 11:28:42

>>957

ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い

960 ：デフォルトの名無しさん：04/10/26 00:49:26

このままのスレでいいじゃん。

961 ：デフォルトの名無しさん：04/10/26 01:14:57

スレタイに「くーす」要追加。

962 ：デフォルトの名無しさん：04/10/27 05:30:18

AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？

963 ：デフォルトの名無しさん：04/10/27 17:20:16

次スレはS2JSFが完成してからだね。

964 ：デフォルトの名無しさん：04/10/27 20:13:24

関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。
S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。

965 ：デフォルトの名無しさん：04/10/27 20:15:46

最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。

966 ：デフォルトの名無しさん：04/10/27 20:57:39

>>964
なんでかっこわるいの？

967 ：デフォルトの名無しさん：04/10/27 22:00:22

ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。

968 ：デフォルトの名無しさん：04/10/27 22:11:17

>>967
それがかっこわるい理由か？

969 ：デフォルトの名無しさん：04/10/27 22:59:04

>>967
RFC&W3Cﾏﾝｾｰなんだね。

IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは
文字化けする場合があるバグありバージョンがある。
客に文字化けするんだがって言われたらブラウザのバグですって言うの？

まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって
なると思うけど。

970 ：デフォルトの名無しさん：04/10/27 23:13:06

次スレ立てました。

国産DIコンテナSeaserとくーすその2
http://pc5.2ch.net/test/read.cgi/tech/1098885253/

971 ：デフォルトの名無しさん：04/10/28 01:05:52

技術屋がかっこつけようとすると
お客さんの価値観とは合わなくなる事が多く思いますが
よい例でしょうかね。

俺も出来る事なら存分にかっこつけてみたいわ。

972 ：デフォルトの名無しさん：04/10/28 02:20:21

969が正解でしたね。

ひがさんてば、こんな事にまで答えてくれるとは・・・・。

973 ：デフォルトの名無しさん：04/10/29 00:38:27

>>972
俺は >>571 です。
ここはエセ技術屋が多いインターネッツですね。
うんこばかりだな。

974 ：デフォルトの名無しさん：04/10/29 01:42:43

はいはい
あなたみたいにみんなから尊敬される素晴らしい技
術屋さんには見るもの全てがうんこにしか見えない
んだろうからここに来なくてもいいよ

975 ：デフォルトの名無しさん：04/10/29 01:53:25

エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁

976 ：デフォルトの名無しさん：04/10/29 01:59:02

お，半角SPACEたんｷﾀｰ(AA略)
相変わらずの粘着ぶりでつね！

977 ：デフォルトの名無しさん：04/10/29 02:00:22

metaタグうんぬん言ってた人が
571ってこと？

まあmetaタグがどうのってこだわりがあって
そういうのが技術力だって価値観も確かにアリだと思うけど
そういう価値観の人ならseasarもくーすも要らないんじゃないかな。

978 ：デフォルトの名無しさん：04/10/29 02:15:26

571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ
ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ
要するに 571 たんはひがたんのうんこが食べたいのでつ
頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ

979 ：デフォルトの名無しさん：04/10/29 23:50:16

ひがさんはいつ仕事してるんだろうか