トップページ⇒tech
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
002315NGNG
間に合わなかった＿|￣|○ つか、対応してくれるんだ！

こういうところもS2が好きな理由です。
002414NGNG
ごめん、間違えた。>>23は漏れ。
騙った訳じゃないのでゆるしてちょ。
002515NGNG
いやゆるさん！
002614NGNG
｡･ﾟ･(ﾉД`)･ﾟ･｡ｳﾜｰﾝ
002721NGNG
>>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
目先のお手軽さや便利さを求めちゃ何故まずいんだろう？

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

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

お客様の要望を満たして保守も容易にできるようにできていれば、正しいオブジェクト指向にこだわる必要はないんじゃないの？
005446NGNG
>>49
そんな度胸ありません！
0055デフォルトの名無しさんNGNG
>>51
> くーすはどうも退化としか思えないんだよね。
> 目先のお手軽さや便利さは得られるかも知れないけど、"オブジェクト"としての
> 柔軟性や多態性なんかが損なわれてる気がする。

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

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

必死で書き込んでる奴らは
ヒガ氏の掌で踊らされているだけだということを
自覚したほうがいいな（藁
0057デフォルトの名無しさんNGNG
44=46=48!=54ですが。

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

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

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

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

技術者ならくーすの技術面について話をしようぜ。
0061デフォルトの名無しさんNGNG
技術の世界でスキルのない人間使ってそれなりの成果物をあげることは、かなり
技術者よりの話題だと思うんだが。

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

で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
づけしたもんなんだし。
0062デフォルトの名無しさんNGNG
ひがさんの「BeanMetaDataには振る舞いを持たせるべきではない」という方針は
現場の事情で、その対価としてOOP的な「柔軟性や多態性なんかは損なわれて
いる」という結論でいいんですか？本当に？

アホでも素人でも妄想でも語れる現場話にしたい人は置いとくとして、エンジニア
の人達はこの結論でいいの？本当に？
006344NGNG
>>61
>で、ノウハウを手続きとしてまとめ上げることには俺は賛成だ。おれたちが「デザインパターン」と
>呼んでるものだって、いままでいろんな技術者が経験的に獲得してきたものを文書化して、名前
>づけしたもんなんだし。

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

ただ、的外れな指摘で「レガシーなオブジェクト指向」とかいうのはやめて欲しい。すごく迷惑。
0064デフォルトの名無しさんNGNG
要するに、
ヒガ氏の提唱しているのはビジネス的な視点での方法論で、
ここで書き込んでる人たちはビジネス的は視点としては理解はできるものの
技術的な視点で話をしたいと。

それじゃ、話が合うわけねーじゃん。
つーか、なんでそんな人たちがヒガ氏やらくーすやらに興味持ってるのかさっぱりわからん。
0065デフォルトの名無しさんNGNG
>>60
くーすの技術面？

くーす語るんだったら技術面じゃなくて
ビジネスでの有効性だとかそういう話じゃないの？
0066デフォルトの名無しさんNGNG
とりあえずハッキリしてるのは、ヒガ氏の実装で得られる利点と、損なわれる難点を
技術的に語れる人間はこのスレには居ないって事だ。

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


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

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

って事だｗ
006744NGNG
>>64
> 要するに、
> ヒガ氏の提唱しているのはビジネス的な視点での方法論で、

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

って、んなわけねーだろ。
0068デフォルトの名無しさんNGNG
>>62
いや、ひがさんの日記は、BeanMetaDataに振る舞いを「もたせるべきではない」という
話ではないだろ。BeanMetaDataはメタデータの管理（に直結した振る舞い）だけをすべき
だったのに、SQL自動生成とか関係ない振る舞いを持たせてしまった、という話だろ。

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

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

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

データと振る舞いをまとめるときに、「データと直結した振る舞いを持たせる」「データをつかった
ほげほげは別にする」というのはオブジェクト指向的には正しい判断じゃないか？
0069デフォルトの名無しさんNGNG
>>67
ああ、それ自体は技術の話題だ。
でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。
0070デフォルトの名無しさんNGNG
>>69
> >>67
> ああ、それ自体は技術の話題だ。
> でもそういうふうにする理由の大部分は、ビジネス的な要因であって、
> 技術的に美しいからとかオブジェクト指向の概念的に美しいから、とかではないと思う。


もしそうっだったとしたら、なぜひがさんは
従来のオブジェクト指向を「レガシー」と言って技術的に批判するの?
0071デフォルトの名無しさんNGNG
おれは言ってる事はともかくとして、「レガシー」という表現を使ったことについてはおかしいと思う。

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

ま、「レガシー」って言っちゃったのは失言でしたってこった。
どれだけ多くの人たちがあなたのBlogをチェックしてんのか忘れないでね。>>ひが氏
0073デフォルトの名無しさんNGNG
しかしまあ、正直言って「importって何の意味があるんですか」「java.langはimportしなくちゃ
いけないんですか」とか聞く奴が毎年量産されていることを考えると、そいつらと一緒に仕事
していく手法を身につけとかないといけないってのは切実な問題かもしれん。

だって毎年量産されるんだし...
0074デフォルトの名無しさんNGNG
いやぁ、くーすはともかくとして、Seasarは明らかにシステム構築の敷居を高くしているよ。
いろいろ覚えることあって大変だ。何がどういう役割を持っていてどう扱うのが正しいのか、
原作者にしか分からない理論（しかも、漏れ的には相当あやしい）を理解するのに何年かかるんだ。
そして覚えてそれで一体何になるのか。謎は深まる。
0075デフォルトの名無しさんNGNG
何年って、おれは使い始めて１ヶ月後にはチームの連中に説明してたが....
0076デフォルトの名無しさんNGNG
くーす周辺の「お客様」とか「現場」は、目の前の客と現場に部分最適化して、
将来の客と現場に対する思考を停止するためのエクスキューズ用語。
0077デフォルトの名無しさんNGNG
さらにチームの連中は「Struts覚えるより仕組みが簡単ですね」とか言ってたが....
0078デフォルトの名無しさんNGNG
独自の複雑なフレームワークを駆使した開発方法を
示して難解フレームワーク固有の知識で壁を構築するっていうのは、
よく見かける手ではあるけどね。

シンプルな解決法は他にいくらでもあるのに。
本当にいいものは分かってもらおうという迫力が文章やコードで示されてる
のだけど、Seasarは・・・、まぁ、しょうがないな。
0079デフォルトの名無しさんNGNG
>>68
なんか凄い自信家ですねｗ

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

そうだな。Strutsよりはマシかもしれん。
Strutsも大いなるネタの代表例でさ、あれよりいいってうのは、
果たして。大差は無いように思う。
0081デフォルトの名無しさんNGNG
なんかわからんが、Seasarはファクトリ＋AOPだし（というかDIコンテナは大体そうだわな）、
くーすはWeb開発ノウハウの集合体であって、別に独自のフレームワークや固有の知識だと
思った事ないんだが。むしろ「あーたしかにそんな感じでやってるよ」ってくらいで。

逆にその「まとめよう」というところに価値があると思ってる。
0082デフォルトの名無しさんNGNG
すごい勢いでレスがついてますね。
みんな比嘉さんにもてあそばれてるなあ。

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

しかし、Blogで２ちゃんのスレに煽りを入れて、
こんなにたくさんの人が踊らされるなんて、さすが比嘉さん。
0083デフォルトの名無しさんNGNG
むしろひが氏のネタの半端さがレスを呼んでるんじゃないの。
DIスレの213=332と同様。厨がいたほうが一見盛り上がってるように見える罠。
0084デフォルトの名無しさんNGNG
>>82

そうか。やっぱり、ネタだったのか。
くそー、悔しい。
まぁ、そりゃそうか。
でも、本当にイカンのはマジなトーンで
DIコンテナORマッピングAOPとか言ってるやつらだぞ。
思わず反応してしまう・・・
0085デフォルトの名無しさんNGNG
まあ自分の主張を目立つように書こうとしてつっぱしり過ぎたってとこだろう。
もし本気でレガシーって思って書いてたら、S2自体の価値が疑われかねないので、
調子のって突っ走ってしまったと思いたいね。

まあ一方で、データと振る舞いの組み合わせ方は微妙な判断が必要な問題だ
と思う。その判断を卒業したてのＰＧに任せたくはないが、やらせないと低能の
ままの奴と付き合い続けなければいけないというジレンマに...
0086デフォルトの名無しさんNGNG
>>84
ほんとにもてあそんぶためのネタとしてレガシーなんて言ったんだとしたら、S2に対する指示を
失いかねないネタだと思うぞ。

おれは勢い余ったんだと思うけどね。
0087デフォルトの名無しさんNGNG
指示＝支持
0088デフォルトの名無しさんNGNG
とりあえず呼んどくか。

　　☆ ﾃｨﾝ

　　　 　　 ☆　ﾃｨﾝ　　〃　 ∧＿∧ 　 ／￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）＜　 ﾋｶﾞﾀｿ消火まだー？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿)＿ ＼＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣￣／|
　　　　　　　　| ￣ ￣￣￣￣￣￣:|　:|
　　　　　　　　|　　　　　　　　　　　.|／

DIスレをリスペクトして「ﾃｨﾝ」だ。
0089デフォルトの名無しさんNGNG
結論：やっぱEJB。
0090デフォルトの名無しさんNGNG
>>89

EJBが実は最も壮大なネタで、
それよりマシなものなら「漏れにも作れる！」
と思う香具師、たくさんいるんじゃないかね。
しかし、EJBよりマシなものできたところで、
EJB自体がネタだから、どっちにしろネタなのだ。
0091デフォルトの名無しさんNGNG
似た方向を目指しててそれぞれ一長一短なモノなら、
メジャーな手法を使うのは当然だよな。
0092デフォルトの名無しさんNGNG
ふ〜ん
0093デフォルトの名無しさんNGNG
まあ、Java自体がネタだからね。
0094デフォルトの名無しさんNGNG
>>82
レガシーっていってるのは、1つのクラスが役割を複数持ってる
ような設計のことでしょう。
これまでのオブジェクト指向がすべてレガシーっていってるわけじゃない。

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

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

やっぱりね、Seaserに限った事じゃないけど楽になるだろうって思って
使うのは、全体的に見て楽になるかを見ないといかんね。
0096デフォルトの名無しさんNGNG
でも

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

だそうですから。
0097デフォルトの名無しさんNGNG
DIっつっても、DIで作られたクラス使う分にはただのファクトリなんだし
対して技術的に難しい概念ってことはないと思うが。
009895NGNG
>>97
>技術的に難しい概念ってことはないと思うが。
OOで一回でも作った事がある人は難しいとは思わんとだろうけど
お客はそうじゃないし。

DBAがプログラム中にSQLがあるのとO/Rマッパ使ってるときとで
インパクトが違うのとにてるんでないかなーと。
0099デフォルトの名無しさんNGNG
>>95
実装を意識する必要はないというやり方ですからね。
気にするのは、インターフェースであり実装ではない。
実装はブラックボックスで良いと思う。
■ このスレッドは過去ログ倉庫に格納されています