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

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を考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。

---

---

[ 続きを読む ] / [ 携帯版 ]

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