- 1 名前：デフォルトの名無しさん [04/10/27 22:54:13]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
d.hatena.ne.jp/higayasuo/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
- 820 名前：デフォルトの名無しさん mailto:sage [04/12/06 07:05:19]
- で、新しいのでちゃんと直ってるの？
- 821 名前：デフォルトの名無しさん mailto:sage [04/12/06 07:51:22]
- >>820
マルチプロセッサ環境が無いから俺には確認できん。
つい最近まではあったんだけど。。。
誰かﾚﾎﾟよろ。
khi氏の書き込み待ちになってしまうのか？
彼は書いてる文面はむかつくが（性格も悪いんだろうけど）、
指摘してるポイントは正しいからね。
- 822 名前：デフォルトの名無しさん mailto:sage [04/12/06 11:22:00]
- >>821
だから、マルチプロセッサとスレッドセーフと、どんな関係があるのかと。
- 823 名前：デフォルトの名無しさん mailto:sage [04/12/06 12:11:53]
- MP構成でなければなかなか再現しないので実際に修正されたという確信がもてない、という関係
まあMPで試して大丈夫ならOKというものでもないんだけど。
論理的な正しさをソースコードで検証しないとどうしようもない。
- 824 名前：デフォルトの名無しさん mailto:sage [04/12/06 22:26:35]
- khi氏という高スキル開発者がSeasarプロジェクトへ合流か。
順風過ぎて少し妬ましいね。
- 825 名前：デフォルトの名無しさん mailto:sage [04/12/06 23:03:12]
- >>824
あまりやる気あるようには見えないけどね。
まあ、脇から問題見つけて文句言う人間がいるだけで全然違うからね。
- 826 名前：デフォルトの名無しさん mailto:ｓage [04/12/06 23:35:18]
- >>808
マルチプロセッサだと、スレッドセーフまわりのバグに当たり易くなる。
- 827 名前：デフォルトの名無しさん mailto:sage [04/12/07 00:21:00]
- >>826
つか、シングルプロセッサだと当たりにくいよね。
昔、貧乏プロジェクトでテスト環境にマルチプロセッサの環境準備できなかったことがあて。
負荷テストで相当の多重度かけて数日動かして問題なかったのに、
マルチプロセッサの本番サーバでリリースしたら初日にいきなりAccessViolationしやがったし。
負荷テストの１／１０程度の同時アクセスしかなかったんだけど出やすいんだよね。
当然だけど。
自前のものならまだしも、下請けに作らせたものだったから、
大問題になっちゃったよ。
しかも、仕様変更だとかふざけた事言いやがって！
ああ、嫌なこと思い出したなぁ。
だからうちは下請けに仕事やらせるときはマルチプロセッサ環境での負荷検証してから納品させるようにした。
下請けにとってはやな客なんだろうなあ。
- 828 名前：813 mailto:sage [04/12/07 00:56:06]
- つーか、マルチプロセッサ以前の問題でしょ。
ttp://d.hatena.ne.jp/khi/20041201#c
↑ここら辺りの頓珍漢なやりとりを見りゃ、skimura氏が
HashMapクラスのAPI仕様すら理解してなかったってのは明白だ。
> ttp://java.sun.com/j2se/1.4/ja/docs/ja/api/java/util/HashMap.html
> この実装は同期化されません。複数のスレッドが同時にこのマップにアクセスし、
> それらのスレッドの少なくとも 1 つが構造的にマップを変更する場合には、
> 外部で同期をとる必要があります。構造的な変更とは、1 つ以上のマッピングを
> 追加または削除するオペレーションのことです。
こんなの、ちょっと知識のある人がコードレビューすりゃ一発で
指摘されるもんなのに、今まで放置されてたってのは異常。
……って思ってたら、
> なんていうか、「オープンソース」よりも「(ソースコードの付いてる)
> フリーソフト」に近い雰囲気を感じないといえば嘘になります。
って記述を見て納得。
- 829 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:01:44]
- S2Daoを仕事で使おうとしてるんだけど、これ、EntityManagerが惜しい！
SQL自動生成とEntityManagerの両立ができたらいいんだけど、出来ないのかな。
というのは、QUERYアノテーションで基本的なメソッドについてはSQL自動生成させて
おいて、それとは別にEntityManagerの findObjectを使いたいんだよね。
それができれば、もしDaoによいメソッドがなければ、findObjectにQUERY
アノテーションと同じ文法でWHERE句を渡してやれば好きなようにデータを取得できる。
HibernateのHSQLみたいな使い方ができる
でもEntityManagerを使うためにはAbstractDaoを拡張した実装クラスを作らないとい
けない。そうするとインターフェースへの自動生成ができない（実装しないと
コンパイルできないし）。自動生成はしたいけど、EntityManagerのfindメソッドも一部
では使いたい。EntityManagerだけ生成できるのかJavaDocもないから良くわからん。
あとふと思ったが、H2Daoは楽は楽だが、一方でO/R Mappingフレームワークが普通に
提供している「DBから読み込んだデータのキャッシング」は提供しないね。まあ機能的に
あたりまえなんだろうけど、この辺りを自分で実装する場合の負荷を考えるとどうなんだ
ろか。
- 830 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:07:36]
- H2Dao(・∀・)ｲｲ
- 831 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:25:44]
- >>830
おお、ほんとだ、H2Daoってなんだ.....orz
- 832 名前：デフォルトの名無しさん mailto:sage [04/12/07 01:39:10]
- どこかにあるっていうから、探してみたら
ひが氏とも同期の話してた
ttp://seasarproject.g.hatena.ne.jp/skimura/20040723
khi氏も最初の対応の後は、気づかなかったから、今まで放置だったんじゃないか？
まあ、直ったからいいけど
- 833 名前：デフォルトの名無しさん mailto:sage [04/12/07 03:16:30]
- 完璧はないんだから、すぐに対応してくれたskimura氏は立派だと思うよ、オレは
S2.1.4をすぐ出した、ひが氏もそうだし
それを当たり前と思うかどうかは、藻前らに任せるが
責任感もってやってくれてると思うと多少は安心する
- 834 名前：デフォルトの名無しさん mailto:sage [04/12/07 03:32:11]
- >>831
Hummer2 Desert Access Optionの略ですね。
これで砂漠も川も縦横無尽。
- 835 名前：デフォルトの名無しさん mailto:sage [04/12/07 04:31:29]
- >>829
> あとふと思ったが、H2Daoは楽は楽だが、一方でO/R Mappingフレームワークが普通に
> 提供している「DBから読み込んだデータのキャッシング」は提供しないね。まあ機能的に
> あたりまえなんだろうけど、この辺りを自分で実装する場合の負荷を考えるとどうなんだ
> ろか。
キャッシングが提供されてないのはDTOセントリックなアーキテクチャしか
眼中にないからだと思う。
ttp://d.hatena.ne.jp/higayasuo/20040808#1091933710
ttp://d.hatena.ne.jp/higayasuo/20041010#1097399686
ただ、こういうアーキテクチャがどういうドメインに適しているかについて
全く記述がない点が不信感を煽る。
- 836 名前：デフォルトの名無しさん mailto:sage [04/12/07 07:13:56]
- キャッシュは鬼門
- 837 名前：デフォルトの名無しさん mailto:sage [04/12/07 09:37:00]
- >>829
> findObjectにQUERY
> アノテーションと同じ文法でWHERE句を渡してやれば好きなようにデータを取得できる。
> HibernateのHSQLみたいな使い方ができる
できるってマニュアルに書いてあるぞ。
return getEntityManager().find("ename LIKE ?", "%" + ename + "%");
ってそうじゃないの。
- 838 名前：デフォルトの名無しさん [04/12/07 11:13:29]
- キャッシュのヒット率を上げてパフォーマンスを上げようと必死なデータベースエンジニアからしてみれば O/R Mapping なんてお笑いなんだろうな
- 839 名前：デフォルトの名無しさん mailto:sage [04/12/07 11:29:18]
- >>838
キャッシュは、近いところにあることにも意味があると思うが。
SQL自体を発行しないわけだから。
- 840 名前：デフォルトの名無しさん mailto:sage [04/12/07 12:10:05]
- ttp://d.hatena.ne.jp/higayasuo/20041207#1102379088
> これは、どのようなドメインにもいえます。
（ ´_ゝ`） ﾌｰﾝ
- 841 名前：デフォルトの名無しさん mailto:sage [04/12/07 19:35:15]
- >>838
O/Rマッピングが字面として聞こえてきた頃の事、これでアノ鬱陶しい
SQLともおさらばだぜ、ヒャッホーと浮かれたもんだ・・・・・・・・・
あの時、うちのDBエンジニアは俺をどういう目で見てたんだろう。
勿論、恐くて聞けないが＿|￣|○|||
- 842 名前：デフォルトの名無しさん [04/12/07 20:39:42]
- くーすにしてもSeasarにしても，利用者が増えれると，
楽してお金を得る人たちがいて，ネズミ講みたいできがのらん．
- 843 名前：デフォルトの名無しさん [04/12/07 20:50:28]
- >>842
関西の毒舌蛇男が参加してから嫌な臭いがしだしましたね。
- 844 名前：デフォルトの名無しさん mailto:sage [04/12/07 21:42:49]
- >>842
どういうこと？
- 845 名前：デフォルトの名無しさん mailto:sage [04/12/07 22:31:19]
- >>843
誰のことー？？
- 846 名前：デフォルトの名無しさん [04/12/07 22:31:30]
- >>844
くーすはシンプルで分かりやすいですが，業務分析は扱わず今まで通りです
から，業務分析をくーすに繋げるあたりの教育やらコンサルやらのビジネス
がなり立つでしょう．そのスペースを狙っている人達がみえかくれ．
Seasar上の開発はプログラミングというよりコーダー的な仕事になり，
それに関る人達の実装技術は育たないことになり，どんどん骨抜きになりそ
う．
というか，そもそも技術力がないソフトハウスをSeasarはターゲットユーザ
にしてる感あり．
- 847 名前：デフォルトの名無しさん mailto:sage [04/12/07 22:51:35]
- >>846
そういう技術の無い若手を採りすぎた会社にいます。
人事部長が変って大学名だけで使えない奴とりまくってしまった。
現場は悲惨だよ。
- 848 名前：デフォルトの名無しさん mailto:sage [04/12/07 23:16:37]
- >>847
その日本語も、そういう現場でつちかってしまったのですね。
- 849 名前：デフォルトの名無しさん mailto:sage [04/12/07 23:33:49]
- >>846の句読点が気になる今日この頃。
- 850 名前：デフォルトの名無しさん mailto:ｓage [04/12/08 00:11:26]
- Seaserも大分信用無くしたなぁ…。
OOやらフレームワークやら語ってた割に、排他制御すらまともに出来ていなかったなんて…。
他にも似たようなバグ抱えてるんじゃないか？
- 851 名前：デフォルトの名無しさん mailto:sage [04/12/08 00:34:46]
- ちょっと追ってみたけど、俺みたいなのでもわかるような
基本的なところで、ぼろぼろじゃん。
Web屋ってこういうの苦手だからしょうがないのかもしれないけど。
組み込みとかの経験ばっちりあるやつを開発に参加させないとダメなんちゃう？
- 852 名前：デフォルトの名無しさん mailto:sage [04/12/08 01:17:57]
- O-Rマッピングツールは、SELECTには使わないのがベストプラクティス。
C/U/Dだけさくっと作って、参照クエリはじっくりSQLを記述する。
- 853 名前：デフォルトの名無しさん mailto:sage [04/12/08 01:52:32]
- >>852
SELECTも、とりあえずORマッピングで遅延取得しまくりで動かしておいて、あとから必要なところだけじっくりSQLを記述する方がベストプラクティスだと思う。
- 854 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:07:09]
- どんなにO/Rマッピングを使っても
沢山の可愛そうな厨房を先導しても
SQLから離れては生きられないのよ！
- 855 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:12:55]
- >>854
それは、ORマッピングをかいかぶりすぎ。
ORマッピングはSQLの結果をマッピングしてくれるだけで、複雑なSQLを簡単にしてくれるわけではない。
JOINに関してはある程度面倒をみてくれるが。
- 856 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:23:42]
- O/RマッピングでSQLが不要になると思った奴て結構多そうだよな。
ASP.NETでJ2EEが消えると思ってる奴とどちらが多いのか気になるところだ。
- 857 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:29:17]
- >>856
で、「結局SQLが必要だからORマッピングなんか役に立たない」と勘違いしてるやつもいるね。
- 858 名前：デフォルトの名無しさん mailto:sage [04/12/08 02:30:11]
- そして、ここをORマッピングのスレと勘違いしてるやつもいるな。
- 859 名前：デフォルトの名無しさん mailto:sage [04/12/08 03:13:02]
- >>856
SQLTemplateがCayenneやHibernateにいまごろ実装されていく様子をみると、開発者自身もそう夢見てたんだろうね。
スレ違いか。
- 860 名前：デフォルトの名無しさん [04/12/08 06:34:41]
- d.hatena.ne.jp/higayasuo/20041207#1102379088
> Fowlerはプレゼンテーション層で必要とされる構造と
> ドメインオブジェクトの間にミスマッチがあるときだけ、
> DTOを使えといっていますが、たいていの場合(よほど
> 単純な画面でない限り)、ミスマッチはあるものです。
ここでいうミスマッチのイメージがわかないです。
どなたか、例を挙げていただけるとうれしいのですが。
- 861 名前：デフォルトの名無しさん mailto:sage [04/12/08 07:57:30]
- >>846
業務分析を楽に稼げる仕事だと思ってるあたりがおめでたい
- 862 名前：デフォルトの名無しさん [04/12/08 10:00:51]
- >>861
よく読んだら。業務分析できない人たちへの教育やコンサルであって、
業務分析を逃げて稼ぐといういみでは。
- 863 名前：デフォルトの名無しさん mailto:sage [04/12/08 10:12:04]
- なるほどね。>>862は例えばオブジェクト指向できない人たちへの教育やコンサルについてはどう思ってるの。
そもそも社外研修を受けさせないと駄目な会社は逝ってよしって言いたいのかな。
- 864 名前：862 mailto:sage [04/12/08 10:33:42]
- >>863
まず断っておくが俺は846ではないので。
「オブジェクト指向できない人たちへの教育やコンサルについては」
どうでも良いと思っている。好きにすればよいと。
846は「そのスペースを狙っている人達がみえかくれ．」と書いている
が、そこを狙っている人達の怪しさを感じ、使う気がしないといって
いると読んだまで。ひがさんは良いとして、おこぼれ頂戴と虎視眈々
と狙っている人達がなんとなくくーすもSeaserもだめにしそうな感じ
が俺もする。
- 865 名前：デフォルトの名無しさん mailto:sage [04/12/08 12:02:59]
- >>846
> 業務分析は扱わず今まで通りですから
こういうくーすの守備範囲に関する元ネタどこ?
- 866 名前：デフォルトの名無しさん mailto:sage [04/12/08 12:15:41]
- ほい
marrow.strnet.com/wiki/pukiwiki.php?%A5%C0%A5%A4%A5%B3%A5%F3%BB%FE%C2%E5%A4%CE%C0%DF%B7%D7%BC%EA%CB%A1%A4%AF%A1%BC%A4%B9
- 867 名前：デフォルトの名無しさん mailto:sage [04/12/08 19:05:20]
- そもそもJavaでサーバサイド開発というのがネタだと漏れは思ってるんで。
もうSeaserも含めてJavaな方々はネタ作りに必死だなと常々思う。
- 868 名前：デフォルトの名無しさん mailto:ｓage [04/12/08 19:51:55]
- 禿堂。
サーバサイドはPHPだよな。
- 869 名前：デフォルトの名無しさん mailto:sage [04/12/08 20:35:05]
- >>868
いや、PHPはイカンと思うが。
でも、Javaよりはマシかもね。
- 870 名前：デフォルトの名無しさん mailto:sage [04/12/08 22:25:59]
- そこで.Netですよ。
- 871 名前：デフォルトの名無しさん mailto:sage [04/12/08 22:57:52]
- >>870
.NetはPHPより悪いJavaよりさらにタチが悪い気がするな。
立ち位置がどうしよもなく中途半端だし、ＭＳだしな。
- 872 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:21:17]
- >>869
で、結論はPerlということか。
- 873 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:25:07]
- ＞ＭＳだしな。
ん？Microsoft製だと何かまずいの？
Microsoftのソフト開発環境はとても使いやすいが。
- 874 名前：デフォルトの名無しさん mailto:sage [04/12/08 23:38:46]
- >>867
サーバサイド開発がネタ
というか、某板某スレの、「Javaはネタ→禿どう」のコンビの人みたいだね。
- 875 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:05:40]
- >873
871じゃないが、
売れてるだけあっていいところは沢山あるんだけどさ。
寄らば大樹の陰が行き過ぎて変なところから圧力かかるのがＭＳのやなとこ。
成り行きでＭＳ”ばかり”やるようになると、ほかの良い物を導入しようとしたとき
「それＭＳじゃないからヤダ」って馬鹿を言う奴がいつのまにか周り中にいたりする。
せっかく自由社会にいるのに自分から独裁者に仕えるのは悪趣味だと思うぞ。
>Microsoftのソフト開発環境はとても使いやすいが。
「俺は」使いやすいとは思わんけど。どっちかというとボーランド派だから。
ようは個人の好み。
- 876 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:33:52]
- >>875
抽象的杉。説得力皆無。
- 877 名前：デフォルトの名無しさん mailto:sage [04/12/09 00:42:31]
- >>876
開発環境ぐらい、フリーのものを使いたいぞな。
- 878 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:03:28]
- そこで vi + gcc + gdb ですよ。
- 879 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:14:44]
- お金払うものでも、自由であればいいよ。
金払って開発環境使い始めたが最後、あとはすべてそこの製品で賄わなければ元がとれない、というものじゃなければ。
- 880 名前：デフォルトの名無しさん mailto:sage [04/12/09 01:41:39]
- >>874
いんや、Javaはなかなかよいと漏れは思ってるよ。
SwingはなかなかいいAPI構成だと思うし、Eclipseは神だしね。
ただ、ここで議論しているようなデータベースのインターフェースとなる
業務アプリを作るときには、Javaは向いてないなってなことだ。
- 881 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:35:07]
- Swingのフォームとバリューオブジェクトのビーンが相互にやりとりできる仕組みさえできればいいと思うんだけどね。
- 882 名前：デフォルトの名無しさん mailto:sage [04/12/09 02:41:54]
- だれかが言ってたようにSeasarが失敗だとするならば、その理由は、ヒガさんに全体的なモデルがなかったことだと思う。
くーすはベストプラクティスの積み上げで、全体的なモデルを構築できてないように思える。
ベストプラクティスは既知の問題には対応できるけど、未知の問題に対応するにはモデルの構築が不可欠だから。
だれかが言ってた、Seasarが失敗だというのが誤りであれば、３行目を除いては正しいとはいえなくなるわけだが。
- 883 名前：デフォルトの名無しさん mailto:sage [04/12/09 03:09:05]
- くーすという方法論とSeasarというプロダクトは別なのだが
- 884 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:41:55]
- くーすって方法論なの？
- 885 名前：デフォルトの名無しさん mailto:sage [04/12/09 04:42:54]
- Seasarは方法論なしにやってるってこと？
- 886 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:27:44]
- Seasarの開発手法はXPのひが版
Seasarでの開発手法はくーす
- 887 名前：デフォルトの名無しさん mailto:sage [04/12/09 11:36:00]
- ttp://d.hatena.ne.jp/higayasuo/20041209#1102556567
（ ´_ゝ`） ﾌｰﾝ
- 888 名前：デフォルトの名無しさん mailto:sage [04/12/09 16:49:05]
-
ちょっと聞きたいんだけど、振る舞いを持たないDTOって
例えば、伝票ってエンティティがあって、こいつの赤伝が欲しいって時に
ステートレスなサービスオブジェクトで、わざわざ伝票の全ての金額項目を×-1していくってこと？
エンティティ自体にtoDebitNote()とか作って、それ呼べば済む話だろうに。
複数のエンティティから特定のエンティティを生成する場合とか、似たような例は
あると思うけど、普通そういうロジックはエンティティ自身に持たせるんじゃないの？
サービス層がステートレスである必要性はわかるんだが、振る舞いを持たないDTOって
いくらなんでもバカすぎじゃね？
ValueObjectにすら振る舞いは持たせるだろ、普通。
- 889 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:08:33]
- 伝票エンティティ自体に自分自身の赤伝を作らせるのは
あまり趣味ではないですな。
伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
それは趣味なのでさておき、エンティティ自体に
赤伝生成責務を置くと、金額に-1をかけるコストに
何か変化はあるのでしょうか？
振る舞いをデータから分離するってのは
普通業務はデータは安定していて
ロジックは変化しやすいものだからってのが理由だそうです。
赤伝ってのはかなり安定した業務ロジックだから
ちょっと例えが悪いかも知れませんね。
- 890 名前：デフォルトの名無しさん mailto:sage [04/12/09 18:17:05]
- >>889
> 伝票エンティティ自体に自分自身の赤伝を作らせるのは
> あまり趣味ではないですな。
> 伝票ってのは蓄積される極々静的なものとして徹底して捉えたいので。
だからサービスがtoDebitNote()を呼ぶんでしょ
>
> それは趣味なのでさておき、エンティティ自体に
> 赤伝生成責務を置くと、金額に-1をかけるコストに
> 何か変化はあるのでしょうか？
だたでさえ肥大しがちなサービスからコードが減るよね。
金額なプロパティがいくつもある場合は特に。
>
> 振る舞いをデータから分離するってのは
> 普通業務はデータは安定していて
> ロジックは変化しやすいものだからってのが理由だそうです。
> 赤伝ってのはかなり安定した業務ロジックだから
> ちょっと例えが悪いかも知れませんね。
変化しやすいものを分離する理由はとはなんでしょう？
- 891 名前：デフォルトの名無しさん mailto:sage [04/12/09 21:14:15]
- >>888
＞＞サービス層がステートレスである必要性はわかるんだが
俺にはその必要性がわからない。
教えてくれ！
- 892 名前：890 mailto:sage [04/12/09 21:26:33]
- >>891
> >>888
> ＞＞サービス層がステートレスである必要性はわかるんだが
> 俺にはその必要性がわからない。
> 教えてくれ！
ステートフルで一度作ってみれ。難しいと思うが。
まぁ、なんちゅうか、リクエスト単位での処理を同期とか
ややこしいこと考えずに作ろうとすると、必然的にステートレスになるわけだ。
StrutsのActionクラスが典型だろう。
ステートフルにしちゃうと、ややこしい同期処理を考えなきゃいけない上に
結果的にサービスオブジェクトのインスタンスを、リクエストの数だけ
生成しなきゃいけなくなるわけだ。
こんなんでよろしい？
- 893 名前：デフォルトの名無しさん mailto:sage [04/12/09 22:19:32]
- サービスオブジェクトのインスタンスを、リクエストの数だけ生成したらいいんじゃない？
- 894 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:31:05]
- >>892
同期処理の問題だけ？
「同期処理とか」
の「とか」の部分について説明して欲しいな。
>>888に
「ValueObjectにすら振る舞いは持たせるだろ、普通。 」
って書いてあるけど、
ValueObjectはリクエストの数だけインスタンス作るからステートフルでもOKということ？
そもそも、くーすって状態に依存しないメソッドを使用すればテストも楽になるし、
他のメソッドなどに依存しないから再利用性も高まるし、
とか他のメリットもあったんじゃなかったっけ？
- 895 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:34:14]
- >>892
振る舞いを持たないDTOっていくらなんでもバカすぎじゃね？
と書きながら
必然的にステートレスになるわけだ。
というところは矛盾してないか？
振る舞いを持ったDTOはステートフルじゃねーのか？
- 896 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:36:22]
- >>894-895
粘着に粘着するなよｗ
- 897 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:51:17]
- >>895
DTOに持たせる振る舞いはテストが面倒でもいいんだよ！
- 898 名前：デフォルトの名無しさん mailto:sage [04/12/09 23:56:31]
- ∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ j
彡､ |∪| | Ｊ >>897。
/ ∩ノ ⊃ ヽ
( ＼ ／ ＿ノ | |
.＼ “ ／＿＿| |
＼ ／＿＿＿ ／
- 899 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:23:47]
- >>896
888は粘着じゃないだろ。
まっとうな質問だと思うけど?
- 900 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:36:16]
- >>894も粘着してるようには思えないがな。
>>895は粘着っぽいけど
- 901 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:50:54]
- >>895も素朴な疑問といえば素朴な疑問だがな
- 902 名前：888 mailto:sage [04/12/10 00:56:21]
- >>893
もちろん、そうしたいならそうすればいいんでないの？
ファサードとして使えるステートレスなサービス層が無いってことで、
ロジックの見通しが悪くなるとか、透過的なトランザクション処理が
やりづらくなっちゃうとかいう可能性はあるわけだけど。
>>894
「とか」の部分って何だろうね。自分で書きながらもよく解ってないかも。ｽﾏｿ
ところでValueObjectの定義はわかってる？
通貨とか税率とかそういう小さな単位のオブジェクトのことだよ？
テストはファサードになってるサービス毎に作ればいいよね。
ま、DTOっちゅうかエンティティに振る舞い持たせたからって、
テストがやりづらくなることは無いんだけど。
「状態に依存するメソッド」の状態の定義が曖昧だな。俺も、もちょっと考えてみる。
>>895
ステートレスなのはサービスで、そのステートレスなサービスがDTOに対して
支持をするわけだ。お前、今から赤伝になれ、みたいな。
同じことをサービスでやるよりは、よっぽど可読性もいいと思うんだけどなぁ。
サービスが何やってるのか一目瞭然だし。
- 903 名前：デフォルトの名無しさん mailto:sage [04/12/10 00:57:34]
- 粘着に見える程度が、ここではまともなのです。
- 904 名前：デフォルトの名無しさん mailto:sage [04/12/10 01:28:15]
- >>888
正直、その問題に対してはくーす関係者は誰もまともに答えてないと思う。
ひが君はそっち方面の思考をすっかり停止しているし、こんの君は撹乱するだけだ。
唯一正面切って答えてるのは↓だと思うが、いまいち。
ttp://d.hatena.ne.jp/koichik/20041022#1098468196
- 905 名前：888 mailto:sage [04/12/10 01:41:48]
- >>>904
確かに難しい問題だとは思うけど、
これから世界に向けて発信して行こうっていうプロジェクトの思想としては、
ちょっとお粗末な気がするんだよ。
俺、１０年以上OOな思考にどっぷり浸かってるから、今更悪夢みたいな
手続き型の世界には戻りたくないっていう意識があるからかも知れんが、
ちょっと...なぁ。
だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
- 906 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:04:06]
- ちょっと振る舞い無し&ステートレス問題からは外れるけど、
そもそもOOな思考がばっちり出来る人ならくーすとかいらないんじゃないかな。
くーすは手続き型どっぷりな人でも、OOの恩恵が受けやすいって話だと
いう事なんじゃないかなーと。
「思想」としては後ろ向きではあるよね。
どっちかというと商売寄りな発想、でも俺はそれでいいと思う。
- 907 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:05:36]
- あ、ごめん、思想がお粗末なんじゃなくて、
きちんと説明しないって事がお粗末なのか。
読み違えました。
- 908 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:20:57]
- >>837
うむ、だからそのgetEntityManager().findObject()を使うには、AbstractDaoのサブクラスを作らないといけない。
AbstractDaoをimplementsした実装クラスを作ると、insertやらgetXXやらのメソッドを実装しなくちゃいけ
なくなるので、今度はSQL自動生成ができなくなる。自動生成したいメソッドもあるけど、findObjectも使いたい、
というジレンマだったわけだ。
インターフェースにメソッド名だけ定義すると、自動的に実装クラスが生成される。でもEntityManagerを
使うには実装クラスを作らないと行けない、と困ってたんだが。
でもS2DaoIntercepterのソースコードを読んで、単に実装クラスの方で、SQL自動生成したいメソッドを
abstractにしとけば問題ないということに気がついた。まだ試してないけど。
- 909 名前：デフォルトの名無しさん mailto:sage [04/12/10 02:21:51]
- >>905
> だれかまともに答えてくれ ⇒Seasar&くーすの中の人達。
「現場」だの「お客様」だのを盾にして逃げる擁護厨が出現して終わりなﾖｶｰﾝ。
- 910 名前：デフォルトの名無しさん mailto:sage [04/12/10 07:10:23]
- >>905
そんなことは、既に答えてる気がする。
www.wikiroom.com/tpircs/?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
量が多くて大変だけど。
- 911 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:15:51]
- >>888
例えば、あるDTOを文字列に変換する必要がある場合を考えてみると、
a) dto.toString()
b) service.convertToString(dto)
のふたつのパターンで悩んでるってことだよね？
a)のメリットはdtoについてカプセル化することができることで、
b)のメリットはAOPなんかをはさめるってこと。
で、どっちがいいのかってのは、実のところ擬似問題なんだよね。
a)はオブジェクトのふるまいに関することで、
b)はシステムのふるまいに関すること。
888は、この両者を混同しているような気がする。
だから、きちんと答えるとすると、
「エンティティ自体にtoDebitNote()を実装してもいいけど、
それを行なう一連の手続きは、きちんとサービス層のオブジェクトの責任にしてね」
って感じになるのかな。
- 912 名前：デフォルトの名無しさん mailto:sage [04/12/10 08:38:13]
- >>908
というより、これまでと同じようにインターフェースを作って、
Daoの実装は、abstract classにして必要なメソッドだけを実装すればOK。
- 913 名前：デフォルトの名無しさん mailto:sage [04/12/10 10:27:34]
- ひが日記を読んで、こりゃやっぱり構造化分析で、
だからくーす（古酒）なんだよなーと思った。
ところで赤伝生成とtoDebitNoteってメソッド名が
どうも結びつかんのでさっぱりイメージが湧かないなー
とか思ってたら、はぶ氏が答えてますね。
- 914 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:26:51]
- OO大好きで啓蒙好きな人は、なぜだか会計に弱い事が多い
以上、極私的な経験則に基づく極端な偏見を述べてみました
- 915 名前：デフォルトの名無しさん mailto:sage [04/12/10 12:59:55]
-
>>はぶ氏
「赤伝になる」ではなく「赤伝にする」です。
ついでにdebitnoteってそのまま「赤伝」のことなんだけど、最近の辞書には
借方票ってのってますな。なんだそれって感じ。
イメージとしては自分自身のインスタンス、またはコピーインスタンスを返すような
メソッドをイメージしてたんだけど、ま、単なる思い付きだったんで例えとしては最悪ですな。
結論には納得です。俺も似たような方向性なので。
>>ひが氏
保守のコストについて語りだすと泥沼になりそうなので(俺が)、一点だけ。
一番危惧しているのは、何でもかんでもサービスオブジェクトに突っ込んでしまって
その結果、肥大したサービスオブジェクトが保守性を下げてしまう事なんだけども、
その辺りはどう考えてるんですか？
適切に分割っていっても、その指針もまた、DTOにどこまで振る舞いを持たせるかっていう
命題と同じで、曖昧になりがちだし、複雑な業務になればなるほど、分割も難しいと思うんだけど。
俺の場合は、サービスオブジェクトの見通しをよくするためにエンティティに振る舞いを
持たせて、基本的にサービスオブジェクトは分割しない方針です。
一つの、一連の業務の流れの中で閉じておきたいと考えるので。
>>911
できれば、もちょっとよく読んでくれ。
一連の手続をサービスオブジェクトの責務とすることは↑で何度かそれとなく言ってる。
- 916 名前：デフォルトの名無しさん mailto:sage [04/12/10 13:05:23]
- >>914
OOは大好きだけど、啓蒙しようって気は無いよ。
寧ろ啓蒙されたいかも。
俺、そんなに偉いポストにいるわけじゃないから、
毎回アーキテクトやれるってわけじゃないし、
最近は人が作ったものを治してばっかりだし、
はぁ..
- 917 名前：913 mailto:sage [04/12/10 13:20:38]
- 赤伝の事をDebitNoteというのかー。知らなかった・・・。
前に海外拠点向けのシステム作ったときは
Revised、Adjustなんて言葉使ってたけど
考えてみればそれは販売側の業務用語だったんだな。
会計用語じゃなかったんだ。勉強になります。
- 918 名前：デフォルトの名無しさん mailto:sage [04/12/10 15:14:35]
- 俺がやった貿易システムじゃ
Debit Note は請求書の事だったけどな。
専門用語英語は難しい。
ひが氏のもわかるし、915のもわかる、
いいとこどりとかバランスって事なんだろうけど
それだとあいまいだしね、難しい。
俺は全部サービスに突っ込んじゃいたいかな。
肥大化しても、サービス分割はしない。
ステップ数大きいクラスが出来たら、すまん、と謝る。
うーん、気持ち悪いな。ダメか。
- 919 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:35:52]
- >>918
なぜ全部サービスに突っ込みたいの?
- 920 名前：デフォルトの名無しさん mailto:sage [04/12/10 17:38:20]
- >>912
なるほどあったまい〜。
ついでに一つ聞いてもいい？
hsqlでIDENTITYとかデフォルト値使う時って、insert/update SQL書かなきゃだめ？
どうもいくらためしてもだめだったんだけど、何か良い方法はあるかな。
|
 |
