5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

1 :デフォルトの名無しさん:04/12/12 23:37:01
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ?みんなもう使ってるの?
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

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


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

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

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


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


関連スレ(なのか?)

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


2 :デフォルトの名無しさん:04/12/12 23:43:16
>>1
スレ立て乙。

このへんも関連スレかな。

Dependncy Injectionを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1099827125/l50

Martin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50

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


3 :デフォルトの名無しさん:04/12/13 00:37:36
前スレより
>960 名前:デフォルトの名無しさん [sage] :2004/12/12(日) 18:38:39
>>>957
>むしろ、くーすは上流工程に責務を集中させるから、XP 等に比べて
>その部分の取替え可能性に関するリスクが高い、という見方もあると思うが。

XPについては、俺に仕事くれてる人が採用したがってるんで検討してみたんだけど、
検討してみた結果、この手法は実装フェーズ以降にしか使えないと思った。

というのは、XPでストーリーをタスクに分割する前に、まずはシステム全体のアーキテクチャ、
つまりシステムを何層に分割するのかとか、例外の扱いはどうするのかとか、ログはどうとるのか
とか、全体に及ぶような設計を先にして「今回はこういうルールでやってください」って言っとかないと、
なんだか訳の分からない実装の集合体ができそうに思う。まったく統一感がなくてメンテナンスが
しにくい。
だから、XPでもやっぱり上流行程って必要なんじゃないかな。

で思ったのだが、 くーすの流れで言うところの、ロバストネス解析あたりまでを設計チームでやり
こんで、シーケンス図を書くあたりからXPの手法を導入ってしたら案外うまくいくんじゃないだろう
か。業務フロー図一枚くらいをストーリーにして、あとはタスクに分割して実装していくって感じで。

4 :デフォルトの名無しさん:04/12/13 01:26:27
ま、御託は資源の排他制御が出来るようになってから、な。

5 :デフォルトの名無しさん:04/12/13 01:39:20
>>3
> だから、XPでもやっぱり上流行程って必要なんじゃないかな。

「アジャイルと規律」を読め。その問題が詳細に検討されてるから。

# 関係ないが、DIスレの213-214ゴールデンコンビを思い出す…。

6 :デフォルトの名無しさん:04/12/13 09:29:53
>>3
FDDでいいじゃん。

7 :デフォルトの名無しさん:04/12/13 20:21:31
フロッピーディスクドライブ

8 :デフォルトの名無しさん:04/12/13 21:02:16
しょせんそのレベルか。

9 :デフォルトの名無しさん:04/12/13 21:16:01
(・∀・)ハイーキョ

10 :デフォルトの名無しさん:04/12/13 23:45:19
はおゆんらいらー!

11 :デフォルトの名無しさん:04/12/14 00:32:16
ほっちゃーん! ほ、ほーっ、ホアアーッ!! ホアーッ!!

12 :デフォルトの名無しさん:04/12/14 02:39:29
うぉーあいにーめん!

13 :デフォルトの名無しさん:04/12/14 11:50:25
IKEMEN JAPAN !!!

14 :デフォルトの名無しさん:04/12/14 19:11:25
前スレ>>933さんの提案は残念ながらひがさんの目にとまらなかったようですね。
僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。

15 :デフォルトの名無しさん:04/12/14 22:20:42
前スレ934
> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。

これってむしろS2Dao側で属性ごとにダーティーチェックして対応してくれるのが
正しい気がするんだが。現状のS2Daoってそういうことやってないの?

教えて君でスマソ。

16 :デフォルトの名無しさん:04/12/15 00:14:08
いやマジで、「このカラムにシステム時刻を入れたいだけなんだよ」とか「このカラムの
フラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。

別に対した手間じゃないんだろうけど、でも全カラム一斉UPDATEがわずか一行で
定義出来るのに、それより短いSQL文のためにSQLファイルをつくんのかよ....orz
という気分になってしまう。

17 :デフォルトの名無しさん:04/12/15 08:09:54
>>16
もしかして1項目変更するのが全項目変更するより簡単な処理だと思ってるの?

18 :デフォルトの名無しさん:04/12/15 08:20:15
今回のスレは「その3」の3が全角になったんだね。

>>17
確かにクエリを組み立てる側の制御は組み立てるクエリの長さで決まるわけじゃないからねえ。
だから、ARGSアノテーションとかが必要になるんだと思うんだけど。
16は仕組みをあまり分からず書いているのかもしれないけど、
そういうユーザーの要望の中から対応すべき要望を抽出して対応することによって
ツールとかは熟成されていくんだと思うよ。

くだらなくても要望出さなかったら作者の必要な機能ばかりのツールになってしまうからね。

19 :デフォルトの名無しさん:04/12/15 10:11:14
S2Daoって、BLOB型とかの値は取り出せないの?

20 :デフォルトの名無しさん:04/12/15 11:20:18
>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな?

まぁ、いちいち噛み付かずに
>>17さんの言う通り、
ちょっとづつでも要望出してちょっとづつでも良いツールになっていってもらおうよ。
僕は一応、ソースのどの辺いじればよいのか調べています。

21 :デフォルトの名無しさん:04/12/15 12:01:45
>>20
>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな?

そうです。
短いSQLのためにSQLファイルを作るのが面倒だという話です。

S2Daoは「UPDATE テーブル SET PK以外のカラム全部 WHERE PK」ってなSQLを自動生成
してくれるけど、「PK以外のカラム全部」を特定のカラムだけにするのにSQLファイルを書く
のがね。

SQLを一行書いたファイルを作るだけなんだけど、「PK以外のカラム全部」のカラムが20個
だったりしても長いSQLが自動生成できるのと比べてしまうと、たった一つのカラムのために
SQLファイルを書くのが面倒に感じまして。

22 :デフォルトの名無しさん:04/12/15 12:43:05
update_PERSISTENT_COLUMNS = "hoge";

だって。よかったじゃん。
tp://d.hatena.ne.jp/higayasuo/20041215

23 :15:04/12/15 14:32:48
間に合わなかった_| ̄|○ つか、対応してくれるんだ!

こういうところもS2が好きな理由です。

24 :14:04/12/15 14:34:01
ごめん、間違えた。>>23は漏れ。
騙った訳じゃないのでゆるしてちょ。

25 :15:04/12/15 16:40:25
いやゆるさん!

26 :14:04/12/15 17:13:10
。・゚・(ノД`)・゚・。ウワーン

27 :21:04/12/15 17:32:06
>>22
感激だっ。ありがとうひがさん....

28 :デフォルトの名無しさん:04/12/15 17:45:05
見てるとは思うけど、お礼コメントしてきたらよいかも。

29 :デフォルトの名無しさん:04/12/15 19:48:28
お礼だけのコメントは情報量ないから止めた方がよくないか?
お礼がズラズラと並んでる図は信者臭くてダサいし

30 :デフォルトの名無しさん:04/12/15 19:54:15
お礼と一緒に喧嘩も売るとか

31 :デフォルトの名無しさん:04/12/15 20:57:55
趣味悪いなー

32 :デフォルトの名無しさん:04/12/15 23:55:56
「ひがたん、乙」とだけ書いてくればいいのではないか?

33 :デフォルトの名無しさん:04/12/16 08:04:25
とっておきのエロ画像とか貼るのがいいのではないか?

34 :デフォルトの名無しさん:04/12/16 09:26:24
蛯○友里の愛顧らなどがよろしいかと。

35 :デフォルトの名無しさん:04/12/16 09:30:25
AOPをフルに使用したコラが良いと思われ。

36 :デフォルトの名無しさん:04/12/16 22:51:45
最近大きな変化は無いね。

早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。

37 :デフォルトの名無しさん:04/12/16 22:53:29
>>36

ネタに騙されてるよ

38 :デフォルトの名無しさん:04/12/16 23:48:52
>>37
ネタ?
MLでの導入事例集作成のやり取りのことですか?

39 :デフォルトの名無しさん:04/12/16 23:50:02
ひがさん仕事はやー。ちょっと追いかけるの休んでると、どんどん機能がリリースされてく。
つーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz

40 :デフォルトの名無しさん:04/12/17 00:31:59
AOPつかわねーと意味ねーじゃん。

41 :デフォルトの名無しさん:04/12/17 00:42:59
AOP使わないとS2Dao使えないし、自動トランザクション制御使えないし、
モックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。

42 :デフォルトの名無しさん:04/12/17 01:02:00
>>39
とりあえず、ドキュメントどおりにdiconファイルに記述すればOK

43 :デフォルトの名無しさん:04/12/17 15:24:17
マジレスすると自分で考えてAOPを使うのが難しいってことだろ。
考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。

44 :デフォルトの名無しさん:04/12/17 21:38:25
http://d.hatena.ne.jp/higayasuo/20041217#1103278289

> SQLを自動生成したり、Beanからバインド変数を組み立てたりという仕事は、
> これまで、BeanMetaDataにさせてました。データのことを最も知ってるクラスに
> 振る舞いを持たせるのは、自然なことだと思っていたためです。
>
> しかし、S2Daoに仕様の追加があるたびに、BeanMetaDataに変更が入るのです。
> メタ情報は全く変更されていないのにもかかわらず。

SQLの自動生成ロジックの変更によって、メタ情報に変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?

バインド変数組み立てロジックの変更によって、メタ情報の変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?

どちらも何の問題もないように思いますが。

45 :デフォルトの名無しさん:04/12/17 21:53:31
> これは、BeanMetaDataに多くの責任を持たせていたためです。
> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

それは単に責務の割り当て方が適当でなかったために

> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

と感じるのだと思いますが。

例えば

BeanSchema.toXML

のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。

46 :デフォルトの名無しさん:04/12/17 21:55:32
> 振る舞いを役割ごとに分割する、言い方を変えると振る舞いを
> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。

よくわからないので、
具体的な例を挙げていただけませんか?

47 :デフォルトの名無しさん:04/12/17 22:03:48
SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの?

で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。

その点についてはおれは反対する要素はないぞ。

48 :デフォルトの名無しさん:04/12/17 22:13:39
>>47
> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの?
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。

うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。

49 :デフォルトの名無しさん:04/12/17 22:31:17
>>46
ここではなくてblogのコメントに書いていただけませんか?

50 :デフォルトの名無しさん:04/12/17 22:33:40
> 永続化されるデータに業務に応じた振る舞いを持たせるというのは、
> 1つのクラスに複数の役割を持たせることになります。

なりません。

データは何一つサービスを提供しません。
よって、データは責務を持ちません。


51 :デフォルトの名無しさん:04/12/17 22:33:41
そりゃおかしいだろう。
S2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。

52 :51:04/12/17 22:34:29
ごめん、51は>>48に対するレスね。

53 :デフォルトの名無しさん:04/12/17 22:48:37
>>51
目先のお手軽さや便利さを求めちゃ何故まずいんだろう?

それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。

オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。

お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの?

54 :46:04/12/17 22:49:04
>>49
そんな度胸ありません!

55 :デフォルトの名無しさん:04/12/17 22:49:13
>>51
> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。

同感です。
結局は、前々スレの686の一言につきると思う。

>686
> くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
> (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
> 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
> Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
> カバー、的な。


56 :デフォルトの名無しさん:04/12/17 22:52:30
ヒガ氏はああいう書き込みで燃料投下して
そのBlogに対する書き込みをニヤニヤして読んでると思われ。

必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな(藁

57 :デフォルトの名無しさん:04/12/17 22:55:14
44=46=48!=54ですが。

>>54
> >>49
> そんな度胸ありません!

そのとおりですw

58 :デフォルトの名無しさん:04/12/17 22:58:15
>>55
みなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。

59 :58:04/12/17 23:00:23
>>58
誤 後ろ向きな方法論で結果を出すしかありません
正 後ろ向きな方法論を利用してでも結果を出すしかありません

...ま、大してかわらねーか。

60 :デフォルトの名無しさん:04/12/17 23:01:04
>>53
> >>51
> 目先のお手軽さや便利さを求めちゃ何故まずいんだろう?
>
> それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
>
> オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
>
> お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの?

それについては否定はしないけど、それはビジネスの話。

技術者ならくーすの技術面について話をしようぜ。


61 :デフォルトの名無しさん:04/12/17 23:06:45
技術の世界でスキルのない人間使ってそれなりの成果物をあげることは、かなり
技術者よりの話題だと思うんだが。

まあみんな分かってるとは思うけど、くーすでいっていることは、すげえ新しいことでは
なくて、いままでビジネスの世界で生きてきた人が経験として得てきた知識と言うかノウハウ
(ともかくこの低スキルどもにコーディングをさせてこの仕事仕上げないといけないんだよ!、
とかいうやつ)だよな。それを手続きとしてまとめたもんだ。

で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。

62 :デフォルトの名無しさん:04/12/17 23:12:21
ひがさんの「BeanMetaDataには振る舞いを持たせるべきではない」という方針は
現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか?本当に?

アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの?本当に?

63 :44:04/12/17 23:13:21
>>61
>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。

それ自体は否定しないし、これらをまとめあげようとするひがさんは偉大だと思う。

ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。

64 :デフォルトの名無しさん:04/12/17 23:17:26
要するに、
ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。

それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。

65 :デフォルトの名無しさん:04/12/17 23:19:53
>>60
くーすの技術面?

くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの?

66 :デフォルトの名無しさん:04/12/17 23:29:51
とりあえずハッキリしてるのは、ヒガ氏の実装で得られる利点と、損なわれる難点を
技術的に語れる人間はこのスレには居ないって事だ。

それはそれで構わないと思う。そこは所詮2ちゃんだし?
重要なのは、このスレがヒガ氏へのQとして機能し得るか否かって事だ。


何が言いたいかって言うと

ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ

って事だw

67 :44:04/12/17 23:30:55
>>64
> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、

くーすの言う、DTOとかStatelessBusinessロジックはビジネスの話だと。
はあ、そうですか。

って、んなわけねーだろ。

68 :デフォルトの名無しさん:04/12/17 23:31:44
>>62
いや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理(に直結した振る舞い)だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。

振る舞いとデータを分離するといってるんじゃなくて、「データにやまほど振る舞いをつけた
くなったとき、その振る舞いがデータと直結してるかどうかちょっと考えてみろ」っていって
るんだと思うけど。

まあ俺が思うのは、データに直結してないけど、そのデータを利用する機能を山ほど搭載
したFatなクラス設計(モデリング?)というは、「レガシー」なんではなくて、そんなものは
始めからオブジェクト指向の原則に反してるだろ、ということだな。

それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
かなり微妙だし、俺も正直言って間違うよ。

データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか?

69 :デフォルトの名無しさん:04/12/17 23:33:15
>>67
ああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。

70 :デフォルトの名無しさん:04/12/17 23:42:39
>>69
> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。


もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?

71 :デフォルトの名無しさん:04/12/17 23:45:04
おれは言ってる事はともかくとして、「レガシー」という表現を使ったことについてはおかしいと思う。

ここでレガシーと言われているものって、レガシーなんじゃなくて、そんなのはもともとオブジェクト指向的に
間違ってるんだし。

72 :51:04/12/17 23:52:15
>>66
いや、別にくーすに従わなきゃS2使ってバリバリにOOPなシステム作ることは
可能なわけよ。だからひが氏の実装自体には問題ない。むしろ素晴らしいと思うよ。
問題なのはくーすだよ。ただ、心配してるだけなんだけどね。
マジョリティとしての技術の方向性っちゅーのかな。それがこの先どうなっちゃうのか、とか、
くーすによってさらに加速されるであろう量産型低スキルエンジニア達の増産とか、
そいつらと一緒に、これからも仕事していかなきゃならない自分の身の振り方とかを。
ビジネス的にはそれでいいだろうけどさ、長期的に見て、まず「人」は育たないよな。
だから前々スレ686の一言に尽きるって結論になっちゃうんだけど。

ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏

73 :デフォルトの名無しさん:04/12/17 23:58:38
しかしまあ、正直言って「importって何の意味があるんですか」「java.langはimportしなくちゃ
いけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。

だって毎年量産されるんだし...

74 :デフォルトの名無しさん:04/12/18 00:06:55
いやぁ、くーすはともかくとして、Seasarは明らかにシステム構築の敷居を高くしているよ。
いろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論(しかも、漏れ的には相当あやしい)を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。

75 :デフォルトの名無しさん:04/12/18 00:07:53
何年って、おれは使い始めて1ヶ月後にはチームの連中に説明してたが....

76 :デフォルトの名無しさん:04/12/18 00:08:23
くーす周辺の「お客様」とか「現場」は、目の前の客と現場に部分最適化して、
将来の客と現場に対する思考を停止するためのエクスキューズ用語。


77 :デフォルトの名無しさん:04/12/18 00:09:26
さらにチームの連中は「Struts覚えるより仕組みが簡単ですね」とか言ってたが....

78 :デフォルトの名無しさん:04/12/18 00:14:24
独自の複雑なフレームワークを駆使した開発方法を
示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。

シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。

79 :デフォルトの名無しさん:04/12/18 00:14:55
>>68
なんか凄い自信家ですねw

>>それをレガシーだと言うなら、間違う人が多すぎたってことだろう。たしかにそこの判断は
>>かなり微妙だし、俺も正直言って間違うよ。
この辺に自惚れさが見え隠れしているように感じられるのは気のせいでしょうか?

80 :デフォルトの名無しさん:04/12/18 00:16:07
>>77

そうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。

81 :デフォルトの名無しさん:04/12/18 00:17:35
なんかわからんが、Seasarはファクトリ+AOPだし(というかDIコンテナは大体そうだわな)、
くーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。

逆にその「まとめよう」というところに価値があると思ってる。

82 :デフォルトの名無しさん:04/12/18 00:21:20
すごい勢いでレスがついてますね。
みんな比嘉さんにもてあそばれてるなあ。

しかし、「レガシー」って括られるとそりゃ頭にきますよね。
みんな最先端を走ってるつもりなんですからねえ。
そう書けばここで盛り上がるのわかって書いてるのに
予想通りの盛り上がりを見せてるのはちょっと笑えるね。

しかし、Blogで2ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。

83 :デフォルトの名無しさん:04/12/18 00:24:31
むしろひが氏のネタの半端さがレスを呼んでるんじゃないの。
DIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。

84 :デフォルトの名無しさん:04/12/18 00:28:13
>>82

そうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・

85 :デフォルトの名無しさん:04/12/18 00:29:47
まあ自分の主張を目立つように書こうとしてつっぱしり過ぎたってとこだろう。
もし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。

まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのPGに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...

86 :デフォルトの名無しさん:04/12/18 00:31:45
>>84
ほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。

おれは勢い余ったんだと思うけどね。

87 :デフォルトの名無しさん:04/12/18 00:33:57
指示=支持

88 :デフォルトの名無しさん:04/12/18 00:39:08
とりあえず呼んどくか。

  ☆ ティン

       ☆ ティン  〃  ∧_∧   / ̄ ̄ ̄ ̄ ̄ ̄ ̄
          ヽ ___\(\・∀・)<  ヒガタソ消火まだー?
             \_/⊂ ⊂_)_ \_______
           / ̄ ̄ ̄ ̄ ̄ ̄ ̄/|
        |  ̄  ̄ ̄ ̄ ̄ ̄ ̄:| :|
        |           .|/

DIスレをリスペクトして「ティン」だ。

89 :デフォルトの名無しさん:04/12/18 03:15:01
結論:やっぱEJB。

90 :デフォルトの名無しさん:04/12/18 12:01:40
>>89

EJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる!」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。

91 :デフォルトの名無しさん:04/12/18 13:32:36
似た方向を目指しててそれぞれ一長一短なモノなら、
メジャーな手法を使うのは当然だよな。

92 :デフォルトの名無しさん:04/12/18 13:32:51
ふ〜ん

93 :デフォルトの名無しさん:04/12/18 16:16:25
まあ、Java自体がネタだからね。

94 :デフォルトの名無しさん:04/12/18 16:29:36
>>82
レガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。

ナイーブって言い方に変わってるね。

95 :デフォルトの名無しさん:04/12/18 16:55:10
ダイコン書くのだるい。。。ってか、ファイルが分散するのって
正直どう思ってるんだろう。S2Struts使うとStrutsConfとダイコンも
書かなきゃいけないし。
特に全体を追おうとするときって、目茶目茶だるい。EclipseでCtrl+クラス
で実装開いてくれるけど、インターフェース使ってると
インターフェース開くから、ダイコン見て実態クラス見てって。。。
書いてる本人は分かるから良いんだろうけどさ。

あと、お客に技術トランスファーしなきゃいけないのに
Seaser使っちゃって(一緒にやってる人がね)、おいおい
お客さん(IT企業じゃないないシステム課の人)
に分かるように説明できるのーって感じ。

やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。

96 :デフォルトの名無しさん:04/12/18 16:58:01
でも

>>この「ナイーブ」は当然 (?) without EJB のアレ (笑) です.幼稚・稚拙というニュアンス.

だそうですから。

97 :デフォルトの名無しさん:04/12/18 17:03:26
DIっつっても、DIで作られたクラス使う分にはただのファクトリなんだし
対して技術的に難しい概念ってことはないと思うが。

98 :95:04/12/18 17:14:31
>>97
>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。

DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。

99 :デフォルトの名無しさん:04/12/18 17:30:32
>>95
実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。

100 :95:04/12/18 17:41:08
>>99
じゃあ、あるデータ項目を追加したいって場合は
実装はいじらせないって事?


101 :デフォルトの名無しさん:04/12/18 17:55:38
>>95
プロジェクトで役割を明確にしろよ。
みんながみんな実装のロジック見るわけじゃないだろ。
なんのためのインターフェースだと思ってる?
てか、Saesarをどうのこうの言う以前にOO開発できないでしょ。
そんな考え方じゃ。

102 :デフォルトの名無しさん:04/12/18 18:00:55
ソフトウェア開発の基本が分かってない人↑

103 :デフォルトの名無しさん:04/12/18 18:01:06
>>100
ちゃんと設計しろよw

104 :デフォルトの名無しさん:04/12/18 18:02:56
設計は絶対に変えない。これがくーす。

105 :デフォルトの名無しさん:04/12/18 18:08:35
>>102
基本を教えてください。

106 :デフォルトの名無しさん:04/12/18 18:11:25
>>102
基本?
それってあんたのMY RULEのこと?

107 :デフォルトの名無しさん:04/12/18 18:34:12
ここは貧血症君とレガシー君が互いに罵倒し合うスレですか。
そうですか。

108 :デフォルトの名無しさん:04/12/18 18:35:58
>>107
そうですよ。
傍観者は書き込まないでください。

109 :デフォルトの名無しさん:04/12/18 18:42:10
>>95
「interface開く 〜 interfaceのタイプ階層を見て実装クラスを開く」
って2段階になるのがうざいよね。

IDE側に、interface名にカーソルあわせて「実装クラスを開く」
みたいな機能が欲しくなる時がある。実装クラスが一つの場合は
そのまま実装クラスのソースを開き、複数ある場合はドロップダウンで
選択とか。

110 :デフォルトの名無しさん:04/12/18 19:25:36
ここ読んでておもうのは、もしかして本当にモデルオブジェクト(ここで想定しているのは、
S2Daoが返す、テーブルに対応したBeanとか)にいっさい振る舞いを持たせなくて、
setterとgetter以外あってはいけないとか思ってる人が多いのか。

そりゃ貧血症どころか構造体にすぎんじゃないか。

おれはモデルにほとんど機能は実装しないが、それでもそのモデルに直接関わる機能
(モデル内のインスタンス・フィールドだけで処理が片付いてしまうようなもの)はモデルに
実装するぞ。複数のモデルが絡んでくるようなものはサービスにまわす。貧血症ぎみの
クラスは多いが、それでも構造体よりはましだと思う。

111 :デフォルトの名無しさん:04/12/18 19:51:10
>>110
前スレの後半で俺も似たようなこと言ったんだけど、
構造体として使うのがくーすらしいよ。

つーかドメインオブジェクトが何かって事をそもそも理解されてないようだから、
このスレの"ナイーブOO指向好き"と論点が噛み合わないんだよな。
複数業務にまたがるロジックがあるからこそドメインオブジェクトが存在してるんだろうに。
あれだけ、でかでかともっともらしいことを書くんなら、せめてもうちょっと
OOについての理解を深めてからにしてもらいたい>>比嘉氏

112 :デフォルトの名無しさん:04/12/18 20:28:05
ここはHDataSetのサポートをしてくれるスレじゃないんですか。
そうですか。

113 :デフォルトの名無しさん:04/12/18 20:29:53
>>111
ttp://d.hatena.ne.jp/higayasuo/20040801#1091337811
> OOPの良さは分かったけど、OOA,OODってよくわからんと思ってました。
> プログラミングのスタイルも我流で、適当にクラスを作っていただけです。
> 心がけていたのは、メソッド全体を一度に画面で確認できるくらい
> 小さいものにすることだけ。

114 :デフォルトの名無しさん:04/12/18 20:30:44
人が育たないって主張に対するレスポンスがないな

115 :デフォルトの名無しさん:04/12/18 20:59:21
>>109
ほれ
http://eclipsewiki.net/eclipse/?Implementors%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3


116 :デフォルトの名無しさん:04/12/18 21:34:57
>>114
自分で勝手に育っていく奴以外はほっとけ。
そんなことに金かけてる時代じゃねーんだよ。

ま、あんまりたくさん育っても任せる仕事がとってこれないから
くーすみたいなのでできない奴をうまく使いつつ、
勝手に育った奴に仕事任せていけばいいんじゃない?
育たない奴はいつまでもプログラマ。か、別の業種で頑張ればいいんじゃないか?

一般的な会社組織ってピラミッド型になってて、
成長していくとピラミッドがでかくなってしまうよね?
でもピラミッドの上方(高給取り)の比率を高くしないように
ピラミッドの形を維持していかなければならないから、
実はみんなに育たれちゃうと困るんだよね。
(全体の人件費を抑えざるを得なくなってしまうから)

日本の高齢化社会の年齢構成みたいに高給の人間の比率が多い組織になると
収益率を上げていくのは大変だからね。

117 :デフォルトの名無しさん:04/12/18 23:01:46
ドメインオブジェクトと永続オブジェクトを分ける話じゃないんですね。

118 :デフォルトの名無しさん:04/12/18 23:55:39
サービス層はドメインオブジェクトじゃないのか?
データアクセス層を純粋にデータアクセスだけに特化させることはOKな感じもする。
つまりDBからデータを取ってくる以外のロジックは存在しないただのBeanって感じで。

119 :デフォルトの名無しさん:04/12/19 00:29:37
結局、エンティティBeanのショボイ奴か。

120 :デフォルトの名無しさん:04/12/19 02:32:35
くーすは名前を返上すべし。
熟成とは縁のないファストフード作りのマニュアルじゃん。

121 :デフォルトの名無しさん:04/12/19 05:13:06
http://d.hatena.ne.jp/higayasuo/20041218#1103335335
> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。
>
> 私の経験からするとドメインオブジェクトが複数の業務で
> 使われるということは良くある話です。
> 複数の業務の業務ロジックを1つのドメインオブジェクトに
> 持たせるということは、単一責任の原則に違反しています。
> クラスを変更する理由が複数あるためです。

複数の業務の業務ロジックをドメインオブジェクトへ
持たせたとしても、単一責任の原則には違反しません。

「業務Aの機能と業務Bの機能をドメインオブジェクトDへ持たせている」

と考えると単一責任の原則に反しているように見えますが、

「ドメインオブジェクトDの機能を使って、業務Aの機能と業務Bの機能を実現している」

と考えれば、Dの変更理由は常にひとつです。

よって、

> 問題は、ドメインオブジェクトに業務ロジックを追加するのが、
> ナイーブかどうかということです。

は「ナイーブではありません」が結論。


# ちなみに「単一責任の原則」はアジャイルソフトウェア開発の奥義に
# 載ってます。いい本ですよ。

122 :121=44:04/12/19 05:28:10
べつに、DomainDrivenDesignを否定しなくてもいいとおもうんだけどね>ひがさん

くーすのネーミングの理由を聞かれたakonが
> 車輪の再発明ではなく、昔の道具でも使い方しだいで対応できるという心をこめてのネーミングです。
って言ってることですし、手続き型上等、TransactionScriptマンセーと開き直ればいーじゃない。


123 :デフォルトの名無しさん:04/12/19 05:39:07
それにしても、オブジェクト指向じゃないくーすに(21世紀の手続き型なんでしょ)ナイーブなオブジェクト指向とか、レガシーなオブジェクト指向とか言われたくない。

124 :デフォルトの名無しさん:04/12/19 05:44:32
>>114
>人が育たないって主張に対するレスポンスがないな

くーすは人を成長させるとことにフォーカスしてないからしょうがないよ。

人を成長させるってことなら、XPが一番だな。とくにペアプロが効果大。

125 :デフォルトの名無しさん:04/12/19 07:49:55
>121
それは設計によるだろ。

126 :デフォルトの名無しさん:04/12/19 08:36:39
くーすを好みそうな人たちのいる組織もたくさん思い当たる。
俺はそこがいやで転職したわけだが。

127 :デフォルトの名無しさん:04/12/19 09:52:23
>>126
くーすやSeasarを使おうが使うまいが、
力のない会社にプロジェクトは失敗はついて回るでしょうし、
くーすやSeasarを使おうが使うまいが、
力ののある会社はそつなくプロジェクトを成功させるでしょうね。



128 :95:04/12/19 10:58:20
>>101
あー、開発段階の話じゃないのよ。
納品して、お客さんがちょっとカスタマイズしたいって場合ね。
もちろんサポート外になるのは、こっちもお客も同意済み。

>>115
さんきゅー

129 :44:04/12/19 11:32:42
http://d.hatena.ne.jp/higayasuo/20041218#1103335335
> 私がいっているのは、データと振る舞いをカプセル化するという
> 考えは、オブジェクト指向の重要なポイントですが、単純に
> データに振る舞いを追加するのではなく、そこに、クラスは
> 1つの役割だけを担うようにするという視点を必ず持つように
> しましょうということです。

これは分かるのですが、これを理由に

>役割ごとにクラスを分割するという観点で考えると、
>
> * 永続化されるデータを管理するクラス
> * データベースにアクセスするクラス
> * 業務ロジックを扱うクラス
> に別れるというのは、理にかなったことだということが
> 分かると思います。

という結論が導き出される理由が分かりません。

「データを管理」や「業務ロジックを扱う」などはクラスの役割とするには低レベルすぎますし、曖昧にすぎます。

以下はjunitのjavadocから抜き出したものですが、

-TestResult
A TestResult collects the results of executing a test case.
-TestSuite
A TestSuite is a Composite of Tests.

役割というのは上記のような粒度のものであって、データの管理や業務ロジックを扱う、などはその内に含まれるものです。それ単体で役割として考えるべきものではありません。

130 :44:04/12/19 11:36:47
>>127
よく分析麻痺、設計麻痺に陥ってるプロジェクトがあるけど
そういうプロジェクトにはくーすの割り切りの良さはスゴク効果的だと思うな。

131 :デフォルトの名無しさん:04/12/19 15:22:18
>>121
その論理が成り立つなら、どんなクラスでも単一責任の原則に
違反することはない罠。
あるクラスの機能を使ってるといえば良いんだから。

132 :デフォルトの名無しさん:04/12/19 16:18:08
>>127は会議で話題をループさせるタイプだ。
間違いない。

133 :デフォルトの名無しさん:04/12/19 17:55:31
>>95
S2ActionServletとかRegistActionClassPlugInを使えば
Actionに関しては全くダイコンを書かなくても大丈夫だよ?
ファイルの分散も気にならなくなり、
さらに金運も上がって女の子にもモテモテでウハウハです。


ActionにAOP適用してたりするとだめだけどね。
漏れの場合はその辺もRequestProcessorへのAOP適用で代用できたけど。

134 :44:04/12/19 19:50:54
>>131

???
もっと詳細キボン。

135 :デフォルトの名無しさん:04/12/19 20:05:47
>>134
あるオブジェクトZが、A, B, C, ..., Yの役割を持っていたとしても、
オブジェクトZの機能を使ってるんだといえば、
単一責任だというように読める。

業務Aのための機能と業務Bのための機能は、
やっぱり別々の役割で内科医。

136 :デフォルトの名無しさん:04/12/20 01:38:58
おまいら話の粒度を揃えてから喋れ。
業務って、具体的に何をどうすることを想定しているのだ

137 :デフォルトの名無しさん:04/12/20 02:14:07
トランザクションをコミットするまで。

138 :デフォルトの名無しさん:04/12/20 02:45:50
就職してボーナスが出るまで

139 :デフォルトの名無しさん:04/12/20 03:16:33
>>137
それじゃ大きすぎないかな。

支払を管理する支払テーブルがあったとして
支払に関連するものとして、
通常の買掛金に対する支払と
売掛金返金に伴う支払と2つあった時に、
トランザクション単位で考えれば業務は2つだけど
支払データ生成ロジックは共通で使いたいでしょ。

この場合、買掛金消込、売掛金返金、支払データ生成
の最低3つを業務と捉えるのが望ましいと思うんだけど。
トランザクションの数とは一致しない。

とはいえ、確かに殆どの場合は
トランザクションと一緒で問題ないかもね。

140 :デフォルトの名無しさん:04/12/20 04:44:58
http://d.hatena.ne.jp/higayasuo/20041219#1103445985

単一責任がどーのこーの言う前に、まずオブジェクト指向の基礎から学び直していただきたい。

141 :デフォルトの名無しさん:04/12/20 05:15:02
>140
ナイーブの意味もついでに調べてみよう

142 :デフォルトの名無しさん:04/12/20 06:38:50
>>140
データと振る舞いが一緒だとオブジェクト指向だと思っている
単純なやつはけーん。

143 :デフォルトの名無しさん:04/12/20 09:57:33
140じゃないけど、どの辺りを読むとそういう結論になるのか分からん。
157には同意

144 :デフォルトの名無しさん:04/12/20 09:57:53
>>141
ナイーブなオブジェクト指向、っていうことばなんだけどさ、

http://www.ogis-ri.co.jp/otc/hiroba/OoBook/Beginner/B3.html

OOSE以前のオブジェクト指向設計方法論の
「OOピュアたるべし、ユースケースはOOじゃない」
みたいな考え方を指していたと思うんだけど、
いつの間に凝集性の低いクラスを作ることを「ナイーブなオブジェクト指向」と呼ぶようになったの?


145 :デフォルトの名無しさん:04/12/20 10:10:24
>>144
よーどんさんたちの言う
「ナイーブなオブジェクト指向」は知らないけど
普通に「ナイーブ」なオブジェクト指向って事なら
142の煽りのような意味で取りますわな。文脈からしてさ。
そういう意味でひがたんは使ってると読んだんだけど・・・

なにっ?もしかして、OOワールドでは
コードやヨードンが厳密に定義した言葉として
認識されてるのかっ?

146 :デフォルトの名無しさん:04/12/20 10:13:30
>>143
そうだな。確かに>>157はいいことを言ってる。俺も禿胴だ。

147 :44:04/12/20 10:15:48
>>135

[ 業務A ]
ログイン機能 ---> use isExpired()

[ 業務B ]
社員給料計算機能 ---> use calculatePay

[ オブジェクトZ ]
------------
社員クラス
------------
+isExpired
+calculatePay
------------

この場合のオブジェクトZは単一責任の原則をやぶってると思う?
おれは思わないよ。

148 :デフォルトの名無しさん:04/12/20 10:17:30
>>145

違う概念を同じ名前で表したら混乱を招くでしょ。

149 :44:04/12/20 10:27:09
http://d.hatena.ne.jp/higayasuo/20041220#1103504150
>工数は、リッチな業務ロジック層とDTOパターンのほうが少なくなります。
>DTOとEntityを相互変換する手間がかからないためです。

リッチなドメインオブジェクトパターンではDTOは(めったに)使わないですよ。

150 :デフォルトの名無しさん:04/12/20 10:32:13
>>145
厳密に定義されてなければ、同じ言葉を別の意味でつかっても混乱をまねかない、ってもんじゃないだろ。

151 :デフォルトの名無しさん:04/12/20 11:04:47
>>147
>この場合のオブジェクトZは単一責任の原則をやぶってると思う?

システム領域の機能とビジネス領域の機能を一緒に持たせて単一責任も何も。
ナイーブすぎませんか?

152 :44:04/12/20 11:11:49
> オブジェクト指向について意見を書くことは、特にデータと
> 振る舞いを1つにすることが、常に正しいとは限らないなんて
> 書くことは、私にとってものすごくリスクの高い&なんのメリット
> のないことです。
>
> にもかかわらず、あえて書いているのは、正しくオブジェクト
> 指向を実践しているように見えても、それが保守性の低下を招く
> 場合もあるということを認識して欲しいということです。

これの例として

> EntityDを使う新たな業務機能が追加されるたびにEntityDに
> メソッドを追加していくと、EntityDは次第に複雑に
> なってきます。

を挙げられているようですが、
EntityDが複雑になる原因は、データと振る舞いを1つにしたことではなく、機能の追加によって次第にEntityDの責務が単一でなくなっていくからです。
このような場合、「データと振る舞いを分割する」のような極端な方法に走らなくとも、EntityDが持つ責務に応じてExtract Classしてやればよいと思います。


> 薄いサービス層とリッチなドメインオブジェクトパターンは、
> 業務機能Aに仕様変更が入っても業務機能Bに仕様変更が入っても
> EntityDを修正することになります。

業務Aから呼ばれようが、業務Bから呼ばれようが
EntityDの持つ責務に変更が入ったのだからEntityDに修正が入るのは
当然だと思いますが。

153 :44:04/12/20 11:13:19
>>151
どちらがシステム領域で、どちらがビジネス領域?
両方ビジネス領域だと思いますが?


154 :デフォルトの名無しさん:04/12/20 11:14:14
だから、「ナイーブなオブジェクト指向」じゃなくて
「ナイーブな」オブジェクト指向、って感じで普通に使ったんじゃないの?て話。

148も150も、ナイーブって言葉をはじめて聞いたんでしょうか?
俺、もっと普通に使う言葉だと思ってましたよ。
151がさりげなく使ってるように。

ばかばかしいからこの話やめな。
「ナイーブなオブジェクト指向」って言葉は
テクニカルタームとして、ヨードン、コードが定義した内容でフィックスされてて
ひが氏の使い方は間違い、で、俺の負け、それでいいよ、もう。

155 :デフォルトの名無しさん:04/12/20 11:17:34
ナイーブだナイーブだ言ってる人たちは

http://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?DomainModel

を知ってるのだろうか。

156 :デフォルトの名無しさん:04/12/20 11:26:10
>>153
確かに、ログインした職責によって
権限を切り替えたりとか、ビジネス領域ですね。

ただ、認証クラスが処理した結果取得出来た属性(IDや職責)を
社員クラスにセットしてやるだけで後はいいじゃん、とか
給料計算を社員自身にさせるのはどうかなあ、とか
議論のある所だと思います。

正解がないだけに色々と人によってまちまちになっちゃうから
いっその事統一ルールで、データの振る舞いは
全部分けちゃえって話だと読みましたがどうでしょう。

157 :デフォルトの名無しさん:04/12/20 11:28:34
>>155
前スレでその話は出たのです。
貧血症でも金欠症よりはましだという
はぶさんの言葉もありましたな。

158 :デフォルトの名無しさん:04/12/20 11:29:14
別にS2使うからといってくーすを守らないといけないかというとそんなことはないし
くーすが気に入ったからと言ってS2でないと駄目ってことでもないし。
そもそもどっちもマイナーなんだし放置でいいんじゃないのと思うのは俺だけか?

159 :デフォルトの名無しさん:04/12/20 12:23:58
>>153
>両方ビジネス領域だと思いますが?

J2EEが提供するような低水準サービスと間違われたか? スマソ
情報システム以前に存在する概念(実体)とシステム化に伴う
概念とを一緒にするのがどうかってことなんだけど。
ところでシステムにログインできるのは社員だけ?
役員や派遣社員は? バイトを雇ったら?
漏れはログインに関わる機能が社員にあるのは、
例としても不適切すぎると思うが、
44氏はアダルト、で、俺の負け、それでいいよ、もう。

160 :デフォルトの名無しさん:04/12/20 13:01:10
>>159
おっしゃることはわかりました。けど

you arent gonna need it.

今想定しているシステムでは
-社員のログイン
-社員の給料計算
しかやらないのでこれで十分ですw
必要になったらリファクタリングしましょう。


161 :デフォルトの名無しさん:04/12/20 13:03:53
>>159
その話は面白いので、いいよもうで逃亡しないで
もっとやって下さい。

ログインが159の言う意味でのシステム領域か
ビジネス領域かは案件によって様々で
一概にはいえないと思いますけど、
後半は全く同意で御座居ます。

162 :デフォルトの名無しさん:04/12/20 15:21:38
勝ち負けの争いだったのか。
ということは、傍観してる俺の勝ち。

163 :デフォルトの名無しさん:04/12/20 16:50:57
http://d.hatena.ne.jp/higayasuo/20041219#1103445985
>
> http://d.hatena.ne.jp/makotan/20041219#p4
>
> で、うまくまとめられてると思いますが、できる限りスコープ(役割)を小さく抑えることで、
> 修正が入ったときの影響範囲が小さくなり、保守性が増します。

リンク先を読みましたが、データと振る舞いを分けるメリットが
よく分かりません。
データと振る舞いを分けるとなぜ修正の影響範囲が小さくなるのでしょうか?

また、私には逆にデメリットばかりが思いつきます。

-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)


> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。

簡略化するために常に分離しないことにしても良いのでは?


164 :44:04/12/20 16:53:51
> 2chとのやりとりは、正直ブルーだったけど、44氏にありがとうといわれて、
> うれしかったです。これからも、よろしくお願いします。

そんなご丁寧にw
こちらこそよろしくお願いします。


165 :デフォルトの名無しさん:04/12/20 21:16:58
ナイーブな人だな。

166 :デフォルトの名無しさん:04/12/20 22:46:09
>>147
これ実際のプロジェクトでやられたら激しくやだ
calculatePayはどう考えても社員クラスにもたすべきじゃない。
44は実務でこんな設計してんの?それとも実務を知らない学生さんなのか?

167 :デフォルトの名無しさん:04/12/20 23:32:04
給料が社員自身のパーソナリティに強く依存している会社なんだよ。
月給=体重/(身長*身長) 万円 とか。

168 :44:04/12/20 23:38:05
>>166
> >>147
> これ実際のプロジェクトでやられたら激しくやだ
> calculatePayはどう考えても社員クラスにもたすべきじゃない。
> 44は実務でこんな設計してんの?それとも実務を知らない学生さんなのか?

アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
文句があるならロバート・C・マーティンへどうぞw

冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。


169 :デフォルトの名無しさん:04/12/20 23:39:41
さむいねw>167

170 :デフォルトの名無しさん:04/12/20 23:58:42
S2Dao使ってるんだけど、ログのレベルどうにかならないかな。
SQL文のログと、「トランザクションを〜」のログレベルが同じなのはどうかと思う。
SQL文って障害解析時に使うけど、「トランザクションを〜」が同じレベルで存在してると、ウザイ。

171 :デフォルトの名無しさん:04/12/21 00:27:25
実運用時にSQLをログに吐いたりするもんなのか?

172 :デフォルトの名無しさん:04/12/21 00:44:04
>>168
>アジャイルソフトウェア開発の奥義の125Pから持ってきた例なので、
>文句があるならロバート・C・マーティンへどうぞw
書いたのが誰であれ、自分が引用したんだから、自分で責任もって答えたらどうなの?
やっぱり学生さんなのか?

>冗談はさておき、calculatePayを社員へ持たすべきじゃない理由を教えてほしいんだけど。
1.社員の情報だけじゃ給与計算なんて出来ん
勤怠情報とか、税金とか、手当てとか、あと成果主義の会社だったら
会社の業績とかが給与計算に必要なわけで、calculatePayを社員にもたすと
社員とその他もろもろのあいだに依存関係が出来る。
2.calculatePayを社員にもたすと給与計算の変更があるたびに社員クラスを変更しなければならない
そのときに社員クラスにバグを作りこまないという保証がない。
3.calculatePayは月給を計算するんだとして、ボーナスはどうするのか、出張旅費清算はどうするのか?
社員クラスにcalculateボーナスメソッドを持たすとして、会社の制度が変更になってボーナスがなくなったらどうすんの?


173 :デフォルトの名無しさん:04/12/21 00:48:03
>>168
やっぱり給与計算となると、
皆自分の経験したり勉強した
実務の事考えちゃうんだと思う。

そうなるとはぶ氏のいってるような事を
考えちゃって、違和感を感じる、と。

>160で、この例ではそこまで想定してないから
YAGNIだって書いてあるけども
簡略すぎて逆にイメージ湧かないんだと思います。

174 :173:04/12/21 00:50:42
おっと、ちょうどそんなレスとかぶった。
>172
そんな訳で、このお題に関しては、そこまではYAGNIらしいんだ。

175 :デフォルトの名無しさん:04/12/21 00:57:22
44に逆に質問
図形クラスがあったとして、saveメソッドを図形クラスに持たせるべきかどうか?
複数の保存形式をサポートしたい場合、saveメソッドを図形クラスに持たせた場合と
別のクラスに持たせる場合で修正の影響範囲ばどちらが小さいか?

、saveメソッドを別のクラスに持たせる場合
-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)
というデメリットが実際に起こるかどうか?

44はくーすがどうたらいう前に、オブジェクト指向を勉強しなおした方がいいと思う。


176 :173:04/12/21 01:02:05
>172
何度もすんません。せっかくだから自分でも考えてみた。

1はなるほど。

2は、社員クラスだろうと給与計算だろうと、変更のリスクは同じかなーと。
どちらかというと、そのリスクを回避するために、
テストがよりしやすいのはどっちかな?って話に持ってった方が吉だと思う。

3は、給与計算に出張旅費生産を組み込むのはちょっと仕事させすぎだと思う。
俺だったら経費の支払と給与計算は別にする。
仕訳も作ったりする場合、まったく別だしね。

最終的に銀行に振り込む情報を管理する機能(例えばFBデータを管理するクラスとか)や
給与明細を出力する機能はこれまた別じゃないか、と。

3はちょっと揚げ足気味かな、ごめん。でも気になったので。
ボーナスは、うーん、どうしよう。

177 :デフォルトの名無しさん:04/12/21 01:05:15
170に賛成。
171は、障害出たとき、スタックトレースだけを頼りにしてるのか?
SQLExceptionだったら、どうするんだ?SQL文なくても分かるのと、分からないのあるだろ。

178 :デフォルトの名無しさん:04/12/21 01:19:01
> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。

MMRのキバヤシの口調に似てる。

179 :デフォルトの名無しさん:04/12/21 01:43:10
ところではぶさんの日記みて、思ったんだが、直接S2とは関係ない、全般的な問題だとは
思うが、Strutsを使った時のDTO <--> ActionForm変換の手間をなんとかできんものか....

180 :デフォルトの名無しさん:04/12/21 01:48:24
おれは逆に、「トランザクションを〜」のメッセージも障害解析時に使う、と
思ったんだけどどうだろうか。「あーここでロールバックしてるわ」とかそういう
情報になるしさ。

181 :デフォルトの名無しさん:04/12/21 02:18:12
>>170
org.seasar.extension.jtaだけINFOにするとかで止めれるんじゃない?

182 :デフォルトの名無しさん:04/12/21 11:44:00
どこに責任があるとかないとか考えて、モノによって処理が書いてある場所が微妙に違うのが一番困る。

183 :デフォルトの名無しさん:04/12/21 21:52:55
それは無責任ですな。

184 :44:04/12/21 22:01:38
>>172
1と3のような要件の時にはcalculatePay持たすべきじゃないかもしれないけど、
「社員の給与は社員の役職によってのみ決まる」という場合には社員に持たせてもいいと思うんだけど、どう?

また、2の考えを押し進めると以下の(A)を(B)のようにするべきという話になると思うんだけど、こんなクラス、ちょっとありえないよね。
なので2の考え方は間違ってると考えます。

=== A ===
class Stack
 def push( o )
  ...
 def pop
  ...
end
=== B ===
class StackData
 ...
end

class StackPush
 def push( stack_data, o )
  ...
end

class StackPop
 def pop( stack_data )
 ...
end

185 :44:04/12/21 22:04:55
>>175
ごめん、質問の意図がわからないよ。


186 :デフォルトの名無しさん:04/12/21 22:07:12
stackのpushとpopは対(つい)の操作。
calculatePayとisExpiredは無関係。
そんな例示でいったい誰を説得しようというのか。

187 :デフォルトの名無しさん:04/12/21 22:08:43
>>184
> 役職によってのみ決まる

役職によって決まるんなら、役職に持たせれ。

188 :44:04/12/21 22:14:00
>>173
そっかー。
いろいろいい例を考えてはみたけど、漏れの貧弱な想像力ではいいサンプルが思い浮かばなかったんでつ orz

189 :デフォルトの名無しさん:04/12/21 22:20:12
役職はクラスじゃないだろう。
給料の計算はPaymentCalculatorクラスにまとめるでどうよ。

190 :44:04/12/21 22:20:30
>>186
> stackのpushとpopは対(つい)の操作。
> calculatePayとisExpiredは無関係。
> そんな例示でいったい誰を説得しようというのか。

対の操作 = ひとつのロール、だよね。

172は、例えひとつのロールとして表すべきクラスでも、
エンバグの危険を避けるためにデータと処理を分けるべき、と言っていると思ってるんだけど。

もしそうじゃなかったとしたら、172の2の反論自体無効だね。
だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。


191 :デフォルトの名無しさん:04/12/21 22:37:35
>>189
> 役職はクラスじゃないだろう。

なぜ?
役職によって違うなら、役職ごとに違う処理を役職ごとに実装するのはありだと思うが。

192 :デフォルトの名無しさん:04/12/21 22:58:56
>もしそうじゃなかったとしたら、172の2の反論自体無効だね。
>だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。

calculatePayとisExpiredはひとつのロール?
おれはどう考えても別々のロールだと思うんだけど。



193 :44:04/12/21 23:03:36
>>192
> calculatePayとisExpiredはひとつのロール?
> おれはどう考えても別々のロールだと思うんだけど。

コンテキストによる。

194 :デフォルトの名無しさん:04/12/21 23:26:31
おれはインスタンス変数だけで処理が完結するなら、その動作は該当クラスに乗せても
いいと思う。

あくまでモデルの話だけどさ。

195 :デフォルトの名無しさん:04/12/21 23:49:10
>>193
じゃそんな例出すなよ。コンテキストによるなんていわれたら議論のしようがない。
おれはcalculatePayとisExpiredがひとつのロールになるコンテキストなんて現実にはほとんどありえないと思うが。

196 :デフォルトの名無しさん:04/12/21 23:55:42
それに
>>147
>この場合のオブジェクトZは単一責任の原則をやぶってると思う?
>おれは思わないよ。
ていってるのはなんなんだ?これを見たら普通44はcalculatePayとisExpiredがひとつのロール
だと考えてると思うんじゃない?

197 :デフォルトの名無しさん:04/12/22 00:31:50
役職はStateパターンにして、社員にくっつければ?

198 :デフォルトの名無しさん:04/12/22 01:15:56
> 役職はStateパターンにして、社員にくっつければ?
なんでも適当に言えばいいってもんじゃないぞ

199 :デフォルトの名無しさん:04/12/22 06:30:10
>>198
いや、そんなに悪くないんじゃない?
俺の場合、役職に関する処理が増えた場合はそれを採用するかも。

200 :197:04/12/22 09:34:04
昇進したら役職Stateを取り替えるだけ。
ある役職の処理が変わっても、社員や他の役職のソース修正しなくて済む。
けっこう良かったですよ。

201 :デフォルトの名無しさん:04/12/22 10:03:05
>>200
役職や職責でstateパターンってまだ試した事無いんだけど
どうも永続化が、って逆か、DBから読み込んで
Entityを生成する時が面倒な気が、ぼんやりとするんです。
どうでした?俺が判ってないだけかなー。

202 :デフォルトの名無しさん:04/12/22 10:57:48
役職は状態遷移じゃないだろう。このスレ大丈夫か?



203 :デフォルトの名無しさん:04/12/22 11:23:43
現実世界では役職と状態遷移は違うものでしょうけども
197の提案は、同じ設計パターンが使えませんかねって話なので
202は反論になってないです。

ファウラーに、在庫推移は複式簿記で管理しないだろ、大丈夫かお前?
といってるようなもんじゃないでしょうか。

もうちょっとダメな理由を詳しくよろしく。

204 :デフォルトの名無しさん:04/12/22 12:48:01
>>202
デザインパターンはマニュアル思考しかできない人間を生産してしまう
などというトンチキな批判がうまれる原因w

205 :デフォルトの名無しさん:04/12/22 13:40:53
>>203
処理中心になってしまうかもしれないけど、考え方としてはStrategyパターンで行ったほうが素直なのではないでしょうか?
やっぱり、役職は状態ではないと思う。
話が戻ってしまうかもしれないが・・

206 :デフォルトの名無しさん:04/12/22 14:01:45
>>201
Hibernateにおまかせ。

207 :デフォルトの名無しさん:04/12/22 14:15:34
状態は列挙のうち一つしかもてない。役職は複数もてる(もしくは持たない)ことが一般的。


役職はロール(というオブジェクト)の一種。
組織の規程は、ロールに対して責務を割り当てる。けして個人や部署じゃない。これはビジネスルール。
個人や部署はパーティとしてまとめられる。
パーティはN個のロールを持てる。
組織の規程は、パーティへのロールの割り当て方について制約を課す。これもビジネスルール。

208 :デフォルトの名無しさん:04/12/22 15:53:55
GOFとかちゃんと読んでるのか、おまえら

209 :デフォルトの名無しさん:04/12/22 15:56:50
DIとかくーすに話を戻しましょう。

210 :デフォルトの名無しさん:04/12/22 17:39:41
なんで? もう語ることないじゃん。
手続き型マンセー、Transaction Script上等って結論じゃなかったか?

211 :デフォルトの名無しさん:04/12/22 19:06:21
でもSQLだけは勘弁な

212 :デフォルトの名無しさん:04/12/22 19:21:10
エンティティの責任は、データを保持することなので、それ以上の責任を押し付けてはいけません。

213 :デフォルトの名無しさん:04/12/22 19:23:07
給料が社員によって決まるとしても、社員には給料を決める権限などないのです。
給料計算は、給料計算担当者が。

214 :デフォルトの名無しさん:04/12/22 19:25:37
>>211
Aチーム、なつかしーなおい。

215 :デフォルトの名無しさん:04/12/22 23:52:39
>211はコング

216 :デフォルトの名無しさん:04/12/23 01:39:27
>>213
社員は
-自分の役職
-役職からの給与算出方法
のみを知っていれば「権限」などなくても給与計算できます。
よって給与計算担当者は必要ありません。

もちろん、コンテキストによっては給与計算担当者が必要になることがあるかもしれないことは否定しませんが。

217 :デフォルトの名無しさん:04/12/23 01:49:58
>>216
で、社員ひとりひとりに自分で給与計算させる会社があるの?
モデリングとは話が違うかもしれんけど、社員を渡せば給料が返ってくる、給与計算者がいるほうがいいと思うなぁ。

218 :デフォルトの名無しさん:04/12/23 02:38:08
>「社員の給与は社員の役職によってのみ決まる」

この前提がそもそも非現実的で意味無し。

219 :デフォルトの名無しさん:04/12/23 02:54:18
>>218
サンプルコードに何を求めてるんだろう?

220 :デフォルトの名無しさん:04/12/23 03:16:33
現実的なコードじゃない?
あした使えるコード。
あさって納品できるコード。

221 :デフォルトの名無しさん:04/12/23 03:23:17
サンプルコードに関して、>>216-217のような話は無意味では。
「社員が持つべきケースのサンプル」
と、「計算担当者が持つべきケースのサンプル」があるだけ。

222 :デフォルトの名無しさん:04/12/23 05:34:21
で、社員が持つべきケースなんてほとんどないから、意味がないというかサンプルとして有害じゃないの?

223 :デフォルトの名無しさん:04/12/23 06:19:12
だれが、社員と給与で例を示したんだ?
そいつのせいでスレ違いな書き込みばかりになってるじゃないか!

224 :デフォルトの名無しさん:04/12/23 07:15:49
Seasarもくーすも、話題にするような目立った動きないから、いいんじゃない?
ログ見ても、ナイーブがどうこうとか、某blogのアイドル写真がそろそろ邪魔くさいとか、あまりスレタイとは関係ないし。

225 :デフォルトの名無しさん:04/12/23 11:44:27
>>223
どうやらファウラーらしい

226 :デフォルトの名無しさん:04/12/24 01:15:05
>>156
> 正解がないだけに色々と人によってまちまちになっちゃうから
> いっその事統一ルールで、データの振る舞いは
> 全部分けちゃえって話だと読みましたがどうでしょう。

に賛成。
債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。

227 :デフォルトの名無しさん:04/12/24 01:22:01
View やトリガーがあると追えない?
維持すべき設計文書を書いてないだけじゃないかな。

228 :デフォルトの名無しさん:04/12/24 01:32:03
そうすると、一ヶ所に処理を記述したときには、そのソースだけを見ればよかったのが、設計文書とViewなりトリガーなりとJavaのソースと、いろいろなところを見ないといけなくなるわけですね。
しかも、設計文書とJavaソースとViewやトリガは、見るためのツールが違うので、煩雑に。
それだけ追うための手間が増えるわけですよ。

修正の場合も、設計文書を必ず修正する必要があって、この作業は徹底するのにかなりの労力を伴う。
単純に比較すれば、一ヶ所で記述した場合にくらべて、労力自体は増えると思うのですよ。
とくに、設計文書管理の労力。

229 :デフォルトの名無しさん:04/12/24 01:36:25
で、問題はくーすでたびたび話題になってる、作業に関わる人のレベルが一定ではないということですね。
実際には、問題になるのは、レベルではなくて、考え方で。
むしろレベルが高い、考え方の違う人が書いたシステムが非常に追いにくくなるわけで。
システムを追う前に、どのような考え方で書かれたのかをプロファイリングしないといけない。

230 :デフォルトの名無しさん:04/12/24 01:51:24
ドキュメントは非常に儚いので、アプリケーションの枝葉がドキュメントに依存するのは、問題があるんじゃないかと。
アプリケーション独自のロジックに関しては、ドキュメントがなくてもわかるようなものが理想で。

ただし、アプリケーションの骨格がドキュメントに依存するのは仕方がないと思う。
でも、アプリケーションの骨格は、揺るぎにくく共通化しやすいから、その部分をみんなで使えるようにしましょう、と。
で、そのアプリケーションの骨格のドキュメントが、くーすなのかなぁと思う。

231 :デフォルトの名無しさん:04/12/24 07:11:05
シンプルなオブジェクトを複雑に組み合わせるのと、複雑なオブジェクトをシンプルに組み合わせるのと、どっちがいいんだろう?

232 :デフォルトの名無しさん:04/12/24 10:23:03
>>226
> に賛成。
> 債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
> DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。

債務(さいむ)じゃなくて責務(せきむ)な。

233 :デフォルトの名無しさん:04/12/24 10:59:07
ドキュメントが儚い?
恥ずかしげも無くよく言えるな、おい。
XPerもどきの増殖にも困ったもんだ。

234 :デフォルトの名無しさん:04/12/24 11:54:34
>>233
数度の変更を経たにもかかわらず、ちゃんと同期しているドキュメントをみたことがない。

235 :デフォルトの名無しさん:04/12/24 12:00:19
俺も無い



236 :デフォルトの名無しさん:04/12/24 12:13:41
233は、よほど躾の行き届いた組織にいるらしい。
うらやましいな。

237 :デフォルトの名無しさん:04/12/24 12:16:24
ActionFormにインジェクションできますか?

238 :デフォルトの名無しさん:04/12/24 12:56:08
見た事がないというか、出来た事がない_| ̄|○|||
先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。

アジャイルって本当に素晴らしいモノなのかな?なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・

239 :デフォルトの名無しさん:04/12/24 13:20:43
ここはサンデープログラマのスレですか?

240 :デフォルトの名無しさん:04/12/24 13:27:04
234はSCMをしないPRJにしかいたことがないようだな。
変更管理をきっちりすれば同期問題はおきないぞ。

241 :デフォルトの名無しさん:04/12/24 13:37:09
>>240
だから、変更管理をきっちりしてる
プロジェクトで仕事した事がない、って話なんです。
ちっこい案件は別だけど。

242 :デフォルトの名無しさん:04/12/24 14:06:25
>>241
PMがマヌケということか。同情するよ。
まぁ、悲観するな。そのうちまともなPRJに出会えるから。

243 :デフォルトの名無しさん:04/12/24 18:46:41
>>240
構成管理をきっちりしないと、同期問題がおきるってことでしょ。
で、構成管理をきっちりすることは、組織的な成熟度が高くないといけない。
適用しやすい開発方法論を考えるのなら、
「こうやればうまく開発できます。でもドキュメントが大切なので、構成管理はきっちりやってください」
というものはどうかと思う。

構成管理がきっちりできるなら、他の能力も高いことが多いから、どうとでもやってくれという感じ。

244 :デフォルトの名無しさん:04/12/24 19:21:28
             ___
.            |(・∀・)|
.            | ̄ ̄ ̄   ジサクジエン王国
         △
        △l |
   __△|_.田 |△_____
      |__|__門_|__|_____|_____


245 :デフォルトの名無しさん:04/12/24 20:25:35
データと振る舞いは別クラスにすべき、と言っている人たちは
TheBlobを避けるためにPoltergeistに向かっているように思うなー。

The Blob
http://www.antipatterns.com/briefing/sld024.htm

Poltergeist
http://www.antipatterns.com/briefing/sld030.htm

246 :デフォルトの名無しさん:04/12/24 21:56:59
結局、適材適所
だからフレームワークは無用
プログラミングしよう

247 :デフォルトの名無しさん:04/12/24 23:21:51
243は、ある程度の規模のPRJで構成管理をやらなければ開発は頓挫するという事実が理解できていないようだ。
まぁ、わからないでもないよ。最近は知ったかぶりのアジャイル莫迦が多すぎるからな。
JAVAWORLDも酷い記事を書くやつが増えたが、編集は何をやっているんだか。


248 :デフォルトの名無しさん:04/12/24 23:55:56
>>247夜釣りご苦労。

249 :デフォルトの名無しさん:04/12/25 00:24:40
ちなみにくーすの元ネタICONIXは、シーケンス図とかの中間成果物は
使い捨てで、ソースコードとの同期はやらないんだよね。


250 :デフォルトの名無しさん:04/12/25 00:44:07
あれ?
捨てはロバストネス図じゃなかったっけ?

251 :デフォルトの名無しさん:04/12/25 00:44:27
あれ?
捨てはロバストネス図じゃなかったっけ?

252 :デフォルトの名無しさん:04/12/25 00:46:05
あれ?あれ?あれ?あれ?あれ?あれ?あれ?
あれ?あれ?あれ?あれ?あれ?あれ?あれ?
あれ?あれ?あれ?あれ?あれ?あれ?あれ?
あれ?あれ?あれ?あれ?あれ?あれ?あれ?
あれ?あれ?あれ?あれ?あれ?あれ?あれ?

253 :243:04/12/25 04:43:59
元の話にもどすと、サーブレットフィルターやAOPやDBのトリガーなど、コードに現れない形で処理が分散するときには、ドキュメントを同期したにしても、ドキュメント自体が分散しがちで、結局わけがわからなくなりそう。
もちろん適切に使えばよいけど、一度乱用する時期を経ないと適切に使えないと思う。
プロジェクトの発言権を持った人の中に乱用する時期の人がいる可能性も高い。

254 :243:04/12/25 09:15:37
まとめれば

「ドメインモデルは、複雑なコードを整理しやすいのがメリットだ。
ただ、開発者にとって理解しにくく、またRDBMSとのマッピングが複雑になる。
そこで、ORマッピングレイヤを設けなくてはならない。
そのため、ドメインロジックがシンプルな場合は、トランザクションスクリプトを採用した方がいい。」

ということだ。やっぱファウラータンは俺のために言葉を用意してくれてて偉いな。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html

255 :デフォルトの名無しさん:04/12/25 11:49:58
>>254
そんな考えはレガシーで、ドメインモデルは複雑な
ロジックを記述するには向かない
という考えってどうよというのが先週からの話。
少しは流れを嫁。

256 :デフォルトの名無しさん:04/12/25 11:59:49
>>255
つまり、すごく複雑ならドメインモデルでちょっと複雑ならトランザクションスクリプトっていってるのを、すごく複雑でもトランザクションスクリプトでってこと?

257 :デフォルトの名無しさん:04/12/25 12:10:33
お父さんは貧血症

258 :デフォルトの名無しさん:04/12/25 12:17:38
>>256
この辺かな。
http://d.hatena.ne.jp/higayasuo/20041223#1103771319
1週間くらい前からいろいろもとねたがある。

259 :デフォルトの名無しさん:04/12/25 12:23:36
ドメインモデルを作っても貧血になっちゃうからよくない、と。

260 :デフォルトの名無しさん:04/12/25 12:25:56
> 1.あるコンポーネントは自分で処理するか、自分よりも詳細なことを知っている別のコンポーネントに処理を任せる。
> 2.1を再帰的に繰り返す。

構造化じゃん。

261 :デフォルトの名無しさん:04/12/25 12:34:10
>>260
メソッド分割なのかコンポーネント分割なのかという話だと思うよ。
ちなみにそれが構造化ならあらゆる処理がが構造化。
自分で処理するか他人に任せるしかないんだから。

262 :デフォルトの名無しさん:04/12/25 12:38:20
ドメインモデルを適切に構築するのは難しいから、いっそのことトランザクションスクリプトでってこと?
でも、トランザクションスクリプトじゃない、って書いてある。

ここに書いてあるのは、トランザクションスクリプトを構造化したらいいって話だよね?
そしたら、コマンドパターンっぽく切り替えやすくなると。
構造化って、おおざっぱなものが細かいものを再帰的に内包するモデルのことだよね?
違うの?

263 :デフォルトの名無しさん:04/12/25 12:45:11
デマルコの「構造化分析とシステム仕様」に、なんだかそのものズバリの図が書いてあるんだけど・・・。
で、Javaだと、ひとつの処理をひとつのオブジェクトに割り当てるといろいろ切り替えれて便利、っていう話だと思ったんだけど。

264 :デフォルトの名無しさん:04/12/25 12:53:17
Javaの場合は関数ポインタもないし、言語仕様としてはメソッドはオブジェクトではないからクラスに追加したり切り替えたりできない。
ってことで、オブジェクトに持って切り替えれるようにしましょうってことでしょ?
切り替える用途やら規模によって、ストラテジーだとかコマンドとかステートとか、いろいろパターン名が変わるだけで。

265 :デフォルトの名無しさん:04/12/25 12:59:51
>>262
たぶん、構造化というよりは、自分の役割だけをこなしてあとは、
人に任せるということなんだと思う。
ドメインモデルは、1つのクラスに役割が集中しすぎる危険性があるという話。

266 :デフォルトの名無しさん:04/12/25 13:32:42
>>265
言い方が違うだけで、構造化とやってることは同じだと思うけど。
人=オブジェクトって考えが出てるけど、これはJavaの言語仕様上オブジェクトが便利なだけで。
関数ポインタが使えるか、メソッドを代入できる言語では、オブジェクトである必要はなさそうだし。
そのオブジェクトはステートレスなんだよね?

つまりは、ドメインモデルを適切に構築するのは難しいから、構造化されたトランザクションスクリプトで、ってことでしょ?

267 :デフォルトの名無しさん:04/12/25 13:43:17
で、手続き呼び出しの構造化ツリーの構築にDIが便利と、そういうことでしょ?

ただ、ここでインターフェイスを持ち出してくる必要があるのかないのか。
インターフェイスはテストの都合で必要なわけで。
処理を動的に切り替える予定がない部分をインターフェイスにする理由は、それしかないよね?

268 :デフォルトの名無しさん:04/12/25 13:43:59
あ、AOPもか。

269 :デフォルトの名無しさん:04/12/25 14:00:59
なんかトランザクションスクリプトってことになんとか持っていきたいように思えるが、
「モデル」部分を「単純なデータ保持/DBアクセスオブジェクト」として完全委譲した
だけで、これはドメインオブジェクトだって理解した方がいいんじゃないの?

トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
メソッド一つで全部やってしまうようなもんだろ。

プレゼンテーション層 -> サービス層(薄い) -> ドメインモデル(モデルを基準に分割/ORマッピングもする) ->DB

プレゼンテーション層 -> サービス層(薄い) -> ドメインオブジェクト(サービスを基準に分割) -> 薄いモデル(ほぼORマッピングだけする) -> DB

になっただけなんじゃないの? どっちみちサービスの連鎖の開始ポイントとして、Facade的な
薄いサービス層は現れてしまうし。
で、薄いモデル部分がドメインモデルと比べて明らかな貧血症だから騒いでるだけだろ。
俺にはデータアクセスをドメインモデルから外に出して、分割の基準を変えたように見える。

270 :デフォルトの名無しさん:04/12/25 14:18:51
トランザクションスクリプトじゃなんで嫌なのかがよくわからんけど、先のblogだけ見ると構造化されたトランザクションスクリプトにしか見えないんだよね。
結局サービス層のことをドメインと呼んで、その前に置いたコントローラー的な層をサービス層と呼んでるんじゃない?
で、実際にドメインになる部分が薄くなって、「ドメインモデル貧血症」になってるからどうこう言ってるんじゃないの?

いや、よくわからんのだけど。

271 :デフォルトの名無しさん:04/12/25 14:19:40
分割の基準を変えたように見えるという点では同じかな?

272 :デフォルトの名無しさん:04/12/25 14:24:06
>>267,268
学生ですか?
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある?

273 :デフォルトの名無しさん:04/12/25 14:26:26
> トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
> メソッド一つで全部やってしまうようなもんだろ。

いや、ドメインモデルを構築する代わりに全部1つの流れでやりましょうっていう形。
だから、ドメインモデルと置き換わるはず。
で、もちろん1つのメソッド・ひとつのオブジェクトで完結する必要はないと思う。
サービス層は、適切なトランザクションスクリプトを呼び出す層ということになるんじゃない?

274 :デフォルトの名無しさん:04/12/25 14:30:12
>>272
> 手作業でトランザクション制御する手間

トランザクションが必要で、それがAOPで実現されてるならインターフェイスを使うしかないね。
で、機能拡張とか仕様変更とかの話だと、ソース追う手間が増えることを考えると、一概に言えるのかなぁ。
ソース追う手間は、無視してしまえる程度にしか増えないものなの?

275 :デフォルトの名無しさん:04/12/25 14:33:31
機能拡張とか仕様変更とかで、インターフェイスが便利なときは、そのときインターフェイス作るっていうのは?
いままでのクラスと同じ名前でインターフェイス作れば、ソースは変更しなくていいし、オブジェクトの生成はDIでやってるわけだからそこ書き換えるだけじゃないかなぁと。

276 :デフォルトの名無しさん:04/12/25 14:38:52
ttp://www.nri-aitd.com/tips/g-patern.html
これなんか読んでると、別にトランザクション・スクリプトでもいいじゃん、という気になる。

おれ、ドメインモデルってモデル間が密結合しすぎのような気がするんだけど。

277 :デフォルトの名無しさん:04/12/25 14:47:03
その記事に書いてある通り、どっちがいいかはビジネスロジックの複雑さに依るのだろう。

278 :254:04/12/25 14:53:06
>>255
結論は同じところに落ち着きますた。

279 :デフォルトの名無しさん:04/12/25 15:04:29
>>278
複雑な業務ロジックだと、トランザクションスクリプトには
向かないというのはなぜ?
別にトランザクションスクリプトはどうでもいいんだけど、
コンポーネント分割でDIで組み立てるやり方なら、
逆に複雑な業務ロジックに向いてると思うけど、
理由は、それぞれのコンポーネントは小さいから。
ドメインモデルは、複雑なロジックになればなるほど、
クラスは大きくなる。

280 :デフォルトの名無しさん:04/12/25 15:28:04
>>279
複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ?
なにか説明するにしても、ファウラーの言葉の引用になりそう。

とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
で、複雑な業務ロジックの場合は、オブジェクトが状態を持ったほうが好都合なんじゃないのかなぁ。

281 :デフォルトの名無しさん:04/12/25 15:29:35
ドメインモデルで複雑なロジックになればクラスが大きくなるというのなら、そのときトランザクションスクリプトならそれぞれのコンポーネントを小さく保てるのはなぜ?

282 :デフォルトの名無しさん:04/12/25 15:41:59
>>281
複雑なロジックを単純な役割に分割してそれぞれの役割にコンポーネントを
割り振るからだろう。
それぞれの役割は単機能だから小さい。
ドメインモデルだとデータに対して振る舞いを割り当てるから、
複雑になればなるほど、やらなければならない役割が増える。

283 :デフォルトの名無しさん:04/12/25 15:47:38
>>280
> >>279
> 複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ?
> なにか説明するにしても、ファウラーの言葉の引用になりそう。

引用は別に良いと思うけど、理由を説明できなければ意味はない。
ファウラーたんも盲目的に信じて欲しいとは思ってないと思うけど。

> とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。

そんなことどっかに書いてある?


284 :デフォルトの名無しさん:04/12/25 15:48:11
トランザクションスクリプトだと単純な役割に分割できるときに、ドメインモデルだと単純な役割に分割できないことになるのはなぜ?

285 :デフォルトの名無しさん:04/12/25 15:49:57
>>283
> そんなことどっかに書いてある?

そうじゃないの?

286 :デフォルトの名無しさん:04/12/25 15:58:55
>>284
>>282に書いてあるじゃん。分割単位が役割じゃなくてモデルだからだろ。

287 :デフォルトの名無しさん:04/12/25 16:14:55
そのモデルが適切に分割できないということになるのはなぜ?

288 :デフォルトの名無しさん:04/12/25 16:39:26
さあ? DBのテーブル構造に依存しちゃったんじゃないか? モデルって永続化のやるしねえ。

289 :デフォルトの名無しさん:04/12/25 16:43:00
逆に、モデルを適切に分割することができないとして、そのときトランザクションスクリプトを細切れに分割したところで、おおきなドメインのモデルよりも有効だと言えるの?
トランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな?

290 :デフォルトの名無しさん:04/12/25 16:44:21
>>288
ORマッピングで、1つのテーブルをいくつかのオブジェクトにマッピングできるものもあるわけだし。

291 :デフォルトの名無しさん:04/12/25 16:59:38
>>289のいいたいことがよくわからんのだが、ドメインモデルに比べればそんな利点は霞むと
いいたいのか、大して変わんないんだからドメインモデルでいいじゃんといいたいのか、
言ってることに利点など何もない、問題は存在しないといいたいのか。

292 :デフォルトの名無しさん:04/12/25 17:00:37
スレ違いだけど、ちょっと気になったんで、確認させてください。
デマルコの「構造化分析とシステム仕様」は、「構造化」の原典のひとつだと思って引っ張ってきたんだけど、違ってる?

293 :デフォルトの名無しさん:04/12/25 17:01:10
>>289
分割統治せよは、昔から言われている真実。
大きいより小さいほうが中身がわかりやすいのは当たり前。
複雑なドメインロジックの場合、データと役割は単位(大きさ)が
かみ合わないことのほうが多いので適切に分割できない。
たいていの場合、1つのデータに多くの役割が集中する。
なぜかっていうとそのデータに関する役割を集めるからね。
必然的にそうなる。

294 :デフォルトの名無しさん:04/12/25 17:02:35
>>291
ドメインモデルが分割できないときに、細切れのトランザクションスクリプトをばらまいても、問題を複雑にするだけということはないだろうか?と。

295 :デフォルトの名無しさん:04/12/25 17:03:02
ちょっと前にも出てたけど、ドメインモデルってモデルを基準に機能をどこにおくか
考えるからさ、「この機能、どこにおいてもぴったりしない」とかいうことがあるよねえ。
で「社員Util」とか変なのがいつのまにか作られてたり。

俺はサービスを分割基準に置くのは悪い考えではないと思うし、それによってオブジェクト指向的な
利点を無効にしてしまうこともないと思うよ。
モデルの役割をモデル内データの管理とその永続化だけにしようって考え方も、とてもオブジェクト
指向的だとおもうけど。

296 :デフォルトの名無しさん:04/12/25 17:06:51
>>294
んん? 単にモデルにはモデルの役割だけさせて、ビジネスロジックはモデルの役割じゃないから
サービスとして分割しようって言ってるだけだと思うんだけど。

サービスとして分割してしまえば、分割の自由度は上がる。でも意味もなく細切れにしたら混乱する
のはあたりまえ。「ここは分割しなきゃ」と思ったときに、ドメインモデルだと分割しにくいけども、
サービスだけならきれいに分割できることがあるってだけ。

297 :デフォルトの名無しさん:04/12/25 17:07:09
>>292
間違ってないよ。
なんか構造化は悪いものだとか、オブジェクト指向とはかみ合わないとか
勘違いしているやつが多いのか。

298 :デフォルトの名無しさん:04/12/25 17:19:33
ようするに、ttp://www.nri-aitd.com/tips/g-patern.htmlのグラフだと、トランザクションスクリプトは問題が複雑になったときに加速度的に設計コストがあがってるけど、そうではない、っていうことなんだよね?
実際、ここにはドメインモデルがいいとは書いてあるけど、トランザクションスクリプトがダメな理由は書いてないね。

だから、どっちも疑問といえば疑問なんだけど。
ただ、モデル化は視点の問題だと思ってるので、片方のモデルで適切に分割できないのに片方のモデルでは適切に分割できる、というのが、にわかに信じれない。
複雑なものを細切れにすると、単純なものが複雑に散らばるだけなんじゃないかと。
それよりは、大きな複雑なものがあったほうが、見通しも良くていいんじゃないかと思うわけです。
そのとき、それぞれの部品の単純さを主張しても、意味のある主張になるのかなぁと。

実際に上記のサイトのグラフで線が入れ替わるところのような複雑なものは、単純に例示できないだろうから、難しい話だとは思うんだけど。

299 :デフォルトの名無しさん:04/12/25 17:26:23
>>297
そう。
だから、なんでヒガさんが構造化だと言われたことを誤解だと斬って捨ててるのか、疑問。

300 :デフォルトの名無しさん:04/12/25 17:27:20
>298
適切って言葉をどう捉えるか。くーす的なのは「いかに維持しやすいか」が視点だろう。
そのかわりドメインモデルの明快な美しさは失われるが、それはビジネスだから諦める。

理屈ではドメインモデルってみんな好きなんだよ。でも仕事で使ってみると
世の中明快に割り切れるものなんてないし、たとえうまく設計できたとしても
システムは完成した瞬間から陳腐化するから維持運営に結構苦労する。

サービス分割って考えは希望が持てる。業務とコードが対応してるから直すときに躊躇がいらない。
将来一部業務に大変更が発生しても、ほかへの影響なしにそこだけ手を入れられるってのはステキだ。

301 :デフォルトの名無しさん:04/12/25 17:40:47
おれは、そのモデルの機能が_本当に_多くて複雑なモデルになるなら、
それはそれでかまわないと思ってる。でも実際には、そのモデルAの役割というよりは、モデルA
とBとCをつかってほにゃららする、という機能が結構あるんだよ。
結果としてAがB、Cを保持したりして実現するわけだ。

それがAというモデルの機能なのか?という疑問というのが1点ある。B、Cでないとどうして
いえるのか? またAでもBでもCでもなく、ABCと取りまとめる別のモデルの機能ではないか?

さらに、その機能のためにAはB、Cを保持してるわけで、結局は「複雑に散らばってる」わけだ。

大きな複雑なモデルってのは、「大きなものがひとつあって、そこだけ見ればなんとかなる」んじゃ
なくて、細切れのモデルが一つのモデルの中で絡み合ってごちゃごちゃになってて、結局全部の
モデルを理解していないと「大きな複雑なモデル」を理解できない。だから「ドメインモデルは全体を
理解してないと使えない」と言われるわけ。さらにモデルが永続化も担うので、役割過剰と言われ
ても仕方がないと思う。

サービス分割も同じ問題ははらんでるよ(あるサービスが別のサービスと絡み合うとかね)。
ただサービスが一つのビジネスロジック上の役割で分割されているので、触るときに影響範囲が
見えやすいし、「あ、これは別の業務だな」と思ったら躊躇なく分割できる。結果として細切れの
サービスができかねないのは事実なんだけど、細切れのものが業務単位でまとまってるので、
多少はまし、といったところか。

302 :デフォルトの名無しさん:04/12/25 17:40:52
誰にツケ回したところで、結局は自分で払うんだべ。

303 :デフォルトの名無しさん:04/12/25 17:44:56
>>300
とりあえず前提条件おさらい。
どうやって計ったかはしらないけど、トランザクションスクリプトだと天井つきぬけるくらいコストがかかるとファウラーが主張するくらいビジネスロジックが複雑なときの話。
で大きいまま分割できないドメインのモデルがある。

そのとき、そのドメインのモデルは、その大きさのままが維持しやすいことになるんじゃないのかなぁ。
将来そのモデルのかかわる一部業務に大変更が発生しても、いろいろなところを追わずに、そのモデルだけ修正すれば済むわけで。
もちろん、分割できないモデルだから、そのモデル全般に影響が及んでるだろうけど。

縁がありそうな程度の複雑さのビジネスロジックでは、>>300に賛成。

304 :デフォルトの名無しさん:04/12/25 17:49:36
>>303
うーん、なんか逆な気がするな。
大きく複雑なモデルは仕事をいろんなモデルに移譲しまくってるので、「業務」単位でみると、
一つの業務追加・変更で複数のモデルに影響がでるよ。
モデルの分割単位はあくまで「なんらかのビジネス上の概念」であって、業務ではないからね。

で、たいていの業務では、「なんらかのビジネス上の概念」が複数絡まってるもんだ。この複数
絡まってる機能をどこにおく?という話じゃないか。

305 :デフォルトの名無しさん:04/12/25 17:50:53
>>301
いや、そのとき、ドメインモデルだと細切れのモデルが絡み合っててごちゃごちゃになってて結局全部のモデルを理解してないくらい複雑なのに、サービス分割だと影響範囲が見えやすく業務単位でまとまってるってことはないんじゃないのかな、と。
サービスを、躊躇なく分割したり業務単位でまとめれるなら、ドメインモデルも同じように分割して業務単位でまとめれる可能性が高いんじゃなかろうか。

306 :デフォルトの名無しさん:04/12/25 17:54:52
ドメインモデルのときは複雑な業務ロジックの話をしてるのに、サービス分割のときはそこまで複雑じゃない業務ロジックの話をしてるように見える。

もちろん、複雑じゃない業務ロジックの話で、ドメインモデルよりサービスでの分割がいいというのは、同意できる。

307 :デフォルトの名無しさん:04/12/25 17:59:13
>>305
そうだね。でもそのようにドメインモデルを分割したら、それはドメインモデルじゃないんじゃない?

ドメインモデルはそのモノが担うべきものだけを提供すべきで、業務的な必要性から関係ない機能を
追加するもんじゃないからさ。理想としては、もし業務要件が複数のモデルが絡み合うものなら、
複数のモデルを直すべきなんだよね。

業務要件で勝手にまとめてどっかのモデルに押し込んじゃったりしたら、ドメインモデル特有のオブジェ
クト指向的美しさは台無しじゃないか? でもビジネスはそんな美しさは関係ない訳で、そこに軋轢があ
るんじゃないか。
サービスだと、そもそも業務単位でまとめるもんなんだし、分割しやすいしまとめやすいってことじゃ
ないかと。まあ業務要件があって仕事があるという現実に即した分割方法じゃないかな?

308 :デフォルトの名無しさん:04/12/25 18:03:57
http://www.nri-aitd.com/tips/image/g-patern_4.gifなんだがな、
まずどういうシステムを対象にどのように測定したのか知りたい。
同じシステムをそれぞれのパタンで作って比較したのか、
それとも色んなシステムを比較したのか。どこかにどのように
調査したのか書いてるのある?

309 :デフォルトの名無しさん:04/12/25 18:21:01
>>307
その意見が、非常に複雑な業務ロジックで成り立つのかが疑問なんです。

まあ、その解を得ることに、「>>308の図が読み解ける」という以上の意味はないんだけど。
というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
もちろん長い年月ソフトウェアに関わって、いろいろな開発をみてきて、実際の測定もしてきたわけだから、それなりの根拠があることは間違いないんだけど。

310 :デフォルトの名無しさん:04/12/25 18:33:04
非常に複雑な業務ロジックってなんなんだろね。
ありがちなのは飛行機工場の生産管理とかかな?

311 :デフォルトの名無しさん:04/12/25 18:35:43
いきあたりばったりのうちの営業

312 :デフォルトの名無しさん:04/12/25 18:43:34
業務になってる部分が少ないから却下、とか。

313 :デフォルトの名無しさん:04/12/25 18:46:17
>>305
トランザクションスクリプトは、任意の単位に分けられるから
機能単位に分ければ良いが、
ドメインモデルは、意味のあるデータ単位に振る舞いを持たせるから
機能単位に分割できないという話でしょ。

314 :デフォルトの名無しさん:04/12/25 18:56:32
>>309
> というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
禿胴

315 :デフォルトの名無しさん:04/12/25 18:58:44
>>309
ファウラーのいっているトランザクションスクリプトは、
1つのクラスでメソッド分割するイメージなんだと思うな。
それだったら、複雑になればなるほどクラスが大きくなるから
その維持は大変になる。
ドメインモデルは、複雑とはいっても複数のクラスに処理が
分散されているからましということなんじゃないだろうか。

そういう前提なら、http://www.nri-aitd.com/tips/image/g-patern_4.gif
まぁ、そうかなという気もする。

くーすでいっている役割分担によるコンポーネント分割方式なら、
複雑になっても、それぞれのコンポーネントの役割は明確で、
小さいから維持は、ドメインモデルよりしやすいだろう。

316 :デフォルトの名無しさん:04/12/25 19:07:03
>>313
いや、それで、トランザクションを分けたときに、業務単位にまとめれたり、影響範囲がみえやすかったりするのだろうか、と。
ドメインモデルでは、複雑でごちゃごちゃに絡み合ってそれ以上分割できず、全体をみないといけないのにだよ?

317 :デフォルトの名無しさん:04/12/25 19:16:00
ドメインモデルは比較的単純な業務でも複数のモデルが絡み合う(というかそういう風につくるもん)
なんで、単純比較してしまうとなあ。

318 :デフォルトの名無しさん:04/12/25 19:18:34
>>316
業務単位に最初からクラスを作れば良いんだから分けられるに決まってる。
影響範囲が見やすいといっているのは、本来独立した複数の業務が
交差することはないためでしょう。

319 :デフォルトの名無しさん:04/12/25 19:29:13
>>317
うん、だから、単純な業務ではドメインモデルじゃないほうがいいというのは共通認識になってると思う。

>>318
いちおう、>>303あたりの前提条件みてください。

320 :デフォルトの名無しさん:04/12/25 20:04:06
>>319
だから、複雑で分割できないと思っているのは、
データを中心に見ているからでしょう。
データに関連する振る舞いを全部持たせようとするとそうなる。
複数のモデルに関連する振る舞いをどれかのモデルに持たせればそうなる。
機能を中心に見ればそんなことはない。
どんな複雑な機能だって、シンプルな機能に分解できる。


321 :デフォルトの名無しさん:04/12/25 20:07:13
>>319>>320はなんか話がかみ合ってないんじゃないか?

322 :デフォルトの名無しさん:04/12/25 20:10:51
重複したコードが散らばって、機能追加・変更が大変になりそうだけど。

323 :デフォルトの名無しさん:04/12/25 20:14:45
だからさ、サービスで分割ってのは、まさに「データに振る舞いをのせるのでは
なくて、データの管理と永続化は外に出しちゃって、ビジネスロジックは機能で
分割しましょう」って話じゃないのか?

324 :デフォルトの名無しさん:04/12/25 20:17:06
>>309
>というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。

PofEAAによるとそれは「nonscientific graphs」らしいよ。
ファウラーたんの感覚的なものに過ぎないんじゃないかな。

325 :デフォルトの名無しさん:04/12/25 20:17:35
>>320
だから、機能がシンプルなものに分割できることはわかってるんだけど、そのつながりが複雑になるんじゃないの?と。
で、そういう話をしているときに、単体のシンプルさを主張しても、あまり意味がないんじゃない?
って、だいぶ前に書いた気がする。

326 :デフォルトの名無しさん:04/12/25 20:21:03
>>324
萎えた

327 :デフォルトの名無しさん:04/12/25 20:21:24
>>324
ま、そんなもんなんだろう。
とりあえず、ファウラーたんを信用ことにするよ。
感覚的なものを極端に書いてると思っておく。

ただ、いつもどおり目の青い人の国でのお話だから、日本で鵜呑みにはできんけど。

328 :デフォルトの名無しさん:04/12/25 20:32:50
>>325
そういうことか。
どんなに複雑な組み合わせでできたコンポーネント群でも
特定のコンポーネントを見れば、自分と直接関連のある
コンポーネントだけとしか関係を持たないから
つながりも複雑になることはない。

329 :デフォルトの名無しさん:04/12/25 20:33:26
ファウラータソの感覚に振り回されてクリスマスの休日にドメインモデル談義か。おめでてえな。

330 :デフォルトの名無しさん:04/12/25 20:40:58
そろそろこっち逝け

Martin Fowlerのスレッド
http://pc5.2ch.net/test/read.cgi/prog/1099814095/l50


331 :デフォルトの名無しさん:04/12/25 20:41:19
結論:構造化に始まり構造化に終わる。

332 :デフォルトの名無しさん:04/12/25 20:56:43
いいじゃんここで。おもしろいよ。
業務機能とソースコードのバランスをどうとるか、って噺はあんまり聞かないから。

333 :デフォルトの名無しさん:04/12/25 20:56:58
Transaction Script=構造化的OO
Domain Model=DOA的OO
ってことでいいのか?
http://www.nri-aitd.com/tips/g-patern.html
それぞれの特徴を見てるとそんな気がしてきた。

334 :デフォルトの名無しさん:04/12/25 21:04:03
>>328
話が、ファウラーたんもびっくりレベルの複雑な業務ロジックだったときに、果たしてそういえるのか。
特定のコンポーネントだけをみて、自分と直接関係のあるコンポーネントだけをみて、用が足せるのか。
甚だ疑問。

335 :デフォルトの名無しさん:04/12/25 21:09:27
>>333
またまたスレ違いの質問なんだけど、DOAの原典的な本とか、始祖的な人ってどこらへんになるんだろう?
一度中途半端に調べてみたんだけど、わからなかった。

336 :デフォルトの名無しさん:04/12/25 21:23:52
>>334
疑問に思うのは自由だけど、それで用は足せる。
DIでは、自分の直接の知り合いとしか話しないから。
相手を探しにいくことはないんですよ。
コンテナが必要な人をDIしてくれるんだから。

337 :デフォルトの名無しさん:04/12/25 21:26:40
PoEAAを書いた頃にDIってあったの?


338 :デフォルトの名無しさん:04/12/25 21:48:02
>>336
べつにここでDIを出してくる必要はないと思うんだけど。

それと、DIでオブジェクトが組み立てられて、個々のオブジェクトが単純で、少ない数のオブジェクトとしかやりとりしないからといっても、本質的な複雑さが解消できるものではないと思うよ。
本質的な複雑さというのは、系が閉じているときは一定なので、モデリングのやりかたで複雑さがかわるものでもないし。

339 :デフォルトの名無しさん:04/12/25 22:09:43
ここでDIが出てくる必要はないな。
業務サービスベースで考えるので、そもそもの実装が「なんらかの特定業務に
関連した情報を返す」ということがモデリングのスタート地点になってる。

ドメインモデルは「おれのモデルでできることはここまでだよ。他の処理はほかの
モデルがやるんだろ? おれは知らんよ」という構成になっているので、各モデルの
位置づけを理解した上で、さらにそれがどうつながってるか理解しないと、何を
やろうとしているのか(何の業務を解決しようとしているのか)分からなくなる。

サービスベースでもサービスが増えればややこしいのは事実。DAOも含めると、30
近いクラスが絡み合ってることもあるよ。
でもこの複雑さは、おれたちが普通に関数なりメソッドを呼ぶときに「あ、ここはちょっと
別のprivateなメソッドにでも分けるか」とかやってメソッド一つずつをシンプルにして、
1メソッド3000行とかならないようにするのと似てる。つまり機能が複雑になってきたし、
重複しそうだから、一部機能を_機能として_分割してるわけで。

おなじ絡み合っているのでも、つながりが追いやすいんじゃないかな。

340 :デフォルトの名無しさん:04/12/25 22:34:46
たぶんそういうことだろうね。
業務が複雑になったときには、ドメインモデルを構築してないと、「なんらかの特定業務」すらどこで行っていいかわからなくなると思う。
でも、ドメインモデル構築自体の複雑さが問題にならなくなるような複雑なシステムはそれほどない、と。
たぶんシステムの多くを占めてる、流通系とかお店のシステムだと業務がそれほど複雑じゃなくて、商品・サービスの移動と「なんらかの特定業務」がリンクしやすいしね。

341 :デフォルトの名無しさん:04/12/25 22:35:36
最近なんかこのスレ妙に建設的じゃねーか(w
でも悪くない気分

342 :デフォルトの名無しさん:04/12/25 22:41:00
おれのおかげだな。

343 :デフォルトの名無しさん:04/12/25 22:43:18
>>342のせいで気分が悪くなった

344 :デフォルトの名無しさん:04/12/25 23:07:12
英語や技術を頑張るのは結構だが、先人を平気で禿呼ばわりする人格を
変えるのが先だと思う。それとも英語で書く時と日本語で書く時に
使い分けるつもりなんだろうか?
ほんと気分悪い。

345 :342:04/12/25 23:13:06
>>344
それはおれは関係ないよー。
でも、気分が悪いことを思い出させてしまってごめんよー。

346 :デフォルトの名無しさん:04/12/26 00:09:43
>>344
誰もファウラータンを禿なんてよんでないよー。

347 :デフォルトの名無しさん:04/12/26 00:25:30
 「_ ̄フ  ノ^ー┐ ///////////ノ/
 ,-、二、 ーク /  7_/////////^
 `ー‐‐'  `ー'     ///////し
   _l^l_  i^i i^i   ///////
  / ,--┘ U ノ |  //////^
  !__ニコ  lニ.ノ    7///    _,,.. . __
 __l^l__へ  i^i i^i  //^    .. _  `ヽ
 ゙┐r┐T゙ ∪ ノ |  |/     /::/.┬".)   l
  く,ノr'_,ノ  lニ.ノ   7    _iゞ/イ。_ノ    _r'''、
   |    ,へ ,ヘ /    / ニ-''^\¨   ∠.} l
   |    `゙ / / |.   |l、ヾ⌒-|  u  r_ノノ "
   |    ヾ二ノ  |    ヽ |`´_,--|  i、ニイ
   |    /,ニ^\. |     \l<-ニフ ,ノ ,. \、'
  | | | |  | しリj |  \    \ ̄ ,/ノ/ , | Z
  ゚ ゚ ゚ ゚  `ー" ー'  〔      / ̄/ '", /// ,.

348 :デフォルトの名無しさん:04/12/26 03:07:23
俺はどっちかというと344のような
学級会的道徳観の持ち主の方がすんごい気持ち悪い。
おえー。

349 :デフォルトの名無しさん:04/12/26 09:51:18
もし>344が上司のことを影で悪くいいながら
本人の前で言わないようなことしてたら同じ穴の狢
他人に腹が立つのは大抵そこに自分を見るかららしいぞw

350 :デフォルトの名無しさん:04/12/27 01:17:16
ファウラーたん議論が終わった感じだけど、蒸し返してみる。

ドメインモデルってMVCモデルのMを具現化したものだろ。でもくーすってMVCじゃなくて、
ヤコブソンのBCEを具現化したものだろ。Boundary-Control-Entityって用語を使ってる
ところからして。

BCEってMVCの問題点を解決するものとしてあげられてるんだし、MVCなドメインモデル
から見て矛盾があるのはいわば当然じゃないかな。

351 :デフォルトの名無しさん:04/12/27 01:47:28
>>350
ファウラーのMVCモデルは、ウェブプレゼンテーション層の中だけの話。
アプリケーション全体をMVCにして、UI以外を全てMに押し付けるモデルは、EJBが重すぎて崩壊してしまったのを見ればわかるように、実際には使い物にならない。

352 :デフォルトの名無しさん:04/12/27 01:58:28
J2EEのMVC Model2におけるMはファウラーたんのドメインモデルの領域だと思うが...

あとEJBが重すぎるのはリモートコールを多用するからじゃないか?
ローカルコールで動かすと、悪名高いEntityBeanですらそれなりの速度で動くぞ。

353 :デフォルトの名無しさん:04/12/27 02:00:05
動作の重さを言ってるわけじゃないのだが・・・
それと、蒸し返すといっても、少なくともこのスレでMVCという言葉は出てきたことがないのだが。

354 :デフォルトの名無しさん:04/12/27 02:09:43
そうだね....
じゃあ、蒸し返すのでなく次の話題ってコトでどうだろうか.....

355 :デフォルトの名無しさん:04/12/27 02:22:10
いやぁ、MVC Model2なんて使い物にならないというか、どうにもならないことがわかってるので、話題としておもしろくない・・・

356 :デフォルトの名無しさん:04/12/27 02:44:32
MVCmodel2だと、VがMからデータを得る。
でも、ファウラーのMVCでは、Vはドメインモデルとやりとりしない。
MVCmodel2とファウラーのモデルは対応しない。

というか、MVCmodel2で、やんちゃなV(JSP)と、たよりないC(Servlet)を与えられて、「あとはMです。ご自由に」と広大な空き地をおしつけられても、ねぇ。

357 :デフォルトの名無しさん:04/12/27 08:11:08
ドメインモデルとしてのMは、ほんとにドメイン特有のオブジェクト群。
MVCmodel2としてVに渡されるMは、ドメインモデルとは別のものでVが必要とするM。

ドメインモデルのMからMVCmodel2としてのMへの翻訳が必要。
おれはかならずこの翻訳を意識している。
翻訳しないケースがあれば、それはたまたま両者が一致しているという特殊ケースと位置付ける。

358 :デフォルトの名無しさん:04/12/27 08:55:23
>>357
そのMVC Model2のモデルとドメインモデルの変換コストの話が
http://d.hatena.ne.jp/higayasuo/20041207#1102379088
http://d.hatena.ne.jp/higayasuo/20041220#1103516338
で、ドメインモデルが工数がかかるという根拠になってるみたい。

結局話題がリンクしてる?

359 :デフォルトの名無しさん:04/12/27 10:00:03
kusuに話をもどしていいかな?
kusuが対象とする開発は20-50人の中規模と思うのだけど、
開発者にDIについての認識を強要するのは酷な話。
少なくとも、開発者全員が一読するという代物ではない。
であれば、kusuって開発の方法論であって開発標準ではないよね。
この規模の方法論って他にもあるのに、なんであえて提唱したのか
よくわからないんだよなぁ。

360 :デフォルトの名無しさん:04/12/27 10:53:43
>>357
翻訳といっても、その幅は広いよね。
インスタンスへのリンクを渡すだけのファサードな場合もあれば、ドメインモデルの全プロパティをコピーするDTOな場合もある。
357の意図してるのはどちら?

361 :デフォルトの名無しさん:04/12/27 11:20:48
>359
同じ規模のものが他にあっても、提唱しない理由にはならないでしょ。
ほとんど同じものが他にあるなら別だけど。

362 :デフォルトの名無しさん:04/12/27 11:33:58
一口にMVCと言っても色々。
http://www.google.co.jp/search?hl=ja&q=%E3%82%B3%E3%83%B3%E3%83%88%E3%83%AD%E3%83%BC%E3%83%A9%E3%81%8C%E9%A0%91%E5%BC%B5%E3%82%8B+mvc
とかBuschmann本とか。

くーすと「レガシーなオブジェクト指向」との距離は、
Webアプリへの最適化によるものだ、と言ってみるテスト。

363 :デフォルトの名無しさん:04/12/27 12:28:39
どうでもいいけど、Seasarそっちのけだな。

DIスレと分けた意味はあるんだろうか?

364 :デフォルトの名無しさん:04/12/27 12:41:18
>>362
Webじゃなくても、基本的には変わらんと思うが。

365 :デフォルトの名無しさん:04/12/27 12:43:10
>>361
他のものとどこが違うか、よくわからない。
Seasarに依存するってとこ?

366 :デフォルトの名無しさん:04/12/27 12:50:35
>>361
PofEAAの解説にしかみえないのは、俺だけ?

367 :デフォルトの名無しさん:04/12/27 13:00:07
>>361
いや、比嘉氏は既存の中規模システム開発用の開発標準にでは
満足いかなかったのではないかと思う。つまり、RUPを軽くした
国内開発者向けの標準を作らなければならないという危機感が
あったのではないか、と、そんな気がする。
kusu本を出すなら、その辺の経緯も記してもらいたい。

368 :デフォルトの名無しさん:04/12/27 13:40:28
開発者が俺一人な小規模組織にはくーすは不要ですか?

369 :デフォルトの名無しさん:04/12/27 14:52:46
>>368
自分の技術レベルが低いと思ったら使えばいいんじゃないの。

370 :44:04/12/27 20:02:55
http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>話を簡単にするために常にデータと振る舞いを一緒にするというのは、
>それはそれでOK。
>
>ただし、機能が増えるにしたがって役割多すぎなクラスになる
>危険性があるということです。最初は、データと構造を一緒に
>しておいて、機能が増えてきたらリファクタリングすればいい
>という考えもあるかもしれません。しかし、それは、
>リファクタリングではありません。利用する側から見て
>インターフェースが変わってしまうからです。

インターフェース/クラスの内部でExtract Classしたクラスへ対して委譲すればいいだけでは?
そうすればインターフェースは変わりませんよね。


371 :44:04/12/27 20:14:15
http://d.hatena.ne.jp/higayasuo/20041220#1103529853
>「データ構造を公開することによる疎結合性を妨害」という点では、
>永続化されるようなデータの構造は、もともとpublicですから特に
>問題にはならないと思います。

何に対してpublicなのでしょうか?

また、データ構造をクラスの外へ公開することによるデメリットとして、修正箇所がアプリケーション中に分散してしまうことなどがあると思いますが、publicであることはこのことに何か解決策をもたらしているのでしょうか?


372 :44:04/12/27 20:18:34
つい責めるようなな口調になってしまいました。申し訳ないです。

373 :デフォルトの名無しさん:04/12/27 20:55:20
>371
>修正箇所がアプリケーション中に分散してしまうことなどがあると

あっちこっち直すことになるかもしれないが、
どの業務機能から使われてるかが分かるから影響範囲が明確になる、とも言える。
これは高度に抽象化をおこなわないことによるメリットかな。

修正が難しいのはデータを「変更」する処理だろうが、それって分散して存在することは稀。
SeasarならS2Daoでエンティティ単位の管理ができるから、そんなに大変ではないだろう。
主として影響を受けるのは大抵は入力・表示関係。そしてそれはUI層の問題だから別の話になる。

374 :デフォルトの名無しさん:04/12/27 23:23:59
みなSeasarやくーすにどうしてそんなに熱くなるのか,
だれか分析してくれ。


375 :デフォルトの名無しさん:04/12/27 23:44:14
それにはまずロバストネス分析から始めないとだめだな。
バウンダリはなんだ?

376 :デフォルトの名無しさん:04/12/27 23:59:28
>>374
パンダに熱くなったほうがいいのにね。

377 :デフォルトの名無しさん:04/12/27 23:59:50
>>375
ひがたん

378 :デフォルトの名無しさん:04/12/28 00:01:49
>>372
とりあえず、以後、他人に意見するのは止めることですね。

379 :デフォルトの名無しさん:04/12/28 00:05:03
>>378
パンダに意見するのはOKですか?

380 :デフォルトの名無しさん:04/12/28 02:29:38
s2jsfのexampleなんで、編集だけで、削除とか作ってないんだ?
「易しさと優しさ」とか言ってたのに、あとは、自分でやれってことか?

381 :デフォルトの名無しさん:04/12/28 04:34:27
>>373
とりあえず前半部分は技術者の意見とは思えない。

後半は俺が読み違えてるのかもしれないので確認したいんだけど、
public属性の影響を受けるのは、値を設定するところじゃなくて
むしろ単純読込の方が量が多くて問題になる。

たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
という変更があったときに、アクセッサ経由で統一されている方が楽。
そのモデルのサブクラスを作って変数をオーバーライドしちゃうと
ベースクラス側でのメソッドの中でアクセスしてる変数と別物になっちゃうので
スマートな形でサブクラス化できないこともある。

膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
ソースにコメントをつけながらやることであって、できるだけ基本は
守っていた方がいい事が多い。

ひがさんはOOPのメリットをあまり理解できなかった側の人だと思うので、
44さんはもう突っ込まないであげればいいと思う。DI自体は悪くない技術だし、
彼らのモチベーションが高い方がseasarがいい方に行くと思うから。

逆にseasarが好きで変な方向に行って欲しくないからこそ、ひがさんにいろいろ
突っ込みを入れてるのかもしれないけど

382 :デフォルトの名無しさん:04/12/28 04:36:35
>>380
そこはスローガンなんだからそんな言い方するこたあないだろ。
「削除も作ってほしいなあ」とか言えば気分良く作ってくれる人が
いるかもしれないのに。

383 :デフォルトの名無しさん:04/12/28 08:07:41
s2jsfってjsfのコンポーネントぜんぜん使えんのか

384 :デフォルトの名無しさん:04/12/28 08:27:57
>>381
うーん、何が言いたいのかよくわからんわ。

> たとえばその属性の型が変わったり、setXXの時に小数点2桁で丸めたい、
> という変更があったときに、アクセッサ経由で統一されている方が楽。

だったらそうすりゃいいじゃん。
>>381はフィールドをpublic属性にする話をしているように読めるのだけど...
永続化データがpublicだという話をそう読んだわけ?

永続化されるようなデータはそもそも構造が公開されてるもんだと
いう意味で、publicだと言ってるだけだと思うけど。

S2Dao使ったって結局各データにはアクセッサ使ってアクセスするんだし、
プロパティとして扱ってるから、アクセッサ経由だし。

385 :デフォルトの名無しさん:04/12/28 09:32:41
>>380
何だくれくれクンか

386 :デフォルトの名無しさん:04/12/28 09:40:36
>>376
何でパンダなんだ?

387 :デフォルトの名無しさん:04/12/28 09:43:19
>>381

> 膨大な繰り返し処理の速度を速くしたくてわざとpublic属性にすることは
> あるけど、そういうのは基本を踏まえた上での小手先のテクニックとして
> ソースにコメントをつけながらやることであって、できるだけ基本は
> 守っていた方がいい事が多い。

すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ?
想像できんので教えてくれ。

388 :デフォルトの名無しさん:04/12/28 10:31:43
ひが君がpublished的な意味でpublicって言ったのが、
>>381に伝わらなかったってだけじゃないの。

ttp://www.martinfowler.com/bliki/PublishedInterface.html

まあマターリ行こうや。>>387


389 :デフォルトの名無しさん:04/12/28 10:39:14
>>386
NHKみてなかったの?かわいかったのに。
「NHKスペシャル地球大進化 生命の巨大化」の枠でやってたから、巨大化ってパンダのことかーっ、と思いながらみてますた。

390 :デフォルトの名無しさん:04/12/28 11:34:24
OOが開発効率の足枷になってる事に留意しろっつうの

391 :デフォルトの名無しさん:04/12/28 12:34:36
org.seasar.dao.impl.DaoMetaDataImpl#createResultSetHandler
method.getReturnType().isAssignableFrom(List.class)

List.class.isAssignableFrom(method.getReturnType())

じゃないか?

392 :デフォルトの名無しさん:04/12/28 12:37:39
>>388
比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても影響ないってことだろ。

393 :44:04/12/28 18:33:55
http://d.hatena.ne.jp/higayasuo/20041227#1104147737
>もともと永続化されるデータ、テーブルで管理されるようなデータ
>というのは、その構造は、ER図などで外部に対して公開されています。
>
>一般的に言われるようなカプセル化の話は当てはまりません。

外部の意味が曖昧なので推測で。

ここでい言う「外部」が
>>392
>比嘉氏が言いたいのは、ERDは早々に確定するから属性公開しても
>影響ないってことだろ。
ということであれば、それでもなお、カプセル化の話は当てはまると思います。カプセル化さえされていればクラスの内部で、Extract Classした先への委譲でも、Replace Type Code with State/Strategyでも、なんでもやりたい放題できますから。

また、「外部」が外部システム等であったとしても、若干の不自由は強いられるかもしれませんが、それでもなお上記の理由でカプセル化する利点は存在すると考えます。


394 :デフォルトの名無しさん:04/12/28 18:45:41
http://game10.2ch.net/test/read.cgi/game/1104208080/l100
このスレ荒らしてあげて下さい。
ウイルス貼りまくっていいですよ。
歓迎します。

395 :44:04/12/28 18:46:59
http://d.hatena.ne.jp/higayasuo/20041227#1104186174
>補足しておくと、ドメインモデルは、もともとデータを持ってる
>クラスに振る舞いを持たせたほうが良いという観点なはずです。それが、
>
>public class Employee {
> private PayCaluculator calculator;
> ...
> public BigDecimal caluculatePay() {
> return calculator.calculatePay(this);
> }
>}
>
>という形だということは、役割でクラス分割するのと実質同じです。

Extract Classは以下のように行うので
http://www.refactoring.com/catalog/extractClass.html
PayCaluculatorクラスができることはありませんです。


396 :デフォルトの名無しさん:04/12/28 18:52:42
>>387
> すまん、膨大な繰り返し処理って具体的にはどんな業務ロジックなんだ?
> 想像できんので教えてくれ。

業務ロジックかどうかは微妙だけど java.awt.Point数万個を使うようなグラフィック処理。
あと、石油埋蔵量予測システム。(どっかで読んだ)

397 :デフォルトの名無しさん:04/12/28 19:20:48
>>396
サンキュ。そういうやつか。俺の仕事では出会うことは無さそうでほっとした。

398 :デフォルトの名無しさん:04/12/28 21:34:31
今更こんな事を聞くには恥ずかしいんだけど・・・・・・・

MAIN─Seasar─dicon
            │
            ├クラスA
            ├クラスB
            ├クラスC
            └クラスD

「SeasarとはクラスA−Dの纏め役で、どれを使うかdiconに
書いておけば、そのクラスを返してくれるもの。」
という理解で合ってる?ドキュメントを1ヶ月ほど読み耽って
やっとこ辿り着いた答えがコレだったんだけど・・・・・・

399 :デフォルトの名無しさん:04/12/28 22:15:34
ひがさんにOOSEを読んでみて欲しいな。

400 :デフォルトの名無しさん:04/12/28 23:21:27
>ひがさんにOOSEを読んでみて欲しいな。

ひがさんが問題としていることは、OOSEでも取り上げられているから。

401 :デフォルトの名無しさん:04/12/28 23:36:56
>>398 すっげーおおざっぱには、それでよい。

402 :デフォルトの名無しさん:04/12/28 23:44:35
初心者が1ヶ月読まないとそこにたどりつけないドキュメント。

403 :デフォルトの名無しさん:04/12/28 23:46:47
http://d.hatena.ne.jp/higayasuo/20041228#1104228438
>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。

OOSEのP120~P129はその答えとなりませんか?

404 :デフォルトの名無しさん:04/12/28 23:50:20
>>402
ちょっとコードを書けばすぐにわかると思うんだけどね。
最近はドキュメント読んだだけで済ませようとする人が
多いのでびっくりだ。

405 :デフォルトの名無しさん:04/12/29 00:07:16
>その原因は、過度なデータ中心のクラス設計にあると私は考えています。
>データと振る舞いを1つのクラスにまとめるのは、自然なことですが、
>あるデータを使う機能をすべて1つにまとめると役割持ちすぎなクラスに
>なりやすいと考えています。業務アプリケーションなどはとくそうで、
>直接関係のない機能が1つのエンティティに押し込まれやすくなります。

そうなった場合に適宜リファクタリングしてやれば解決する問題だと考えます。

>また、複数のデータにまたがるような機能は、そもそも適したクラスに
>振る舞いを割り当てるのが難しくなります。

複数のデータにまたがるような機能が全てそうだとは言いませんが、どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ割り当てれば良い、と古のOOSEに記されています。そのことには異存ありません。
# UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

データと振る舞いをひとつのクラスにまとめる。責務が多くなりすぎたらクラスを分割してやる。振る舞いを割り当てるのに適したクラスが無い場合はコントローラクラスとする。これでも駄目なのでしょうか?


406 :デフォルトの名無しさん:04/12/29 00:18:26
>>404
読む人のせいにする筆者

407 :401:04/12/29 00:33:02
>>402
最新版のドキュメントは、昔と較べると段違いに充実していると思う。
# S2JSFのドキュメントがないのは、正式公開前だし、しかたないだろう。
まさたかさんの入門記事も参考になる。
http://d.hatena.ne.jp/masataka_k/searchdiary?of=15&word=%2a%5bseasar%2dtutorial%5d
(もしかすると若干記述が古くてハマるかもしれん)。

俺はS2財団の人ではない。単なるファンだ。
だが、煽りが出たらごめん。> やすを氏ほか。
あと技術的な話をしているところを、側面的なネタで汚してすまん。

408 :デフォルトの名無しさん:04/12/29 00:36:32
>>401
そうですか・・・・・・やっと、やっとここまで辿り着きました(;´д⊂ヽヒックヒック

>>404
ぶっちゃけその通りです>ドキュメント読んだだけで済ませようと
「Seasar = フレームワーク」と勘違いして、「クラスを切り替えられるのは分かったから、それ
で最終的にはどうなるんだ?」という明後日な視点でドキュメントを読み続けてました。

髭剃りを他の何かだと頑なに信じ込んでしまってる人が、説明書を見ながら「髭が剃れるのは
分かったから、最終的にどうなるんだ?」と途方に暮れてる姿を想像してもらえれば近いので
はないかと・・・・・・
勿論、結論は「だから髭が剃れるんだよ」というものなんですが、見てる方向が違うと辿り着け
ないんですね、これが_| ̄|○|||

最後に、とりあえず現在のところドキュメントに不満はありません。
目は何も見てはいない、見ているのは脳。という言葉をちょっぴり実感した年末でしたw

409 :デフォルトの名無しさん:04/12/29 00:38:44
>>405
>複数のデータにまたがるような機能が全てそうだとは言いませんが、
>どのドメインオブジェクトへも割り当てがたい責務はコントローラクラスへ
>割り当てれば良い、と古のOOSEに記されています。
>そのことには異存ありません。
> # UnifiedProcessは全く追っていないので、もうobsoleteなのかもしれませんが

余談ですが、昨今の、ロバストネス分析で導出されたコントロールクラスは設計モデルでそのままストレートにクラス化すべし、という風潮はあまり好きになれないです。
某オブジェクト指向本も読んでみたんですが、ドメインモデル貧血症推奨な感じで、なんだか。

RUPの人もICONIXの人も、分析段階でのコントローラクラスの責務はバウンダリかエンティティに割り当てる、もしくはコントローラ自体をクラス化する、と言ってるように思うんだが。
というか、スリーアミーゴはICONIXの人よりもきつい言い方をしてて

「コントロールクラスを実現するのに別々の設計クラスを用意するのは
適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

と言ってるのだが。

410 :デフォルトの名無しさん:04/12/29 01:16:38
S2のドキュメントは昔に比べたらめっちゃ充実ですね。
S2Daoもここのところリリースが多かったですが、追加したあのテーションとかも
ちゃんとドキュメントに反映されてるし。

411 :デフォルトの名無しさん:04/12/29 01:19:31
>>409
>「コントロールクラスを実現するのに別々の設計クラスを用意するのは
> 適切ではない場合がある。むしろ、関連するバウンダリやエンティティを
> 実現する設計クラスと同じものでコントロールクラスを実現したほうが良い」

原文を知らないので良くわからないのだけど、それってStrutsで言えば、
Action内で直接エンティティにアクセスするってことかな?

412 :デフォルトの名無しさん:04/12/29 01:44:34
相変わらずドキュメントネタしか突っ込めない>>406


413 :デフォルトの名無しさん:04/12/29 02:59:21
どうでもいいが、S2JSFだけ早くリリース汁

414 :デフォルトの名無しさん:04/12/29 10:04:49
さっぱり話についていけないので、とりあえずPoEAAを読み始めた。

415 :デフォルトの名無しさん:04/12/29 10:41:39
ひがし
> blogに、これまでのオブジェクト指向の批判を書くのは、
> 私にとってはものすごくリスクの高いことです。なにを
> 言われてもおかしくないですから。現にいろいろ言われ
> ているわけですが、それでもあえて書いているのは、こ
> れまでのオブジェクト指向がなぜうまくいっていないの
> かを考え直すきっかけになればと思っているからなのです。

「これまでのオブジェクト指向」の定義と
「うまくいっていない」とする根拠を明確に示さないとただの
戯言.今までにない自分が始めて見つけた設計方法と認識して
いるならば非常に痛い.自らの失敗経験や知りえる範囲での失
敗を踏まえた程度ではないのか.


416 :デフォルトの名無しさん:04/12/29 10:47:38
  ↑
OO厨キター!

417 :デフォルトの名無しさん:04/12/29 10:53:09
>>415
同じコトをファウラータソにも突っ込んでやってくれ。
http://www.nri-aitd.com/tips/image/g-patern_4.gif
は根拠が薄弱すぎるとひが氏なんかよりも罪深いぞ。
特に線の交差するところは重要じゃないか?
SQLのあまりにもな例といい結構ファウラータソも危ういと感じる。

418 :デフォルトの名無しさん:04/12/29 11:17:33
>>417

いいんだけど、ファイル名が怪しい


419 :デフォルトの名無しさん:04/12/29 11:23:16
もうね、GoF以上にソフトウェア開発の実装におけるパターン化をやろうとしても、
ムリだってことがハッキリしたと思う。

これ以上ソフトウェア開発を効率化しようとするなら、
例えば業務会計ソフトなら、会計ソフトをプラグインで柔軟に変更可能にするとか、
そのAPIをソースコードごと公開するとか、
そういう、実装が伴ったものになると思う。
EJBのようなアプリケーション固有の実装を伴わないフレームワークは必要無い。


420 :デフォルトの名無しさん:04/12/29 11:25:26
Enterprise Applicationは個々に異なる、という前提があるので、残念。

421 :デフォルトの名無しさん:04/12/29 11:28:02
>>420
わからん
前提があるからどうなんだ?


422 :デフォルトの名無しさん:04/12/29 11:35:10
>>419
DI + II まだー?

423 :デフォルトの名無しさん:04/12/29 11:48:15
実装を共有しようとするのは現実的でなく、
フレームワークやパターンや開発手法を共有するしかない、ということ

424 :デフォルトの名無しさん:04/12/29 11:53:57
>>423
PhotoshopやEclipseはどうなんだ?
プラグイン毎にソフト作り直すのが現実的なのだろうか

業務ソフトだってその考え方をもっと進めなきゃいかんと俺は思う

425 :デフォルトの名無しさん:04/12/29 11:57:30
現実には、業務ソフトにまともなプラグイン機構を持ったソフトは
未だ存在しないから、せめてムダなフレームワークを使わず
ただシンプルに作り抜くことが、今できることなんだろうと思うけどね。

426 :デフォルトの名無しさん:04/12/29 12:26:00
>>417
原文読め
自分がネタにマジレスってことに気付くから

427 :デフォルトの名無しさん:04/12/30 05:38:44
>>424
ベースを作ればあとは付加機能でしかないという分野以外で、同じようにプラグインの仕組みを考えるのはナンセンスだと思うが。
やっても意味がないという結論がでるようなことがらについて考えを進めても意味がなさげ。

428 :デフォルトの名無しさん:04/12/30 10:34:34
ひがさんのblog
> 手を変え、品を変え、オブジェクト指向は説明されてきましたが、情況はそれほど好転しているように思えません。

続く文章も、手を変え品を変えたオブジェクト指向の説明に見えるので、状況がそれほど好転しない気がする。

429 :デフォルトの名無しさん:04/12/30 12:05:33
>>427

確かに、同じようなプラグインの仕組みは、やるだけムダなのかもしれないし
けど、うまく設計すれば、うまくいくかもしれない。
設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。

S2やEJBは何の解決にもならないのは確か。
ならシンプルな技術基盤で作りたいね。
Javaを使ったウェブプログラミングがめんどくさいからいろんなフレームワーク
がでているわけで、なら別のプラットフォームを選ぶのがいいと漏れは結論した。
結果を出せるのはスクリプト言語だなと思ってる。

430 :デフォルトの名無しさん:04/12/30 12:29:30
>>429
>設計は難しいものになるだろうけど、チャレンジしてほしいけどね。誰かに。
なんだよ、他人事かよ・・

431 :デフォルトの名無しさん:04/12/30 12:32:07
業務というもの自体がPlugableじゃないからね。
何か新しい業務が埋め込まれたら、既存の業務に必ず変化があるし。

Plugableにするために工程とかプログラムの部分部分がちょっとでも複雑になるなら、普通にシンプルに作って、わかりやすく変更できるようにした方がよさげ。

432 :デフォルトの名無しさん:04/12/30 12:54:03
>>431

プラグイン機構を持ったソフトを売るか、それ自体を使ったソリューションビジネスを始めようってんでも
ない限り、そういう先を読んだ拡張性を重視するのは、危険だな。
You aren't gonna need itの原則だ。
まさに、普通にシンプルがよさげ。


まぁ、プラグイン機構を持つのに向いている分野もあれば、向いてない分野もあると思う。
向いている分野も結構あると思うんだけどね。

433 :デフォルトの名無しさん:04/12/30 13:20:21
たとえば、金融商品を扱うとかで、商品自体がデータ構造とアルゴリズムを持つような場合は、取り扱い商品をモジュールとして追加できるようにするというのはアリだろうね。

434 :デフォルトの名無しさん:04/12/30 14:25:34
>>429はDIスレに帰れ。

皆さんネタ厨に餌を与えないでください。

435 :デフォルトの名無しさん:04/12/30 16:11:04
>>434

多分、無知だからだと思うんだ。
だから、スクリプト言語によるウェブシステム構築よりSeaserで作ったほうがイイ点、
勝ってる点を教えてください。

436 :デフォルトの名無しさん:04/12/30 17:44:22
>>435
規模とか開発の人数によるよ。
スクリプト言語よりもJava+Seasarの方が、均質なコードを書くための労力が少ない。
均質なコードを書く労力が問題なければ、スクリプト言語でいいと思う。

437 :デフォルトの名無しさん:04/12/30 20:38:38
マジにスクリプトのほうがコンパイル言語より基幹につかうに向いていると思ってるなら、死んだほうがいいな。

438 :デフォルトの名無しさん:04/12/30 20:41:53
基幹っていっても、でかい基幹ばかりじゃないからなぁ。

439 :デフォルトの名無しさん:04/12/30 20:46:22
5年くらい前なら、Javaで基幹系? 正気ですか? 医者よびましょうか? というような
感じだったような。今はどうであれ、先の事はわからない。

440 :デフォルトの名無しさん:04/12/30 20:55:03
そのときでも、実務では使えないだけで実績がでてきたら使いたいというのがあったわけだけど、スクリプト言語の場合は・・・

441 :デフォルトの名無しさん:04/12/30 22:17:47
>437
>440

だから、それはなぜかを示してほしい

442 :デフォルトの名無しさん:04/12/31 02:11:36
素人には基幹系は無理。
Javaプログラマは素人。
よって、Javaプログラマには基幹系は無理。
以上。

443 :デフォルトの名無しさん:04/12/31 02:57:28
>442
二番目が根拠無し

444 :デフォルトの名無しさん:04/12/31 06:40:09
明らかにスレ違い。>スクリプト言語と業務アプリ
別のとこでやってくれ。

445 :デフォルトの名無しさん:04/12/31 06:58:58
ここの話の流れだと、スクリプト言語とJava+Seasarを対比して、Seasarの特徴を知るという感じでもないね。

446 :デフォルトの名無しさん:04/12/31 12:16:06
>>436

均質っていうけどなぁ、
均質にするのは方法論であって。
その方法論を実現するのには、コンパイルに依存しない
弱い結合が必要だっていうから、Seaserがあるわけでしょ。
コンパイル依存をなくしたいと思って行きつくところは、
動的なスクリプト言語ってことにならないだろうか?

それに、O/Rマッピングとか、ソフトウェアを複雑にする要因を
増やしてもしょうがないと思う。

447 :デフォルトの名無しさん:04/12/31 12:32:32
>>446
実装との依存性はなくしたいだけど、
仕様(interface)との関係は明確にしたい。
仕様に合致してるかどうかはコンパイラにチェックして欲しい。

O/Rマッピングは関係無いと思うけど。
S2Daoの話なら別に複雑じゃないよ。

448 :デフォルトの名無しさん:04/12/31 13:01:45
>>447

しかし、キャスト要らずのコードにするために、
あのdiで書かれた設定ファイルが必要になるわけで、
どっちにしろ動かしてみるまで分からないのは一緒だと
思うのだけど、どうだろうか。

それに、あのdiファイルってすごく冗長で書くの辛いしツール要るしで、
なんか本末転倒感が強い。

449 :デフォルトの名無しさん:04/12/31 13:03:08
キャスト要らずってのは、間違いかな。どっちにしろ要るんだから。

450 :デフォルトの名無しさん:04/12/31 13:21:45
業務ソフトは必ず一から作り直さないとダメ、
プラグイン機構を持ってもしょうがない、
ってな話あるけど、必ずしも、
そうでもない気がする。
ERPソフトの全てがネタだとは思わないし、
適切なインターフェースさえ定義して
そのインターフェースAPIの意図を素早く読み取って
プラグイン作る人さえそろえば、
少ない労力で結果として効果の高いソフトが作れると思うよ。

451 :デフォルトの名無しさん:04/12/31 13:38:52
確かにコンフィグ系コンテナって設定ファイルが冗長だよな。
S2は特にそうだ。

452 :446,448,449,450 ◆iKwMOjCT4s :04/12/31 13:54:34
そもそも、コンテナとは何か?
言語本来備わっている名前空間機能ではいかんのか?
と思うわけだな

453 :デフォルトの名無しさん:04/12/31 13:55:39
モチツケ。

454 :デフォルトの名無しさん:04/12/31 14:19:36
>>450

> 適切なインターフェースさえ定義して
> そのインターフェースAPIの意図を素早く読み取って
> プラグイン作る人さえそろえば、
> 少ない労力で結果として効果の高いソフトが作れると思うよ。

そうだな。早く藻前がそれを作って公開すればみんなそれがどれくらい素晴らしいか理解できると思うよ。
とっとと作れ。

455 :デフォルトの名無しさん:04/12/31 14:19:51
>>448
また、使ってないやつがコメントしてるのか。
S2は自動バインディングがほんとだから
DIについてはクラスの登録以外はあまりすることがない。

Springの設定ファイルについて文句あるなら、
Springすれでどうぞ。

456 :デフォルトの名無しさん:04/12/31 15:17:34
スレ違い+勘違いUzeeeeeeeeeeeeeeeeee!!!

457 :デフォルトの名無しさん:04/12/31 18:22:16
比嘉氏のドメインモデルに対する懸念には同意だ。
ビジネスモデルも柔軟性があり、いい発想だ。
しかし、ドメイン分析をまともに出来る奴がいねーのは問題だわな。
巷にはノウハウ本が溢れているが、だーれも読んでねーってことだ。
読者がアホなのか、執筆者がアホなのか。
まぁ、後者だろう。


458 :デフォルトの名無しさん:04/12/31 21:15:26
>>457
> 読者がアホなのか、執筆者がアホなのか。
> まぁ、後者だろう。

○ージス総研と○蔵に通報しますた。

459 :デフォルトの名無しさん:04/12/31 23:10:34
>>458
つうか、日本でドメイン分析をまともにやったプロジェクトはないだろ。
あるなら教えてくれ。
まぁ、未経験者の執筆した本でも趣味でやってる奴には楽しめるかもしれん。

460 :デフォルトの名無しさん:04/12/31 23:30:24
もし仮に、diconをポトペタできる様なRADツールが存在したとして、需要が有るか否か
もし仮に、diconをポトペタできる様なRADツールを作るとして、実現可能性はどれくらい
あるか?
または既にそういったツールが有るのか否か、情報提供キボーン

461 :デフォルトの名無しさん:05/01/01 00:14:37
>>460
こんな年の暮れに何をかいとんねん。
もう新年だけど。
diconをぽとぺたする意味が良く分からん。
ツールならKijimunaはけっこう良くできてるよ。

462 :デフォルトの名無しさん:05/01/01 02:32:56
皆様、あけましておめでとうございます。
なにはともあれ、今年もIT屋さんとしてがんばっていこうではありませんか ;-)

463 :デフォルトの名無しさん:05/01/01 17:06:34
>>455
自動バインディングのために、クラスに定数定義したり、
やっぱりxml書かなきゃいけなかったりする。

そこまでする理由ってのが、どうにも見つからないんだな。
結局、Javaプラットフォームがプログラミングしづらいから、
なんとかカバーしようとしているだけとしか思えない。

464 :デフォルトの名無しさん:05/01/01 17:39:59
だからJavaでやる意義を問いたいならスレ違いだって言ってんだよ。


465 :あなたの運勢は 【ぴょん吉】 ですから!!残念っっ!!:05/01/01 17:46:02
m9(^Д^) プギャー

466 :デフォルトの名無しさん:05/01/01 19:08:51
>>464
いや、漏れが一番知りたいのは、
Seaser作る人使う人が
ウェブ/データベースプログラミングをJavaでやると選択した理由なんだよ。

漏れの知らない深い理由があるのではないかなと。

467 :デフォルトの名無しさん:05/01/01 20:44:15
>>466
・CGIは力不足
・mod_{perl,ruby}は挙動が怪しいときに追うのが辛い
・PHPは言語仕様が糞

あとは別ヌレでどうぞ

468 :デフォルトの名無しさん:05/01/01 20:51:24
>>467
モチツケ

469 :デフォルトの名無しさん:05/01/01 20:58:13
>>461
実は俺>>391なんです。
Kijimunaの存在自体知りませんでしたorz

ただ、それはそれとして、設定ファイルを書くのが面倒という意見が多いんで
工夫できないものなのかな?工夫する為のツールは存在しないのかな?存
在はしてるけど認知度が低いのかな?認知されてるけど機能が足りてない
のかな?等々、現状どうなってるのか不思議に思ったものでネタ振りしたつ
もりだったんですが・・・・・・スベっちゃいました。

「手書きが面倒」という感覚は、ある種の人達(例えばLinux畑の人達とか?)
にはどう説明しても理解してもらえないんで、もしかしたらSeasar使いの人達
もその類の人達なのかと思ったんですが・・・・・・

実際のとこ、どうなんでしょう?

470 :469:05/01/01 21:00:04
間違えた、>>391ではなく>>398です。

>>391さんは無関係です。申し訳ない、ごめんなさい。

471 :デフォルトの名無しさん:05/01/01 21:20:04
>>466
積極的に選ぶ奴もいれば仕事上仕方なしに使う奴もいるさ。
理由はそれぞれ。Javaを使うと決まったときに少しでも楽するために
S2を使うだけだ。気にしないでキミは自分の道を行くのが良かろう。

472 :デフォルトの名無しさん:05/01/01 21:21:24
>>469
手書きが面倒だからといってVBみたいになれば楽かというとそうでもなかろう。
少なくともKijimuna使ってる分にはそんなに苦労はしてない。

473 :.net厨のお年玉は 【1519円】 でした:05/01/01 21:34:24
( ´д)ヒソ(´д`)ヒソ(д` )

474 :469:05/01/01 22:01:01
>>472
「そんなに苦労はしてない」この言葉にはとても多くの意味があって・・・・・・

例えば、Linuxのlilo.confは手書きです。これは設定ファイル自体が非常に
単純で、GUIエディタを作るまでもないというのがLinux畑な人達の言い分な
んだと思うんですが、一方でグラフィカルなブートマネージャに対する人気
は凄く高いという側面もあります。

決して批判してるわけではないんですが(批判できるほどSeasarを理解でき
てませんorz)、使いこなしてる人ほど見えなくなる部分みたいなんで一石を
・・・・・・MSはそういうとこ上手いと思う。

て言うか、俺自身が更にSeasarやEclipseを学んで、ポトペタdiconプラグイン
for Eclipseとかを作れる様になればいいんですけどね・・・・・・遠いなぁ(´д`;)

475 :デフォルトの名無しさん:05/01/01 22:47:11
>>467

> mod_{perl,ruby}は挙動が怪しいときに追うのが辛い

これは、例えば、どういうとき?


476 :デフォルトの名無しさん:05/01/01 23:48:52
>>469

私は手書き派ですが、diconファイルをクラスごとに用意してます。それでパッケージ単位でインクルードしたdiconファイルを用意していて、サブシステム単位でそれをインクルードして、さらに全てをインクルードしてます。
で、GUIでこれを出来たら楽という考えを持っています。その一方で、テスト用のdiconファイルを作っているのでそれを任意に出来るようなGUIが想像できないです。そこら辺のイメージが湧かないとGUIの評価も出来ません。
システムは多数の人間で開発するものですので、自分の変更がほかの人に迷惑をかけないようなファイル分割や、チェック方法や、排他方法を望みます。
それが可能ならGUIでもいいんですが。

477 :469:05/01/02 00:19:49
>>476
ごめんなさい。書き込み内容の1/10も理解できませんorz

イメージとしては、GraphEdit(DirectShowFilterの接続をグラフィカルに
設定するMS製ツール)なんですが・・・・・・
dicon用GUIエディタをGraphEditの様なUIで表現可能なのかどうかが
先ず分かりませんorz^256

478 :デフォルトの名無しさん:05/01/02 02:41:56
いや、別に単に「自分でファクトリつくるのめんどいなあ。S2でやっちゃうか」でも
十分に存在価値はあると思うんだけど。intercepter機能を一切使わなくてもね。

PHPはもうちょっとオブジェクト指向面で実績ができてからかなあ。
あと何でも連想配列でなんとかしていくのも俺は気持ち悪い。
Bean書く手間をかけても、そっちのほうがいい。それが俺のJavaを選んだ理由かな。

479 :デフォルトの名無しさん:05/01/02 02:47:50
classファイルをドロップするとファイル位置を元にclassロードして、リフレクションで
完全クラス名を取得して自動的にdiconひな形作成して、GUIでプロパティ設定とか、
コンストラクタ設定とか、インターセプターとか設定できるようにすると面白そうだと
思う。

実現可能性(誰が作るのかとか)をとっぱらって考えると、こういうツールは敷居を
下げてくれるし、重要な要素だと思うよ。手書きで間に合ってる人はいらんだろうけ
ど、手書きXMLに敷居を感じる人間もいるわな。すそ野を広めようと思えば考慮す
る価値はあるよね。

俺はdicon手書きでもkijimunaでそれほど困ってないけど、正直GUIツールがあったら
便利だと思うね。チームの連中にdiconの概念を説明する手間が若干省けるし。

480 :469:05/01/02 12:44:09
>>478
寧ろintercepter機能(S2AOPの事ですよね?)が使いたくてSeasarを追
っかけてます。まぁ、逃げられっぱなしなわけですがorz

例えば、今は単純なベタテキストのログを出力してるけど、将来的には
XMLで出力したい、いやいっそSYSLOGdへ出力したい、まてまてHTML
で出力してWEBブラウザで見るのも捨て難いぞ等と考えた時、それ用
のクラスを書いてdiconを編集するだけで、色んなログの出力が実現で
きるのだとしたら、とても便利そうだぞと、思ったんですが・・・・・・・

もっとも、この発想自体が間違ってる可能性も大アリなんですが(´д`;)

481 :デフォルトの名無しさん:05/01/02 13:37:34
漏れはGUIよりも、XDocletで吐き出せる方が嬉しいな。
読み込み順とかも重要だから難しいかなぁ。

482 :デフォルトの名無しさん:05/01/02 13:45:40
>>480
その発想は間違ってないけど、すでにApacheのLog4Jで実現されてるので
そっち使った方が早い。Log4JはSeasar自身も使ってるし。

483 :デフォルトの名無しさん:05/01/02 13:46:16
あ、いうまでもなく、ログ出力の多様化の話ね。

484 :デフォルトの名無しさん:05/01/03 01:09:26
ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
>Seasar3はJ2EE Development with EJBなのです。

( ´_ゝ`)フーン

Seasarいらねじゃないの?
結局EJB最強ってことか

485 :デフォルトの名無しさん:05/01/03 03:01:28
今S2で作ってるシステムはS3が出たらどうすればいいんだ。すごく不安になってきたよ。

486 :デフォルトの名無しさん:05/01/03 08:41:27
>>485
漏れはアンチSeaserだが、
バージョン間の互換性問題はどこの世界にもある話。
PHPは本当に酷かった。

487 :デフォルトの名無しさん:05/01/03 08:55:32
>>485
だから、リファクタリングの原則だ。
これができてればバージョン上げるくらい楽勝だ。


488 :デフォルトの名無しさん:05/01/03 09:32:05
なんか新年早々えらいこと言い出しましたね。
バージョン間の互換性というより、根本的に考え方が違う。
-Seasar3がでたらSeasar2どうなる。メンテナンスするの?
-今開発中のS2*シリーズは影響受けないのか?
あたりが気になる。

ttp://d.hatena.ne.jp/higayasuo/20050102#1104650907
のコメントを見ると、取り巻き達もこの件は知らなかったの?
S2マンセーな方々がどういう反応するかな?


489 :デフォルトの名無しさん:05/01/03 09:40:02
Seasarの中の人も大変だな

490 :デフォルトの名無しさん:05/01/03 09:51:05
>>487
売りであるS2Daoが全然変わっちゃいそうだから
リファクタリングというより作り直しになっちゃいう。


491 :デフォルトの名無しさん:05/01/03 10:42:40
ttp://d.hatena.ne.jp/higayasuo/20050103#1104716008
>Seasar3は、Seasar2とは全くコンセプトが異なるので、基本的に互換性はありません。
>でも、Seasar2を使われている方は、心配する必要はありません。
>Seasar2は、今後も開発を続けます。J2SE5にも対応します。
>今後も主力は、Seasar2 + S2ファミリーということになります。

あ〜やっぱり。そうなるとS2/S3の2系列になる。それも悩ましい。

492 :デフォルトの名無しさん:05/01/03 10:54:48
ひがたんは、ビジネスモデルとドメインモデルの違いを理解していない模様.


493 :デフォルトの名無しさん:05/01/03 11:21:14
>>492
ドメインモデルもビジネスモデルもちゃんとした定義なんてないと思うよ。
もしかして、DDDの定義がちゃんとした定義だと思ってるとか。

494 :デフォルトの名無しさん:05/01/03 12:44:45
ビジネスモデルはビジネスが成り立つことを表すためのモデル
ドメインモデルもシステム化対象となる問題領域を捉えるためのモデル
という理解ではだめか?

495 :デフォルトの名無しさん:05/01/03 13:09:07
>>494
それは、それで違和感ないけど、みんないってること違うからね。
いまのところしょうがないんじゃないかな。
ファウラーたんがきちんと定義してくれたらそれがデファクトになるかもね。
ただドメインモデルの定義も
http://martinfowler.com/eaaCatalog/domainModel.html
でいいのかなぁって気も。

496 :デフォルトの名無しさん:05/01/03 13:30:27
>>491
つまりSeasar3が作られたとしても、使うメリットは少ないってことだな。
Seasarという名のもとに違うコンセプトのものが語られて、開発リソースの分散と混乱をまねくだけまねいてあぼん、か。
先が見えたな。

497 :デフォルトの名無しさん:05/01/03 13:44:03
>>496
藻前は、Seasar2もつかってないんだろうから、Seasar3も使わなくて良いよ。
ちなみに、Seasar2がでたときも、Seasar1と全く違うコンセプトのものだったよ。

498 :デフォルトの名無しさん:05/01/03 14:08:00
ビジネスモデルをおもいっきし間違えてる。
ひがさんの言ってるビジネスモデルは「業務フロー」(ビジネスフローとでも言えばいいか)。
業務フローのなかで特有のモデルがドメインモデル。
常識的な範囲で、ビジネスモデルは儲ける方法のことだし。

煽り抜きで、ちょとがっかりした。

499 :デフォルトの名無しさん:05/01/03 15:35:59
>>497
そのときは、Seasar1を捨ててSeasar2に移行したわけだろ。
まるっきりコンセプトを変えた新版を出して、旧版はそのまま継続って、そしたら新版使う理由なんかないよ。
開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。
違うコンセプトで同じ名前の2つのプロダクトを、混乱しないようにプロモーションする力があるようにも思えないし。

500 :デフォルトの名無しさん:05/01/03 15:54:48
>>498

>ビジネスモデルとは、実際におこなっている業務、あるいは
>これからおこなおうとしている業務の形態・仕組みを指すこととします

といっているから、別に業務フローじゃないんじゃないの。
http://d.hatena.ne.jp/habuakihiro/20050103#1104733873
でいってる前者ってやつかな。
それによるとやはりちゃんとした定義はないということだけど。

それにしても、自分の考えと少しでも違うとまちがってると
いうやつが多いね。
2chだからそんなものだが。

501 :デフォルトの名無しさん:05/01/03 16:16:34
S3の必要性がわからんな。

502 :デフォルトの名無しさん:05/01/03 18:14:15
S3なんかまだ誰も望んでない、手前のS2JSFを確実に仕上げてくれ。

503 :デフォルトの名無しさん:05/01/03 20:14:21
>>502
禿胴。S3なんてことしなくてもS2EJB3でいいじゃんと技術に疎い漏れが逝ってみるテスt

504 :デフォルトの名無しさん:05/01/03 20:14:38
>>499
> 開発リソースも限られてるわけだし、どっちかに偏らざるを得ない。
> S2に偏るならS3は縮小していくし、S3に偏るなら移行のタイミングを与えられないままS2の利用者も減っていく。

これはSeasarの開発陣の少なさを考えると杞憂とは言い切れんな。
取り巻き/応援団は結構多そうだが、実質開発リソースは1人だからな。
まぁ二兎追うものは(ry


505 :デフォルトの名無しさん:05/01/03 20:44:44
EJBと比べてて思うんだが、S2で、アプリケーションサーバ(つまりS2Containerが動いている
ところ)だけ物理的に別サーバに写そうと思ったらどうしたらいいのかな。

EJBだとJNDIとRemoteHomeとでリモートでのメソッド呼び出しに対応できそうだけど、
たとえばStruts+S2で稼働してたとして、負荷が高くなってきたのでS2で作ったサービス
層を複数サーバにして、合わせてStrutsのプレゼンテーション層と物理的に分離しよう
としたとする。どういう方策があるだろうか。

おれがちらと考えたのは、Struts -> EJB -> S2 というように、間になんかリモート呼び出し
に対応した層を挟むしか思いつかないんだけど。

506 :デフォルトの名無しさん:05/01/03 21:04:10
>>505
そこでS2Remotingですよ。

507 :デフォルトの名無しさん:05/01/03 21:55:05
S2Remotingってどうなったの?
一向にリリースの気配がないようだけど。

508 :デフォルトの名無しさん:05/01/03 21:56:09
>>505
Webコンテナごと横に並べればいいじゃん。

509 :デフォルトの名無しさん:05/01/03 23:16:32
>>508
プレゼンテーション層とサービス層とDBを物理的に分離したい、と言われることは
十分あり得ることだろう。というか別件で言われたんだよ。そういうときS2ならどうなる
のかな、と。

510 :デフォルトの名無しさん:05/01/04 00:28:40
ところでS3のコンセプトって何だろうね。それが素晴らしいなら応援する。
S2がDI+AOPで生まれ変わったのは素晴らしかったと思う。
S3はDI+AOPを捨てさるような新しい何かを考えてるんだろうか。
漏れにはどうもS2の作り直しにしか見えないので不安だ。

511 :デフォルトの名無しさん:05/01/04 00:32:48
>>509

そこまで分離したほうがいいシステムって、
どういうもんかなと思ったんだが。思いつきで言ってるというか、
システム派手にしたいだけな臭いがしてくるんだけど。

Rubyのtuple spaceの実装例はけっこう感動した。これを使えば
物理的にネットワークに繋げれば自動的にサーバ同士が連携して処理速度上げたり
クラスタリングのやり始めたり、というカッコイイことも可能だ。
そんなことやったほうがいいような機能を求める顧客には、会った事はないが!

512 :デフォルトの名無しさん:05/01/04 00:39:43
>>511
ハードをたくさん売るために決まってるだろw

513 :デフォルトの名無しさん:05/01/04 00:46:26
>>511

で、顧客は次にこういうのだ。
「ハード一台で済むシステム作れないかな。台数少ないから、予算は前の1/4で」

こういう素人を超えたITオンチが今のシステム屋を支えているのだ
なんのために生きてんだろ!

514 :デフォルトの名無しさん:05/01/04 11:37:10
>>511
DBさえ多重化していれば良いという程度のシステムばかりではないんですよ.

515 :デフォルトの名無しさん:05/01/04 11:59:53
>>500
はぶのいうことは話半分で聞いたほうが良いよ.
ttp://www.atmarkit.co.jp/aig/04biz/businessmodel.html

516 :デフォルトの名無しさん:05/01/04 12:29:04
ビジネスモデルでぐぐったがよくわからん。定義が曖昧ということはいえそう。
はぶ氏のも曖昧な中のひとつの自説ということじゃないだろうか。

517 :デフォルトの名無しさん:05/01/04 12:42:34
大体ビジネスなんて言葉を使う時点で胡散臭いもんだ

518 :デフォルトの名無しさん:05/01/04 12:46:50
>517
そこまで戻って話をせにゃならんのか?
でもまぁ、身のある話をするにはそうなのかもしれないな。
でかい声で言ったもん勝ち、それを分かった気になったもん勝ちな業界だし。

519 :デフォルトの名無しさん:05/01/04 12:53:30
大体コンテナなんて言葉を使う時点で胡散臭いもんだ

520 :デフォルトの名無しさん:05/01/04 13:50:03
はぶ氏とひが氏が誰を指すかの定義もあいまいなのか・・・

521 :デフォルトの名無しさん:05/01/04 14:00:26
この時期にS3の話を聞きたいと思う奴はいないよな。
「別系列」ってゆーけど、S2=前Version=時代遅れ、と認識する人が多いだろう。
しかも、順調に行けばGW明けにそうなる。
そーゆーS2をこれからもメンテする献身的な人がどれだけいるか疑問だ。

http://d.hatena.ne.jp/habuakihiro/20050104#1104805780
>Tiger対応とS2JSFリリースは、S3に関係なく最優先でお願いしたい事項です。

本音だろうな。他に頼む人いないし。

>この辺は主としてマーケティングの話になってくるんでしょう。

ぷっ。

522 :デフォルトの名無しさん:05/01/04 14:05:05
やっぱりEJBでないとダメな局面があったのでは。
それが技術的なものかどうかは知らないが。

523 :デフォルトの名無しさん:05/01/04 14:13:57
分散させる場合は、EJBがいいよ。
EJBは分散技術だし。
EJBが提案されたときは、分散システムが主流になると思われてた。
実際には、分散が必要になるシステムは、非常に限られていたってことだ。

524 :デフォルトの名無しさん:05/01/04 14:46:28
分散厨は実践J2EEシステムデザインとPofEAAを読みなさい。

525 :デフォルトの名無しさん:05/01/04 16:14:48
>>517
businessという英語を外来語として日本語化したときに、胡散臭さが付け加えられてしまったからな。
システムとかエンジニアとかSEとかマネージメントとかDIコンテナとか、似たような例はたくさん。

526 :デフォルトの名無しさん:05/01/04 21:31:40
つまり業界全体が胡散臭いと。
まああってるかもしれん。

527 :デフォルトの名無しさん:05/01/04 21:40:19
要はOAだよな。

528 :デフォルトの名無しさん:05/01/04 21:58:48
OriginalAnime?

529 :デフォルトの名無しさん:05/01/04 22:11:17
S3のコンセプトは「優しさと易しさ」じゃなくて
「J2EEにフィードバックすること」なのかな。


530 :デフォルトの名無しさん:05/01/05 05:28:55
S3のコンセプトは「自己顕示欲」です。

531 :デフォルトの名無しさん:05/01/05 10:17:01
>>524

毛唐のやつらは 複雑なこと VS. 簡単なこと
をポリシーなく立場を入れ替えながら争うのがそもそも好みですから.残念


532 :デフォルトの名無しさん:05/01/05 10:43:37
なんかこのスレ文系臭い

533 :デフォルトの名無しさん:05/01/05 20:44:24
行動を伴わなければ趣味でしかないような学びは雑学でしかない。
もしくは
人の仕事というのは趣味の延長でしかない

534 :デフォルトの名無しさん:05/01/05 21:58:32
>>533
誤爆か?

535 :デフォルトの名無しさん:05/01/05 23:38:53
>>534
誘爆かと。
ttp://d.hatena.ne.jp/habuakihiro/20050105#1104915865

536 :デフォルトの名無しさん:05/01/05 23:55:06
S2ともくーすとも関係ないな。ストーカー怖い怖い。

537 :デフォルトの名無しさん:05/01/06 00:01:43
せくーすしたいなあ…

538 :デフォルトの名無しさん:05/01/06 00:45:44
「関係者の掲示板に貼り付いてチェックしてるアンチ」
の図を妄想してる輩はBloglinesを知らないんだろうか。
まさか。

539 :デフォルトの名無しさん:05/01/06 01:18:24
>>538
スレと関係ないことまでいちいち書き込むあたりが怖いってことだろ。
>>533がストーカーかかまってくんか追っ掛けか知らないけどな。



540 :デフォルトの名無しさん:05/01/06 11:28:21
>>535
彼はNIFTYのフォーラムにはまっていた頃からはったり雑学やろうでくちばっかりの
男でした.
>> 某スレ
酔うと伝票めくりをしていた時代からの成り上がり話をぐたぐた話すのは
いつもの十八番だ.たしかにうざい.

541 :デフォルトの名無しさん:05/01/06 11:44:00
>540
句読点までこだわるとは、
手の込んだことをおやりになる。

542 :デフォルトの名無しさん:05/01/06 11:58:16
>>540
一緒に飲んでるんだw
その場で説教してやれ
はぶヲチでスレと関係ない
こと書くなウザイ

543 :デフォルトの名無しさん:05/01/06 12:23:42
その場で説教すると何がおきるのかな?
だれか適当な聞き役をあてがって、その場を去るのが無難だね。

544 :デフォルトの名無しさん:05/01/06 12:52:43
ヒガ氏、次のネタカモン

545 :デフォルトの名無しさん:05/01/06 15:49:56
NIFTYの頃からヲチしてるて・・
S2周りの人大変だな。

546 :デフォルトの名無しさん:05/01/07 13:28:56
にじみ出るふいんきは騙れませんよ。

547 :デフォルトの名無しさん:05/01/07 18:33:36
S3の前に、S2のAOPをもうちょっと強力にして欲しい。AOPAlliance自体が
まだしょぼしょぼだから仕方ないのかも知れんが、現状のS2AOPの程度では、
お子ちゃまみたいなログ取りインターセプタか、トランザクション管理
くらいにしか使えない。
AOPはその程度でいいんだ、っていうならそれでいいんだけど・・・

548 :デフォルトの名無しさん:05/01/07 19:18:18
AOPはその程度でいい

549 :デフォルトの名無しさん:05/01/07 20:07:55
AOPなんて見えないgoto文みたいなもん。
その程度で済ましとかないと保守不能になる。

550 :デフォルトの名無しさん:05/01/07 21:44:05
AOPを駆使しまくって実装されたシステム、保守すること考えたら憂鬱だな。
どこでなにが起きるか把握するだけで疲れそう。

551 :デフォルトの名無しさん:05/01/07 22:56:41
そういや、各AOPのパフォーマンス比較が以前あったみたいだけど、S2AOPはどれくらいの能力なんだろうね

ttp://www.theserverside.com/articles/article.tss?l=AspectWerkzP1

552 :デフォルトの名無しさん:05/01/07 23:32:05
>>547
どう強化されたらどんなことに使える?

553 :デフォルトの名無しさん:05/01/08 00:57:30
日経ソフトウェアで、だれかがAOPについて書いてたね。
読みながら、コワイコワイと思った。

554 :デフォルトの名無しさん:05/01/08 12:39:22
AOPって結局なんなのかイマイチ分かってませんが、S2AOPに限れば
必要な時にdiconを開いてみるだけで済みそうに思うんですが・・・・・・
大した使い方してないからそう思うのかもしれないけど・・・・・・

555 :デフォルトの名無しさん:05/01/08 14:54:22
AOPはトレース埋める位にしないと。コミットとかロールバックを任せたら大変な事に。

556 :デフォルトの名無しさん:05/01/08 14:58:19
>>555
詳細キボン

557 :デフォルトの名無しさん:05/01/08 15:27:51
>>556
ねたにつられるなよ。
トランザクション制御は、AOPに向いてる代表的な機能の1つなんだから。

558 :デフォルトの名無しさん:05/01/08 19:27:53
>>554
ある処理で何が起こるか正確に把握するために、diconファイルのすべてに目を通す必要が出てくる。

559 :デフォルトの名無しさん:05/01/08 21:07:15
なんで「すべてに」なの?

560 :デフォルトの名無しさん:05/01/08 21:59:42
投下してみるか
ttp://arton.no-ip.info/diary/20050103.html#p01

561 :デフォルトの名無しさん:05/01/08 22:07:41
>>559
どこでどのオブジェクトにアスペクト仕込まれてるかわからなくなるから。
自分だけでコーディングするなら問題ないけどね。

562 :デフォルトの名無しさん:05/01/09 03:19:38
ん〜
適切にdiconファイルを分けておけば、「すべて」を見る必要はないような…?
まあ、あとはドキュメントとかコメントで対応するとか(アテにならん場合が多いけど)


563 :デフォルトの名無しさん:05/01/09 04:04:37
>>562
オートインジェクションとか考えると。
適切に分けられてるかどうか確認しないといけないし。
ドキュメントは、コードがドキュメント通りになっているかの確認が。

自動的になにかするようなコードから追えないものは、オートインジェクションも含めて、コードを追うのが難しい。

564 :デフォルトの名無しさん:05/01/09 05:55:15
追うのが難しいのは本質的にどうしようもない希ガス

管理手法の確立とそれの徹底をすればいいんだろうが、それだとコードとは
別なところに、全面的ではないにしろ大きく依存することになるわけだから、
それほそれで面倒な問題を孕むしな('A`)

管理とか保守をするのにソースコードとdiconファイルからインジェクションされてる
対象とその内容が簡単に視認できるようなツールがあるといいよなあ

まあ、漏れは今のところkijimunaで間に合ってるけど、AOPを非機能要件以外
のあれやらこれやらに使いたかったりするなら、保守の難しさが軽減されるような
何らかの仕組みなりモノがないとさすがにやってられないだろうな

565 :デフォルトの名無しさん:05/01/09 19:47:41
>>564
> 保守の難しさが軽減されるような
> 何らかの仕組み

それは、Seaser非依存OOPプログラミングだ

566 :デフォルトの名無しさん:05/01/09 20:11:19
>>565
現状に満足してるなら、別にそれでいいと思うよ。

567 :デフォルトの名無しさん:05/01/09 20:38:48
Seasarを使い込んでる人に聞きたいんだけど、もしかしてdiconてかなり巨大
なツリー状になる?
メンテナンスが大変な事になってるdicon一式(実際の場面に即したdiconなら
擬似サンプルでも良くてclassとかの本体は不要)公開してもらえないですか?

568 :デフォルトの名無しさん:05/01/09 21:54:22
>>567
いまの時点でSeasarを使い込んでる人って、いろんなことをちゃんとわかってやってるだろうから、メンテナンスが大変なことになってるdiconってないんじゃなかろうか。

569 :デフォルトの名無しさん:05/01/09 22:05:24
diconって普通分割するだろ? 用途別にとか層別にとか。

570 :デフォルトの名無しさん:05/01/09 23:55:02
>>567
「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。

571 :デフォルトの名無しさん:05/01/10 00:04:50
>>567
「巨大なツリー状」と「メンテナンスが大変なことになってる」が、つながらないんだけども。

572 :デフォルトの名無しさん:05/01/10 05:56:29
論理削除ってわざわざS2Daoで面倒見る必要ってあるのかな。
もう一層上で対応するのが自然だと思うが。
やるんなら、0、1のフラグだけだと使えん。
通常はnull値で、削除すると日時で更新されるようにならないと。
がんばってください。


573 :デフォルトの名無しさん:05/01/11 22:56:46
> プレゼンテーション層の革命のはじまりです。

そんな、革命的なものじゃないように見えるけど
モアベター程度に見えるし、ほとんどの人は普通のJSPや普通のJSFで充分な気がする。

574 :デフォルトの名無しさん:05/01/14 02:15:17


「多くの人が実際の能力以上のことができると思い違いをしている。
 誰でも、ポップスター、高裁判事、有能なテレビ司会者に
 なれるかのように教師が教えているからだ」

                            チャールズ英皇太子





575 :デフォルトの名無しさん:05/01/15 01:46:50
>>574
大したスキルもないくせにひが君と同等の立場で
語りたがるアンチへの嫌味ですか。
そうですか。

576 :デフォルトの名無しさん:05/01/26 14:10:33
S2Dao のデバッグは sql を出力してくれるんだが、
必要な sql_quote がかかっていなくてsqlとして実行できないんだな。

sql がおかしいのかと思ってしばらくはまっちゃったぞ。
デバッグしにくいから、誰か気づいた人quote かけとくれよ。
おねげーしますだ。


577 :デフォルトの名無しさん:05/01/26 17:30:36
>>576

sql_quoteって何。
文字列ならシングルコーテーションで囲まれていた気はするけど。


578 :デフォルトの名無しさん:05/01/26 20:20:51
(・∀・)ハイーキョ

579 :576:05/01/27 13:41:56
>>577
sql_quote ってのはあれだ、文字列の中にシングルクォートがあったら、
クォートしてくれるってことだ。
hoge'hoge -> hoge''hoge
そうしないと、sqlエラーになっちゃうだろ?
insert fuga(hoge) values ('hoge'hoge'); => era-
insert fuga(hoge) values ('hoge''hoge'); => ok-



580 :デフォルトの名無しさん:05/01/27 15:07:19
>>579
era-ってかわいいね

581 :デフォルトの名無しさん:05/01/27 21:20:51
>>579
バインド変数(/*hoge*/みたいな)を使えば関係ないんじゃないの。

582 :デフォルトの名無しさん:05/01/27 23:19:30
SeasarとMayaの関係がよく分からないんだけど。


583 :デフォルトの名無しさん:05/01/28 08:02:30
っつか、Mayaってなに?
仕様をがんばって作って、しょぼい実装ができそうなことだけわかったけど。

584 :デフォルトの名無しさん:05/01/28 21:34:06
>>583
http://pc5.2ch.net/test/read.cgi/cg/1059565585/

585 :デフォルトの名無しさん:05/01/29 02:12:15
>>584
あ、それなら使ったことあるよ。

586 :デフォルトの名無しさん:05/01/29 18:36:52
SPEEDってのもあるね

関係が分からない。

関係者の方々説明たのんます。

587 :デフォルトの名無しさん:05/02/03 21:56:06
既出だったらごめんなんだけど

S2JSFってHTMLを売りにしてるけど
あれって拡張子が.htmlなだけで厳密にはHTMLじゃないよね。
サンプルで普通のHTMLまで変換されてたのが気になって...
あれは拡張子htmlでいいのか?

588 :デフォルトの名無しさん:05/02/04 10:19:49
拡張子なんて飾(ry

589 :デフォルトの名無しさん:05/02/05 19:59:16
>>587
普通のHTMLが変換されたらなんか問題あるの?


590 :デフォルトの名無しさん:05/02/06 18:57:03
そういやkoichik氏のとこでCGLIBをASMに置き換えたテストやってるな。きっかけは前スレの以下の発言。

http://pc5.2ch.net/test/read.cgi/tech/1092044210/571

>多少、建設的なネタを。ひが君 「cglib 遅せーから Javassist 使う」 とか言ってないで
>直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
>思うけどな。
>
> 性能: ASM > Javassist(初心者向け) > cglib(初心者向けASMラッパー)
>       > BCEL > SERP

で、実際にASM使ったら3割程度しか変わらんかったそうな。

591 :デフォルトの名無しさん:05/02/07 23:06:04
3割向上って、結構凄いと思うが。

592 :デフォルトの名無しさん:05/02/08 23:02:21
やっちゃいけないベンチマークの見本のようなコードだけど、この結果信用できるのか?
何もしないメソッドなんて動的コンパイル後実際に呼び出されているかどうかすら怪しい。

593 :デフォルトの名無しさん:05/02/08 23:10:50
呼び出し速度を測る方法として、空メソッド呼び出し以外のいい方法ってある?

ちょっと思い当たらないんだけど。

594 :デフォルトの名無しさん:05/02/09 11:58:58
>>593
べつに、純粋な呼出速度計らなくていいだろ。
比較できればいいんだから。

595 :デフォルトの名無しさん:05/02/09 13:09:55
>>593
>>592は、アスペクト有る無しで15倍違うという結果は怪しいってだけで本題じゃないんだ。
(とは言っても、Sunのクライアントコンパイラはそこまでやらないはずなので
以下のオーバーヘッドを除けば、まず正しいと思う。)
で、本題のCGLIBとASMの比較。
コンパイル前(1)、コンパイル(2)、コンパイル後(3)、全部纏めて測定しているのはどうだろうか。
俺は3だけ欲しい。が、これは体感値だと言われればぐうの音も出ない。
そこまで望むなら自分でやれと言われれば、いやあ御尤も。

596 :デフォルトの名無しさん:05/02/14 21:56:30
あげ

597 :デフォルトの名無しさん:05/02/14 21:57:01
さげちゃった。。。

598 :デフォルトの名無しさん:05/02/15 10:36:16
MayaってS2とは独立したフレームワークだと思ってるんだけど
なんでSeasarプロジェクトで開発してるんだろう…
将来的にS2JSFの代わりに使うことを考えてるのかな?

そういうところがSeasarとMayaの関係がよくわからないという
状況を生み出しているような気がしないでもない。

599 :デフォルトの名無しさん:05/02/15 12:04:05
というか、Mayaがよくわからない。
なにか開発してて、開発が進んでるらしくて、HTML吐くあたりで動くらしいということしかわからない。
まるでジンジャー

600 :デフォルトの名無しさん:05/02/15 20:14:26
>>599
>>584

601 :デフォルトの名無しさん:05/02/15 23:03:41
2回目はおもしろくないぞ。

602 :デフォルトの名無しさん:05/02/16 03:51:57
>>599
極度に乱暴に言うとTapestryのHTMLテンプレート部分+JSPのTaglib資産継承かな。

詳しくはまさたか氏のBlog(ttp://d.hatena.ne.jp/masataka_k/)の去年の11月末前後をチェックすべし。

603 :デフォルトの名無しさん:05/02/19 10:41:06
結局、ちょっと英語かぶれになればChengeLogも英語だけになって、「日本人が開発してるから情報が日本語」っていうことも満たされなくなるわけか。

604 :デフォルトの名無しさん:05/02/19 17:08:58
正直、大言壮語に付き合うのがダルい。

605 :デフォルトの名無しさん:05/02/19 19:00:20
確かに今は大言壮語かもしれない。
でも革命の初期ってそんなもんだろ?
俺はひがたんを信じているぜ!!!

606 :デフォルトの名無しさん:05/02/19 21:00:04
笑う人は笑わせておけばいい



607 :デフォルトの名無しさん:05/02/19 21:14:56
お笑いが流行ってますからね。

608 :デフォルトの名無しさん:05/02/20 02:20:42
S2Daoはミもフタもない。

くーすはさらにミもフタもない。

ひが氏の英語はさらにミもフタもない。

609 :デフォルトの名無しさん:05/02/20 02:49:59
えーっ、S2Daoはフタはないけどミはあると思うけどなぁ。
そういえば最近くーすってブログに書いてないね。

610 :デフォルトの名無しさん:05/02/20 17:34:00
大言壮語は同感だけど英語で情報発信しようという姿勢はいいんじゃない?
なにもないよりは多少おかしくても英語情報があったほうがましだと思う。
日本のユーザも大切にして欲しいとは思うけどね。

611 :デフォルトの名無しさん:05/02/20 18:51:59
608の人生はさらにもフタもない。

612 :デフォルトの名無しさん:05/02/20 18:58:57
>611
ミはなくないんだ。

613 :デフォルトの名無しさん:05/02/20 20:09:43
>>610
ここでの問題は、単に英語の練習というだけで情報が英語だけになったってことだ。

614 :デフォルトの名無しさん:05/02/20 20:52:06
>>613
MLには日本語でアナウンスすることになったから安心汁。

615 :デフォルトの名無しさん:05/02/20 21:07:09
>>613
練習だったんだ…。そりゃ失礼。

616 :デフォルトの名無しさん:05/02/20 21:37:27
>>614
MLに情報流しログも見れるからサイトには情報いらない、という考え方?あいかわらず。

617 :デフォルトの名無しさん:05/02/20 22:06:48
>>616
サイトって?

618 :デフォルトの名無しさん:05/02/20 22:25:50
公式サイト。
で、そこから公式にリンクが張られてるseasar wiki。
最近のwhat's newには日本語での情報がない。

619 :デフォルトの名無しさん:05/02/20 22:43:52
>>618
614に書いてないだけ。
seasar wikiも日本語でアナウンスするらしいよ。

620 :デフォルトの名無しさん:05/02/21 00:05:23
あぁ、じゃ、まず英語で情報がでて、日本語はあとからゆっくりってことか。

621 :デフォルトの名無しさん:05/02/21 00:38:45
>>620
「あとからゆっくり」のソースは?

622 :デフォルトの名無しさん:05/02/21 00:40:50
2/9以降、Seasar本体とS2Daoの情報は、英語でしかwikiに書いてない。

623 :デフォルトの名無しさん:05/02/21 01:20:34
>>622
過去のはあとからゆっくりじゃなくてもう日本語にならないんじゃね?
明日以降、過去のが日本語化されたら622のおかげ。

624 :デフォルトの名無しさん:05/02/26 23:49:10
なんかMayaがすごいことになってきているね。

625 :デフォルトの名無しさん:05/02/27 00:10:45
リリースがめちゃくちゃ早いことだけはわかるんだが、Mayaがなんなのか
よくわからない。

TapestryともS2JSFとも違う、なんかのプレゼンテーション層フレームワークらしい
ことは分かるんだが。

626 :デフォルトの名無しさん:05/02/27 01:09:04
結局Seasar2が必要なんだよね?
なんか、面白い機能を試すのにSeasar2が必要だし、Seasar2単体で試しても面白くないしで、壁が高い気がする。

627 :デフォルトの名無しさん:05/02/27 01:21:32
JSP2.0でいいや。

628 :デフォルトの名無しさん:05/02/27 01:59:50
>>625
Jasperに相当するテンプレートエンジンだとか。
JasperはJSPを処理するけどMayaはHTMLを処理するのが違いだとか。
TapestryやS2JSFとの違いは、Mayaはテンプレートエンジンだけで
フレームワークではないということだと思ってる。
だから色々なフレームワークと組み合わせて使うことが出来るのだとか。

>>626
MayaはS2とは独立に使えることになってるはず。
WebWorkと組み合わせて動いたってレポートがあった。
どこかにSpringとも組み合わせられるとも書いてあった。

>>627
Webデザイナと協業しないとかWebデザイナがJSP大丈夫な場合はそれでいいかもね。

629 :627:05/02/27 02:19:18
>>628
あぁ、そうなのか。
だからJSPで全然不満ないんだ。
Webデザイナとは無縁だし。

630 :デフォルトの名無しさん:05/02/27 13:06:17
>>626
そりゃSeasarの壁じゃなくておまいの「好奇心の低さ」と言う壁だべさ

631 :デフォルトの名無しさん:05/02/27 14:00:55
>>630
別にそれでもいいけど。
Seasar2自体には興味はないし。
他に同じようなことができるものがあるなら、そっち試すだけで。

632 :デフォルトの名無しさん:05/02/27 16:37:09
うんそうだね。だから631はこのスレに来なくてもいいよ。

633 :デフォルトの名無しさん:05/02/27 16:45:27
壁が高い
  ↓
おまえがクズ
  ↓
めんどう
  ↓
来なくていいよ

っていう流れ、好きだなぁ。

634 :デフォルトの名無しさん:05/02/27 21:20:21
たしかに3割向上だったら、大手をふって効率アップっていえるかも。

635 :デフォルトの名無しさん:05/02/27 21:35:44
ところで、そこの効率アップって、アプリ全体の影響って大きいの?

636 :デフォルトの名無しさん:05/02/27 22:31:35
まあ2.2はJavassistで決定みたいだけどな

637 :デフォルトの名無しさん:05/02/27 22:49:09
>>636
もう公開されてるよ
早くなった実感がない

638 :デフォルトの名無しさん:05/02/27 23:01:27
結論:JSP2.0 + EJB3.0 これ。

639 :デフォルトの名無しさん:05/02/28 00:02:19
思いがけぬ結論にワラタ

640 :デフォルトの名無しさん:05/02/28 13:24:52
> DIは理解するものではなく、体で覚えるものです。

宗教みたいになってきたな。

641 :デフォルトの名無しさん:05/02/28 17:47:32
セガサターン白!

642 :デフォルトの名無しさん:05/03/01 02:43:49
S2JSFはSeasar2なしでいけるの?

643 :デフォルトの名無しさん:05/03/01 11:37:36
>>642
無理。S2が必要。

644 :デフォルトの名無しさん:05/03/01 13:06:48
> RC1からS2JSF自体は、JSP1.2に対応したWebコンテナ(例えばTomcat4.1)なら動作するようになります。

じゃあ、これ、どういうこと?
この文章見ると、S2JSFだけ使うなら、Tomcat4.1なら(他のライブラリなしに)動作するとも読めるんだけど。
というか、そう読んだんだけど。

645 :デフォルトの名無しさん:05/03/01 14:13:39
>>644
EA7まではJSP2.0に対応したWebコンテナ(例えばTomcat5.0)が必要だったけど
その制限が緩くなったってことじゃないか?
「S2JSF自体は」と書いているのは、組み合わせるJSF実装なんかに制限される
場合もあるからだろうね。
いくらなんでも「他のライブラリなしに」は補完しすぎw

646 :デフォルトの名無しさん:05/03/01 14:39:14
逆に、「S2JSF+Tomcat4.1」で動くという情報しかないから、何を補完して考えればいいのかわかんなかった。
Tomcat4.1なら動くっていうのも、じゃあ動かないのは?って考えてJSP1.1で動かないのはどうでもいいし、JSP2.0では動かないってことか?とか。
いままでJSP2.0で動いててJSP1.2で動くようになったなら「JSP1.2でも」だろ、と。

というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。

647 :デフォルトの名無しさん:05/03/01 15:11:07
>いままでJSP2.0で動いててJSP1.2で動くようになったなら「JSP1.2でも」だろ、と。
それくらい補完しなよ。

>というか、「S2JSF+Tomcat4.1+なんかcommons系」くらいでSeasar2なしで動くようになったのかと期待してみた。
それならMayaに期待しなよ。
つーか、そんなにS2外したいのか?

648 :デフォルトの名無しさん:05/03/01 19:01:22
> それくらい補完しなよ。

それで補完したのが「他のライブラリなしに」だったのさ。

>>647
> つーか、そんなにS2外したいのか?

選択肢としてね。

649 :デフォルトの名無しさん:05/03/01 19:41:56
他のプレゼンテーションフレームワークを使ったらいいんじゃないか

650 :デフォルトの名無しさん:05/03/01 20:15:40
>>649
いや、選択肢のひとつとしてね。
S2JSFだったりMayaだったりNirvanaだったりJSPだったり、それをS2と組み合わせたりSpringと組み合わせたり、コンテナ使わなかったり。
いろんな選択肢を考えれるようにしときたいし。
S2必須なら、S2JSFが他に比べて卓越してない限り、S2を使う前提でしか選択肢にならないから。

651 :デフォルトの名無しさん:05/03/02 01:15:27
今まで細かいところで「これだとSpringに依存しちゃいますから!残念!!」とか言ってきたのに、
普通にS2が無いと動かないJSF実装を出すってのはどうなんだ。俺はダブルスタンダードに思えて
釈然としないんだが。

652 :デフォルトの名無しさん:05/03/02 01:32:10
S2JSFはアプリじゃないから。
S2JSFのアプリはPOJOだからS2に依存しないと思うよ。

653 :デフォルトの名無しさん:05/03/02 01:46:35
>>651
Maya使えば?

654 :デフォルトの名無しさん:05/03/02 02:01:47
>>652
S2JSFに依存するのはOKなのか。

655 :デフォルトの名無しさん:05/03/02 02:15:41
アプリはPOJOだからS2JSFにも依存しないと思うけど?
HTMLに独自属性を埋め込むページテンプレートはS2JSFに依存するけど。

656 :デフォルトの名無しさん:05/03/02 07:31:08
なんで事あるごとにSpringにつっかかるんだろうな。まるでMicrosoftのアンチLinuxキャンペーンみたいだ
有名にさえなれば、類似プロジェクトとの比較なんてJava系雑誌がくどい位やってくれるだろうに

657 :デフォルトの名無しさん:05/03/02 09:24:08
MSのキャンペーンに例えられるとはまるでS2のほうがSpringよりもメジャーみたいだw

658 :デフォルトの名無しさん:05/03/02 14:00:10
>>655
POJOだから依存しないっていうのがねぇ。
POJOだから依存しないっていうのは、ソースコードレベルの話だけだ。
結局それなしでは動かせない。

659 :デフォルトの名無しさん:05/03/02 17:14:12
>>658
それを言い出すときりが無くない?
コンテナが無ければ動かせない、そもそもJavaのランタイムが無いと動かせないサーバが無etc.etc...
どのレベルまで依存を許容できるか、ってだけの問題にしかならない。
具体的にどうして欲しいのか言ってみなさいよ。

Struts→JSFのときみたいに実装と仕様を分けろってこと?
(S2の仕様だけ分離して、いろんな人が実装する…あ、それは面白いかもw)
または、Springでも動く(ってぐらい依存度の低い)S2JSFを期待してるのかしら。

それとも単にいちゃもん付けたいだけなのかな。


660 :デフォルトの名無しさん:05/03/02 17:23:06
> それとも単にいちゃもん付けたいだけなのかな。
何をいまさらw

661 :デフォルトの名無しさん:05/03/02 21:16:36
>>659
> どのレベルまで依存を許容できるか、ってだけの問題にしかならない。

いや、その程度の問題なんだが。
S2が無いと動かないってのはどうなんだ?っていう答えがPOJOだからS2に依存しないっていうのが、的外れだってこと。

662 :デフォルトの名無しさん:05/03/02 22:05:53
だらかね、
最終的に動作する環境でいろんなものに依存するのは当たり前なの。
おまいはサーバも無いところにソースだけ納品してるのか?

いちいち「依存してる」って言葉について説明するのも馬鹿らしいんだけど、
ここで言ってる「依存しない」は運用時ではなくて開発時のことさね。
特定のライブラリに依存しないPOJOで作れると何がよいって、テストが楽だし安全でしょ?

あともう一つ勘違いしてるっぽいポイントは、
S2を利用するプログラム(例えばおまいさんが作る業務システム)が、
S2/S2JSFに対して依存度が低いって言ってるんであって、(←しつこいけど開発時のことね。)
S2JSFがS2に依存しない何て話は出てないし話題にする必要も無い。
S2プロダクトシリーズであるS2JSFが、S2と密接に関連するのは当たり前だろう。


おまいはどんな世界を夢見てるんだい?

663 :デフォルトの名無しさん:05/03/02 22:40:05
>>662
>>651の答えとして>>652の「POJOだから」が適当なのかという話をしてるわけだが。
なに逆切れしてんの?

664 :デフォルトの名無しさん:05/03/02 22:42:18
> S2プロダクトシリーズであるS2JSFが、S2と密接に関連するのは当たり前だろう。

だから>>651の意見が出てくるんだろ。
それで、POJOだから依存しないって、なんかおかしいんじゃね?

665 :デフォルトの名無しさん:05/03/02 22:50:23
>>664
> それで、POJOだから依存しないって、なんかおかしいんじゃね?

どうおかしいんだい?

666 :デフォルトの名無しさん:05/03/02 22:57:03
HTMLをテンプレートとして使うJSF実装でS2非依存のモノもあるんだから(MayaとかNiravanaとか)、依存するのが嫌ならそちら使えばいい話かと。



667 :デフォルトの名無しさん:05/03/02 23:05:31
技術的なことはわからないけどひがタンに難癖つけたい奴がブログの粗探ししてるだけだ。
技術的なことを真剣に考えて言ってるわけじゃない。そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。

668 :デフォルトの名無しさん:05/03/02 23:23:27
>>664
「これだとSpringに依存しちゃいますから!残念!!」みたいな発言は
たとえばSpringのDataSourceUtilsとか、ApplicationListenerなどを利用させるような開発手法についての批判だった気がする。
だからPOJOだから大丈夫という回答になるんだと思うけど
S2JSFがS2が無いと動かないという話とは別物のような気がするけどな。
例えるなら、「SpringのMVCフレームワークがSpring無しで動かないのはおかしい」みたいな話になるのでは?

669 :デフォルトの名無しさん:05/03/03 00:05:02
>>664
S2/S2JSFのアプリはPOJO
  ↓
SpringのAPIを使ってない
  ↓
Springでは動かない
  ↓
結局S2/S2JSFに依存してる
  ↓
POJOだから依存しないって、なんかおかしいんじゃね?

ということか?
それで咎められるべきはS2やS2JSFじゃないと思うぞ。


670 :デフォルトの名無しさん:05/03/03 00:44:44
>>669
別にとがめるとかではなくて、そこでPOJOだからっていうのは理由になってないんじゃない?って言いたいだけ。
「依存してるけどPOJOだからロジック部分は再利用可能」
だったらわかるけど。

>>667
> そもそもS2に依存するのが嫌なら最初からS2ファミリーには興味持たない。

S2JSFは面白そうだと思うんだけど。
S2に依存するのが嫌なら興味持たなくていい程度の、他と大差ないしくみなの?

671 :デフォルトの名無しさん:05/03/03 01:00:14
>>670
>>668読めば、「POJOだからっていうのは理由になって」るのが分かるぞ。


672 :デフォルトの名無しさん:05/03/03 01:05:26
>S2に依存するのが嫌なら興味持たなくていい程度の、他と大差ないしくみなの?
他って具体的に何よ。半端な釣りすんなよ。

673 :デフォルトの名無しさん:05/03/03 01:11:28
>>671
その、別物の方の話を>>651はしてるんじゃないの?
まぁ、>>651に関しては、S2Daoとかもすでにあったわけでいまさら言うことじゃないと思うけど。

674 :デフォルトの名無しさん:05/03/03 01:12:30
>>672
Mayaとかちょっと上で話題に出てるんだけど・・・

675 :デフォルトの名無しさん:05/03/03 01:13:46
別物の方の話をしてるってことは、つまり言いがかりをつけてるってことじゃないかw

676 :デフォルトの名無しさん:05/03/03 01:21:14
なんか、変なやつが混じってるな。
つまりもなにも、いまさら言うことじゃないと書いてるわけで。
「そこでPOJOだから」はないんじゃないの?って言いたかっただけだ。
>>668の前後入れ替えればいいだけで、意図はわかったからもういいけど。

677 :デフォルトの名無しさん:05/03/03 09:20:40
最初に自分が「S2JSFがS2ないと駄目なのか」とか言い出したくせに
途中から「POJOだからはないんじゃない」と言いたかっただけだと
すりかえておきながら変な奴が混ざってるとかいってる藻舞も変なヤシw

678 :デフォルトの名無しさん:05/03/03 15:10:07
>>677
そりゃ、途中で「POJOだから依存しない」って言われたからさ。

679 :デフォルトの名無しさん:05/03/03 15:13:32
>>677
変なやつというのは、「釣り」だとか「言いがかり」だとか、被害妄想的な煽り文句入れてるやつね。

680 :デフォルトの名無しさん:05/03/04 00:00:15
で、結局POJOってのはハッタリだった訳だ。

681 :デフォルトの名無しさん:05/03/04 01:12:09
それはそれで大切かと。
POJOであれば、ソースコード的には依存しないわけで。
そこには価値があると思う。

682 :デフォルトの名無しさん:05/03/04 02:04:25
DI導入するだけで、こうもコードがすっきりするものかとびっくりするね。
俺はSpring使ってるけど

683 :デフォルトの名無しさん:05/03/05 12:09:28
コンテナから生成するのはBCEのCだけですか?他はnewで生成する?
すべてコンテナから取得するわけではないとどっかに
書いてあった気がしたんですが。うるおぼえですみません。

684 :デフォルトの名無しさん:05/03/05 19:59:24
Bはアプリケーションコンテナ(Tomcatとか)が生成、EはCに対してDIで生成…で良かったと思うけど。

685 :デフォルトの名無しさん:05/03/06 20:53:52
ひがたん....
プレゼンテーション層だけ、と限定しても未だにWebObjectsが最強だと思うんですけど。

仕事ではStrutsでいらいらするけど。

686 :デフォルトの名無しさん:05/03/06 22:25:06
WebLogic最強説

687 :デフォルトの名無しさん:05/03/06 22:42:31
Webber最速説

688 :デフォルトの名無しさん:05/03/06 23:23:42
しかし、
S2JSFからS2をはずそうという発送が出てくること自体凄いよなあ。
そしたらS2JSFじゃないじゃんw

つーか、そんなことをココで聞く前に自分でソースでも見てれば、そんなくだらない疑問はすぐに解決してこのスレが荒れることは無かったのに。


つーか、オープンソースなんだから。。。
ソース見ればすぐに分かるようなことを、クレクレしてくる奴はどうかと思うけどね。

689 :デフォルトの名無しさん:05/03/06 23:25:31
>>688
すぐわかったあなたはえらい
自分で作ってみるまで良さがぜんぜんわからなかった…

690 :デフォルトの名無しさん:05/03/07 02:31:27
Seasarはあまり触ってないけど、今月のJavaWorldに出てたS2JSFのサンプルを見てたしかに使い易そうだと思った。
来月のJavaWorldで特集組まれるみたいだし、最近JavaWorldはS2プッシュしてるね

691 :デフォルトの名無しさん:05/03/07 16:53:40
S2JSFのエキザンポー、見たんだけど、
S2をいじるのは初めてで、S2JSFうんぬん以前に
あまりにあっけないんで、逆にすんごい不安になってしまった。

今の出向先の自社謹製フレームワークがもうしんどくてしんどくて。
早いところ自社に帰ってS2で仕事したい。

692 :デフォルトの名無しさん:05/03/07 17:40:53
はぶにっきの荒らしコメントが
全く誰にも気づかれずに未だにポツンとあるのが
ちょっと笑った。元気が出た。

693 :683:05/03/07 23:32:11
>>684
BCEのEはgetter,setterのみが幾つかあるようなものだと
思っているのだけれども、Eをコンテナから生成しても
意味なくないですか?


694 :デフォルトの名無しさん:05/03/08 00:00:46
>>693
S2Daoって知ってるか?

695 :デフォルトの名無しさん:05/03/08 19:26:17
テーブルA B Cの三つがあるとして、
AとBがN:1、BとCがN:1の関係になっています。
Select ... FROM A
LEFT OUTER JOIN B ON A.bid=B.bid
LEFT OUTER JOIN C ON B.cid=C.cid
としたい場合、Aのbeanクラスで
private B bbean;
public static final int bbean_RELNO=0;
public static final String bbean_RELKEYS="bid";
private C cbean;
public static final int cbean_RELNO=1;
public static final String cbean_RELKEYS="bbean.cid:cid";
とすると、
Select ... FROM A
LEFT OUTER JOIN B bbean ON A.bid=bbean.bid
LEFT OUTER JOIN C cbean ON A.bbean.cid=cbean.cid
ってなSQLが出力されます。
hsqldbなら問題無かったのですが、PostgreSQLだとAなんてスキーマは無ぇよ!って怒られます。

こういうときって本来はRELKEYSにどういう風に書けばいいんでしょうか?


696 :デフォルトの名無しさん:05/03/08 19:34:23
>>695
メーリングリストでききなよ

697 :デフォルトの名無しさん:05/03/08 19:48:10
だってMLは賢い人たちばっかりで、
漏れみたいなお馬鹿Qは投げにくいんだもん.....

698 :デフォルトの名無しさん:05/03/08 22:27:12
全然お馬鹿Qじゃないと思うが。

699 :太田@下宿:05/03/09 07:33:39
695さん>

http://www.wikiroom.com/oreju/?plugin=attach&openfile=s2daoNM1.zip&refer=%A5%B7%A1%BC%A5%B5%A1%BC%A5%B5%A5%F3%A5%D7%A5%EB%A5%D7%A5%ED%A5%B8%A5%A7%A5%AF%A5%C8

のサンプルと同じようにやるとうまくいくと思いますよ。クラスAでは,

>public static final String cbean_RELKEYS="bbean.cid:cid";

は定義しないで,

>public static final int cbean_RELNO=1;

のみを定義するとうまくいくと思います。

700 :デフォルトの名無しさん:05/03/09 19:24:24
お馬鹿Q!!爆笑

701 :695:05/03/10 11:00:19
やっぱりお馬鹿Qだ…すみません、肝心なこと書き忘れてました。

>>699
ありがとうございます。
頂いたサンプルでは、SQLファイルを用意しているようですが、
SQLの自動出力は難しい、ということでしょうか。

702 :デフォルトの名無しさん:05/03/11 02:38:02
最終的に吐かせたいSQLが決まってるならSQLファイルを準備するのがいいと思う。

多種RDBMSに同一ソースで対応したいっていうなら話は別だけど。

703 :695:05/03/11 10:02:41
>>702
そうなんですか!
僕は寧ろ、できるなら自動でやる方が好ましいのかと思って、
がんばってSQLファイル削減してるところでした_| ̄|○

今後は躊躇無くSQLファイルを使っていきたいと思います。
ありがとうございました。

704 :デフォルトの名無しさん:05/03/12 01:11:56
S2Daoの利点って、効率良く書かれたSQLをそのままDAOに使用出来るところだよ。
これができるのって、あとはiBatisくらいしかないんじゃないか。

逆にSQLを徹底的に隠す方向のO/Rマッピングなら、Cayenneくらい徹底的に隠して
ほしい。

HibernateのHQLってそういう意味でなんか中途半端なイメージがあるんだよね。
クエリでSQLもどきをかくなら、もうSQL書かせてくれたらいいから、とか思ってします。

705 :695:05/03/12 11:16:42
>>704
他のO/Rマッピングツールを使ったことが無かったので分からなかったのですが、
S2Daoの秀でている点というものが激しく納得できました。ありがとうございます。

といってるところにMLにタイムリーな話題が^^;

706 :デフォルトの名無しさん:05/03/19 14:34:01
くーすのサイトってどこにあんの?
seasar.orgにはみつからん。

707 :デフォルトの名無しさん:05/03/19 15:01:20
Spring >>>>>>>>>>>>>>> seasar2
国粋主義者以外はSpringかEJB3.0だろ。

708 :デフォルトの名無しさん:05/03/19 15:43:29
沖縄も外国じゃねぇの?

709 :デフォルトの名無しさん:05/03/19 22:03:25
Java PressでSpringの大特集してるね。
Kijimunaも良いけど、SpringIDEはもっとすごいね。

710 :デフォルトの名無しさん:05/03/20 00:00:57
つか、Springに対して、Seasarの優ってる点って殆ど無いし。

711 :デフォルトの名無しさん:05/03/20 01:44:14
えー、そうなの?
オートインジェクションが便利だよ。

712 :デフォルトの名無しさん:05/03/20 02:06:13
直感的ではないファイル分割の挙動も素敵だ。

713 :デフォルトの名無しさん:05/03/20 14:14:45
リリースが速いのはいいのだがそろそろs2-frameworkをcontainer部分とutils部分に分けてそれぞれ別のリリースサイクルにしてほしいっす。

ttp://lists.sourceforge.jp/pipermail/seasar-user/2005-March/001578.html
みたいな返答を見るとバージョンアップに躊躇してしまう。


714 :デフォルトの名無しさん:05/03/20 14:46:27
くーす本いつ出るのかなあ
話なくなったのかなあ

715 :デフォルトの名無しさん:05/03/21 00:05:37
S2Strutsを試してみようと思って、StrutsUploadのファイルアップロード処理を
作ってみようと思ったんですが、org.apache.struts.upload.FormFileをActionFormに
セットするのに失敗してしまいます。

java.lang.IllegalArgumentException:
Cannot invoke org.seasar.struts.examples.form.UploadForm.setTheFile - argument type mismatch

StrutsConfig.xmlはこんな感じです。
<form-beans>
<form-bean
name="uploadForm"
type="org.seasar.struts.examples.form.UploadForm"/>
</form-beans>
<action-mappings>
<action
path="/upload"
type="mylib.seasar.upload.UploadAction"
name="uploadForm"
scope="request"
validate="true"
input="/pages/uploadInput.jsp">
<forward name="success" path="/pages/uploadResult.jsp" />
</action>
</action-mappings>

どこが悪いのかわかる方お願いします。

716 :デフォルトの名無しさん:05/03/21 01:24:29
UploadFormのsetTheFile()というメソッドを確認したほうがいいんでない?

717 :715:05/03/21 02:41:19
UploadFormはこんな風になってます。
public void setTheFile(FormFile theFile) {
this.theFile = theFile;
}

FormFileは「org.apache.struts.upload.FormFile」で、UploadFormクラスは
StrutsUploadのサンプルからもらってきたものなんです。

StrutsUploadの方だと、アップロードしたファイルやその情報をFormFileに
格納して、setTheFileからセットしてくれるんですが、POJO型のActionじゃ
それは無理なんでしょうか。

718 :デフォルトの名無しさん:2005/03/21(月) 13:22:43
typeがあってないわけだから
Object型でうけてみて
何の型できているか確認してみたらどうでしょう

719 :デフォルトの名無しさん:2005/03/21(月) 13:23:27
およそ忠告ほど人が気前よく与える物はない。


                  ラ・ロシュフコー


720 :デフォルトの名無しさん:2005/03/22(火) 00:15:27
>>718
なるほど!
ありがとうございました。

207 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)