国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0002デフォルトの名無しさん
NGNGスレ立て乙。
このへんも関連スレかな。
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デフォルトの名無しさん
NGNG0005デフォルトの名無しさん
NGNG> だから、XPでもやっぱり上流行程って必要なんじゃないかな。
「アジャイルと規律」を読め。その問題が詳細に検討されてるから。
# 関係ないが、DIスレの213-214ゴールデンコンビを思い出す…。
0006デフォルトの名無しさん
NGNGFDDでいいじゃん。
0007デフォルトの名無しさん
NGNG0008デフォルトの名無しさん
NGNG0009デフォルトの名無しさん
NGNG0010デフォルトの名無しさん
NGNG0011デフォルトの名無しさん
NGNG0012デフォルトの名無しさん
NGNG0013デフォルトの名無しさん
NGNG0014デフォルトの名無しさん
NGNG僕も欲しいし、賛同者>>934さんもいるみたいなので、
ちょっとコード書いてMLに流してみます。
0015デフォルトの名無しさん
NGNG> update文で「このフィールドひとつだけ更新したい」ってときにもSQL文を書かなくてすむ。
これってむしろS2Dao側で属性ごとにダーティーチェックして対応してくれるのが
正しい気がするんだが。現状のS2Daoってそういうことやってないの?
教えて君でスマソ。
0016デフォルトの名無しさん
NGNGフラグをオンにしたいだけなんだよ」とかいうときに、いちいちSQLファイル作って、
ARGSアノテーション書いてってのが邪魔臭い。
別に対した手間じゃないんだろうけど、でも全カラム一斉UPDATEがわずか一行で
定義出来るのに、それより短いSQL文のためにSQLファイルをつくんのかよ....orz
という気分になってしまう。
0017デフォルトの名無しさん
NGNGもしかして１項目変更するのが全項目変更するより簡単な処理だと思ってるの？
0018デフォルトの名無しさん
NGNG>>17
確かにクエリを組み立てる側の制御は組み立てるクエリの長さで決まるわけじゃないからねえ。
だから、ARGSアノテーションとかが必要になるんだと思うんだけど。
16は仕組みをあまり分からず書いているのかもしれないけど、
そういうユーザーの要望の中から対応すべき要望を抽出して対応することによって
ツールとかは熟成されていくんだと思うよ。
くだらなくても要望出さなかったら作者の必要な機能ばかりのツールになってしまうからね。
0019デフォルトの名無しさん
NGNG0020デフォルトの名無しさん
NGNG自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
まぁ、いちいち噛み付かずに
>>17さんの言う通り、
ちょっとづつでも要望出してちょっとづつでも良いツールになっていってもらおうよ。
僕は一応、ソースのどの辺いじればよいのか調べています。
0021デフォルトの名無しさん
NGNG>>>16の「大した手間じゃない」はS2側の内部処理ではなくて、
>自分自身の「短いSQL文のためにSQLファイルを作る」ことを指してるんじゃないのかな？
そうです。
短いSQLのためにSQLファイルを作るのが面倒だという話です。
S2Daoは「UPDATE テーブル SET PK以外のカラム全部 WHERE PK」ってなSQLを自動生成
してくれるけど、「PK以外のカラム全部」を特定のカラムだけにするのにSQLファイルを書く
のがね。
SQLを一行書いたファイルを作るだけなんだけど、「PK以外のカラム全部」のカラムが２０個
だったりしても長いSQLが自動生成できるのと比べてしまうと、たった一つのカラムのために
SQLファイルを書くのが面倒に感じまして。
0022デフォルトの名無しさん
NGNGだって。よかったじゃん。
tp://d.hatena.ne.jp/higayasuo/20041215
002315
NGNGこういうところもS2が好きな理由です。
002515
NGNG002614
NGNG0028デフォルトの名無しさん
NGNG0029デフォルトの名無しさん
NGNGお礼がズラズラと並んでる図は信者臭くてダサいし
0030デフォルトの名無しさん
NGNG0031デフォルトの名無しさん
NGNG0032デフォルトの名無しさん
NGNG0033デフォルトの名無しさん
NGNG0034デフォルトの名無しさん
NGNG0035デフォルトの名無しさん
NGNG0036デフォルトの名無しさん
NGNG早く、事例集を作らないかなあ。
実績がはっきりしてナイト採用しないところもあると思うんだけどねぇ。
0037デフォルトの名無しさん
NGNGネタに騙されてるよ
0038デフォルトの名無しさん
NGNGネタ？
MLでの導入事例集作成のやり取りのことですか？
0039デフォルトの名無しさん
NGNGつーかおれ、未だにAOPの使い方がよくわかんね。コンテナ機能だけでも便利だからいいけどさ。 orz
0040デフォルトの名無しさん
NGNG0041デフォルトの名無しさん
NGNGモックオブジェクト使えないし、デリゲートも自動でできないんだぞ。だめじゃん。
0042デフォルトの名無しさん
NGNGとりあえず、ドキュメントどおりにdiconファイルに記述すればOK
0043デフォルトの名無しさん
NGNG考えながら付属のやつを使ってりゃそのうちinterceptorを自作するようになるさ。
0044デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたりという仕事は、
> これまで、BeanMetaDataにさせてました。データのことを最も知ってるクラスに
> 振る舞いを持たせるのは、自然なことだと思っていたためです。
>
> しかし、S2Daoに仕様の追加があるたびに、BeanMetaDataに変更が入るのです。
> メタ情報は全く変更されていないのにもかかわらず。
SQLの自動生成ロジックの変更によって、メタ情報に変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
バインド変数組み立てロジックの変更によって、メタ情報の変更がないにもかかわらず、
BeanMetaDataに変更が入ることのどこが問題なのでしょうか?
どちらも何の問題もないように思いますが。
0045デフォルトの名無しさん
NGNG> SQLを自動生成したり、Beanからバインド変数を組み立てたり
> という役割は、メタデータを管理するというBeanMetaDataの
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
それは単に責務の割り当て方が適当でなかったために
> 本来の役割とは異なることなので、別なクラスに任せるべき
> だったのです。
と感じるのだと思いますが。
例えば
BeanSchema.toXML
のようなメソッドはBeanMetaDataクラスに持たせるべき責務のように
思えます。
0046デフォルトの名無しさん
NGNG> モデリングするという考えは、重要ながらかなり見落とされている
> ことが多いのではないでしょうか。
よくわからないので、
具体的な例を挙げていただけませんか?
0047デフォルトの名無しさん
NGNGメソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
べきだった、という話じゃないの？
で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
その点についてはおれは反対する要素はないぞ。
0048デフォルトの名無しさん
NGNG> SQL自動生成を実行するSQLFactoryみたいなオブジェクトがあって、
> メソッドに引数を渡すとSQLを生成して返すとか、そういう構造である
> べきだった、という話じゃないの？
>
> で、生成したSQLもオプジェクトとしてラッピングされてて、execute()とか
> するとSQLが実行されるとか、こう、役割を細かくわけていくということだろう。
うんにゃ、
ひがさんは BeanMetaDataには振る舞いを持たせるべきではない、と言っているよ。
0049デフォルトの名無しさん
NGNGここではなくてblogのコメントに書いていただけませんか？
0050デフォルトの名無しさん
NGNG> 1つのクラスに複数の役割を持たせることになります。
なりません。
データは何一つサービスを提供しません。
よって、データは責務を持ちません。
0051デフォルトの名無しさん
NGNGS2Daoのソース読んだわけじゃないから詳しいことは分からんが、
少なくとも>>45には激しく同意。
Object指向としての理想的なモデリングは、SwingとかEclipseなんかが
参考になるとは思うんだが、その中にデータを表すってだけの
構造体みたいなクラスは見当たらんよね。ま、ドメインが違うじゃんって
いわれればそれまでだけど。
くーすはどうも退化としか思えないんだよね。
目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
柔軟性や多態性なんかが損なわれてる気がする。
0053デフォルトの名無しさん
NGNG目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
0055デフォルトの名無しさん
NGNG> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。
同感です。
結局は、前々スレの686の一言につきると思う。
>686
> くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
> (予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
> 決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
> Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
> カバー、的な。
0056デフォルトの名無しさん
NGNGそのBlogに対する書き込みをニヤニヤして読んでると思われ。
必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな（藁
0057デフォルトの名無しさん
NGNG>>54
> >>49
> そんな度胸ありません！
そのとおりですw
0058デフォルトの名無しさん
NGNGみなさんはいい部下をお持ちのようですね。
うちは素人だらけなので後ろ向きな方法論で結果を出すしかありません。
しかも、各自で技術力を向上させようとする前向きさも、センスもない連中が山ほどいます。まじで皆さんがうらやましいです。
0060デフォルトの名無しさん
NGNG> >>51
> 目先のお手軽さや便利さを求めちゃ何故まずいんだろう？
>
> それで、スキルない人間使って生産性が上がって利益が上げられるんだったらいいと思うんだけどなあ。
>
> オブジェクト指向に精通した人間じゃなければ設計できない・開発できないということだと会社として利益を上げにくいんだよね。
>
> お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
それについては否定はしないけど、それはビジネスの話。
技術者ならくーすの技術面について話をしようぜ。
0061デフォルトの名無しさん
NGNG技術者よりの話題だと思うんだが。
まあみんな分かってるとは思うけど、くーすでいっていることは、すげえ新しいことでは
なくて、いままでビジネスの世界で生きてきた人が経験として得てきた知識と言うかノウハウ
（ともかくこの低スキルどもにコーディングをさせてこの仕事仕上げないといけないんだよ！、
とかいうやつ）だよな。それを手続きとしてまとめたもんだ。
で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。
0062デフォルトの名無しさん
NGNG現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？
アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの？本当に？
006344
NGNG>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。
それ自体は否定しないし、これらをまとめあげようとするひがさんは偉大だと思う。
ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。
0064デフォルトの名無しさん
NGNGヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。
それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。
0065デフォルトの名無しさん
NGNGくーすの技術面？
くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの？
0066デフォルトの名無しさん
NGNG技術的に語れる人間はこのスレには居ないって事だ。
それはそれで構わないと思う。そこは所詮２ちゃんだし？
重要なのは、このスレがヒガ氏へのＱとして機能し得るか否かって事だ。
何が言いたいかって言うと
ヒガ様、手隙の時で構いませんので、その辺をBLOGの方で技術的に解説よろ
って事だｗ
■ このスレッドは過去ログ倉庫に格納されています