国産オープンソースDI ..
577:デフォルトの名無しさん
04/10/13 19:01:57
しかしみんないろんな日記よく読んでるねえ。
みんななんだかんだいってもS2が気になってしょうがないんだね。
578:570
04/10/13 19:24:45
>>577
まさにそのとおり。からさわぎいくどー。
579:デフォルトの名無しさん
04/10/13 21:03:02
S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...
580:デフォルトの名無しさん
04/10/13 21:09:02
>>579
あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。
581:デフォルトの名無しさん
04/10/13 21:33:58
うちなーんちゅ記念ｶｷｺ
582:デフォルトの名無しさん
04/10/13 23:19:53
>> 580
コアな部分は全部１人でやってるよ。
583:デフォルトの名無しさん
04/10/13 23:43:03
S2Dao使うにはMySQLは不向きだな。
584:デフォルトの名無しさん
04/10/14 00:05:05
>>579
オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような
585:デフォルトの名無しさん
04/10/14 00:07:17
コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。
586:デフォルトの名無しさん
04/10/14 06:56:40
>>573
> パスワード変更クラスとメールアドレス変更クラスをつくりやがった
これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。
587:デフォルトの名無しさん
04/10/14 06:57:10
顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん
588:デフォルトの名無しさん
04/10/14 07:22:10
ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？
589:デフォルトの名無しさん
04/10/14 16:25:45
顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。
わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。
是非俺にも納得できるように説明して欲しい
590:デフォルトの名無しさん
04/10/14 16:36:32
誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、
という無法状態を放置しているのがそもそもの間違い。
591:570
04/10/14 17:11:30
>>589
データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。
ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。
592:デフォルトの名無しさん
04/10/14 17:54:51
>無法状態を放置しているのがそもそもの間違い。
まあそりゃそうなんだが。
>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか
ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。
で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。
593:デフォルトの名無しさん
04/10/14 20:34:50
>>592
顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。
>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・
594:デフォルトの名無しさん
04/10/14 21:09:20
>顧客情報と認証情報を別個に分けて管理したい時
そのために内部の実装を分けないといけないようなケースがそんなにあるの？
>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・
誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど
595:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/14 21:38:20
>>591
データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？
597:デフォルトの名無しさん
04/10/14 22:00:15
>596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。
白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。
598:デフォルトの名無しさん
04/10/14 22:07:20
下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。
599:デフォルトの名無しさん
04/10/14 22:16:47
データとロジック分けるメリットって？
600:デフォルトの名無しさん
04/10/14 22:48:16
>>599
メリットは597が言ってる。
でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。
なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。
S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？
601:デフォルトの名無しさん
04/10/14 22:48:26
ValueObjectに処理を持たせるという話をしてるの？
602:デフォルトの名無しさん
04/10/14 23:01:23
>599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。
ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。
603:デフォルトの名無しさん
04/10/14 23:09:27
業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。
604:デフォルトの名無しさん
04/10/14 23:16:36
S2JSFまだぁ？
605:デフォルトの名無しさん
04/10/14 23:21:26
>> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。
606:デフォルトの名無しさん
04/10/14 23:40:01
601ハ、ValueObjectノ意味ヲハキチガエテマス。
607:デフォルトの名無しさん
04/10/15 00:33:00
>603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。
ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。
だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。
うまくいけば楽にならないかなぁ。
608:デフォルトの名無しさん
04/10/15 00:55:06
>>607
ふつーうにS2の実装ってそんな感じじゃないの。
609:デフォルトの名無しさん
04/10/15 03:00:24
ビジネスルールがSQLに分散するんじゃね？
610:デフォルトの名無しさん
04/10/15 09:44:02
ビジネスルールって言葉が曖昧だよな
611:デフォルトの名無しさん
04/10/15 13:35:54
>>609
どーせ、SQLは山ほど書くんだから問題なし。
612:デフォルトの名無しさん
04/10/15 14:09:21
>>611
山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。
613:デフォルトの名無しさん
04/10/16 04:31:40
S2Ayaya を使えばあややのどこにinjectionできますか。
614:デフォルトの名無しさん
04/10/16 04:55:10
もちろん大事なところでしょう。
615:デフォルトの名無しさん
04/10/16 12:56:46
メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？
616:デフォルトの名無しさん
04/10/16 14:25:56
>614
RejectedRuntimeExceptionが発生します。
617:デフォルトの名無しさん
04/10/16 21:29:13
>>591
>データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。
やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
おまいら、以下を読んで目を覚ましてくれ。
----
ドメインモデル貧血症
URLﾘﾝｸ(capsctrl.que.jp)
このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----
618:デフォルトの名無しさん
04/10/16 21:50:51
そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。
619:デフォルトの名無しさん
04/10/16 21:57:31
>やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。
617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。
620:デフォルトの名無しさん
04/10/16 22:49:27
構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？
621:デフォルトの名無しさん
04/10/16 23:09:46
591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。
世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。
大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。
で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。
そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。
622:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/17 01:50:08
DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。
これがすばり貧血症にあたるかわからないけど
URLﾘﾝｸ(www.relaxer.org)
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。
あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。
でもそんな違いは誤差だとかってまた言われそうだ。
627:デフォルトの名無しさん
04/10/17 02:07:30
あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。
628:デフォルトの名無しさん
04/10/17 02:25:12
まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。
業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。
浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。
VB + OCXが割と正解だったってことかな。
629:デフォルトの名無しさん
04/10/17 03:37:46
626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。
完全にスレ違いになってしまいました。
630:デフォルトの名無しさん
04/10/17 09:05:34
>>629
どこが、常人に難しそうなの。
631:デフォルトの名無しさん
04/10/17 10:40:20
最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。
ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。
DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。
これがくーすの考え方なんだと思う。
それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。
632:デフォルトの名無しさん
04/10/17 11:06:45
> DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。
これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)
633:デフォルトの名無しさん
04/10/17 11:19:55
>>632
必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。
634:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/17 12:04:21
>>634
ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。
きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。
内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。
637:デフォルトの名無しさん
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側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。
# URLﾘﾝｸ(d.hatena.ne.jp) とか
ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。
# ひが氏はロングキャッシュは知らんとか言ってるけど。
# URLﾘﾝｸ(d.hatena.ne.jp)
638:デフォルトの名無しさん
04/10/17 16:43:55
>>633
業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
・業務ロジックを起動するための情報を収集する(=入力画面)
・業務モデルに関する情報を提示する(=参照画面)
639:デフォルトの名無しさん
04/10/17 17:35:07
>>637
よくわかる説明だけど、わかるやつにしかわからんってなってるかも。
640:デフォルトの名無しさん
04/10/17 18:18:33
>>638
それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？
業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633
こっちの方が正しいんじゃない？
641:デフォルトの名無しさん
04/10/17 18:49:29
>>640
>>638の1行目を穴が開くまで読むべし。
642:デフォルトの名無しさん
04/10/17 18:56:47
>>641
穴があいたら、次はどうすればいいですか？
643:デフォルトの名無しさん
04/10/17 19:01:05
>>642
入るしかないでしょ。
644:デフォルトの名無しさん
04/10/17 19:52:07
入れるしかないよ。
645:デフォルトの名無しさん
04/10/17 20:19:25
入れるから穴があくんだろ。逆転してるぞ。
646:デフォルトの名無しさん
04/10/17 23:33:54
はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。
647:デフォルトの名無しさん
04/10/17 23:59:45
俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。
ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。
DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！
648:デフォルトの名無しさん
04/10/18 00:09:33
まったく同意。本当、からさわぎ楽しみ。
でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。
649:デフォルトの名無しさん
04/10/18 00:10:53
リファクタリングして説教して来いｗ
みんなが>>646に期待してるぞ
650:647
04/10/18 00:30:39
>>648
>やっぱファウラーの文章とか読むとワクワクするんだよね。
その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。
651:デフォルトの名無しさん
04/10/18 00:45:33
>650
ありがとう、なんか気が楽になりましたよ。
気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w
652:デフォルトの名無しさん
04/10/18 00:47:45
まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。
653:デフォルトの名無しさん
04/10/18 00:59:42
書籍代なんて誤差の範囲だよ。
プププ
654:デフォルトの名無しさん
04/10/18 02:34:48
結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?
655:デフォルトの名無しさん
04/10/18 02:46:23
>. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。
って、所詮2chか。S2にもフォーラムが欲しいな。
656:デフォルトの名無しさん
04/10/18 04:21:56
>>655
みんな各自のblogで満足してるから、実現性は低いね。
657:デフォルトの名無しさん
04/10/18 07:58:24
>>637
ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。
むきだしのドメインオブジェクトなら、画面では激しく使いづらい。
658:デフォルトの名無しさん
04/10/18 09:28:58
>>655MLじゃ駄目なの？
659:デフォルトの名無しさん
04/10/18 15:53:43
>655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？
はぶか？
660:デフォルトの名無しさん
04/10/18 16:07:11
「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」
文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。
661:659
04/10/18 16:08:44
どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません
662:デフォルトの名無しさん
04/10/18 18:00:26
じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。
663:デフォルトの名無しさん
04/10/18 18:56:32
納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。
664:デフォルトの名無しさん
04/10/18 19:08:31
> 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。
という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。
665:デフォルトの名無しさん
04/10/18 19:14:28
>>663
それははぶについてでなくて一般論だよね？
はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。
ほっときゃ本人があっちに書くか。楽しみにしていよう。
666:デフォルトの名無しさん
04/10/18 19:18:17
今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？
って、所詮2chかｗ
667:デフォルトの名無しさん
04/10/18 19:34:01
俺はそんなにスレ・板違いにも思えないんだな。
S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。
ムだのマだのでがっつり分けたがる方が
所詮2ch。
668:デフォルトの名無しさん
04/10/18 20:02:15
>>666
前向きもうしろ向きもなく、雑談。
669:デフォルトの名無しさん
04/10/18 20:03:18
マ板は、ネタスレ用隔離板ですよ。
670:デフォルトの名無しさん
04/10/18 20:04:47
現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。
671:デフォルトの名無しさん
04/10/18 22:29:15
ｽﾙｰしる
672:デフォルトの名無しさん
04/10/18 22:45:41
そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗
673:デフォルトの名無しさん
04/10/18 23:39:08
OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。
674:デフォルトの名無しさん
04/10/19 02:32:25
はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。
675:デフォルトの名無しさん
04/10/19 03:31:31
おお、すずめかあ。懐かしいなあ。
でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。
676:デフォルトの名無しさん
04/10/19 03:50:38
いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。
で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。
677:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/19 21:23:49
>>678
StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。
681:デフォルトの名無しさん
04/10/19 23:15:00
この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？
682:デフォルトの名無しさん
04/10/19 23:31:44
3.14人くらい？
683:デフォルトの名無しさん
04/10/20 00:10:39
S2というか、そもそもJavaで実装すること自体やめたほうがいい
684:デフォルトの名無しさん
04/10/20 01:06:05
なんで？
685:デフォルトの名無しさん
04/10/20 01:27:24
Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。
686:デフォルトの名無しさん
04/10/20 01:29:31
S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。
何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。
# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。
くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。
687:デフォルトの名無しさん
04/10/20 01:41:00
スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。
688:デフォルトの名無しさん
04/10/20 02:04:06
S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。
所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。
689:デフォルトの名無しさん
04/10/20 06:33:55
>「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。
690:デフォルトの名無しさん
04/10/20 06:39:58
>>686
TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。
なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。
あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。
691:デフォルトの名無しさん
04/10/20 09:19:09
S2Quartz!!!
URLﾘﾝｸ(d.hatena.ne.jp)
692:太田＠会社
04/10/20 12:05:09
686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。
693:デフォルトの名無しさん
04/10/20 13:08:35
>>686
>2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆
694:デフォルトの名無しさん
04/10/20 19:20:59
比嘉氏・取り巻き・羽生氏ときて今度は若手か。
徹底的に人に絡んでくるな。
695:デフォルトの名無しさん
04/10/20 19:25:28
つうか、取り巻きって誰かが明示されてないし。
イタい取り巻きの例示きぼん>>686
696:デフォルトの名無しさん
04/10/20 19:26:14
s/取り巻き/若手
697:デフォルトの名無しさん
04/10/20 19:34:42
んなこといいけど、S2JSFって進んでるのかな？
なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。
S2JSFのためにS2のバージョンアップが必要なのだろうか？
698:デフォルトの名無しさん
04/10/20 19:48:08
S2JSFのためのS2.1化だろ。
699:697
04/10/20 19:49:30
う〜〜待ちきれない
700:デフォルトの名無しさん
04/10/20 20:04:00
そこでJSF-Springですよ
701:デフォルトの名無しさん
04/10/20 20:30:58
>>695
やめれ。これ以上個人名を出す必要はないよ。
比嘉氏や羽生氏はともかく他の人は関係ない。
702:デフォルトの名無しさん
04/10/20 23:09:40
ひがさんやはぶさんの名前を出す必要もないけどな
S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。
703:デフォルトの名無しさん
04/10/20 23:12:53
やっぱりからさわぎはくーすのトラックが人気なのかな？
俺もデザイントラックにしようかと思ったんだけど
くーすは本が出るからそっち読むとして
今回はビジネストラックにしようかなとも思って。
マジカ面白かったし。
704:デフォルトの名無しさん
04/10/21 00:08:30
S2JSF いつ頃だろうか。
前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz
705:デフォルトの名無しさん
04/10/21 00:11:39
>>704は>>700に助けてもらえ
706:デフォルトの名無しさん
04/10/21 00:33:30
今のうちにS2に乗り換えてしまくて。
WW2かTapestry試そうかと思ったが、本命はS2JSFなんだよな。
タイミング的に微妙.....
707:デフォルトの名無しさん
04/10/21 00:52:05
何かに依存した設計のデメリットを、ロッドジョンソンに身を以て教えられた。
そんな２７歳の秋。
708:デフォルトの名無しさん
04/10/21 01:22:30
この板以外、どこのブログ見りゃいいんじゃいの？押さえどころ
709:デフォルトの名無しさん
04/10/21 02:45:56
ドメインロジックとSQL
URLﾘﾝｸ(capsctrl.que.jp)
くーすマンセーな人は、一度↑を読んでみて欲しい。
それで、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:デフォルトの名無しさん
04/10/21 09:08:50
はぶ氏がRDB大好きだというのはblog見てるとわかる。
ひが氏はもう少しニュートラルというか使いやすい
ORマッピングを考えてのことなんじゃないかな。
ふたりともTransactionScriptマンセーというのとはまた違う気がする。
ER分析マンセーなのかも知れないが。
713:デフォルトの名無しさん
04/10/21 10:03:23
RDBをRDBとして使う限りにおいては、ER分析マンセーみたいね。
俺も同意。つーか当たり前だと思う。
RDBをただのストレージとして使うやり方は俺には合わんかったんでｼﾗﾈ。
714:太田＠会社
04/10/21 10:37:12
710さん>
幻想というより西方浄土でしょうか。ひがさんにダイレクトに聞いてみると分かりますが，
TransactionScriptマンセーじゃないですね。僕も今は教育側にいるときがありますけど，
理想のOOA/Dは現時点ではあまりに属人性がありすぎて，Martin Folwerのいる会社のような
よほどつわものがそろった組織でないと難しいです。つわものがそろっていれば，理想の
OOA/Dも不可能ではないと思います。
>URLﾘﾝｸ(capsctrl.que.jp)
既読です。読書会でも話題になりました。これをたたき台にして，トレードオフについても
かなり議論になりました。理想のOOAD対ER分析というよりはメンテナンス性対パフォーマンス
というところでしょうか。
715:デフォルトの名無しさん
04/10/21 11:11:11
単に選択の問題であるだけでしょう。
私が今携わっているプロジェクトでは業務ロジックがさほど多くなかったので、
Springを使ったTransactionScriptな設計にしてありますが、
明らかにサービス層の肥大化が予想される場所にはDomainModelを適用しています。
別にどちらが正解であるということもありませんが、OOエキスパートが少ない
環境ではTransactionScript寄りになってしまうことは避けられないでしょうね。
ちなみにくーすはTransactionScriptの発展的なアプローチだろうと思います。
ひがさんは否定しておられるようですが、サービス層と永続化層を分離した
パターンの中で、大別して上記２つ以外に思いつくものはありません。
というか何がどう違うのかもうちょっと説明して欲しいかも。
Entity層にビジネスロジックを含めないって時点で、少なくとも
DomainModelではないし。
今日は風邪で休んでるんで自宅からカキコ。
直に書きに行こうかともおもったけど私なんかの出る幕はではなさそうだし、
この場で失礼。
716:デフォルトの名無しさん
04/10/21 11:15:59
ビジネスロジックって表現がそもそも曖昧だよな
717:715
04/10/21 11:24:03
>>716
> ビジネスロジックって表現がそもそも曖昧だよな
そうかも。
私の中では一連の"業務仕様"ってところで理解してます。
売上げ本数の計上ルールとか？ いい例えが思い浮かばん。
永続化処理とか、メールやCSV取込とかはビジネスロジックとは
呼べないでしょうね。
718:715
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:デフォルトの名無しさん
04/10/21 20:37:11
結論：OO厨は邪魔なだけ。
720:デフォルトの名無しさん
04/10/21 21:44:57
ちゃんとした手法に基づいてやられたら、デスマーチのらくらく残業ができなくなるもんね。
721:デフォルトの名無しさん
04/10/21 22:00:20
ここんところの話が英単語ばっかりでよくわかんにゃい。
くーすの考え方の肝ってどっかに載ってる？
「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。
OOは部品化以外の用途で仕事で使うには、頭がよい人を期待しすぎだよ。
自分で設計してるときはそりゃ楽しいけど、実働後の保守メンバーに馬鹿が１人いただけで設計が崩壊しかねない。
それが自分だったりして鬱になる。
例えると、天才が設計したゼロ戦で華麗に舞って死ぬよりも、
芸が無いグラマンでデスマから生還したほうがいい。
722:デフォルトの名無しさん
04/10/21 22:14:52
その例えだと、グラマンはいかにも燃費が悪い。
ぜいたくに出来た飛行機だと松本零二も言ってます
↑
ここ笑うところ
723:デフォルトの名無しさん
04/10/21 22:58:25
>>721
その、グラマンたるライブラリがSeasar2なんだよ！
POJO書いて、設定ファイルを書くだけ。
S2で欲しい機能があれば、はてなでｷﾎﾞﾝﾇするだけでOK。
724:デフォルトの名無しさん
04/10/21 23:48:09
ひが氏にお願いです。
商用サポートもドキュメント見直しもFlexも
くーす本もからさわぎも全部後回しでいい。
頼むからS2JSFを早く出してください。おながいします。
725:デフォルトの名無しさん
04/10/22 00:28:45
>>724
S2JSF ＞ くーす本 ＞＞＞＞＞＞ その他
726:デフォルトの名無しさん
04/10/22 00:41:18
開発するより宗教論争が好きな人って結構いるね。
727:デフォルトの名無しさん
04/10/22 00:52:30
2chに書いてるﾔｼなんざ大抵そうだな
728:デフォルトの名無しさん
04/10/22 01:04:27
つか、2ちゃんだから出来るんだよ。
現場でやる奴よりは全然いい。
大体宗教論争ってのは、スプーンに天使は
何人乗る事が出来るかとか
そういうアホで無意味な事を議論する事で、
ここでの話はわりと意義はあると思うよ。
729:デフォルトの名無しさん
04/10/22 01:04:56
>>726
開発なんかするより他人を論破することが楽しいですが何か？
730:デフォルトの名無しさん
04/10/22 01:20:59
>>729
hub。
731:デフォルトの名無しさん
04/10/22 01:32:03
>>721
> ここんところの話が英単語ばっかりでよくわかんにゃい。
URLﾘﾝｸ(www.martinfowler.com)
> くーすの考え方の肝ってどっかに載ってる？
> 「業務処理手順をソフトウェア設計者が抽象化してはいけない」ってことかな、と思ってるんだけど。
URLﾘﾝｸ(www.wikiroom.com)
732:デフォルトの名無しさん
04/10/22 01:45:02
URLﾘﾝｸ(d.hatena.ne.jp)
うそーん。ぜんぜん問題わかってないじゃん。
だまされたと思って一回原典読んでみてください。お願いします。
733:デフォルトの名無しさん
04/10/22 01:51:36
URLﾘﾝｸ(d.hatena.ne.jp)
> 良く使われると思われるドキュメントを見直しました。
> すべて、概要、リファレンス、Exampleの3部構成になっています。
> どうでしょう。2chの人
おぉ、こぎれいに、丁寧になってる。
くるしゅうないぞよ。
あとは、www.seasar.orgにそういった改変情報が載るようにすることですね。
それから、ソースと実行結果はスタイルを変えたほうが。
実行結果は黒地白文字とか。
734:デフォルトの名無しさん
04/10/22 02:04:34
733のような奴の言うこと真に受けて、がんばってらっしゃる。
ひがさん、尊敬します。
733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動くプログラムを作ることすらできないですから。残念！
735:デフォルトの名無しさん
04/10/22 02:17:22
>>734
> 733のような奴の言うこと真に受けて、がんばってらっしゃる。
> ひがさん、尊敬します。
>>733って、文体は2ch的で一見失礼だけど、ひが氏のモチベーション向上+
前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。
> 733のような下らない連中は奇麗なドキュメント作っても、大して理解できる訳でもなく、
> ただ単に新しい技術を斜め読みして、あーだこーだ言うだけで、結局まともに動く
> プログラムを作ることすらできないですから。残念！
こういう非生産的なラベリングはやめようよ。つーわけで>>733気にするな。
って、>>733の自演扱いされるのがオチか。
736:デフォルトの名無しさん
04/10/22 02:19:11
>> バウンダリで、直接ドメインオブジェクトを使うのも、かなり困難だと思います。
これって理由は何でだっけ？
737:デフォルトの名無しさん
04/10/22 02:35:11
>>735
>ひが氏のモチベーション向上+
>前向きな成果物改善支援の意図が感じられる好レスだと思うんだが。
ドキュメント的には、「今の段階で」十分すぎるほど揃ってると思う。
日本語ということも含めると、他のオープンソースプロジェクトなんかより
断然素晴らしい。
失礼な文体、普通はモチベーション下がるって。成果物改善支援？大きく出たな。
物は言いようか。好レス？？笑けた。ネタ？
738:733
04/10/22 02:37:38
>>735
ありがとー。
あーだこーだ言うだけ言って、作業に手は貸さないわけだから、そこに対して改善が図られた場合には、ちゃんと気づいて反応するようにしてるです。
739:デフォルトの名無しさん
04/10/22 02:40:58
「今の段階で」というなら、「揃っている」じゃなくて「揃った」、の方があてはまるんじゃねぇの？
740:デフォルトの名無しさん
04/10/22 02:50:08
>>736
あとで仕様変更があってバウンダリとドメインオブジェクトの間にロジック（サービス）を
挟まなくちゃいけなくなった時に困るからじゃなかったっけ。
741:デフォルトの名無しさん
04/10/22 03:06:07
「今の段階としては」だな。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5398日前に更新/285 KB
担当:undef