国産オープンソースDIコンテナSeasar V2(S2)

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:10 / Filesize : 285 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
577 名前：デフォルトの名無しさん mailto:sage [04/10/13 19:01:57]: しかしみんないろんな日記よく読んでるねえ。

みんななんだかんだいってもS2が気になってしょうがないんだね。
578 名前：570 mailto:sage [04/10/13 19:24:45]: >>577
まさにそのとおり。からさわぎいくどー。
579 名前：デフォルトの名無しさん [04/10/13 21:03:02]: S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...
580 名前：デフォルトの名無しさん mailto:sage [04/10/13 21:09:02]: >>579
あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。
581 名前：デフォルトの名無しさん mailto:sage [04/10/13 21:33:58]: うちなーんちゅ記念ｶｷｺ
582 名前：デフォルトの名無しさん mailto:sage [04/10/13 23:19:53]: >> 580
コアな部分は全部１人でやってるよ。
583 名前：デフォルトの名無しさん mailto:sage [04/10/13 23:43:03]: S2Dao使うにはMySQLは不向きだな。
584 名前：デフォルトの名無しさん mailto:sage [04/10/14 00:05:05]: >>579
オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような
585 名前：デフォルトの名無しさん mailto:sage [04/10/14 00:07:17]: コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。
586 名前：デフォルトの名無しさん [04/10/14 06:56:40]: >>573
> パスワード変更クラスとメールアドレス変更クラスをつくりやがった

これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。
587 名前：デフォルトの名無しさん [04/10/14 06:57:10]: 顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん
588 名前：デフォルトの名無しさん mailto:sage [04/10/14 07:22:10]: ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？
589 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:25:45]: 顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。

わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。

是非俺にも納得できるように説明して欲しい
590 名前：デフォルトの名無しさん mailto:sage [04/10/14 16:36:32]: 誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、

という無法状態を放置しているのがそもそもの間違い。
591 名前：570 mailto:sage [04/10/14 17:11:30]: >>589
データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。

ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。
592 名前：デフォルトの名無しさん mailto:sage [04/10/14 17:54:51]: >無法状態を放置しているのがそもそもの間違い。

まあそりゃそうなんだが。

>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか

ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。

で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。
593 名前：デフォルトの名無しさん mailto:sage [04/10/14 20:34:50]: >>592
顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。

>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・
594 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:09:20]: >顧客情報と認証情報を別個に分けて管理したい時

そのために内部の実装を分けないといけないようなケースがそんなにあるの？

>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・

誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど
595 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:21:04]: >>592
>ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
>daoCustomer.setData(this);
>dao.update(connection);
>みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
>渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
>使えば楽になるのかなあと思って興味を持ってるわけだけど。

S2Dao使うと、dao.update(customer);で済む。
複数のdaoでconnectionを共有するなんてのは、まさにDIの使いどころ。
596 名前：デフォルトの名無しさん mailto:sage [04/10/14 21:38:20]: >>591
データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？
597 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:00:15]: >596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。

白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。
598 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:07:20]: 下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。
599 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:16:47]: データとロジック分けるメリットって？
600 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:48:16]: >>599
メリットは597が言ってる。

でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。

なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。

S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？
601 名前：デフォルトの名無しさん mailto:sage [04/10/14 22:48:26]: ValueObjectに処理を持たせるという話をしてるの？
602 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:01:23]: >599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。

ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。
603 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:09:27]: 業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。
604 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:16:36]: S2JSFまだぁ？
605 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:21:26]: >> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。
606 名前：デフォルトの名無しさん mailto:sage [04/10/14 23:40:01]: 601ハ、ValueObjectノ意味ヲハキチガエテマス。
607 名前：デフォルトの名無しさん mailto:sage [04/10/15 00:33:00]: >603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。

ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。

だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。

うまくいけば楽にならないかなぁ。
608 名前：デフォルトの名無しさん mailto:sage [04/10/15 00:55:06]: >>607
ふつーうにS2の実装ってそんな感じじゃないの。
609 名前：デフォルトの名無しさん mailto:sage [04/10/15 03:00:24]: ビジネスルールがSQLに分散するんじゃね？
610 名前：デフォルトの名無しさん mailto:sage [04/10/15 09:44:02]: ビジネスルールって言葉が曖昧だよな
611 名前：デフォルトの名無しさん mailto:sage [04/10/15 13:35:54]: >>609
どーせ、SQLは山ほど書くんだから問題なし。
612 名前：デフォルトの名無しさん mailto:sage [04/10/15 14:09:21]: >>611
山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。
613 名前：デフォルトの名無しさん mailto:sage [04/10/16 04:31:40]: S2Ayaya を使えばあややのどこにinjectionできますか。
614 名前：デフォルトの名無しさん [04/10/16 04:55:10]: もちろん大事なところでしょう。
615 名前：デフォルトの名無しさん mailto:sage [04/10/16 12:56:46]: メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？
616 名前：デフォルトの名無しさん mailto:sage [04/10/16 14:25:56]: >614

RejectedRuntimeExceptionが発生します。
617 名前：デフォルトの名無しさん [04/10/16 21:29:13]: >>591
>データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。

やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。

おまいら、以下を読んで目を覚ましてくれ。

----
ドメインモデル貧血症
capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----
618 名前：デフォルトの名無しさん mailto:sage [04/10/16 21:50:51]: そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。
619 名前：デフォルトの名無しさん mailto:sage [04/10/16 21:57:31]: >やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。

617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。
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]: ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。
721 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:00:20]: ここんところの話が英単語ばっかりでよくわかんにゃい。

くーすの考え方の肝ってどっかに載ってる？
「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。

OOは部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。
自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が１人いただけで設計が崩壊しかねない。
それが自分だったりして鬱になる。

例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、
芸が無いグラマンでデスマから生還したほうがいい。
722 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:14:52]: その例えだと、グラマンはいかにも燃費が悪い。
ぜいたくに出来た飛行機だと松本零二も言ってます
↑
ここ笑うところ
723 名前：デフォルトの名無しさん mailto:sage [04/10/21 22:58:25]: >>721
その、グラマンたるライブラリがSeasar2なんだよ！

POJO書いて、設定ファイルを書くだけ。
S2で欲しい機能があれば、はてなでｷﾎﾞﾝﾇするだけでOK。
724 名前：デフォルトの名無しさん mailto:sage [04/10/21 23:48:09]: ひが氏にお願いです。
商用サポートもドキュメント見直しもFlexも
くーす本もからさわぎも全部後回しでいい。
頼むからS2JSFを早く出してください。おながいします。
725 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:28:45]: >>724

S2JSF ＞くーす本＞＞＞＞＞＞その他
726 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:41:18]: 開発するより宗教論争が好きな人って結構いるね。
727 名前：デフォルトの名無しさん mailto:sage [04/10/22 00:52:30]: 2chに書いてるﾔｼなんざ大抵そうだな
728 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:04:27]: つか、2ちゃんだから出来るんだよ。
現場でやる奴よりは全然いい。

大体宗教論争ってのは、スプーンに天使は
何人乗る事が出来るかとか
そういうアホで無意味な事を議論する事で、
ここでの話はわりと意義はあると思うよ。
729 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:04:56]: >>726
開発なんかするより他人を論破することが楽しいですが何か？
730 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:20:59]: >>729
hub。
731 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:32:03]: >>721

> ここんところの話が英単語ばっかりでよくわかんにゃい。

www.martinfowler.com/eaaCatalog/

> くーすの考え方の肝ってどっかに載ってる？
> 「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。

www.wikiroom.com/tpircs/?cmd=read&page=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1&word=higa%A4%B5%A4%F3%A4%CB%A4%E8%A4%EB%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%CA%FD%CB%A1
732 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:45:02]: ttp://d.hatena.ne.jp/higayasuo/20041021#1098336935

うそーん。ぜんぜん問題わかってないじゃん。

だまされたと思って一回原典読んでみてください。お願いします。
733 名前：デフォルトの名無しさん mailto:sage [04/10/22 01:51:36]: ttp://d.hatena.ne.jp/higayasuo/
> 良く使われると思われるドキュメントを見直しました。
> すべて、概要、リファレンス、Exampleの3部構成になっています。
> どうでしょう。2chの人

おぉ、こぎれいに、丁寧になってる。
くるしゅうないぞよ。

あとは、www.seasar.orgにそういった改変情報が載るようにすることですね。
それから、ソースと実行結果はスタイルを変えたほうが。
実行結果は黒地白文字とか。
734 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:04:34]: 733のような奴の言うこと真に受けて、がんばってらっしゃる。
ひがさん、尊敬します。
733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動くプログラムを作ることすらできないですから。残念！
735 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:17:22]: >>734
> 733のような奴の言うこと真に受けて、がんばってらっしゃる。
> ひがさん、尊敬します。

>>733って、文体は2ch的で一見失礼だけど、ひが氏のモチベーション向上+
前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。

> 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、
> ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動く
> プログラムを作ることすらできないですから。残念！

こういう非生産的なラベリングはやめようよ。つーわけで>>733気にするな。

って、>>733の自演扱いされるのがオチか。
736 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:19:11]: >> バウンダリで、直接ドメインオブジェクトを使うのも、かなり困難だと思います。
これって理由は何でだっけ？
737 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:35:11]: >>735
>ひが氏のモチベーション向上+
>前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。

ドキュメント的には、「今の段階で」十分すぎるほど揃ってると思う。
日本語ということも含めると、他のオープンソースプロジェクトなんかより
断然素晴らしい。

失礼な文体、普通はモチベーション下がるって。成果物改善支援？大きく出たな。
物は言いようか。好レス？？笑けた。ネタ？
738 名前：733 mailto:sage [04/10/22 02:37:38]: >>735
ありがとー。
あーだこーだ言うだけ言って、作業に手は貸さないわけだから、そこに対して改善が図られた場合には、ちゃんと気づいて反応するようにしてるです。
739 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:40:58]: 「今の段階で」というなら、「揃っている」じゃなくて「揃った」、の方があてはまるんじゃねぇの？
740 名前：デフォルトの名無しさん mailto:sage [04/10/22 02:50:08]: >>736
あとで仕様変更があってバウンダリとドメインオブジェクトの間にロジック（サービス）を
挟まなくちゃいけなくなった時に困るからじゃなかったっけ。
741 名前：デフォルトの名無しさん mailto:sage [04/10/22 03:06:07]: 「今の段階としては」だな。
742 名前：デフォルトの名無しさん [04/10/22 06:11:18]: d.hatena.ne.jp/higayasuo/20041021#1098310525
> リソース層にRDBMSを使う限り、SQLの知識は必須です。
> デザインパターンやP of EAAの習得には熱心だけど、
> SQLには興味ないなんて人がいるなら、知識のバランスに
> かけてます。

d.hatena.ne.jp/habuakihiro/20041021#1098369060
> JSPバリバリですぅ～。でもServletはわかりませ～ん。ってのと、
> ORマッピングツールバリバリですぅ～。でもSQLはわかりませ～ん。
> っていうのは、似たり寄ったりだと思うんだが、

お二人とも勘違いなさっているようですけど、
DomainModelを推している人たちは

「SQLが分からないから使わない」

んじゃなくて

「SQLにビジネスロジックを入れたくないから使わない」

んです。

RDBMSを使っている限りはSQLの知識が必須なのは当然でしょう。
743 名前：デフォルトの名無しさん mailto:sage [04/10/22 06:50:50]: >>732
問題と思うことをきちんと指摘したら。
人にいわれる本を全部読むような時間のあるひとはいないだろ。
744 名前：デフォルトの名無しさん mailto:sage [04/10/22 07:09:24]: >742
推している人たちって誰のこと？
DomainModelいいよ！って言ってる人全部ってわけじゃないでしょ？

SQL書きたくないから～って人は確実にいる（何人か知ってる）し、
そういう人を想定して言ってるんじゃないかな。
SQLばっちり分かっててかつDomainModelを推してる人よりは多いと
感覚的には思うが、どうだろね。
745 名前：デフォルトの名無しさん mailto:sage [04/10/22 07:52:08]: >>742
DomainModelを推している人は、
「SQLが分からないから使わない」
と思っているとは、書いてないと思うけど。

それは、被害妄想。
746 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:27:37]: >>735
我田引水
747 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:30:03]: >>742
なあビジネスロジックって何？
ほんとにわかんねえんだよ。
SQLで平均とか一発で出せても
使うなってことか？平均何とかも
ビジネスロジックだと思うんだけど。
748 名前：デフォルトの名無しさん mailto:sage [04/10/22 08:34:15]: 何でこのスレはageる人が多いんだ？
749 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:00:30]: >>732
ひがたんはそんなの読まなくてもいいからS2JSFを先に作って欲しい。
正直漏れはくーすはどうでもいい。便利な道具としてのS2が気に入ってるんだ。
もしひが氏が真面目に原典とやらを読んだ結果S2JSFのリリースが遅れたりしたら
>>732ぬっころす
750 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:20:50]: そこまで粘着すると、キモいね。
751 名前：デフォルトの名無しさん mailto:sage [04/10/22 09:32:31]: 2chに書いてるだけでキモいけどね
とりあえずこのスレは粘着のスクツということでFA
752 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:35:49]: >>747
そういうことみたいだな。

複雑な会計の帳票とか出すとき
どうするんだろうって思うよ。

UNIONとかFROM句にサブクエリとか
ガンガン書いてやっとまともなレスポンスで
出るようになる帳票とか山ほどある。

だからS2Daoは、最初見たとき霧が晴れた気分でした。
753 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:42:12]: ドキュメントがいくつか更新されたみたいです。
・DIContainer
・AOP
・テスト技法
・S2DAO
の4項目かな？

どこの項目が更新されたかわかるように印をつけて（updateとかnewとか）
くれるとありがたいなあ･･･
754 名前：デフォルトの名無しさん mailto:sage [04/10/22 10:59:46]: >>753
>>733で既出。そこのブログにリリースノートが。
755 名前：デフォルトの名無しさん mailto:sage [04/10/22 11:02:18]: >>754=>>733様
756 名前：753 mailto:sage [04/10/22 12:41:35]: ぐあっ・・・ほんとだ　orz
駄ﾚｽでした。重複ｽﾏｿ
757 名前：デフォルトの名無しさん mailto:sage [04/10/22 14:05:19]: >>732

>だまされたと思って一回原典読んでみてください。お願いします。

オマエが騙しそうだなー

>>742
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
読んでみたんだけどなー

> 「SQLが分からないから使わない」
>
>んじゃなくて
>
>「SQLにビジネスロジックを入れたくないから使わない」
>
>んです。

リッチなSQLの例が、SQLの入門書レベルだからなー
勉強したくないだけだろうと思われても仕方が無いなー
VB厨でもPHPerでももっと複雑なSQLを普通に書くと思うなー

>>752
そうだなー
PoEAAが具体的にどういうシステムを想定しているのかを知りたくなるなー
758 名前：デフォルトの名無しさん mailto:sage [04/10/22 14:25:16]: >>757
> リッチなSQLの例が、SQLの入門書レベルだからなー

同意
759 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:02:33]: SQLの中身については、いやまあサンプルって事で。

それいったら、過去実績である注文データに対して
ディスカウントキャンペーンを適用するようなつくりになってて
蓄積された実績を何時でも恣意的に改変できる形になってるじゃん。

注文ってエンティティの構造は捉えられていても
その意味というか本質というか、全然考慮されてない。
その理由は、勿論サンプルだから、でしょう。

まじボケだったらファウラー、おちゃめさんです。

つっこみ始めたらきりがないから、ここは
「SQLに業務ロジックを入れる」って事のだけ
見ればいいよ。
760 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:42:20]: >ただ、アプリケーション開発者はこれくらい複雑なだけでも避けちゃうんだよね。

これくらい↓
複雑↓

SELECT DISTINCT MONTH(o.date) AS month
FROM lineItems l
INNER JOIN orders o ON l.orderID = o.orderID
INNER JOIN customers c ON o.customerID = c.customerID
WHERE (c.name = ?) AND (l.product = 'Talisker')
GROUP BY o.orderID, o.date, c.NAME
HAVING (SUM(l.cost) > 5000)

確かにおちゃめだ。Fowler氏自身はSQLを使いこなしているようだが。
このレベルを避けちゃうようなﾔｼと仕事してるのかと思ったら不憫に
感じるというか親近感が湧いたYO
761 名前：759 mailto:sage [04/10/22 15:54:39]: 一人いたな、簡単なJOINのSQLでも
全部Accessで作ってからちょこちょこ直す人。

結構経験あって、Win32APIとかすごく詳しかったけど、
業務系はあまりやってこなかったみたい。
帳票のSQLとかほとんど俺が書いて、メールで渡してたなあ。

しかもその人がテーブル設計やったもんだからもう、
俺も不憫に思ってくれい。

そのSQL書ける人が書いてメールで渡すってのを
メール経由でコピペとかじゃなくて、
きちんと組み込めるのがS2Daoな訳ですな。
762 名前：デフォルトの名無しさん mailto:sage [04/10/22 15:55:38]: ・・・普通の集計にしか見えんのですが。
763 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:11:53]: その普通の集計をわざわざコードでやるがいいと
おっしゃっておるのでつよ。

これがリッチSQLなのでつ。リッチクライアントも決して

普通のVBの画面にしか見えんのですが。

などといってはいかんのでつ。
764 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:25:34]: しょぼいSQLで済むことにあれだけコード書くようだと
複雑なクエリーが必要な場合にどれだけコードを書くんだ？
いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ
あるかないかわからない移植のことを考えるよりもさっさと作って
リリースするほうが重要なんじゃないか。いるものだけ作るという
原則に反している気がする
765 名前：デフォルトの名無しさん mailto:sage [04/10/22 16:39:18]: つまりあれだ。
S2Daoﾏﾝｾｰってことだな。
766 名前：デフォルトの名無しさん mailto:sage [04/10/22 17:14:54]: だな！
767 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:55:24]: >>763
> リッチクライアントも決して
> 普通のVBの画面にしか見えんのですが。
> などといってはいかんのでつ。

比較対象がHTMLフォームだから。
768 名前：デフォルトの名無しさん mailto:sage [04/10/22 21:58:01]: あのドキュメントは社員さんが書いたのか。
サイトの運営も社員さんにやってもらったほうがいいね。
なんにしろ、組織的なサポートは心強い。
769 名前：デフォルトの名無しさん mailto:sage [04/10/22 23:55:07]: >ビジネスロジックとは
意味わかんね。
だれかかいつまんで説明して
770 名前：デフォルトの名無しさん [04/10/23 00:39:25]: >>764
問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。
とくに問題になる点は
・更新性「EAはこれからめちゃくちゃ変わる」
・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
だろう。
まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。
771 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:50:40]: 結局規模が違えば考え方も違うってことだね。
もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。
772 名前：デフォルトの名無しさん mailto:sage [04/10/23 00:57:52]: >>770
EAはむちゃくちゃ変わるってのは
日本で業務系に携わってても
正直そこまで実感が湧いてこないんですが

それは私の経験不足と言う事でさておいて

大体リッチなSQLを使う所って、経営分析データだとか
会計帳票とかになりますよね。
そういう所はEAとかいう部分と関係なくて
逆に安定しまくっとる所なわけで、
そこにSQL一発ですむものを複雑なコーディングに
置き換えるのはやはり気がひけます。

やっぱりいいとこどりが一番って事でしょう。
議論としちゃつまらん結論ですけどのう。
773 名前：デフォルトの名無しさん mailto:sage [04/10/23 01:35:27]: 全体を捉えた議論の結論としては
「やるべきことをやる、使うべきところで使うべきものを使う」
ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？
つまり、その手法のメリットデメリットはなにか、と。
マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？
774 名前：デフォルトの名無しさん [04/10/23 02:33:35]: 　　殺伐としたスレに救世主が！！

　　　　　　　無職
　　　　ヽ|・∀・|ノ　＜人殺しマン参上
　　　　　　 |=◎=|
　　　　　　|　|
headlines.yahoo.co.jp/hl?a=20041022-00000505-yom-soci
775 名前：デフォルトの名無しさん mailto:age [04/10/23 03:05:17]: S2JSF間近aga!!!
776 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:07:08]: >>770

> ・更新性「EAはこれからめちゃくちゃ変わる」

だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？

> ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」

データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？

云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。
777 名前：デフォルトの名無しさん mailto:sage [04/10/23 03:51:27]: ファウラーのblikiを翻訳してる方によると
やはり日本とアメリカの事情の違いってのがあるそうで、
日本にくらべてあっちはアプリ開発とDB開発の分業が
相当徹底されているらしいですね。

で、

> ・カプセル化「ビジネスロジックを担当するコードが
>データベース設計変更時に影響を与えられることはない」

ってのは、776の言う通り、設計変更っていや
ビジネスロジックの変更の事だろう、って気分に私もなりましたが
もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ
と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。

あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら
うそつけバーカとか書いちゃって下さい。

あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、
やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。
778 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:00:15]: 773の意見にまったく同意です。

でもまあ、総論みたいな所も、答えは「いいとこどり」に
落ち着く事は判っていても、喧々諤々やっといた方が
いいと思うんですよ。

その事で、双方の「いいとこ」の範囲が、
前より広く感じられて来たりしたら良いと思うし。

ここ、読んでて大変面白いですよあたしゃ。
2ちゃんのOO関連スレじゃ一番じゃないですか？
779 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:13:28]: 関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。
結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。
780 名前：デフォルトの名無しさん mailto:sage [04/10/23 04:49:47]: 言語とRDBMSと、どちらが変更される可能性が高いか。
どちらとも言えんと思う。

言語が変わる場合：
C/S からWEB系への移行
Unixに乗り換えで、ASPからJavaへ移行

RDBMSが変わる場合：
パッケージもの。お客様によってRDBMSが異なる
辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。

他にどんな場合があるかな？
781 名前：デフォルトの名無しさん mailto:sage [04/10/23 05:18:03]: 言語は変わる場合より併用の方が多いんじゃないかな。
たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか
# 実際はサーブレット呼び出すようにしてJavaで処理させたりするが。James？なにそれ。ｗ
部分的にPHPで組むことも考えられる。

RDBMSで言えば、最初はPostgreSQLで運営してたけどサービスが成長したからOracleに移行とか。
Windows上のSQLServerで運用していたけど、大人の事情でUNIX使うことになって、Oracleへ、とか。
PostgreSQL→Oracleのようなスケールアップはありがちなんじゃないかと。
逆に、移行しやすいように作っておくことを前提に当初はPostgreSQLで運用開始とか。
782 名前：デフォルトの名無しさん [04/10/23 09:23:30]: >>781
> たとえば、メール処理をするのに、VM起動を嫌ってPerlのスクリプトでやるとか

いろんな言語を組み合わせるのはどうにも気持ち悪い。メンテナンスしづらいでしょ。
開発環境そろえるのに時間かかりそう。環境によってあーだこーだ言うのは最悪。
バージョンがこうだとか、ディレクトリ構成がこうだとか。ウザい。

シンプルが一番。
アプリケーション毎に常駐プログラム作ってそこでデータベースなりメールの処理するとかするでしょ普通。
ポータビリティが重要だと思う。
CVSのモジュールを引っ張り出すだけで自前の環境でシステムの自動テストができるような単純さが開発では重要。

加えると、Javaって面倒だ。
全部スクリプトで作ってしまえばいいと思うのだが。
783 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:13:19]: >>777
だからコミュニケーションの重要性が
日本以上に言われるのかな＞分業の徹底
784 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:40:46]: >>783
うん、そうみたいですね。
blikiの翻訳者さん、こんなのも翻訳してまして
tp://capsctrl.que.jp/kdmsnr/wiki/agiledata/
ここみると、「なぜ一緒に働くことが現在困難なのか」とか
なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、
日米の文化の違いはかなりのもんの様です。

でもアメリカさんだから、ジョークというか
比喩かも知れないですけどね。
785 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:47:58]: seasarの良いところがいまいち分からんなー。

インターフェース書いて、ダイコンファイル書いて
ってめんどくせーって思っちゃう。
サービスに新しい機能付けようと思ったら、インターフェース
とImplクラスの２つを変更しなきゃいけないし。
インターフェースはImpl挿げ替えるだけで、動きを変えられるって
メリット（多態性）で使うんであれば良いし、よく使うんだけど
seasarのためにインターフェースガンガン書くって気にはどうも慣れん。

ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。

漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？
なので私はseasar使うようになったよ」って意見を聞きたいです。
あとEJBはseasarよりさらにダルイっておもっとる。
786 名前：デフォルトの名無しさん mailto:sage [04/10/23 11:59:55]: 別に無理してまでインターフェース用意することも無いでしょう。
必要に迫られたときにインターフェースを抽出することは
IDEなんかのツール使えば一瞬で出来るんだし。
787 名前：786 mailto:sage [04/10/23 12:01:40]: ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。
不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。
788 名前：785 mailto:sage [04/10/23 12:21:54]: レスありがとう。

>別に無理してまでインターフェース用意することも無いでしょう。
seasarってインターフェース必須ではないんだー。誤解してました。

>不必要なメソッド呼び出しを隠蔽できたり、
これは、漏れのやる仕事のに依存してるのかもしれないけど
APIのようなクラスを作るときは、隠蔽って重要だと思います。
でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に
出くわさないんですね。

>Mock使ったテストが容易になったり。
これはもう少し詳しく聞きたいです。seasarのドキュメントにも
テストが容易って書いてありますが、EJBに比べてって事ですか？
struts+Hibernateでテストしにくいって感じた事無いんですよね。
789 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:28:07]: >>785
seasarというより、インターフェースと実装を分離するということは、
OOの重要な部分だと思うけど、分業するときに、
インターフェースを先に決めておけば、実装が追いつかなくても、
Mockとかを使って作業を並行して進められるというメリットがあるね。

実装クラス同士が直接依存しあうことが少なくなるから、
個々のクラスの個々のメソッドを単独で実装・テストしやすい。
直接依存してると、依存しあっている部分を全部コーディングしないと
テストできないから。
790 名前：デフォルトの名無しさん mailto:sage [04/10/23 12:32:00]: >>788
ふだん、どんなテストしてるの。
791 名前：785 mailto:sage [04/10/23 13:10:24]: >>789
>Mockとかを使って作業を並行して進められるというメリットがあるね。
でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも
同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら
インターフェースがある方ですが。。。

>依存しあっている部分を全部コーディングしないと
>テストできないから。
うーんseasarもダミーの実装をダイコンファイルに書いてるだけ
なんだよなと。Implクラスにダミーの戻り値を書いておく方が
楽と感じてます。

>>790
普段は下層のDAOから実装していくって感じなんで
（階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。
サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。
相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。
他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。
792 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:34:02]: >>791
それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。

でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。

あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。

ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。
793 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:57:33]: まさか、自動テストの一括実行をやってないとか。
794 名前：785 mailto:sage [04/10/23 14:32:12]: >>792
ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。

その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。

>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。

上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。
795 名前：デフォルトの名無しさん mailto:sage [04/10/23 14:38:34]: >自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？
796 名前：デフォルトの名無しさん mailto:sage [04/10/23 16:59:16]: デバックってゆうな～
797 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:00:15]: >おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。

モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。

ちなみにdebugなんでデバッ"グ"
798 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:24:12]: OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。

新参者は空気を読め、空気をという話である。
799 名前：785 mailto:sage [04/10/23 18:58:14]: デバッグですね。お恥ずかしい。。。

>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。

逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ　
800 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:10:45]: >>798
何のコピペ？
801 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:36:39]: はぶ氏もひが氏もここの話題に反応してくれてますな

っと、話ふり逃げに思われると残念なので書いとこう
802 名前：デフォルトの名無しさん mailto:sage [04/10/23 21:45:01]: >>800
これだろうな。
ttp://d.hatena.ne.jp/hyoshiok/20041022
803 名前：デフォルトの名無しさん mailto:sage [04/10/23 22:08:24]: ttp://d.hatena.ne.jp/akon/20041023#p2

こんな未来は嫌だ。
804 名前：デフォルトの名無しさん [04/10/23 23:03:29]: どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
805 名前：デフォルトの名無しさん [04/10/23 23:05:49]: > Stateless BusinessLogicパターンのメリット
> ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617

上記サイトの内容で疑問点がありまして。

ひがさんは

「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」

と仰っています。

ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。

このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
806 名前：デフォルトの名無しさん [04/10/23 23:27:38]: >>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
807 名前：785 mailto:sage [04/10/23 23:35:51]: >>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。

よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。

でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
808 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:44:01]: statelessって「実装に依存しない」って意味なんじゃないですか？

依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。

stateless
【形-1】国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっかとうちけん｝］のない
【形-2】《コ》処理状態｛しょりじょうたい｝を把握｛はあく｝しない～◆【対】stateful

って辞書にあるそのまんまの意味だとばっかり思ってました。
809 名前：デフォルトの名無しさん [04/10/23 23:48:50]: d.hatena.ne.jp/higayasuo/20040805#1091664617
810 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:51:34]: >>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？

> 処理状態｛しょりじょうたい｝を把握｛はあく｝しない

そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
811 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:52:33]: >>808
かなり根本から間違ってるな。State が lessなんだぞ。
812 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:57:32]: >>808
SLSB/SFSBの違いを思い出せ。
813 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:58:14]: オブジェクトが状態をもたない。
814 名前：デフォルトの名無しさん [04/10/23 23:59:14]: class Foo {
int s;
int method(int x);
}
があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく
sの値にも依存すればstatefulで、
xの値のみに依存すればstatelessなんじゃね？

だから
＞Statelessといっても、すべてスタティックメソッドにすれば良いという
っていうことになるんだと思ったけど
815 名前：デフォルトの名無しさん [04/10/24 00:01:29]: >>814
statelessでもポリモフィズムは使いたい。
816 名前：デフォルトの名無しさん [04/10/24 00:03:16]: >>814
>すべてスタティックメソッドにすれば良いという

ポリモーフィズムが使えるところが違うっていうところだな。
システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。
これやるとプログラマのシステムの意図の理解に役に立つし。
817 名前：805 [04/10/24 00:07:34]: >>807
> >>805
> ステートSがオブジェクト変数だとMaかMbからのみ変更される
> って事だからだと思うよ。
> ステートSをクラスの外に出すと、MaやMbはステートSに依存
> はするけれど、MaとMbの依存関係は無くなるんだね。

そうかな?

「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」
なら
「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」
と言えると思うんだよね。
818 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:09:28]: >>804
ポインタ希望
819 名前：785 mailto:sage [04/10/24 00:33:53]: >>817
じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
いないのに、MbはMaに依存しているっているって言える？
あくまでステートSに依存しているだけだよね。

あとは、ステートSの場所についてだけどこれは　>>813
って事だね。
820 名前：805 [04/10/24 00:37:11]: メソッドの処理がステートに依存するクラスの例として
以下のクラスがあったとする。

class File
void open();
void close();
int read();
}

これが以下のようにStatelessになったところで
open、close、readの依存関係がなくなったとは言えないと思うんだよね。
例が悪いのかな?

class File {
void open(FileState state);
void close(FileState state);
int read(FileState state);
}
821 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:37]: だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。

810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。

状態を持たないだと判りにくいか、
状態の変化を管理しない。

S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。

結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
822 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:53]: ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。

この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
823 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:50:36]: ああでもよくわかんねぇ
824 名前：デフォルトの名無しさん [04/10/24 00:50:40]: class File {
static int read(String filename, int position);
}
これは？
825 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:52:15]: なんか俺も混乱してきたのでひがさんきぼんぬ
826 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:09]: ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。

あ、821=823です、
まぎらわしくなっちゃってすみません>822
827 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:10]: >>820
オブジェクトをステートレスにしろって事じゃないの？

下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。

上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
828 名前：785 mailto:sage [04/10/24 00:58:40]: >>820
何に対して、誰から見るとStatelessなのか、Statefullなのか
って事だよー。
上のFileクラスは、使う側から見るとopen、close、readのメソッドが
Statefullなんだけど、下のFileクラスは、引数のstateに対して
statefullであって、open、close、readの関係はStatelessだよ。

ようは、stateだけ考えてれば、良いって事。

ん？漏れはコアなseasar利用者じゃないんだが。。。
モンキーターン見てくる
829 名前：805 [04/10/24 01:00:19]: >>819
> >>817
> じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
> Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
> いないのに、MbはMaに依存しているっているって言える？
> あくまでステートSに依存しているだけだよね。

今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。
Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。

へんなこと言ってるかな?

> あとは、ステートSの場所についてだけどこれは　>>813
> って事だね。

そうです。
830 名前：805 mailto:sage [04/10/24 01:05:18]: >>828
> >>820
> 何に対して、誰から見るとStatelessなのか、Statefullなのか
> って事だよー。
> 上のFileクラスは、使う側から見るとopen、close、readのメソッドが
> Statefullなんだけど、下のFileクラスは、引数のstateに対して
> statefullであって、open、close、readの関係はStatelessだよ。
>
> ようは、stateだけ考えてれば、良いって事。
>
> ん？漏れはコアなseasar利用者じゃないんだが。。。
> モンキーターン見てくる

混乱させてごめんなさい。
レスは、今日はもう寝ちゃうので、また明日以降に。
831 名前：デフォルトの名無しさん mailto:sage [04/10/24 02:51:26]: ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
832 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:14:28]: ドメインモデル->実世界の構造のウツシミ
833 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:17:11]: 結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
834 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:20:59]: モデリングの本とかで問題領域とかいわれてる部分。

簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
835 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:23:09]: あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
836 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:44:42]: なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
837 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:01:43]: 児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。

釈然としない所もあるけどさー。
838 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:08:57]: > 釈然としない所もあるけどさー。

どういうところ？
839 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:19:41]: 2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。

でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。

こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
840 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:30:49]: >>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。

その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
841 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:32:09]: >>839
マジカの出番かな？
842 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:59:47]: マジカ？
843 名前：デフォルトの名無しさん mailto:sage [04/10/24 05:01:25]: >>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
844 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:31:16]: 結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
845 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:48:45]: Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。

ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。

S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。

>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。

この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
846 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:58:45]: >>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。
847 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:00:29]: >>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。
848 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:04:19]: >>846
俺は>>845じゃないけど

「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した

っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。
849 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:11:58]: ttp://nekop.programmers.jp/diary/?date=20041024
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz
850 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:12:46]: >>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。
851 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:18:07]: >>849
うちの会社の競争相手は中国人 orz..
852 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:25:51]: >>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。
853 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:26:46]: 先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz
854 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:47:18]: >794

>>漏れ的には、迷ったらメンバーで相談する。

これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。

そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。
855 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:53:57]: 段々と下請の悲哀を語るスレと化してきたな
856 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:56:26]: 結局、ソフトウェア開発の本質的で構造的な問題だからな。
857 名前：デフォルトの名無しさん [04/10/24 12:09:28]: 要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。
858 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:20:20]: >>857が投資していいチームを作って漏れをやとってくれYO
859 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:29:31]: 問題は>>858が良いメンバーか、ということだが…
860 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:51:24]: >>857
その投資の原資はどこからもってくれば良いのでしょうか？
861 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:57:45]: 資本金。
862 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:09:16]: >>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁
863 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:11:12]: データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。
864 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:12:02]: >>862
競争力。
865 名前：858 mailto:sage [04/10/24 13:13:24]: >>859
漏れはいいメンバーになるYO
頑張るから入れてください
866 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:18:14]: >>864
わけわからん
867 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:20:53]: >>853
そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…
868 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:21:18]: >>849
> ttp://nekop.programmers.jp/diary/?date=20041024
> これ読んだらEAは俺には縁のない世界だと思った。

ttp://d.hatena.ne.jp/habuakihiro/20041024#1098575922

はぶ氏も似たようなこと言ってる。
869 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:24:51]: >>844
手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。
オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も
オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。
オブジェクト内の手続きを再利用する方法として継承を使うことができるが、
継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する
ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって
しまうためよくない。

これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。
これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように
見えるかもしれないが、そうではない。

ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の
手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する
ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。
従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の
インタフェースをデータ型から抽出することが、ジェネリックプログラミングを
実現する第一歩となる。
870 名前：デフォルトの名無しさん [04/10/24 13:41:33]: >>844
>結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。

ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。
871 名前：デフォルトの名無しさん [04/10/24 13:48:36]: >>890

>587
>顧客クラスにパスワード変更メソッド付けるなんてアフォ

つまり、データはハッシュマップなりで適当なもので表現して
（実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして
定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは
よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく）
872 名前：デフォルトの名無しさん [04/10/24 13:52:04]: >>871

データを一番シンプルに扱えるのがハッシュマップである以上、
無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。
型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない
っていう仮説はどうかな。
873 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:52:20]: >869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない

結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。
874 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:53:31]: 「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。

データと処理が分離されたCollection API

ｺﾜｰｲ…。
875 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:18]: ttp://sumim.no-ip.com:8080/wiki/710

視点の違い
876 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:32]: データと処理が分離されたデータベース
877 名前：デフォルトの名無しさん [04/10/24 13:58:43]: >>873
結局メソッドを呼び出すのがＯＯ。
オブジェクト指向の肝はポリモーフィズムで、
それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現
するっていう、ただそれだけ。
878 名前：デフォルトの名無しさん [04/10/24 13:59:31]: >>872
Java5で解決ですが。。
879 名前：デフォルトの名無しさん [04/10/24 14:02:18]: >>878
漏れには解決しているようにはとても見えへんのよ
880 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:13:32]: だれか、>>863について斬ってくれ。
881 名前：デフォルトの名無しさん [04/10/24 14:15:50]: ORマッピングで継承って一体なんなんだ？　意味不明。
データはデータ。処理は処理だろ？
882 名前：デフォルトの名無しさん [04/10/24 14:20:09]: 処理の切り替えって、やりたきゃやればいいんじゃないの？
883 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:36:40]: >>881
こういうののことでつ。
ttp://objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html
884 名前：デフォルトの名無しさん [04/10/24 14:44:58]: 処理の切り替えが沢山あるなら、

処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)

みたいのを作って

Manager#addHandler(handler)

てなことやると分離できるな。これが適切なときもあるにはあるだろう
885 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:54:13]: >>871
>>872

そんなお前らはDbUtilsでも使ってろ。

まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。
886 名前：デフォルトの名無しさん mailto:sage [04/10/24 15:57:59]: Ruby最高ってことでFA
887 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:11:53]: >>845
「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。

>>884
そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？
888 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:13:34]: >>887
「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。
889 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:15:11]: >>888
だね。最後の方良く読んでなかった。ｽﾏｿ。
890 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:16:15]: >>871

890ゲット！！

データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。
891 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:21:15]: ER図と照らし合わせながらでしか解読できんコードになるぞ。
892 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:35:46]: なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。

間違っていたらご教授願います。
以下 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用

アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。

ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。

ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。
893 名前：887 mailto:sage [04/10/24 16:53:26]: >>892
なんだ、わかってたのね。

つまり、

[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層

[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層

こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。
894 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:55:07]: >>892
> なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。
895 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:58:47]: OO厨なんてこんなもん
896 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:32:46]: と、OOがわからなかったCプログラマーが申しております。
897 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:42:11]: フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。
898 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:45:23]: >>893
>ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。

プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
899 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:55:05]: >>898
> プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。

ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。
900 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:58:36]: ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。
901 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:10]: >>900
StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。
902 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:41]: ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。

分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。
903 名前：910 mailto:sage [04/10/24 18:12:38]: 説明が悪いのかな。
900氏の言うように「普通にデザインしてたら」、
StrutsのActionなどに提供される業務ロジックインターフェースの
メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。
でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？
多くないならいきなりActionから業務ロジックのインターフェースで提供されてる
メソッド呼び出すほうが素直じゃないの？って思ったんですよ。
904 名前：デフォルトの名無しさん [04/10/24 18:13:33]: >>869
それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。
905 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:18:01]: >>903
必要ないでしょ。ケースバイケース。
906 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:28:51]: かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。

あるプロジェクトでは、人に業務機能を割りあてました。
データベース設計はある一人が担当し、
他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、ある程度のレベルまで上昇しました。
メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。

あるプロジェクトでは、人にシステムの機能を割りあてました。
データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。
メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。

誰が幸せなのでしょう。
907 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:22:17]: >>906
> 誰が幸せなのでしょう。
俺俺！
908 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:25:02]: 綺麗な設計を手に入れたお客さん。
909 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:34:41]: >>897
S2で作れ！期待してます！
910 名前：デフォルトの名無しさん mailto:sage [04/10/24 20:12:08]: >>909
その前にくーすで設計だろ？
911 名前：デフォルトの名無しさん [04/10/24 20:32:39]: そうこうしている間に.Netが主流に。
912 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:01:43]: Ruby.netが最強だと。
913 名前：デフォルトの名無しさん [04/10/24 21:05:27]: 薄いサービス層 ⇒ ドメインモデル
とか
薄いサービス層 ⇒ リッチな業務ロジックモデル

これ、何いうてるんですかね。
どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、
この２つを分ける理由は謎。
914 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:09:50]: >>913
...これまでの流れ、分かってます？
915 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:21:37]: Ruby最強・・・かな？
916 名前：デフォルトの名無しさん [04/10/24 21:21:50]: 正直、ドメインモデル　リッチな業務ロジックモデル

の違いも分からん

藻前ら難しく考えすぎだ
917 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:41:30]: >> 916
お前は、きっちり分割されたシステムの一部を仕様通りに
月１５万でコーディングすればいいだけだから、気にするな。
918 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:56:07]: >>917
月１５万でコーディングしてくれるの？
だったらうちで働いてよ。
919 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:58:55]: 2人日の価格で1人月か。お徳だ。うちにぜひこないか
920 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:14:18]: うほっ！

か　か　な　い　か　？
921 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:11]: >>919
あんたのところ高すぎ。
コーダーで月１５０万かよ！

うちの倍とってるじゃん。。。
922 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:47]: じゃあRubyのDIコンテナに期待しよう
あるのかな
923 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:33:31]: そろそろ新スレ立ててもいいんでない?
924 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:38:28]: 今の流れだと、次スレは必要なさそう。
925 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:39:14]: 盛り上がっているところに水を指すのは申し訳ないが
正直S2ネタが殆どないのにS2の名前で新スレ立てる
意味がないような気ガス。どう見ても単なるOOネタ。
こっちのスレのほうが適している気がする

【OO?】オブジェクトオリエンテッド総合【非OO？】
pc5.2ch.net/test/read.cgi/tech/1041658161/l50
926 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:45:08]: そうだな。
PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？
S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ
927 名前：デフォルトの名無しさん [04/10/24 22:52:43]: >>917
>お前は、きっちり分割されたシステムの一部を仕様通り

そんなシステムあるわけないだろボーケー
928 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:02:45]: >> 927
まず日本語から勉強しましょうね～。
929 名前：805 [04/10/24 23:05:07]: >Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、
>実は間違ってますね。m(_ _)m
>ここでいっている依存関係とは、呼び出し順序の依存関係です。
>
>状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。
>しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、
>MbはMaに依存しているということになります。

Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。

Maの呼び出しによって、ステートS => ステートSa となるとして、
Mbが当てにしているのは「事前のMaの呼び出し」ではなくて
「Ma呼び出しによってセットされるステートSa」なんじゃないかな?

よって、ステートSを外に出したところで MbがステートSaを前提にしていることには
なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。
930 名前：805 mailto:sage [04/10/24 23:06:15]: >>929

ごめん、ソースは
d.hatena.ne.jp/higayasuo/20041024#1098580377
ね。
931 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:13:31]: OOネタはS2というかくーすから転がっていって
ひがさんのブログでの反応とあいまって
こうなったんで、このままここでいいよ。
932 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:16:36]: 普通はスレ違いなんだがな。
このスレには優しい人が多いということか。
933 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:19:16]: このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。
そうすれば、今までのこともスレ違いではなくなる。
934 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:20:03]: ダサッ！
935 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:46:17]: >>929
　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
したりできて便利になるような気がするんだけど。

もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な
ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが
必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう
可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。
936 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:53:55]: 比嘉氏はStateはPresentation層に持つって言ってるので>>935は同じ事を言ってる気がするのだが
937 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:00:23]: >>933-934
「S2のソナタ」にでもしておけばよかろう
正直漏れは次スレいらん気がしてるが
938 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:03:48]: >933
人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて
開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて
じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。

>936
Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら
Presentation層で保持するのでやり易いだろう。
HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど
939 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:13:28]: >> 938
そこでS2JSFですよ。
940 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:15:06]: >938
おれ今までsessionとかrequestってプレゼン側領域だと思って
状態の管理にも使ってたんだけど、世間じゃ違うのかな。
小細工ってどんなの？
941 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:19:59]: OOPの話がしたければ、それなりのスレへ。
新しい別のスレをたてる必要はない。
そこではSeasarの話はスレ違いだがね。
Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。
942 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:25:20]: 禿同
長文多いしage多いしスレ違い多いし
ハッキリ言ってウザイ
943 名前：805 mailto:sage [04/10/25 00:26:53]: >>935
> >>929
> 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
> ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
> したりできて便利になるような気がするんだけど。

ドメインロジックを含んだクラスをステートレスにすると、
SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの
テクニックの大半が使えなくなります。
# 数少ない経験に基づいてるので嘘かもしれませんが。

そんな強烈なデメリットを負ってまでステートレスにして得られるものが、
「サービスオブジェクトのプーリング」というのは、
*個人的には*、割に合わないと感じています。

# もちろん、必然性のあるステートレス化には賛成ですが。
944 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:29:27]: 「ダイコン時代のスレ」でいいんじゃない？
945 名前：デフォルトの名無しさん [04/10/25 00:34:31]: もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。
アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。
もう漏れは飽きた。寝る。
946 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:35:59]: seasarの話、くーすの話、OOの話、業務の話、
全てはひが様のもとへ、じゃ。
よってこのまま続行。

つか、ここの住人が杓子定規なスレタイ重視によって
分散してしまうのは、しじょーにもったいなく思いまーす。
947 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:38:14]: では違うところに集うが良かろう。
でなければまずはsage進行で頼む。
948 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:48:11]: >943
Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。
勿論、仕方無しにPresentationの役割と思ってやってるんだけど

>941、942
見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？
大半の香具師はアンチうざいのでsage進行だと思うしさあ。
とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。

>944、946
禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。
J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。
あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので
宗教論争ならくだらん。
949 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:59:23]: しょっちゅうageてるじゃねえか。
上にくりゃ見えちまうだろうが。
sageくらい覚えろよ。
あと変なポインタ振るな。
長々書き込むな。
正直このスレの住人ウザイ。
2ちゃんにくんな。
950 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:10:48]: J2EEに疲れてませんか、ではくーすの話はスレ違いだね。
951 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:29:23]: >>949
N速にでも逝って２ちゃんらしさを存分に味わっとけ。
次スレはsage進行でマターリと語りたいね。
952 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:30:13]: >>945みたいなアゲにげするやつがいるからねぇ。
953 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:32:45]: じゃ、次はS2JSFでてからってことで解散。
954 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:33:08]: 分析から実装まで
開発を見つめるDICON
955 名前：デフォルトの名無しさん [04/10/25 02:17:15]: もはや広告が撲滅された以上、sageと入れるのは馬鹿。
そもそも同人板のヲタ女達が始めた風習だし。
956 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:24:08]: 風習の起源とか目的とか、どうでもいいだろうが。
いまそういう風習なんだから。
957 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:38:26]: Stateless化することで見込まれているメリットの肝は、実は分業の徹底では
ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、
かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して
しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。

そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって
しまうのが悲しい現状だ。

そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。
958 名前：デフォルトの名無しさん mailto:sage [04/10/25 08:06:05]: 次スレ立てるんなら>>1はガイドラインよろ
sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな
せっかくいい感じになってきたのでﾀﾉﾑ
959 名前：デフォルトの名無しさん [04/10/25 11:28:42]: >>957

ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い
960 名前：デフォルトの名無しさん mailto:sage [04/10/26 00:49:26]: このままのスレでいいじゃん。
961 名前：デフォルトの名無しさん mailto:sage [04/10/26 01:14:57]: スレタイに「くーす」要追加。
962 名前：デフォルトの名無しさん mailto:sage [04/10/27 05:30:18]: AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？
963 名前：デフォルトの名無しさん mailto:sage [04/10/27 17:20:16]: 次スレはS2JSFが完成してからだね。
964 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:13:24]: 関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。
S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。
965 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:15:46]: 最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。
966 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:57:39]: >>964
なんでかっこわるいの？
967 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:00:22]: ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。
968 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:11:17]: >>967
それがかっこわるい理由か？
969 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:59:04]: >>967
RFC&W3Cﾏﾝｾｰなんだね。

IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは
文字化けする場合があるバグありバージョンがある。
客に文字化けするんだがって言われたらブラウザのバグですって言うの？

まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって
なると思うけど。
970 名前：デフォルトの名無しさん [04/10/27 23:13:06]: 次スレ立てました。

国産DIコンテナSeaserとくーすその2
pc5.2ch.net/test/read.cgi/tech/1098885253/
971 名前：デフォルトの名無しさん mailto:sage [04/10/28 01:05:52]: 技術屋がかっこつけようとすると
お客さんの価値観とは合わなくなる事が多く思いますが
よい例でしょうかね。

俺も出来る事なら存分にかっこつけてみたいわ。
972 名前：デフォルトの名無しさん mailto:sage [04/10/28 02:20:21]: 969が正解でしたね。

ひがさんてば、こんな事にまで答えてくれるとは・・・・。
973 名前：デフォルトの名無しさん mailto:sage [04/10/29 00:38:27]: >>972
俺は >>571 です。
ここはエセ技術屋が多いインターネッツですね。
うんこばかりだな。
974 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:42:43]: はいはい
あなたみたいにみんなから尊敬される素晴らしい技
術屋さんには見るもの全てがうんこにしか見えない
んだろうからここに来なくてもいいよ
975 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:53:25]: エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁
976 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:59:02]: お，半角SPACEたんｷﾀｰ(AA略)
相変わらずの粘着ぶりでつね！
977 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:00:22]: metaタグうんぬん言ってた人が
571ってこと？

まあmetaタグがどうのってこだわりがあって
そういうのが技術力だって価値観も確かにアリだと思うけど
そういう価値観の人ならseasarもくーすも要らないんじゃないかな。
978 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:15:26]: 571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ
ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ
要するに 571 たんはひがたんのうんこが食べたいのでつ
頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ
979 名前：デフォルトの名無しさん mailto:sage [04/10/29 23:50:16]: ひがさんはいつ仕事してるんだろうか
980 名前：デフォルトの名無しさん mailto:sage [04/10/30 17:02:00]: タペのサンプルの動かし方がわからん。
981 名前：デフォルトの名無しさん [04/10/31 13:23:24]: 顧客満足＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞W3C,RFC
982 名前：デフォルトの名無しさん mailto:sage [04/10/31 17:26:28]: 長期間の動作保障＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞クイックハック
983 名前：デフォルトの名無しさん mailto:sage [04/10/31 21:52:57]: ベンダの短期的な思惑＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞長期間の動作保障
984 名前：デフォルトの名無しさん [04/10/31 23:28:25]: 長期の動作保証とクリックハックは往々にして両立する罠
例えば、metaタグでcontent-type入れるのとか。
985 名前：デフォルトの名無しさん mailto:sage [04/10/31 23:31:04]: ×リ
○ィ
986 名前：デフォルトの名無しさん mailto:sage [04/11/01 23:58:53]: ちゃんとスレ埋め立てようぜ
次スレばっかり伸びてるじゃねえか
987 名前：デフォルトの名無しさん mailto:sage [04/11/02 00:52:51]: いっそ次スレのほうが先に埋まるのを見届けるとか
988 名前：デフォルトの名無しさん mailto:sage [04/11/02 05:42:06]: 980も超えてるし、そのうち勝手に落ちるよ。
989 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:09:12]: せっかくだからしりとりでもしようぜ。まずは俺からな。

シーサー

次！
990 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:27:24]: サッシ
991 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:47:24]: 示唆
992 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:55:37]: サラシ
993 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:57:10]: シーサー
994 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:01:49]: >>993
サナダムシ
995 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:51:14]: 視差
996 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:55:14]: 桟橋
997 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:14:19]: 審査
998 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:18:16]: 酒蒸し
999 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:23:44]: しにせ
1000 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:24:23]: せん
1001 名前：１００１ [Over 1000 Thread]: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef