- 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/
- 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(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。
|
 |
