- 1 名前：デフォルトの名無しさん mailto:sage [04/08/09 18:36]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
それではスタート！
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
pc5.2ch.net/test/read.cgi/tech/1090653286/
- 620 名前：デフォルトの名無しさん mailto:sage [04/10/16 22:49:27]
- 構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？
- 621 名前：デフォルトの名無しさん mailto:sage [04/10/16 23:09:46]
- 591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。
世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。
大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。
で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。
そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。
- 622 名前：デフォルトの名無しさん mailto:sage [04/10/17 00:13:43]
- > OOってまだそこまで大成功は収めていない手法にも関わらず
ぽかーん。
まるで、親にメシ食わせてもらいながら「親なんて必要ない」とほざいてる中学生みたいだな。
- 623 名前：デフォルトの名無しさん [04/10/17 00:15:16]
- >>620
>OOってまだそこまで大成功は収めていない手法にも関わらず、
ΣΣ(ﾟдﾟlll)ｶﾞｶﾞｰﾝ!!
- 624 名前：617 [04/10/17 00:30:58]
- >>621
> 591だけど、ドメインモデル貧血症の事は知ってます。
> だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
> 別の流れも最近よく目にします、っていう意味ですよ。
寡聞にして知らないのですけど、どのへんで見たのか教えていただけませんか?
> 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
> ってだけなのは、ちょっとお寂しいですね。
いや、
ファ> ドメインモデル貧血症問題の本質は、ドメインモデルのベネフィットを何も得ず、
ファ> コストだけをすべて被ってしまうという点です。
とも仰ってます。
もちろん「ドメインモデルなんて使わないで TransactionScript一本」っていうプロジェクトであれば、
ドメインモデル貧血症に該当してもなんの問題もないとは思いますけど。
> そもそもその貧血症だのなんだの、
> 純血種しか許さない態度が俺は好かん。
これはそうですな。反省してます。
- 625 名前：617 [04/10/17 00:39:55]
- >>612
> >>611
> 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
> SQLバリバリの人だったら、その辺問題ないのかなあ。
SQLバリバリだろうがなかろうが問題ありありだと思うよ。DRY原則に反してるわけだから。
# DRY原則は数あるソフトウェアの原則の中でも、最も尊ぶべき原則だと思うなぁ
- 626 名前：デフォルトの名無しさん mailto:sage [04/10/17 01:50:08]
- DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。
これがすばり貧血症にあたるかわからないけど
tp://www.relaxer.org/process/sample/library/LibrarySystem1.1.1/LibrarySystem_s4.html
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。
あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。
でもそんな違いは誤差だとかってまた言われそうだ。
- 627 名前：デフォルトの名無しさん mailto:sage [04/10/17 02:07:30]
- あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。
- 628 名前：デフォルトの名無しさん mailto:sage [04/10/17 02:25:12]
- まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。
業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。
浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。
VB + OCXが割と正解だったってことかな。
- 629 名前：デフォルトの名無しさん mailto:sage [04/10/17 03:37:46]
- 626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。
完全にスレ違いになってしまいました。
- 630 名前：デフォルトの名無しさん mailto:sage [04/10/17 09:05:34]
- >>629
どこが、常人に難しそうなの。
- 631 名前：デフォルトの名無しさん mailto:sage [04/10/17 10:40:20]
- 最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。
ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。
DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。
これがくーすの考え方なんだと思う。
それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。
- 632 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:06:45]
- > DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。
これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)
- 633 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:19:55]
- >>632
必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。
- 634 名前：デフォルトの名無しさん mailto:sage [04/10/17 11:33:13]
- システムを層に分ける。
データストレージ―(1)―ビジネスロジック―(2)―プレゼンテーション
ここを流れるデータを分類する。
(1)は DTO<->ドメインモデル
(2)は ドメインモデル->View用モデル(左から右のみ)
ドメインモデルをDTOと同じ構造にすることができるのは、
データストレージ層を新規に設ける場合のみ。
DBスキーマを新規にゼロから構築するケースがどのくらいあるだろうか。
ほとんどないのが実情だ。
ドメインモデルとDTOを一緒にしたいという方向から考えると、上記モデルとは矛盾する。
俺は上記モデルから考えるからこそ、ドメインモデルとDTOは一致しないという立場にたつ。
実際、(1)と(2)で別クラス(実際には別インタフェース)を作ってから実装させたことがある。
DB操作、ビジネスロジック、プレゼンテーションを綺麗に作業分担させられたよ。
- 635 名前：デフォルトの名無しさん [04/10/17 11:44:16]
- >>628
> 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
> 前提に、ICONIXやくーすってあると思う。
くーすはそうかもしらんが、ICONIXはそんなこと言ってないと思うんだが?
Use Case Driven Object Modeling with UML(ユースケース入門)で読んだ知識しかないんだけどさ。
- 636 名前：デフォルトの名無しさん mailto:sage [04/10/17 12:04:21]
- >>634
ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。
きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。
内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。
- 637 名前：デフォルトの名無しさん mailto:sage [04/10/17 15:42:09]
- まず前提。Domain ObjectとDTOの相互変換はめんどくさい。
FowlerのPofEAAのService Layerの説明のところに確か
「DTO変換のコストを過小評価するな。オブジェクトのツリーが
深くなるとすげー辛い」みたいなことが書いてあったはずだ
(いま本が手許にないので正確な表現はわからん)。
俺も「Presentation層のコントローラ(この時はStrutsのAction)は
Service Layerを介してDTOを受け取り、Domain Objectには絶対
直接触らない」ってポリシーで設計したけど結局実装とテストが
やたらしんどくなって方針転換したことがある。
んで、DTO変換をしないとなると、Domain Object側に巻き込むか、
DTO側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。
# ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686 とか
ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。
# ひが氏はロングキャッシュは知らんとか言ってるけど。
# ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710
- 638 名前：デフォルトの名無しさん mailto:sage [04/10/17 16:43:55]
- >>633
業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
・業務ロジックを起動するための情報を収集する(=入力画面)
・業務モデルに関する情報を提示する(=参照画面)
- 639 名前：デフォルトの名無しさん mailto:sage [04/10/17 17:35:07]
- >>637
よくわかる説明だけど、わかるやつにしかわからんってなってるかも。
- 640 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:18:33]
- >>638
それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？
業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633
こっちの方が正しいんじゃない？
- 641 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:49:29]
- >>640
>>638の1行目を穴が開くまで読むべし。
- 642 名前：デフォルトの名無しさん mailto:sage [04/10/17 18:56:47]
- >>641
穴があいたら、次はどうすればいいですか？
- 643 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:01:05]
- >>642
入るしかないでしょ。
- 644 名前：デフォルトの名無しさん mailto:sage [04/10/17 19:52:07]
- 入れるしかないよ。
- 645 名前：デフォルトの名無しさん mailto:sage [04/10/17 20:19:25]
- 入れるから穴があくんだろ。逆転してるぞ。
- 646 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:33:54]
- はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。
- 647 名前：デフォルトの名無しさん mailto:sage [04/10/17 23:59:45]
- 俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。
ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。
DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！
- 648 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:09:33]
- まったく同意。本当、からさわぎ楽しみ。
でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。
- 649 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:10:53]
- リファクタリングして説教して来いｗ
みんなが>>646に期待してるぞ
- 650 名前：647 mailto:sage [04/10/18 00:30:39]
- >>648
>やっぱファウラーの文章とか読むとワクワクするんだよね。
その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。
- 651 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:45:33]
- >650
ありがとう、なんか気が楽になりましたよ。
気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w
- 652 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:47:45]
- まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。
- 653 名前：デフォルトの名無しさん mailto:sage [04/10/18 00:59:42]
- 書籍代なんて誤差の範囲だよ。
プププ
- 654 名前：デフォルトの名無しさん [04/10/18 02:34:48]
- 結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?
- 655 名前：デフォルトの名無しさん mailto:sage [04/10/18 02:46:23]
- >. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。
って、所詮2chか。S2にもフォーラムが欲しいな。
- 656 名前：デフォルトの名無しさん mailto:sage [04/10/18 04:21:56]
- >>655
みんな各自のblogで満足してるから、実現性は低いね。
- 657 名前：デフォルトの名無しさん mailto:sage [04/10/18 07:58:24]
- >>637
ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。
むきだしのドメインオブジェクトなら、画面では激しく使いづらい。
- 658 名前：デフォルトの名無しさん mailto:sage [04/10/18 09:28:58]
- >>655MLじゃ駄目なの？
- 659 名前：デフォルトの名無しさん mailto:sage [04/10/18 15:53:43]
- >655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？
はぶか？
- 660 名前：デフォルトの名無しさん mailto:sage [04/10/18 16:07:11]
- 「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」
文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。
- 661 名前：659 mailto:sage [04/10/18 16:08:44]
- どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません
- 662 名前：デフォルトの名無しさん mailto:sage [04/10/18 18:00:26]
- じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。
- 663 名前：デフォルトの名無しさん mailto:sage [04/10/18 18:56:32]
- 納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。
- 664 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:08:31]
- > 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。
という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。
- 665 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:14:28]
- >>663
それははぶについてでなくて一般論だよね？
はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。
ほっときゃ本人があっちに書くか。楽しみにしていよう。
- 666 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:18:17]
- 今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？
って、所詮2chかｗ
- 667 名前：デフォルトの名無しさん mailto:sage [04/10/18 19:34:01]
- 俺はそんなにスレ・板違いにも思えないんだな。
S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。
ムだのマだのでがっつり分けたがる方が
所詮2ch。
- 668 名前：デフォルトの名無しさん mailto:sage [04/10/18 20:02:15]
- >>666
前向きもうしろ向きもなく、雑談。
- 669 名前：デフォルトの名無しさん mailto:sage [04/10/18 20:03:18]
- マ板は、ネタスレ用隔離板ですよ。
- 670 名前：デフォルトの名無しさん mailto:sage [04/10/18 20:04:47]
- 現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。
- 671 名前：デフォルトの名無しさん mailto:sage [04/10/18 22:29:15]
- ｽﾙｰしる
- 672 名前：デフォルトの名無しさん mailto:sage [04/10/18 22:45:41]
- そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗
- 673 名前：デフォルトの名無しさん mailto:sage [04/10/18 23:39:08]
-
OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。
- 674 名前：デフォルトの名無しさん mailto:sage [04/10/19 02:32:25]
- はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。
- 675 名前：デフォルトの名無しさん mailto:sage [04/10/19 03:31:31]
- おお、すずめかあ。懐かしいなあ。
でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。
- 676 名前：デフォルトの名無しさん mailto:sage [04/10/19 03:50:38]
- いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。
で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。
- 677 名前：デフォルトの名無しさん mailto:sage [04/10/19 13:18:16]
- >673
そうだね。一応outer定義してinjectDependencyという手段はあるけど、
メリットのあらかたを享受できないからね。
DIを考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。
- 678 名前：デフォルトの名無しさん [04/10/19 20:57:03]
- 業務アプリケーションをそんなに急いで作りたいなら、一番確実な方法としては
「あらかじめ作る」しか無い。
つまり、業務アプリでEclipseみたいにプラグインで拡張可能なソフトを作ることだと思うよ。
（この設計は極めて難しいものになるだろうけど。）
- 679 名前：デフォルトの名無しさん [04/10/19 20:59:44]
- 業務アプリとはいえ、プラグインプログラミングをやらうとするなら、
ソース公開されていることは必須条件。別にGPLじゃなきゃだめというわけじゃないけど。
（ソース読まずにプラグインだけ作ることは無理だ）
- 680 名前：デフォルトの名無しさん mailto:sage [04/10/19 21:23:49]
- >>678
StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。
- 681 名前：デフォルトの名無しさん mailto:sage [04/10/19 23:15:00]
- この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？
- 682 名前：デフォルトの名無しさん mailto:sage [04/10/19 23:31:44]
- 3.14人くらい？
- 683 名前：デフォルトの名無しさん mailto:sage [04/10/20 00:10:39]
- S2というか、そもそもJavaで実装すること自体やめたほうがいい
- 684 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:06:05]
- なんで？
- 685 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:27:24]
- Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。
- 686 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:29:31]
- S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。
何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。
# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。
くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。
- 687 名前：デフォルトの名無しさん mailto:sage [04/10/20 01:41:00]
- スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。
- 688 名前：デフォルトの名無しさん mailto:sage [04/10/20 02:04:06]
- S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。
所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。
- 689 名前：デフォルトの名無しさん mailto:sage [04/10/20 06:33:55]
- >「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。
- 690 名前：デフォルトの名無しさん mailto:sage [04/10/20 06:39:58]
- >>686
TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。
なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。
あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。
- 691 名前：デフォルトの名無しさん mailto:sage [04/10/20 09:19:09]
- S2Quartz!!!
d.hatena.ne.jp/khi/20041020
- 692 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/20 12:05:09]
- 686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。
- 693 名前：デフォルトの名無しさん mailto:sage [04/10/20 13:08:35]
- >>686
>2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆
- 694 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:20:59]
- 比嘉氏・取り巻き・羽生氏ときて今度は若手か。
徹底的に人に絡んでくるな。
- 695 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:25:28]
- つうか、取り巻きって誰かが明示されてないし。
イタい取り巻きの例示きぼん>>686
- 696 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:26:14]
- s/取り巻き/若手
- 697 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:34:42]
- んなこといいけど、S2JSFって進んでるのかな？
なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。
S2JSFのためにS2のバージョンアップが必要なのだろうか？
- 698 名前：デフォルトの名無しさん mailto:sage [04/10/20 19:48:08]
- S2JSFのためのS2.1化だろ。
- 699 名前：697 mailto:sage [04/10/20 19:49:30]
- う〜〜待ちきれない
- 700 名前：デフォルトの名無しさん mailto:sage [04/10/20 20:04:00]
- そこでJSF-Springですよ
- 701 名前：デフォルトの名無しさん mailto:sage [04/10/20 20:30:58]
- >>695
やめれ。これ以上個人名を出す必要はないよ。
比嘉氏や羽生氏はともかく他の人は関係ない。
- 702 名前：デフォルトの名無しさん mailto:sage [04/10/20 23:09:40]
- ひがさんやはぶさんの名前を出す必要もないけどな
S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。
- 703 名前：デフォルトの名無しさん mailto:sage [04/10/20 23:12:53]
- やっぱりからさわぎはくーすのトラックが人気なのかな？
俺もデザイントラックにしようかと思ったんだけど
くーすは本が出るからそっち読むとして
今回はビジネストラックにしようかなとも思って。
マジカ面白かったし。
- 704 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:08:30]
- S2JSF いつ頃だろうか。
前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz
- 705 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:11:39]
- >>704は>>700に助けてもらえ
- 706 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:33:30]
- 今のうちにS2に乗り換えてしまくて。
WW2かTapestry試そうかと思ったが、本命はS2JSFなんだよな。
タイミング的に微妙.....
- 707 名前：デフォルトの名無しさん mailto:sage [04/10/21 00:52:05]
- 何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。
そんな２７歳の秋。
- 708 名前：デフォルトの名無しさん mailto:sage [04/10/21 01:22:30]
- この板以外、どこのブログ見りゃいいんじゃいの？押さえどころ
- 709 名前：デフォルトの名無しさん [04/10/21 02:45:56]
- ドメインロジックとSQL
capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
くーすマンセーな人は、一度↑を読んでみて欲しい。
それで、TransactionScriptと DomainModelの長所短所を理解した上で
TransactionScriptを使っていただきたいなー。
- 710 名前：デフォルトの名無しさん [04/10/21 06:08:00]
- 大田@会社さんへのレスというわけではないのだけど。
>>692
> 理想は，でも現実的には，だったらどうしたらよい
> という前向きな人たちの集まりだと思うのだけど。
傍から見てると
「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
って言っているように見えちゃうのは俺だけ?
# TransactionScriptが最適解である状況が存在することは否定しないけどさ
- 711 名前：710 [04/10/21 06:19:20]
- 間違えた。
以下のとおりに修正。
>ひがさんとはぶさんを傍から見てると
>「理想=OOA/D」は幻想だった、これからは TransactionScriptマンセー
>って言っているように見えちゃうのは俺だけ?
- 712 名前：デフォルトの名無しさん mailto:sage [04/10/21 09:08:50]
- はぶ氏がRDB大好きだというのはblog見てるとわかる。
ひが氏はもう少しニュートラルというか使いやすい
ORマッピングを考えてのことなんじゃないかな。
ふたりともTransactionScriptマンセーというのとはまた違う気がする。
ER分析マンセーなのかも知れないが。
- 713 名前：デフォルトの名無しさん mailto:sage [04/10/21 10:03:23]
- RDBをRDBとして使う限りにおいては、ER分析マンセーみたいね。
俺も同意。つーか当たり前だと思う。
RDBをただのストレージとして使うやり方は俺には合わんかったんでｼﾗﾈ。
- 714 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/21 10:37:12]
- 710さん>
幻想というより西方浄土でしょうか。ひがさんにダイレクトに聞いてみると分かりますが，
TransactionScriptマンセーじゃないですね。僕も今は教育側にいるときがありますけど，
理想のOOA/Dは現時点ではあまりに属人性がありすぎて，Martin Folwerのいる会社のような
よほどつわものがそろった組織でないと難しいです。つわものがそろっていれば，理想の
OOA/Dも不可能ではないと思います。
>capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
既読です。読書会でも話題になりました。これをたたき台にして，トレードオフについても
かなり議論になりました。理想のOOAD対ER分析というよりはメンテナンス性対パフォーマンス
というところでしょうか。
- 715 名前：デフォルトの名無しさん mailto:sage [04/10/21 11:11:11]
- 単に選択の問題であるだけでしょう。
私が今携わっているプロジェクトでは業務ロジックがさほど多くなかったので、
Springを使ったTransactionScriptな設計にしてありますが、
明らかにサービス層の肥大化が予想される場所にはDomainModelを適用しています。
別にどちらが正解であるということもありませんが、OOエキスパートが少ない
環境ではTransactionScript寄りになってしまうことは避けられないでしょうね。
ちなみにくーすはTransactionScriptの発展的なアプローチだろうと思います。
ひがさんは否定しておられるようですが、サービス層と永続化層を分離した
パターンの中で、大別して上記２つ以外に思いつくものはありません。
というか何がどう違うのかもうちょっと説明して欲しいかも。
Entity層にビジネスロジックを含めないって時点で、少なくとも
DomainModelではないし。
今日は風邪で休んでるんで自宅からカキコ。
直に書きに行こうかともおもったけど私なんかの出る幕はではなさそうだし、
この場で失礼。
- 716 名前：デフォルトの名無しさん mailto:sage [04/10/21 11:15:59]
- ビジネスロジックって表現がそもそも曖昧だよな
- 717 名前：715 mailto:sage [04/10/21 11:24:03]
- >>716
> ビジネスロジックって表現がそもそも曖昧だよな
そうかも。
私の中では一連の"業務仕様"ってところで理解してます。
売上げ本数の計上ルールとか？ いい例えが思い浮かばん。
永続化処理とか、メールやCSV取込とかはビジネスロジックとは
呼べないでしょうね。
- 718 名前：715 mailto:sage [04/10/21 19:00:45]
- 本当に答えて貰ってたんで、ちょっと感激してしまった。
私自身、2chにもカキコすることなんて滅多にないから。
なるほど。
というところですが、時間があればひがさんにもPofEAAの一読をお勧めしたいです。
文章を読む限り、原書の方にはまだ目を通されていないような印象でしたので。
リッチなSQLはDomainModelにもTransactionScriptにも適用されます。
そこでの問題はロジックがSQL内に分散することですが、これがパフォーマンスとの。
トレードオフだと言っているわけで、それはDomainModelにしろTransactionScriptにしろ
同じことです。
ところで、このスレのちょっと上のあたりでDomainModelとDTOとの相互変換云々って
話で盛り上がってたようですね。
私はよく、DomainModelをDTO(テーブルと同じ構造)を内部に複数持ち、
各層に公開するインターフェースを実装したオブジェクトとして定義することがあります。
というか大体これです。
相互変換の必要がないインチキ手抜き設計なので、当然無駄なプロパティや処理が
増えることになりますが、要の部分はインターフェースを介して隠蔽されているため、
実際に問題になるような事は滅多にありません。
Springの各種DaoSupportやS2Daoもそのままの形で適用出来ます。まあ参考までに。
純粋なDomainModelはO/RMapperの発展に合わせて、今後少しずつでも浸透して行くでしょう。
と願ってみる(希望的観測)
- 719 名前：デフォルトの名無しさん mailto:sage [04/10/21 20:37:11]
- 結論：OO厨は邪魔なだけ。
- 720 名前：デフォルトの名無しさん mailto:sage [04/10/21 21:44:57]
- ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。
|
 |
