国産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に変更が入ることのどこが問題なのでしょうか?
どちらも何の問題もないように思いますが。
■ このスレッドは過去ログ倉庫に格納されています