1001コメント376KB

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

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

0001デフォルトの名無しさん

NGNG

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

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

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

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

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

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

関連スレ(なのか?)

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

0002デフォルトの名無しさん

NGNG

>>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

0003デフォルトの名無しさん

NGNG

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

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

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

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

0004デフォルトの名無しさん

NGNG

ま、御託は資源の排他制御が出来るようになってから、な。

0005デフォルトの名無しさん

NGNG

>>3
> だから、XPでもやっぱり上流行程って必要なんじゃないかな。

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

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

0006デフォルトの名無しさん

NGNG

>>3
FDDでいいじゃん。

0007デフォルトの名無しさん

NGNG

フロッピーディスクドライブ

0008デフォルトの名無しさん

NGNG

しょせんそのレベルか。

0009デフォルトの名無しさん

NGNG

(・∀・)ﾊｲｰｷｮ

0010デフォルトの名無しさん

NGNG

はおゆんらいらー！

0011デフォルトの名無しさん

NGNG

ほっちゃーん！　ほ、ほーっ、ホアアーッ!!　ホアーッ!!

0012デフォルトの名無しさん

NGNG

うぉーあいにーめん！

0013デフォルトの名無しさん

NGNG

IKEMEN JAPAN !!!

0014デフォルトの名無しさん

NGNG

前スレ>>933さんの提案は残念ながらひがさんの目にとまらなかったようですね。
僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。

0015デフォルトの名無しさん

NGNG

前スレ934
> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。

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

教えて君でスマソ。

0016デフォルトの名無しさん

NGNG

いやマジで、「このカラムにシステム時刻を入れたいだけなんだよ」とか「このカラムの
フラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。

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

0017デフォルトの名無しさん

NGNG

>>16
もしかして１項目変更するのが全項目変更するより簡単な処理だと思ってるの？

0018デフォルトの名無しさん

NGNG

今回のスレは「その３」の３が全角になったんだね。

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

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

0019デフォルトの名無しさん

NGNG

S2Daoって、BLOB型とかの値は取り出せないの？

0020デフォルトの名無しさん

NGNG

>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？

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

0021デフォルトの名無しさん

NGNG

>>20
>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？

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

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

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

0022デフォルトの名無しさん

NGNG

update_PERSISTENT_COLUMNS = "hoge";

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

002315

NGNG

間に合わなかった＿|￣|○ つか、対応してくれるんだ！

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

002414

NGNG

ごめん、間違えた。>>23は漏れ。
騙った訳じゃないのでゆるしてちょ。

002515

NGNG

いやゆるさん！

002614

NGNG

｡･ﾟ･(ﾉД`)･ﾟ･｡ｳﾜｰﾝ

002721

NGNG

>>22
感激だっ。ありがとうひがさん....

0028デフォルトの名無しさん

NGNG

見てるとは思うけど、お礼コメントしてきたらよいかも。

0029デフォルトの名無しさん

NGNG

お礼だけのコメントは情報量ないから止めた方がよくないか？
お礼がズラズラと並んでる図は信者臭くてダサいし

0030デフォルトの名無しさん

NGNG

お礼と一緒に喧嘩も売るとか

0031デフォルトの名無しさん

NGNG

趣味悪いなー

0032デフォルトの名無しさん

NGNG

「ひがたん、乙」とだけ書いてくればいいのではないか？

0033デフォルトの名無しさん

NGNG

とっておきのエロ画像とか貼るのがいいのではないか？

0034デフォルトの名無しさん

NGNG

蛯○友里の愛顧らなどがよろしいかと。

0035デフォルトの名無しさん

NGNG

AOPをフルに使用したコラが良いと思われ。

0036デフォルトの名無しさん

NGNG

最近大きな変化は無いね。

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

0037デフォルトの名無しさん

NGNG

>>36

ネタに騙されてるよ

0038デフォルトの名無しさん

NGNG

>>37
ネタ？
MLでの導入事例集作成のやり取りのことですか？

0039デフォルトの名無しさん

NGNG

ひがさん仕事はやー。ちょっと追いかけるの休んでると、どんどん機能がリリースされてく。
つーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz

0040デフォルトの名無しさん

NGNG

AOPつかわねーと意味ねーじゃん。

0041デフォルトの名無しさん

NGNG

AOP使わないとS2Dao使えないし、自動トランザクション制御使えないし、
モックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。

0042デフォルトの名無しさん

NGNG

>>39
とりあえず、ドキュメントどおりにdiconファイルに記述すればOK

0043デフォルトの名無しさん

NGNG

マジレスすると自分で考えてAOPを使うのが難しいってことだろ。
考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。

0044デフォルトの名無しさん

NGNG

http://d.hatena.ne.jp/higayasuo/20041217#1103278289

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

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

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

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

0045デフォルトの名無しさん

NGNG

> これは、BeanMetaDataに多くの責任を持たせていたためです。
> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。

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

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

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

例えば

BeanSchema.toXML

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

0046デフォルトの名無しさん

NGNG

> 振る舞いを役割ごとに分割する、言い方を変えると振る舞いを
> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。

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

0047デフォルトの名無しさん

NGNG

SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの？

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

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

0048デフォルトの名無しさん

NGNG

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

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

0049デフォルトの名無しさん

NGNG

>>46
ここではなくてblogのコメントに書いていただけませんか？

0050デフォルトの名無しさん

NGNG

> 永続化されるデータに業務に応じた振る舞いを持たせるというのは、
> 1つのクラスに複数の役割を持たせることになります。

なりません。

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

0051デフォルトの名無しさん

NGNG

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

0052５１

NGNG

ごめん、51は>>48に対するレスね。

0053デフォルトの名無しさん

NGNG

>>51
目先のお手軽さや便利さを求めちゃ何故まずいんだろう？

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

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

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

005446

NGNG

>>49
そんな度胸ありません！

0055デフォルトの名無しさん

NGNG

>>51
> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。

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

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

0056デフォルトの名無しさん

NGNG

ヒガ氏はああいう書き込みで燃料投下して
そのBlogに対する書き込みをニヤニヤして読んでると思われ。

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

0057デフォルトの名無しさん

NGNG

44=46=48!=54ですが。

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

そのとおりですw

0058デフォルトの名無しさん

NGNG

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

005958

NGNG

>>58
誤　後ろ向きな方法論で結果を出すしかありません
正　後ろ向きな方法論を利用してでも結果を出すしかありません

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

0060デフォルトの名無しさん

NGNG

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

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

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

0061デフォルトの名無しさん

NGNG

技術の世界でスキルのない人間使ってそれなりの成果物をあげることは、かなり
技術者よりの話題だと思うんだが。

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

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

0062デフォルトの名無しさん

NGNG

ひがさんの「BeanMetaDataには振る舞いを持たせるべきではない」という方針は
現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？

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

006344

NGNG

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

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

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

0064デフォルトの名無しさん

NGNG

要するに、
ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。

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

0065デフォルトの名無しさん

NGNG

>>60
くーすの技術面？

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

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

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

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