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

国産オープンソースDI ..

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にすべきだと思います。

この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。

846:デフォルトの名無しさん
04/10/24 10:58:45
>>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。

847:デフォルトの名無しさん
04/10/24 11:00:29
>>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。

848:デフォルトの名無しさん
04/10/24 11:04:19
>>846
俺は>>845じゃないけど

「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した

っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。

849:デフォルトの名無しさん
04/10/24 11:11:58
URLﾘﾝｸ(nekop.programmers.jp)
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz

850:デフォルトの名無しさん
04/10/24 11:12:46
>>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。

851:デフォルトの名無しさん
04/10/24 11:18:07
>>849
うちの会社の競争相手は中国人 orz..

852:デフォルトの名無しさん
04/10/24 11:25:51
>>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。

853:デフォルトの名無しさん
04/10/24 11:26:46
先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz

854:デフォルトの名無しさん
04/10/24 11:47:18
>794

>>漏れ的には、迷ったらメンバーで相談する。

これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。

そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。

855:デフォルトの名無しさん
04/10/24 11:53:57
段々と下請の悲哀を語るスレと化してきたな

856:デフォルトの名無しさん
04/10/24 11:56:26
結局、ソフトウェア開発の本質的で構造的な問題だからな。

857:デフォルトの名無しさん
04/10/24 12:09:28
要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。

858:デフォルトの名無しさん
04/10/24 12:20:20
>>857が投資していいチームを作って漏れをやとってくれYO

859:デフォルトの名無しさん
04/10/24 12:29:31
問題は>>858が良いメンバーか、ということだが…

860:デフォルトの名無しさん
04/10/24 12:51:24
>>857
その投資の原資はどこからもってくれば良いのでしょうか？

861:デフォルトの名無しさん
04/10/24 12:57:45
資本金。

862:デフォルトの名無しさん
04/10/24 13:09:16
>>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁

863:デフォルトの名無しさん
04/10/24 13:11:12
データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。

864:デフォルトの名無しさん
04/10/24 13:12:02
>>862
競争力。

865:858
04/10/24 13:13:24
>>859
漏れはいいメンバーになるYO
頑張るから入れてください

866:デフォルトの名無しさん
04/10/24 13:18:14
>>864
わけわからん

867:デフォルトの名無しさん
04/10/24 13:20:53
>>853
そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…

868:デフォルトの名無しさん
04/10/24 13:21:18
>>849
> URLﾘﾝｸ(nekop.programmers.jp)
> これ読んだらEAは俺には縁のない世界だと思った。

URLﾘﾝｸ(d.hatena.ne.jp)

はぶ氏も似たようなこと言ってる。

869:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/24 13:52:20
>869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない

結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。

874:デフォルトの名無しさん
04/10/24 13:53:31
「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。

データと処理が分離されたCollection API

ｺﾜｰｲ…。

875:デフォルトの名無しさん
04/10/24 13:56:18
URLﾘﾝｸ(sumim.no-ip.com:8080)

視点の違い

876:デフォルトの名無しさん
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:デフォルトの名無しさん
04/10/24 14:13:32
だれか、>>863について斬ってくれ。

881:デフォルトの名無しさん
04/10/24 14:15:50
ORマッピングで継承って一体なんなんだ？　意味不明。
データはデータ。処理は処理だろ？

882:デフォルトの名無しさん
04/10/24 14:20:09
処理の切り替えって、やりたきゃやればいいんじゃないの？

883:デフォルトの名無しさん
04/10/24 14:36:40
>>881
こういうののことでつ。
URLﾘﾝｸ(objectstyle.org)

884:デフォルトの名無しさん
04/10/24 14:44:58
処理の切り替えが沢山あるなら、

処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)

みたいのを作って

Manager#addHandler(handler)

てなことやると分離できるな。これが適切なときもあるにはあるだろう

885:デフォルトの名無しさん
04/10/24 14:54:13
>>871
>>872

そんなお前らはDbUtilsでも使ってろ。

まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。

886:デフォルトの名無しさん
04/10/24 15:57:59
Ruby最高ってことでFA

887:デフォルトの名無しさん
04/10/24 16:11:53
>>845
「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。

>>884
そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？

888:デフォルトの名無しさん
04/10/24 16:13:34
>>887
「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。

889:デフォルトの名無しさん
04/10/24 16:15:11
>>888
だね。最後の方良く読んでなかった。ｽﾏｿ。

890:デフォルトの名無しさん
04/10/24 16:16:15
>>871

890ゲット！！

データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。

891:デフォルトの名無しさん
04/10/24 16:21:15
ER図と照らし合わせながらでしか解読できんコードになるぞ。

892:デフォルトの名無しさん
04/10/24 16:35:46
なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。

間違っていたらご教授願います。
以下 URLﾘﾝｸ(capsctrl.que.jp) より引用

アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。

ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。

ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。

893:887
04/10/24 16:53:26
>>892
なんだ、わかってたのね。

つまり、

[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層

[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層

こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。

894:デフォルトの名無しさん
04/10/24 16:55:07
>>892
> なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。

895:デフォルトの名無しさん
04/10/24 16:58:47
OO厨なんてこんなもん

896:デフォルトの名無しさん
04/10/24 17:32:46
と、OOがわからなかったCプログラマーが申しております。

897:デフォルトの名無しさん
04/10/24 17:42:11
フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。

898:デフォルトの名無しさん
04/10/24 17:45:23
>>893
>ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。

プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

899:デフォルトの名無しさん
04/10/24 17:55:05
>>898
> プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。

ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。

900:デフォルトの名無しさん
04/10/24 17:58:36
ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。

901:デフォルトの名無しさん
04/10/24 18:03:10
>>900
StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。

902:デフォルトの名無しさん
04/10/24 18:03:41
ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。

分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。

903:910
04/10/24 18:12:38
説明が悪いのかな。
900氏の言うように「普通にデザインしてたら」、
StrutsのActionなどに提供される業務ロジックインターフェースの
メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。
でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？
多くないならいきなりActionから業務ロジックのインターフェースで提供されてる
メソッド呼び出すほうが素直じゃないの？って思ったんですよ。

904:デフォルトの名無しさん
04/10/24 18:13:33
>>869
それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。

905:デフォルトの名無しさん
04/10/24 18:18:01
>>903
必要ないでしょ。ケースバイケース。

906:デフォルトの名無しさん
04/10/24 18:28:51
かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。

あるプロジェクトでは、人に業務機能を割りあてました。
データベース設計はある一人が担当し、
他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、ある程度のレベルまで上昇しました。
メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。

あるプロジェクトでは、人にシステムの機能を割りあてました。
データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。
メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。

誰が幸せなのでしょう。

907:デフォルトの名無しさん
04/10/24 19:22:17
>>906
> 誰が幸せなのでしょう。
俺俺！

908:デフォルトの名無しさん
04/10/24 19:25:02
綺麗な設計を手に入れたお客さん。

909:デフォルトの名無しさん
04/10/24 19:34:41
>>897
S2で作れ！期待してます！

910:デフォルトの名無しさん
04/10/24 20:12:08
>>909
その前にくーすで設計だろ？

911:デフォルトの名無しさん
04/10/24 20:32:39
そうこうしている間に.Netが主流に。

912:デフォルトの名無しさん
04/10/24 21:01:43
Ruby.netが最強だと。

913:デフォルトの名無しさん
04/10/24 21:05:27
薄いサービス層 ⇒ ドメインモデル
とか
薄いサービス層 ⇒ リッチな業務ロジックモデル

これ、何いうてるんですかね。
どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、
この２つを分ける理由は謎。

914:デフォルトの名無しさん
04/10/24 21:09:50
>>913
...これまでの流れ、分かってます？

915:デフォルトの名無しさん
04/10/24 21:21:37
Ruby最強・・・かな？

916:デフォルトの名無しさん
04/10/24 21:21:50
正直、ドメインモデル　リッチな業務ロジックモデル

の違いも分からん

藻前ら難しく考えすぎだ

917:デフォルトの名無しさん
04/10/24 21:41:30
>> 916
お前は、きっちり分割されたシステムの一部を仕様通りに
月１５万でコーディングすればいいだけだから、気にするな。

918:デフォルトの名無しさん
04/10/24 21:56:07
>>917
月１５万でコーディングしてくれるの？
だったらうちで働いてよ。

919:デフォルトの名無しさん
04/10/24 21:58:55
2人日の価格で1人月か。お徳だ。うちにぜひこないか

920:デフォルトの名無しさん
04/10/24 22:14:18
うほっ！

か　か　な　い　か　？

921:デフォルトの名無しさん
04/10/24 22:16:11
>>919
あんたのところ高すぎ。
コーダーで月１５０万かよ！

うちの倍とってるじゃん。。。

922:デフォルトの名無しさん
04/10/24 22:16:47
じゃあRubyのDIコンテナに期待しよう
あるのかな

923:デフォルトの名無しさん
04/10/24 22:33:31
そろそろ新スレ立ててもいいんでない?

924:デフォルトの名無しさん
04/10/24 22:38:28
今の流れだと、次スレは必要なさそう。

925:デフォルトの名無しさん
04/10/24 22:39:14
盛り上がっているところに水を指すのは申し訳ないが
正直S2ネタが殆どないのにS2の名前で新スレ立てる
意味がないような気ガス。どう見ても単なるOOネタ。
こっちのスレのほうが適している気がする

【OO?】オブジェクトオリエンテッド総合【非OO？】
ｽﾚﾘﾝｸ(tech板)l50

926:デフォルトの名無しさん
04/10/24 22:45:08
そうだな。
PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？
S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ

927:デフォルトの名無しさん
04/10/24 22:52:43
>>917
>お前は、きっちり分割されたシステムの一部を仕様通り

そんなシステムあるわけないだろボーケー

928:デフォルトの名無しさん
04/10/24 23:02:45
>> 927
まず日本語から勉強しましょうね～。

929:805
04/10/24 23:05:07
>Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、
>実は間違ってますね。m(_ _)m
>ここでいっている依存関係とは、呼び出し順序の依存関係です。
>
>状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。
>しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、
>MbはMaに依存しているということになります。

Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。

Maの呼び出しによって、ステートS => ステートSa となるとして、
Mbが当てにしているのは「事前のMaの呼び出し」ではなくて
「Ma呼び出しによってセットされるステートSa」なんじゃないかな?

よって、ステートSを外に出したところで MbがステートSaを前提にしていることには
なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。

930:805
04/10/24 23:06:15
>>929

ごめん、ソースは
URLﾘﾝｸ(d.hatena.ne.jp)
ね。

931:デフォルトの名無しさん
04/10/24 23:13:31
OOネタはS2というかくーすから転がっていって
ひがさんのブログでの反応とあいまって
こうなったんで、このままここでいいよ。

932:デフォルトの名無しさん
04/10/24 23:16:36
普通はスレ違いなんだがな。
このスレには優しい人が多いということか。

933:デフォルトの名無しさん
04/10/24 23:19:16
このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。
そうすれば、今までのこともスレ違いではなくなる。

934:デフォルトの名無しさん
04/10/24 23:20:03
ダサッ！

935:デフォルトの名無しさん
04/10/24 23:46:17
>>929
　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
したりできて便利になるような気がするんだけど。

もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な
ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが
必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう
可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。

936:デフォルトの名無しさん
04/10/24 23:53:55
比嘉氏はStateはPresentation層に持つって言ってるので>>935は同じ事を言ってる気がするのだが

937:デフォルトの名無しさん
04/10/25 00:00:23
>>933-934
「S2のソナタ」にでもしておけばよかろう
正直漏れは次スレいらん気がしてるが

938:デフォルトの名無しさん
04/10/25 00:03:48
>933
人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて
開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて
じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。

>936
Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら
Presentation層で保持するのでやり易いだろう。
HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど

939:デフォルトの名無しさん
04/10/25 00:13:28
>> 938
そこでS2JSFですよ。

940:デフォルトの名無しさん
04/10/25 00:15:06
>938
おれ今までsessionとかrequestってプレゼン側領域だと思って
状態の管理にも使ってたんだけど、世間じゃ違うのかな。
小細工ってどんなの？

941:デフォルトの名無しさん
04/10/25 00:19:59
OOPの話がしたければ、それなりのスレへ。
新しい別のスレをたてる必要はない。
そこではSeasarの話はスレ違いだがね。
Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。

942:デフォルトの名無しさん
04/10/25 00:25:20
禿同
長文多いしage多いしスレ違い多いし
ハッキリ言ってウザイ

943:805
04/10/25 00:26:53
>>935
> >>929
> 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
> ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
> したりできて便利になるような気がするんだけど。

ドメインロジックを含んだクラスをステートレスにすると、
SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの
テクニックの大半が使えなくなります。
# 数少ない経験に基づいてるので嘘かもしれませんが。

そんな強烈なデメリットを負ってまでステートレスにして得られるものが、
「サービスオブジェクトのプーリング」というのは、
*個人的には*、割に合わないと感じています。

# もちろん、必然性のあるステートレス化には賛成ですが。

944:デフォルトの名無しさん
04/10/25 00:29:27
「ダイコン時代のスレ」でいいんじゃない？

945:デフォルトの名無しさん
04/10/25 00:34:31
もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。
アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。
もう漏れは飽きた。寝る。

946:デフォルトの名無しさん
04/10/25 00:35:59
seasarの話、くーすの話、OOの話、業務の話、
全てはひが様のもとへ、じゃ。
よってこのまま続行。

つか、ここの住人が杓子定規なスレタイ重視によって
分散してしまうのは、しじょーにもったいなく思いまーす。

947:デフォルトの名無しさん
04/10/25 00:38:14
では違うところに集うが良かろう。
でなければまずはsage進行で頼む。

948:デフォルトの名無しさん
04/10/25 00:48:11
>943
Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。
勿論、仕方無しにPresentationの役割と思ってやってるんだけど

>941、942
見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？
大半の香具師はアンチうざいのでsage進行だと思うしさあ。
とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。

>944、946
禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。
J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。
あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので
宗教論争ならくだらん。

949:デフォルトの名無しさん
04/10/25 00:59:23
しょっちゅうageてるじゃねえか。
上にくりゃ見えちまうだろうが。
sageくらい覚えろよ。
あと変なポインタ振るな。
長々書き込むな。
正直このスレの住人ウザイ。
2ちゃんにくんな。

950:デフォルトの名無しさん
04/10/25 01:10:48
J2EEに疲れてませんか、ではくーすの話はスレ違いだね。

951:デフォルトの名無しさん
04/10/25 01:29:23
>>949
N速にでも逝って２ちゃんらしさを存分に味わっとけ。
次スレはsage進行でマターリと語りたいね。

952:デフォルトの名無しさん
04/10/25 01:30:13
>>945みたいなアゲにげするやつがいるからねぇ。

953:デフォルトの名無しさん
04/10/25 01:32:45
じゃ、次はS2JSFでてからってことで解散。

954:デフォルトの名無しさん
04/10/25 01:33:08
分析から実装まで
開発を見つめるDICON

955:デフォルトの名無しさん
04/10/25 02:17:15
もはや広告が撲滅された以上、sageと入れるのは馬鹿。
そもそも同人板のヲタ女達が始めた風習だし。

956:デフォルトの名無しさん
04/10/25 02:24:08
風習の起源とか目的とか、どうでもいいだろうが。
いまそういう風習なんだから。

957:デフォルトの名無しさん
04/10/25 02:38:26
Stateless化することで見込まれているメリットの肝は、実は分業の徹底では
ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、
かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して
しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。

そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって
しまうのが悲しい現状だ。

そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。

958:デフォルトの名無しさん
04/10/25 08:06:05
次スレ立てるんなら>>1はガイドラインよろ
sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな
せっかくいい感じになってきたのでﾀﾉﾑ

959:デフォルトの名無しさん
04/10/25 11:28:42
>>957

ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い

960:デフォルトの名無しさん
04/10/26 00:49:26
このままのスレでいいじゃん。

961:デフォルトの名無しさん
04/10/26 01:14:57
スレタイに「くーす」要追加。

962:デフォルトの名無しさん
04/10/27 05:30:18
AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？

963:デフォルトの名無しさん
04/10/27 17:20:16
次スレはS2JSFが完成してからだね。

964:デフォルトの名無しさん
04/10/27 20:13:24
関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。
S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。

965:デフォルトの名無しさん
04/10/27 20:15:46
最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。

966:デフォルトの名無しさん
04/10/27 20:57:39
>>964
なんでかっこわるいの？

967:デフォルトの名無しさん
04/10/27 22:00:22
ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。

968:デフォルトの名無しさん
04/10/27 22:11:17
>>967
それがかっこわるい理由か？

969:デフォルトの名無しさん
04/10/27 22:59:04
>>967
RFC&W3Cﾏﾝｾｰなんだね。

IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは
文字化けする場合があるバグありバージョンがある。
客に文字化けするんだがって言われたらブラウザのバグですって言うの？

まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって
なると思うけど。

970:デフォルトの名無しさん
04/10/27 23:13:06
次スレ立てました。

国産DIコンテナSeaserとくーすその2
ｽﾚﾘﾝｸ(tech板)

971:デフォルトの名無しさん
04/10/28 01:05:52
技術屋がかっこつけようとすると
お客さんの価値観とは合わなくなる事が多く思いますが
よい例でしょうかね。

俺も出来る事なら存分にかっこつけてみたいわ。

972:デフォルトの名無しさん
04/10/28 02:20:21
969が正解でしたね。

ひがさんてば、こんな事にまで答えてくれるとは・・・・。

973:デフォルトの名無しさん
04/10/29 00:38:27
>>972
俺は >>571 です。
ここはエセ技術屋が多いインターネッツですね。
うんこばかりだな。

974:デフォルトの名無しさん
04/10/29 01:42:43
はいはい
あなたみたいにみんなから尊敬される素晴らしい技
術屋さんには見るもの全てがうんこにしか見えない
んだろうからここに来なくてもいいよ

975:デフォルトの名無しさん
04/10/29 01:53:25
エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁

976:デフォルトの名無しさん
04/10/29 01:59:02
お，半角SPACEたんｷﾀｰ(AA略)
相変わらずの粘着ぶりでつね！

977:デフォルトの名無しさん
04/10/29 02:00:22
metaタグうんぬん言ってた人が
571ってこと？

まあmetaタグがどうのってこだわりがあって
そういうのが技術力だって価値観も確かにアリだと思うけど
そういう価値観の人ならseasarもくーすも要らないんじゃないかな。

978:デフォルトの名無しさん
04/10/29 02:15:26
571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ
ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ
要するに 571 たんはひがたんのうんこが食べたいのでつ
頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ

979:デフォルトの名無しさん
04/10/29 23:50:16
ひがさんはいつ仕事してるんだろうか

980:デフォルトの名無しさん
04/10/30 17:02:00
タペのサンプルの動かし方がわからん。

981:デフォルトの名無しさん
04/10/31 13:23:24
顧客満足＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞W3C,RFC

982:デフォルトの名無しさん
04/10/31 17:26:28
長期間の動作保障＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞クイックハック

983:デフォルトの名無しさん
04/10/31 21:52:57
ベンダの短期的な思惑＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞長期間の動作保障

984:デフォルトの名無しさん
04/10/31 23:28:25
長期の動作保証とクリックハックは往々にして両立する罠
例えば、metaタグでcontent-type入れるのとか。

985:デフォルトの名無しさん
04/10/31 23:31:04
×リ
○ィ

986:デフォルトの名無しさん
04/11/01 23:58:53
ちゃんとスレ埋め立てようぜ
次スレばっかり伸びてるじゃねえか

987:デフォルトの名無しさん
04/11/02 00:52:51
いっそ次スレのほうが先に埋まるのを見届けるとか

988:デフォルトの名無しさん
04/11/02 05:42:06
980も超えてるし、そのうち勝手に落ちるよ。

989:デフォルトの名無しさん
04/11/02 14:09:12
せっかくだからしりとりでもしようぜ。まずは俺からな。

シーサー

次！

990:デフォルトの名無しさん
04/11/02 14:27:24
サッシ

991:デフォルトの名無しさん
04/11/02 14:47:24
示唆

992:デフォルトの名無しさん
04/11/02 14:55:37
サラシ

993:デフォルトの名無しさん
04/11/02 14:57:10
シーサー

994:デフォルトの名無しさん
04/11/02 15:01:49
>>993
サナダムシ

995:デフォルトの名無しさん
04/11/02 15:51:14
視差

996:デフォルトの名無しさん
04/11/02 15:55:14
桟橋

997:デフォルトの名無しさん
04/11/02 17:14:19
審査

998:デフォルトの名無しさん
04/11/02 17:18:16
酒蒸し

999:デフォルトの名無しさん
04/11/02 17:23:44
しにせ

1000:デフォルトの名無しさん
04/11/02 17:24:23
せん

1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。