国産オープンソースDI ..
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
「今の段階としては」だな。
742:デフォルトの名無しさん
04/10/22 06:11:18
URLﾘﾝｸ(d.hatena.ne.jp)
> リソース層にRDBMSを使う限り、SQLの知識は必須です。
> デザインパターンやP of EAAの習得には熱心だけど、
> SQLには興味ないなんて人がいるなら、知識のバランスに
> かけてます。
URLﾘﾝｸ(d.hatena.ne.jp)
> JSPバリバリですぅ〜。でもServletはわかりませ〜ん。ってのと、
> ORマッピングツールバリバリですぅ〜。でもSQLはわかりませ〜ん。
> っていうのは、似たり寄ったりだと思うんだが、
お二人とも勘違いなさっているようですけど、
DomainModelを推している人たちは
「SQLが分からないから使わない」
んじゃなくて
「SQLにビジネスロジックを入れたくないから使わない」
んです。
RDBMSを使っている限りはSQLの知識が必須なのは当然でしょう。
743:デフォルトの名無しさん
04/10/22 06:50:50
>>732
問題と思うことをきちんと指摘したら。
人にいわれる本を全部読むような時間のあるひとはいないだろ。
744:デフォルトの名無しさん
04/10/22 07:09:24
>742
推している人たちって誰のこと？
DomainModelいいよ！って言ってる人全部ってわけじゃないでしょ？
SQL書きたくないから〜って人は確実にいる（何人か知ってる）し、
そういう人を想定して言ってるんじゃないかな。
SQLばっちり分かっててかつDomainModelを推してる人よりは多いと
感覚的には思うが、どうだろね。
745:デフォルトの名無しさん
04/10/22 07:52:08
>>742
DomainModelを推している人は、
「SQLが分からないから使わない」
と思っているとは、書いてないと思うけど。
それは、被害妄想。
746:デフォルトの名無しさん
04/10/22 08:27:37
>>735
我田引水
747:デフォルトの名無しさん
04/10/22 08:30:03
>>742
なあビジネスロジックって何？
ほんとにわかんねえんだよ。
SQLで平均とか一発で出せても
使うなってことか？平均何とかも
ビジネスロジックだと思うんだけど。
748:デフォルトの名無しさん
04/10/22 08:34:15
何でこのスレはageる人が多いんだ？
749:デフォルトの名無しさん
04/10/22 09:00:30
>>732
ひがたんはそんなの読まなくてもいいからS2JSFを先に作って欲しい。
正直漏れはくーすはどうでもいい。便利な道具としてのS2が気に入ってるんだ。
もしひが氏が真面目に原典とやらを読んだ結果S2JSFのリリースが遅れたりしたら
>>732ぬっころす
750:デフォルトの名無しさん
04/10/22 09:20:50
そこまで粘着すると、キモいね。
751:デフォルトの名無しさん
04/10/22 09:32:31
2chに書いてるだけでキモいけどね
とりあえずこのスレは粘着のスクツということでFA
752:デフォルトの名無しさん
04/10/22 10:35:49
>>747
そういうことみたいだな。
複雑な会計の帳票とか出すとき
どうするんだろうって思うよ。
UNIONとかFROM句にサブクエリとか
ガンガン書いてやっとまともなレスポンスで
出るようになる帳票とか山ほどある。
だからS2Daoは、最初見たとき霧が晴れた気分でした。
753:デフォルトの名無しさん
04/10/22 10:42:12
ドキュメントがいくつか更新されたみたいです。
・DIContainer
・AOP
・テスト技法
・S2DAO
の4項目かな？
どこの項目が更新されたかわかるように印をつけて（updateとかnewとか）
くれるとありがたいなあ･･･
754:デフォルトの名無しさん
04/10/22 10:59:46
>>753
>>733で既出。そこのブログにリリースノートが。
755:デフォルトの名無しさん
04/10/22 11:02:18
>>754=>>733様
756:753
04/10/22 12:41:35
ぐあっ・・・ほんとだ orz
駄ﾚｽでした。重複ｽﾏｿ
757:デフォルトの名無しさん
04/10/22 14:05:19
>>732
>だまされたと思って一回原典読んでみてください。お願いします。
オマエが騙しそうだなー
>>742
URLﾘﾝｸ(capsctrl.que.jp)
読んでみたんだけどなー
> 「SQLが分からないから使わない」
>
>んじゃなくて
>
>「SQLにビジネスロジックを入れたくないから使わない」
>
>んです。
リッチなSQLの例が、SQLの入門書レベルだからなー
勉強したくないだけだろうと思われても仕方が無いなー
VB厨でもPHPerでももっと複雑なSQLを普通に書くと思うなー
>>752
そうだなー
PoEAAが具体的にどういうシステムを想定しているのかを知りたくなるなー
758:デフォルトの名無しさん
04/10/22 14:25:16
>>757
> リッチなSQLの例が、SQLの入門書レベルだからなー
同意
759:デフォルトの名無しさん
04/10/22 15:02:33
SQLの中身については、いやまあサンプルって事で。
それいったら、過去実績である注文データに対して
ディスカウントキャンペーンを適用するようなつくりになってて
蓄積された実績を何時でも恣意的に改変できる形になってるじゃん。
注文ってエンティティの構造は捉えられていても
その意味というか本質というか、全然考慮されてない。
その理由は、勿論サンプルだから、でしょう。
まじボケだったらファウラー、おちゃめさんです。
つっこみ始めたらきりがないから、ここは
「SQLに業務ロジックを入れる」って事のだけ
見ればいいよ。
760:デフォルトの名無しさん
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
04/10/22 15:54:39
一人いたな、簡単なJOINのSQLでも
全部Accessで作ってからちょこちょこ直す人。
結構経験あって、Win32APIとかすごく詳しかったけど、
業務系はあまりやってこなかったみたい。
帳票のSQLとかほとんど俺が書いて、メールで渡してたなあ。
しかもその人がテーブル設計やったもんだからもう、
俺も不憫に思ってくれい。
そのSQL書ける人が書いてメールで渡すってのを
メール経由でコピペとかじゃなくて、
きちんと組み込めるのがS2Daoな訳ですな。
762:デフォルトの名無しさん
04/10/22 15:55:38
・・・普通の集計にしか見えんのですが。
763:デフォルトの名無しさん
04/10/22 16:11:53
その普通の集計をわざわざコードでやるがいいと
おっしゃっておるのでつよ。
これがリッチSQLなのでつ。リッチクライアントも決して
普通のVBの画面にしか見えんのですが。
などといってはいかんのでつ。
764:デフォルトの名無しさん
04/10/22 16:25:34
しょぼいSQLで済むことにあれだけコード書くようだと
複雑なクエリーが必要な場合にどれだけコードを書くんだ？
いくら将来性がどうとか言われてもバグが増えそうで俺は嫌だ
あるかないかわからない移植のことを考えるよりもさっさと作って
リリースするほうが重要なんじゃないか。いるものだけ作るという
原則に反している気がする
765:デフォルトの名無しさん
04/10/22 16:39:18
つまりあれだ。
S2Daoﾏﾝｾｰってことだな。
766:デフォルトの名無しさん
04/10/22 17:14:54
だな！
767:デフォルトの名無しさん
04/10/22 21:55:24
>>763
> リッチクライアントも決して
> 普通のVBの画面にしか見えんのですが。
> などといってはいかんのでつ。
比較対象がHTMLフォームだから。
768:デフォルトの名無しさん
04/10/22 21:58:01
あのドキュメントは社員さんが書いたのか。
サイトの運営も社員さんにやってもらったほうがいいね。
なんにしろ、組織的なサポートは心強い。
769:デフォルトの名無しさん
04/10/22 23:55:07
>ビジネスロジックとは
意味わかんね。
だれかかいつまんで説明して
770:デフォルトの名無しさん
04/10/23 00:39:25
>>764
問題は移植性だけじゃない。Fowler氏はいろいろ挙げてるじゃないか。
とくに問題になる点は
・更新性「EAはこれからめちゃくちゃ変わる」
・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
だろう。
まあ、俺はどっちかというとS2Daoマンセー派だが、物事はそう単純ではないと言うことだ。
771:デフォルトの名無しさん
04/10/23 00:50:40
結局規模が違えば考え方も違うってことだね。
もちろん、SQLではなくてアプリケーション側で処理してもパフォーマンスに何ら問題ないようになると違うんだろうけど。
772:デフォルトの名無しさん
04/10/23 00:57:52
>>770
EAはむちゃくちゃ変わるってのは
日本で業務系に携わってても
正直そこまで実感が湧いてこないんですが
それは私の経験不足と言う事でさておいて
大体リッチなSQLを使う所って、経営分析データだとか
会計帳票とかになりますよね。
そういう所はEAとかいう部分と関係なくて
逆に安定しまくっとる所なわけで、
そこにSQL一発ですむものを複雑なコーディングに
置き換えるのはやはり気がひけます。
やっぱりいいとこどりが一番って事でしょう。
議論としちゃつまらん結論ですけどのう。
773:デフォルトの名無しさん
04/10/23 01:35:27
全体を捉えた議論の結論としては
「やるべきことをやる、使うべきところで使うべきものを使う」
ということになると思うが、じゃあ、どれはどこで使うのか？という議論が大事なんじゃないの？
つまり、その手法のメリットデメリットはなにか、と。
マンセーするにしても、いっさいがっさいそれでいくわけじゃなくて、多少のデメリットは目をつぶるという程度だろ？
774:デフォルトの名無しさん
04/10/23 02:33:35
殺伐としたスレに救世主が！！
無職
ヽ|・∀・|ノ ＜人殺しマン参上
|=◎=|
| |
URLﾘﾝｸ(headlines.yahoo.co.jp)
775:デフォルトの名無しさん
04/10/23 03:05:17
S2JSF間近aga!!!
776:デフォルトの名無しさん
04/10/23 03:07:08
>>770
> ・更新性「EAはこれからめちゃくちゃ変わる」
だったら今考えている柔軟性が通用するかどうかわからんように思うのだがどうか？
> ・カプセル化「ビジネスロジックを担当するコードがデータベース設計変更時に影響を与えられることはない」
データベース設計が変わったらそれを使っているビジネスロジックも変更する必要があると思うのだがどうか？
云わんとしていることはわかる気がするんだが冗長過ぎる気がしてならんのだよ。
777:デフォルトの名無しさん
04/10/23 03:51:27
ファウラーのblikiを翻訳してる方によると
やはり日本とアメリカの事情の違いってのがあるそうで、
日本にくらべてあっちはアプリ開発とDB開発の分業が
相当徹底されているらしいですね。
で、
> ・カプセル化「ビジネスロジックを担当するコードが
>データベース設計変更時に影響を与えられることはない」
ってのは、776の言う通り、設計変更っていや
ビジネスロジックの変更の事だろう、って気分に私もなりましたが
もしかしたらアメリカさんの事情ならではの発想なのかも知れないなあ
と思った訳です。向こうからしたらこっちの言ってる事がドンくさいと思われるかも。
あくまでも推測なんで、アメリカさんの事情に詳しい方いらっしゃいましたら
うそつけバーカとか書いちゃって下さい。
あと、私も含めてですが776の「DB設計変更=ビジネスロジックの変更」って考え方は、
やっぱり前提がDOAなんでしょうねぇ。でもしっくりくるよね、皮膚感覚で。
778:デフォルトの名無しさん
04/10/23 04:00:15
773の意見にまったく同意です。
でもまあ、総論みたいな所も、答えは「いいとこどり」に
落ち着く事は判っていても、喧々諤々やっといた方が
いいと思うんですよ。
その事で、双方の「いいとこ」の範囲が、
前より広く感じられて来たりしたら良いと思うし。
ここ、読んでて大変面白いですよあたしゃ。
2ちゃんのOO関連スレじゃ一番じゃないですか？
779:デフォルトの名無しさん
04/10/23 04:13:28
関係ないが、某blogでマジックナンバーはいいの悪いの、っていうのがあって、アクセッサ作れってあるけど、すべての定数についてアクセッサ作らされてたらたまらんな、と思った。
結局、マジックナンバーを使うなってことではなくて業務数値をその数値を保持するべきではないところに置くな、ってことじゃないのかな。
780:デフォルトの名無しさん
04/10/23 04:49:47
言語とRDBMSと、どちらが変更される可能性が高いか。
どちらとも言えんと思う。
言語が変わる場合：
C/S からWEB系への移行
Unixに乗り換えで、ASPからJavaへ移行
RDBMSが変わる場合：
パッケージもの。お客様によってRDBMSが異なる
辺縁系のシステムなら、Oracleなどからオープンソースに乗り換え。
他にどんな場合があるかな？
781:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/23 11:13:19
>>777
だからコミュニケーションの重要性が
日本以上に言われるのかな＞分業の徹底
784:デフォルトの名無しさん
04/10/23 11:40:46
>>783
うん、そうみたいですね。
blikiの翻訳者さん、こんなのも翻訳してまして
URLﾘﾝｸ(capsctrl.que.jp)
ここみると、「なぜ一緒に働くことが現在困難なのか」とか
なんかアプリ屋とDB屋がまるでイスラエルとパレスチナの様で、
日米の文化の違いはかなりのもんの様です。
でもアメリカさんだから、ジョークというか
比喩かも知れないですけどね。
785:デフォルトの名無しさん
04/10/23 11:47:58
seasarの良いところがいまいち分からんなー。
インターフェース書いて、ダイコンファイル書いて
ってめんどくせーって思っちゃう。
サービスに新しい機能付けようと思ったら、インターフェース
とImplクラスの２つを変更しなきゃいけないし。
インターフェースはImpl挿げ替えるだけで、動きを変えられるって
メリット（多態性）で使うんであれば良いし、よく使うんだけど
seasarのためにインターフェースガンガン書くって気にはどうも慣れん。
ダイコンファイルでImpl差し替えるって事ってそんなにたくさんあるのかな。
漏れはstruts+Hibernateで全然作ってるけど、「それだとここめんどくさくない？
なので私はseasar使うようになったよ」って意見を聞きたいです。
あとEJBはseasarよりさらにダルイっておもっとる。
786:デフォルトの名無しさん
04/10/23 11:59:55
別に無理してまでインターフェース用意することも無いでしょう。
必要に迫られたときにインターフェースを抽出することは
IDEなんかのツール使えば一瞬で出来るんだし。
787:786
04/10/23 12:01:40
ただ、インターフェース使うとimplのすげかえ以外にもメリットが多いのは事実です。
不必要なメソッド呼び出しを隠蔽できたり、Mock使ったテストが容易になったり。
788:785
04/10/23 12:21:54
レスありがとう。
>別に無理してまでインターフェース用意することも無いでしょう。
seasarってインターフェース必須ではないんだー。誤解してました。
>不必要なメソッド呼び出しを隠蔽できたり、
これは、漏れのやる仕事のに依存してるのかもしれないけど
APIのようなクラスを作るときは、隠蔽って重要だと思います。
でも、そうではない業務ロジックの実装だと余り隠蔽したい場合に
出くわさないんですね。
>Mock使ったテストが容易になったり。
これはもう少し詳しく聞きたいです。seasarのドキュメントにも
テストが容易って書いてありますが、EJBに比べてって事ですか？
struts+Hibernateでテストしにくいって感じた事無いんですよね。
789:デフォルトの名無しさん
04/10/23 12:28:07
>>785
seasarというより、インターフェースと実装を分離するということは、
OOの重要な部分だと思うけど、分業するときに、
インターフェースを先に決めておけば、実装が追いつかなくても、
Mockとかを使って作業を並行して進められるというメリットがあるね。
実装クラス同士が直接依存しあうことが少なくなるから、
個々のクラスの個々のメソッドを単独で実装・テストしやすい。
直接依存してると、依存しあっている部分を全部コーディングしないと
テストできないから。
790:デフォルトの名無しさん
04/10/23 12:32:00
>>788
ふだん、どんなテストしてるの。
791:785
04/10/23 13:10:24
>>789
>Mockとかを使って作業を並行して進められるというメリットがあるね。
でもインターフェースじゃなくて、空のクラスだけMockとして用意するのも
同じだと思うんですが。あ、もちろんどちらが綺麗かって言われたら
インターフェースがある方ですが。。。
>依存しあっている部分を全部コーディングしないと
>テストできないから。
うーんseasarもダミーの実装をダイコンファイルに書いてるだけ
なんだよなと。Implクラスにダミーの戻り値を書いておく方が
楽と感じてます。
>>790
普段は下層のDAOから実装していくって感じなんで
（階層での作業分担はしない）、DAOの単体テスト=>サービスの単体テストって感じ。
サービスで他のコンポーネントに依存するようなら、まずそっちから実装かな。
相互に依存する場合は、必要になるメソッドだけOr上で書いたダミーの実装。
他の人のコンポーネントが必要なときは、クラスだけもらってダミーの実装だなー。
792:デフォルトの名無しさん
04/10/23 13:34:02
>>791
それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。
でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。
あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。
ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。
793:デフォルトの名無しさん
04/10/23 13:57:33
まさか、自動テストの一括実行をやってないとか。
794:785
04/10/23 14:32:12
>>792
ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。
その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。
>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。
上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。
795:デフォルトの名無しさん
04/10/23 14:38:34
>自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？
796:デフォルトの名無しさん
04/10/23 16:59:16
デバックってゆうな〜
797:デフォルトの名無しさん
04/10/23 18:00:15
>おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。
モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。
ちなみにdebugなんでデバッ"グ"
798:デフォルトの名無しさん
04/10/23 18:24:12
OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。
新参者は空気を読め、空気をという話である。
799:785
04/10/23 18:58:14
デバッグですね。お恥ずかしい。。。
>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。
逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ
800:デフォルトの名無しさん
04/10/23 19:10:45
>>798
何のコピペ？
801:デフォルトの名無しさん
04/10/23 19:36:39
はぶ氏もひが氏もここの話題に反応してくれてますな
っと、話ふり逃げに思われると残念なので書いとこう
802:デフォルトの名無しさん
04/10/23 21:45:01
>>800
これだろうな。
URLﾘﾝｸ(d.hatena.ne.jp)
803:デフォルトの名無しさん
04/10/23 22:08:24
URLﾘﾝｸ(d.hatena.ne.jp)
こんな未来は嫌だ。
804:デフォルトの名無しさん
04/10/23 23:03:29
どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
805:デフォルトの名無しさん
04/10/23 23:05:49
> Stateless BusinessLogicパターンのメリット
> URLﾘﾝｸ(d.hatena.ne.jp)
上記サイトの内容で疑問点がありまして。
ひがさんは
「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」
と仰っています。
ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。
このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
806:デフォルトの名無しさん
04/10/23 23:27:38
>>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
807:785
04/10/23 23:35:51
>>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。
よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。
でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
808:デフォルトの名無しさん
04/10/23 23:44:01
statelessって「実装に依存しない」って意味なんじゃないですか？
依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。
stateless
【形-1】 国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっか とうち けん｝］のない
【形-2】 《コ》処理状態｛しょり じょうたい｝を把握｛はあく｝しない〜◆【対】stateful
って辞書にあるそのまんまの意味だとばっかり思ってました。
809:デフォルトの名無しさん
04/10/23 23:48:50
URLﾘﾝｸ(d.hatena.ne.jp)
810:デフォルトの名無しさん
04/10/23 23:51:34
>>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？
> 処理状態｛しょり じょうたい｝を把握｛はあく｝しない
そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
811:デフォルトの名無しさん
04/10/23 23:52:33
>>808
かなり根本から間違ってるな。State が lessなんだぞ。
812:デフォルトの名無しさん
04/10/23 23:57:32
>>808
SLSB/SFSBの違いを思い出せ。
813:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/24 00:09:28
>>804
ポインタ希望
819:785
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:デフォルトの名無しさん
04/10/24 00:47:37
だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。
810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。
状態を持たないだと判りにくいか、
状態の変化を管理しない。
S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。
結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
822:デフォルトの名無しさん
04/10/24 00:47:53
ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。
この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
823:デフォルトの名無しさん
04/10/24 00:50:36
ああでもよくわかんねぇ
824:デフォルトの名無しさん
04/10/24 00:50:40
class File {
static int read(String filename, int position);
}
これは？
825:デフォルトの名無しさん
04/10/24 00:52:15
なんか俺も混乱してきたのでひがさんきぼんぬ
826:デフォルトの名無しさん
04/10/24 00:54:09
ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。
あ、821=823です、
まぎらわしくなっちゃってすみません>822
827:デフォルトの名無しさん
04/10/24 00:54:10
>>820
オブジェクトをステートレスにしろって事じゃないの？
下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。
上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
828:785
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
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:デフォルトの名無しさん
04/10/24 02:51:26
ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
832:デフォルトの名無しさん
04/10/24 03:14:28
ドメインモデル->実世界の構造のウツシミ
833:デフォルトの名無しさん
04/10/24 03:17:11
結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
834:デフォルトの名無しさん
04/10/24 03:20:59
モデリングの本とかで問題領域とかいわれてる部分。
簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
835:デフォルトの名無しさん
04/10/24 03:23:09
あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
836:デフォルトの名無しさん
04/10/24 03:44:42
なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
837:デフォルトの名無しさん
04/10/24 04:01:43
児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。
釈然としない所もあるけどさー。
838:デフォルトの名無しさん
04/10/24 04:08:57
> 釈然としない所もあるけどさー。
どういうところ？
839:デフォルトの名無しさん
04/10/24 04:19:41
2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。
でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。
こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
840:デフォルトの名無しさん
04/10/24 04:30:49
>>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。
その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
841:デフォルトの名無しさん
04/10/24 04:32:09
>>839
マジカの出番かな？
842:デフォルトの名無しさん
04/10/24 04:59:47
マジカ？
843:デフォルトの名無しさん
04/10/24 05:01:25
>>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
844:デフォルトの名無しさん
04/10/24 10:31:16
結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
845:デフォルトの名無しさん
04/10/24 10:48:45
Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。
URLﾘﾝｸ(d.hatena.ne.jp)
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。
S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。
>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。
この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5389日前に更新/285 KB
担当:undef