- 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/
- 802 名前：デフォルトの名無しさん mailto:sage [04/10/23 21:45:01]
- >>800
これだろうな。
ttp://d.hatena.ne.jp/hyoshiok/20041022
- 803 名前：デフォルトの名無しさん mailto:sage [04/10/23 22:08:24]
- ttp://d.hatena.ne.jp/akon/20041023#p2
こんな未来は嫌だ。
- 804 名前：デフォルトの名無しさん [04/10/23 23:03:29]
- どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
- 805 名前：デフォルトの名無しさん [04/10/23 23:05:49]
- > Stateless BusinessLogicパターンのメリット
> ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617
上記サイトの内容で疑問点がありまして。
ひがさんは
「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」
と仰っています。
ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。
このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
- 806 名前：デフォルトの名無しさん [04/10/23 23:27:38]
- >>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
- 807 名前：785 mailto:sage [04/10/23 23:35:51]
- >>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。
よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。
でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
- 808 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:44:01]
- statelessって「実装に依存しない」って意味なんじゃないですか？
依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。
stateless
【形-1】 国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっか とうち けん｝］のない
【形-2】 《コ》処理状態｛しょり じょうたい｝を把握｛はあく｝しない〜◆【対】stateful
って辞書にあるそのまんまの意味だとばっかり思ってました。
- 809 名前：デフォルトの名無しさん [04/10/23 23:48:50]
- d.hatena.ne.jp/higayasuo/20040805#1091664617
- 810 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:51:34]
- >>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？
> 処理状態｛しょり じょうたい｝を把握｛はあく｝しない
そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
- 811 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:52:33]
- >>808
かなり根本から間違ってるな。State が lessなんだぞ。
- 812 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:57:32]
- >>808
SLSB/SFSBの違いを思い出せ。
- 813 名前：デフォルトの名無しさん mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:09:28]
- >>804
ポインタ希望
- 819 名前：785 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:37]
- だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。
810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。
状態を持たないだと判りにくいか、
状態の変化を管理しない。
S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。
結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
- 822 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:53]
- ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。
この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
- 823 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:50:36]
- ああでもよくわかんねぇ
- 824 名前：デフォルトの名無しさん [04/10/24 00:50:40]
- class File {
static int read(String filename, int position);
}
これは？
- 825 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:52:15]
- なんか俺も混乱してきたのでひがさんきぼんぬ
- 826 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:09]
- ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。
あ、821=823です、
まぎらわしくなっちゃってすみません>822
- 827 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:10]
- >>820
オブジェクトをステートレスにしろって事じゃないの？
下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。
上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
- 828 名前：785 mailto:sage [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 mailto:sage [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 名前：デフォルトの名無しさん mailto:sage [04/10/24 02:51:26]
- ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
- 832 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:14:28]
- ドメインモデル->実世界の構造のウツシミ
- 833 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:17:11]
- 結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
- 834 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:20:59]
- モデリングの本とかで問題領域とかいわれてる部分。
簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
- 835 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:23:09]
- あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
- 836 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:44:42]
- なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
- 837 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:01:43]
- 児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。
釈然としない所もあるけどさー。
- 838 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:08:57]
- > 釈然としない所もあるけどさー。
どういうところ？
- 839 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:19:41]
- 2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。
でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。
こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
- 840 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:30:49]
- >>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。
その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
- 841 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:32:09]
- >>839
マジカの出番かな？
- 842 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:59:47]
- マジカ？
- 843 名前：デフォルトの名無しさん mailto:sage [04/10/24 05:01:25]
- >>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
- 844 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:31:16]
- 結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
- 845 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:48:45]
- Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。
ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。
S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。
>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。
この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
- 846 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:58:45]
- >>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。
- 847 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:00:29]
- >>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。
- 848 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:04:19]
- >>846
俺は>>845じゃないけど
「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した
っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。
- 849 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:11:58]
- ttp://nekop.programmers.jp/diary/?date=20041024
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz
- 850 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:12:46]
- >>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。
- 851 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:18:07]
- >>849
うちの会社の競争相手は中国人 orz..
- 852 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:25:51]
- >>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。
- 853 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:26:46]
- 先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz
- 854 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:47:18]
- >794
>>漏れ的には、迷ったらメンバーで相談する。
これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。
そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。
- 855 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:53:57]
- 段々と下請の悲哀を語るスレと化してきたな
- 856 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:56:26]
- 結局、ソフトウェア開発の本質的で構造的な問題だからな。
- 857 名前：デフォルトの名無しさん [04/10/24 12:09:28]
- 要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。
- 858 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:20:20]
- >>857が投資していいチームを作って漏れをやとってくれYO
- 859 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:29:31]
- 問題は>>858が良いメンバーか、ということだが…
- 860 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:51:24]
- >>857
その投資の原資はどこからもってくれば良いのでしょうか？
- 861 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:57:45]
- 資本金。
- 862 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:09:16]
- >>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁
- 863 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:11:12]
- データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。
- 864 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:12:02]
- >>862
競争力。
- 865 名前：858 mailto:sage [04/10/24 13:13:24]
- >>859
漏れはいいメンバーになるYO
頑張るから入れてください
- 866 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:18:14]
- >>864
わけわからん
- 867 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:20:53]
- >>853
そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…
- 868 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:21:18]
- >>849
> ttp://nekop.programmers.jp/diary/?date=20041024
> これ読んだらEAは俺には縁のない世界だと思った。
ttp://d.hatena.ne.jp/habuakihiro/20041024#1098575922
はぶ氏も似たようなこと言ってる。
- 869 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:24:51]
- >>844
手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。
オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も
オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。
オブジェクト内の手続きを再利用する方法として継承を使うことができるが、
継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する
ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって
しまうためよくない。
これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。
これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように
見えるかもしれないが、そうではない。
ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の
手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する
ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。
従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の
インタフェースをデータ型から抽出することが、ジェネリックプログラミングを
実現する第一歩となる。
- 870 名前：デフォルトの名無しさん [04/10/24 13:41:33]
- >>844
>結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。
- 871 名前：デフォルトの名無しさん [04/10/24 13:48:36]
- >>890
>587
>顧客クラスにパスワード変更メソッド付けるなんてアフォ
つまり、データはハッシュマップなりで適当なもので表現して
（実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして
定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは
よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく）
- 872 名前：デフォルトの名無しさん [04/10/24 13:52:04]
- >>871
データを一番シンプルに扱えるのがハッシュマップである以上、
無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。
型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない
っていう仮説はどうかな。
- 873 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:52:20]
- >869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない
結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。
- 874 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:53:31]
- 「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。
データと処理が分離されたCollection API
ｺﾜｰｲ…。
- 875 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:18]
- ttp://sumim.no-ip.com:8080/wiki/710
視点の違い
- 876 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:32]
- データと処理が分離されたデータベース
- 877 名前：デフォルトの名無しさん [04/10/24 13:58:43]
- >>873
結局メソッドを呼び出すのがＯＯ。
オブジェクト指向の肝はポリモーフィズムで、
それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現
するっていう、ただそれだけ。
- 878 名前：デフォルトの名無しさん [04/10/24 13:59:31]
- >>872
Java5で解決ですが。。
- 879 名前：デフォルトの名無しさん [04/10/24 14:02:18]
- >>878
漏れには解決しているようにはとても見えへんのよ
- 880 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:13:32]
- だれか、>>863について斬ってくれ。
- 881 名前：デフォルトの名無しさん [04/10/24 14:15:50]
- ORマッピングで継承って一体なんなんだ？ 意味不明。
データはデータ。処理は処理だろ？
- 882 名前：デフォルトの名無しさん [04/10/24 14:20:09]
- 処理の切り替えって、やりたきゃやればいいんじゃないの？
- 883 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:36:40]
- >>881
こういうののことでつ。
ttp://objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html
- 884 名前：デフォルトの名無しさん [04/10/24 14:44:58]
- 処理の切り替えが沢山あるなら、
処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)
みたいのを作って
Manager#addHandler(handler)
てなことやると分離できるな。これが適切なときもあるにはあるだろう
- 885 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:54:13]
- >>871
>>872
そんなお前らはDbUtilsでも使ってろ。
まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。
- 886 名前：デフォルトの名無しさん mailto:sage [04/10/24 15:57:59]
- Ruby最高ってことでFA
- 887 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:11:53]
- >>845
「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。
>>884
そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？
- 888 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:13:34]
- >>887
「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。
- 889 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:15:11]
- >>888
だね。最後の方良く読んでなかった。ｽﾏｿ。
- 890 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:16:15]
- >>871
890ゲット！！
データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。
- 891 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:21:15]
- ER図と照らし合わせながらでしか解読できんコードになるぞ。
- 892 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:35:46]
- なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。
間違っていたらご教授願います。
以下 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用
アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。
ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。
ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。
- 893 名前：887 mailto:sage [04/10/24 16:53:26]
- >>892
なんだ、わかってたのね。
つまり、
[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層
[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層
こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。
- 894 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:55:07]
- >>892
> なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。
- 895 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:58:47]
- OO厨なんてこんなもん
- 896 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:32:46]
- と、OOがわからなかったCプログラマーが申しております。
- 897 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:42:11]
- フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。
- 898 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:45:23]
- >>893
>ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。
プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
- 899 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:55:05]
- >>898
> プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。
ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。
- 900 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:58:36]
- ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。
- 901 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:10]
- >>900
StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。
- 902 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:41]
- ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。
分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。
|
 |
