[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:10 / Filesize : 285 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

国産オープンソースDIコンテナSeasar V2(S2)



371 名前:330 [04/10/07 00:25:56]
みんな朝からありがトン
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。

330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者(というより共感者?)
以外は気持ち悪い思いをするよね?ということ。

個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK(小規模な場合しか想像できないが)。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。

というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か?
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。







[ 続きを読む ] / [ 携帯版 ]

全部読む 前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<285KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef