- 1 名前：デフォルトの名無しさん [03/02/16 21:37]
- 実際どっちがええの？なんか同じことできそうだけど。
.netはまだ生まれたてだから
JDK1.1の頃のようにバグだらけなんかな。
実績で言ったらJ2eeかえ？
- 31 名前：デフォルトの名無しさん [03/02/17 02:03]
- >>30
アプリケーションサーバにバグが無ければね。
- 32 名前：デフォルトの名無しさん [03/02/17 02:10]
- >>27
この際ＣＯＲＢＡは関係ないでしょ。
>>23
COM+とEJBが対応する技術って言うのは疑問ですな。
- 33 名前：デフォルトの名無しさん [03/02/17 02:20]
- あとASPとServletが対応するのもちと怖い。
気をつけないとスパゲッティになるんじゃないの？
- 34 名前：デフォルトの名無しさん mailto:sage [03/02/17 02:24]
- ObjectSpacesって、Javaのどのテクノロジと対応するんだろう……？
- 35 名前：デフォルトの名無しさん mailto:sage [03/02/17 02:38]
- JDO
- 36 名前：デフォルトの名無しさん mailto:sage [03/02/17 19:28]
- .NetにはJ2EEのMVCアーキテクチャのようなものがあるのですか?
- 37 名前：デフォルトの名無しさん mailto:sage [03/02/17 19:48]
- J2EEネタを振るのはまずい
- 38 名前：デフォルトの名無しさん [03/02/17 20:55]
- >>NetにはJ2EEのMVCアーキテクチャのようなものがあるのですか?
ありません。詳しくはＮＥＴ版ＰＥＴＳＨＯＰをみてくれ
- 39 名前：デフォルトの名無しさん mailto:sage [03/02/17 21:46]
- >>37
２ｃｈってj2eeネタはウケが悪いけどどうしてよ？
- 40 名前：デフォルトの名無しさん mailto:sage [03/02/17 21:49]
- MVCも可能だが、.NET版で使ったデザイン パターンのほうが優れているし
パフォーマンスも良いと。
www.microsoft.com/japan/msdn/net/compare/petshopfaq.asp
- 41 名前：デフォルトの名無しさん mailto:sage [03/02/17 22:40]
- >>40
と、ゲイツたんは主張しております
- 42 名前：デフォルトの名無しさん mailto:sage [03/02/17 23:18]
- >>39
単なるアホアンチがJ2EEを妬んでいるだけ。
ま、ほっとけ。
このスレはJ2EEと.NetのスレなんだしJ2EEの話しないとね。
- 43 名前：デフォルトの名無しさん mailto:sage [03/02/17 23:30]
- >>39
J2EEネタまじでわからん厨が嫌がってるだけだよ。
他のスレ見りゃ、J2EEの話題なんて普通に流れてるよ。
- 44 名前：デフォルトの名無しさん mailto:sage [03/02/17 23:46]
- プロフェッショナルEJBって本どうよ？
- 45 名前：デフォルトの名無しさん [03/02/18 00:43]
- >>40
拡張性を大幅削減し、JavaPetstoreよりソース量が１／６に縮小。
ストアドプロシジャを使ってパフォーマンスの向上。
.NET版PetShopにはＭＳの必死さが伝わってくるよ。
>>36
MVCモデルに近いものとしては、「ASP.NET Web Solution Guide
〜 Multi UI Web Application 編」ってのが、参考になるんだが、
View部分の充実さと比べると、コントローラ部分が余りにも貧弱。
まだまだこれからの技術といった感は拭えない
- 46 名前：デフォルトの名無しさん mailto:sage [03/02/18 00:45]
- >>45後半
MVCじゃなくDocumentView の会社だからじゃないですか？
- 47 名前：デフォルトの名無しさん [03/02/18 00:46]
- >>44
赤いやつね。
いいよ。コードが満載で具体的だが、ちゃんと網羅すべき点は抑えてある。
- 48 名前：デフォルトの名無しさん mailto:sage [03/02/18 00:47]
- >>44 最近出た本だよね。これからJava厨目指す人にはいい本なんじゃないかな。
＃読んだ方の御意見ぷりーず
- 49 名前：デフォルトの名無しさん [03/02/18 01:45]
- Servlet、JSP、Axisはちょっとは理解したつもりだが
EJBって何なのか、マジわからん。これは何？
昔.NET vs EJBとかいう記事よく見かけたから
てっきりEJBがJavaのWEBサービス技術だと勘違いしたよ
EJBって何？何のやくにたつの？
やたら難しいが・・
- 50 名前：デフォルトの名無しさん [03/02/18 01:53]
- >>49
よく言われてるのは、
トランザクション管理とリモート呼び出しが自動化
（ＥＪＢコンテナがやってくれる）されることだと思う。
逆にこれを使わないとほとんどメリットは無い。
コンポーネント化がうんぬんとか言ってるけど。
実際できんの？って感じです。
実際ＥＪＢを使うのは壁が高すぎるし、めんどくさい。
素直にServlet＋JDBCで十分な気がする。
参照系じゃメモリばっか食って使えないと言う話。
あ、MDBはまたちょっと違うけど。
- 51 名前：デフォルトの名無しさん mailto:sage [03/02/18 02:18]
- ふーん。。EJBってのやっぱりservletの拡張技術って感じと捕らえていいんですかね？
WEBサービスとは何の関係もないですよね？
- 52 名前：デフォルトの名無しさん [03/02/18 02:24]
- >>50
実際に使ったことないからそういうこと言っているんだね。
参照系といっても、データベースの中身を全部持ってくる訳
じゃないんだから、メモリなんて問題になることはそれほど
無い。
むしろ、CPUの方が問題が出てくる。
トランザクションの管理を自動化できるということだけでも
導入する価値はあると思うのだが。
- 53 名前：デフォルトの名無しさん mailto:sage [03/02/18 02:35]
- COM+で何年も前から実現してたことだね。(ﾌﾟ
- 54 名前：デフォルトの名無しさん [03/02/18 02:48]
- >>53
使われなければ意味が無い。
- 55 名前：デフォルトの名無しさん [03/02/18 02:52]
- >>51
ServletとEJBはまた別もんだよ。
Webサービスとは直接関係ないと思う。
WEBサービスはSLSBで実装するらしいと言う話も聞いたことあるけど。
>>52
ごめん。メモリを食うのはEntityBeanの話。
１万件のデータを持ってくるとしたら１万件のEntityBeanインスタンスが
必要になるでしょ。ここまで来るとメモリは無視できないと思うよ。
参照系だけならSLSB＋JDBCで十分でしょう。
完全な最新データが必要って言うなら話は別かもしれないけど。
なんかスレ違いになってきた気もしますが・・・
- 56 名前：デフォルトの名無しさん mailto:sage [03/02/18 02:53]
- COM+のトランザクション・マネージャって、何を使ってるのだろう。
あと、COM+のトランザクション機能って、EJBと同時代の技術じゃなかっただろうか。
- 57 名前：デフォルトの名無しさん [03/02/18 03:24]
- だいたいXML WEBサービスって言う名前がｶｺ悪い。
- 58 名前：デフォルトの名無しさん [03/02/18 03:26]
- XML WEBサービスという名前がｶｺわるい
- 59 名前：デフォルトの名無しさん [03/02/18 07:54]
- やっぱ、ＥＪＢだろ！？
- 60 名前：デフォルトの名無しさん mailto:sage [03/02/18 14:32]
- EJBはソース内に直接SELECT文を無駄に書かなくても良いというのが利点ですね。
- 61 名前：デフォルトの名無しさん mailto:sage [03/02/18 15:18]
- ボーランドが.NETプログラムでEJBを使えるようにするらしいよ。
- 62 名前：デフォルトの名無しさん mailto:sage [03/02/18 23:26]
- ＥＪＢつーかアプ鯖重過ぎ。
- 63 名前：デフォルトの名無しさん [03/02/19 01:06]
- 結局ＷＥＢサービスって、
Ｍ＄が参加したＣＯＲＢＡ見たいなもんだと思ってよろしいか？
- 64 名前：デフォルトの名無しさん mailto:age [03/02/19 01:10]
- >>55
>ごめん。メモリを食うのはEntityBeanの話。
>１万件のデータを持ってくるとしたら１万件のEntityBeanインスタンスが
>必要になるでしょ。
うそつけ。バカ
- 65 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:14]
- >>64
>>55は効率の悪いプログラミングをしていると言うことでよろしいか?
- 66 名前：デフォルトの名無しさん mailto:age [03/02/19 01:20]
- >>65
オブジェクトリファレンスとBeanインスタンスはちがう
- 67 名前：デフォルトの名無しさん [03/02/19 01:22]
- >>64、65
効率悪いも何もEntityBeanはそういうもんだっぺ。
１レコード＝EntityBean１インスタンスに対応するんだったら
１万件HITするFinderメソッド切ったらそのとおりじゃん！
selectメソッドつっても結局複数Columnのデータが必要なら、
結局EntityBeanインスタンスが必要になるんじゃないの？
- 68 名前：デフォルトの名無しさん [03/02/19 01:27]
- 糞アーキテクチャの見本だな。MSはそんな糞の真似しないよ。
- 69 名前：デフォルトの名無しさん [03/02/19 01:32]
- 1レコード=EntityBean1インスタンスにするのは、EJB初心者向け
実装指導の時だけですが…
- 70 名前：デフォルトの名無しさん [03/02/19 01:37]
- >>69
EntityBeanって「1レコード=EntityBean1インスタンス」なんじゃないの？
それ以外に作れんの？
- 71 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:38]
- JNDIってなんなの？
- 72 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:43]
- >>71
登録対象が何でもありのDNSみたいなもん。
- 73 名前：デフォルトの名無しさん [03/02/19 01:45]
- 大規模だと.NET使えない理由を分かりやすく教えれ。
>>71
LDAP
- 74 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:47]
- >>70
CMP2.0 CMR。
- 75 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:48]
- >>73
64bit版CLRがないから。
- 76 名前：デフォルトの名無しさん [03/02/19 01:49]
- >>74
それでも結局インスタンスつくるんじゃないの？
- 77 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:49]
- >>73
NTServerしか使えない。.NETよりもNTServerに問題あり。
- 78 名前：デフォルトの名無しさん [03/02/19 01:55]
- Solaris版は無理だとしても、HP-UX版のCLRってでないんかな？
- 79 名前：デフォルトの名無しさん mailto:sage [03/02/19 01:58]
- SourceForgeでプロジェクトでもあげますか。
Solaris版CLR、Linux版CLR、HP-UX版CLR(できたらSDKも)開発。
- 80 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:01]
- >>79
もう MONO ってプロジェクトがあるって。
といっても途中でさじを投げて Wine っつー Win エミュ使うことになった
らしいが。
- 81 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:03]
- >>80
Blackdownのようにはいきませんか。(あれはあれで不幸でしたが)
MSの仕様が不透明だからですかねえ…
- 82 名前：デフォルトの名無しさん [03/02/19 02:13]
- >>70
結局「１レコード＝１EntityBeanインスタンス」で良いか？
- 83 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:16]
- >>81
コアライブラリの中で Win の API を直接呼んでたらしい
- 84 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:16]
- >>82
PK1つで取ってくるデータの固まり全て＝1レコードということなら、
そうかねえ。
- 85 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:20]
- >>83
ﾜﾗﾀ。
さすがMS。Operaの件といい、思想の変化が全くないですね。
- 86 名前：デフォルトの名無しさん [03/02/19 02:36]
- >>84
ＰＫ１つでとってくるデータの塊って何？
テーブルＡとテーブルＢが１対他の関係だとして、
テーブルＡの１レコード＋テーブルＢの対応する外部キーのＮレコード取得している状態？
テーブルＡ、Ｂに対してEntityBeanをマッピングしたら
インスタンス数 ＝
テーブルＡに対応しているEntityBeanインスタンス×１
テーブルＢに対応しているEntityBeanインスタンス×Ｎ
でしょ。
塊すべて１レコードとは違うでしょ？
結局「１レコード＝１EntityBeanインスタンス」では無いの？
- 87 名前：デフォルトの名無しさん [03/02/19 02:38]
- 間違えた
１対他 → １対Ｎ
です。
- 88 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:44]
- >>86
どちらの実装も可能なのではないのかね。
- 89 名前：デフォルトの名無しさん [03/02/19 02:45]
- >>67-68
効率よくする方法自分で考えて自作しろよ。
ある情報、検索するにあたって検索エンジンで1万件ヒットすることがわかっていたとして
検索を1万件のデータをその場ですべてアップロードするような馬鹿な設計をするか?
Googleでも検索結果が10000件になったとしてもそれらすべてを
一つのページに表示するという馬鹿なことをするか?
１0〜100件程度ずつ表示するだろ。
自動絞込み検索アルゴリズムを作ってBeanを分割統治することくらい考えろよ。
それにこの情報がもし画像だとしたらその実体をいちいちBeanの中にいれるアフォなことするか?
参照だけを入れて容量を節約するだろ。
それに一度取り出したBeanをブラウザに表示させるときも、
表示しない部分のBeanはいつまでもメモリ上に保持するなんて馬鹿なことするか?
使わなくなったオブジェクトにはnullを入れるか破棄するのが常識だろ。
それでも足りないなら圧縮できるなら圧縮し直列化して一時保存かさらにDBに保存するとかView表を作るとか考えろよ。
>>68もAPIのせいにしないでアルゴリズムと設計方法を考え直すくらいのことしろよ。
- 90 名前：デフォルトの名無しさん [03/02/19 02:48]
- >>88
どちらの実装もってどれとどれを指してるですか？
スマソ。
結局おいらが言いたいことは
どう実装しようがEntityBean使ったら、
「１レコード＝１EntityBeanインスタンス」になるでしょということです。
なんか思いっきりすれ違いでうざいかな？
- 91 名前：デフォルトの名無しさん mailto:sage [03/02/19 02:48]
- >>89
設計知らない派遣コーダーにそんな話しても無駄
- 92 名前：90 [03/02/19 02:51]
- >>89
言ってることはごもっともだけど、
おいらが言いたいことは設計うんぬんの話ではなくて
EntityBean使ったら、 取得したレコード分「EntityBeanインスタンス」が作られるっちゅー話です。
分かりづらくて申し訳ない。
- 93 名前：デフォルトの名無しさん [03/02/19 03:06]
- >>89
結局はEntityBeanは大量なデータを扱うのには不向きであるという
ことだ。
EJBのもともとの発想はパフォーマンスよりも、いかに分かり易い
プログラムにするかということだから仕方ない。
- 94 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:06]
- 思いっきりスレが伸びてると思ったら・・・
>>90 質問の続きは、「EJB(初心者歓迎)」でどうぞ
pc2.2ch.net/test/read.cgi/tech/1017240849/
- 95 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:11]
- >>93
おい、それで>>89の言いたいことを理解したつもりか?
EntityBeanが大量のデータを扱うには不向きだからといってEJB
を否定するか?
効率的なクエリーの設計にも気を配らない香具師には向いていないだろう。
一つのインスタンスを複数のインスタンスに分割統治する方法も知らないか、使わない者にも不向きだろうな。
- 96 名前：デフォルトの名無しさん [03/02/19 03:11]
- あるところでは有名な丸山某教授のセミナー資料に
「J2EEはプラットフォームを選ばない → でも(開発)言語はJava」
「.NETは(開発)言語を選ばない → でもOSはWindows」
とあった。
結構本質ついた説明かも。
- 97 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:21]
- .NETは言語もプラットフォームも選びません。
- 98 名前：93 [03/02/19 03:22]
- >>95
否定はしていないよ。
ただ、向き不向きがあるということだ。
その言語の長所を理解して使っていこうということだよ。
- 99 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:25]
- >>67
最低線で
「1レコード＝１ValueObject」 (EntityBeanでなく単なるオブジェクト)
ちょっと工夫すると
「Nレコード＝1ValuesObject」
- 100 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:25]
- >>95
世の中には、リモートのEJBの1属性のget/setを鬼のように呼びまくって
挙句の果てに遅いのをAPｻﾊﾞのせいにするアホが大勢いますからねえ･･･
ええ、うちの会社にもいますよ…
そんでもって、J2EEもどきを自分で作ってますよ…
もうアホかと、馬鹿かと(以下略
- 101 名前：デフォルトの名無しさん [03/02/19 03:26]
- たとえばCMP Beanとか使ったら間違いなく
問い合わせの結果セットの１レコード = Beanの1インスタンス
になっちゃいます。
イメージ的にバックエンドのDBのサブセット的な
「データベース」になります。だからLOBデータなんて
持たせたら大変です。
まあEntityBeanを使うだけがEJBじゃないんで、
別にSessionBeanからJDBC生で実行したって
かまわないですし。性能用件が重要であれば、
そのような開発も選択すべき。
イメージ的にEntityBeanならOLTPぽいもの、
意思決定支援やらBI/DWHやらバッチ的なこと
するならJDBCゴリゴリ、ビジネスロジックだけ
SessionBeanみたいな「いまのところはそういう選択」
になるかな。
ただ、このあとどのような新仕様がJ2EE/EJBに
出現するかどうかだけど。
- 102 名前：デフォルトの名無しさん [03/02/19 03:29]
- > 97
M$がWin以外のサーバプラットフォームと開発環境一式を
リファレンス実装でもいいから提供するなら信用しますが？
- 103 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:29]
- まあ、>>67は「J2EEパターン」でも読みなさい、ってこった。
- 104 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:30]
- >>101
ただのJavaクラスのこと、Beanて呼んでる？
ならおっけ。
あと、View + Stored Procedure + JDBC バリバリの開発は、あんま興味ないな(単なる本音
- 105 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:31]
- >>97
> .NETは言語もプラットフォームも選びません。
うそつけｳﾞｫｹﾅｽが。
Javaですら完全に実現していないものを.Netが実現できるわけねーだろｳﾞｫｹ
- 106 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:33]
- >>104
プロジェクトの規模によっては、それもありですな。
高いAPｻﾊﾞ使ってEJBするのはオーバーヘッドがでかいだけで
イミガナイ、にもかかわらずEJBしているプロジェクトって
のもあるのかねえ。
- 107 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:35]
-
Oracle の BC4J とかどうよ？
- 108 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:36]
- >>106
つまり、EJB否定派って感じですか (にこにこ
- 109 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:37]
- パターンとかそんなもんいちいち勉強しなければならないからJ2EEは普及しないんだYO！
VB.NETﾏﾝｾｰ
- 110 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:39]
- >>109
プラットホームが変わろうとも、J2EEパターンと同類の留意事項
を気にしなければ、分散アプリケーションはマトモに作れません。
銀の弾丸を信じるアホはイッテヨシ。
- 111 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:43]
- >>108
プロジェクトが成功する手法をとりましょう、というだけの話しだが。
VBでやるのが適切な仕事なら、VB使いますよ。嫌だけど。
- 112 名前：63 [03/02/19 03:43]
- >>103
読んでるっつーの！
だから設計の話をしてるんじゃないんだってば。
EJBでのプロジェクトはやってないけど、
EntityBeanのメリットって更新系にあると思う。
だからおいらは参照系にはEntityBeanは使わず、
SLSB＋DAO＋VO（EJBデザインパターンではDTO）でやるでしょう。
- 113 名前：デフォルトの名無しさん [03/02/19 03:44]
- > 107
BC4Jは一応フレームワークの部類だけど、
データを扱う「普通の」BeanをDBとO-Rマッピングして
JSP/Servletで扱うイメージ。
EJB対応するには、そのBeanをうにゃうにゃする
感じ(ここはセミナーの説明を聞いただけで実際に検証
してないので怪しい)
- 114 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:45]
- 要はJ2EEに失敗を認めたのがJ2EEパターンだろ？
こうしないとまともなものは作れませんよ、と。
- 115 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:45]
- DB 設計と同じく、EJB 設計にもいろいろと宗教があることがわかりますた
- 116 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:46]
- >>114
言い様だね ﾜﾛﾀ
- 117 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:46]
- >>114
J2EEパターンはGoFなどのデザインパターンに似てる?
- 118 名前：63 [03/02/19 03:47]
- まあ、良きしろ悪きにしろ
J2EE → 選択肢が多い
.NET → 選択肢が無い
って感じではないでしょうか？
.NETはフレームワークの選択の余地も無いでしょ？
- 119 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:47]
- >>109
はぁ? VB.NETだぁ? C#じゃねぇのか?
.NETがJ2EEより普及していないことも知らんのか。
継承できるVB.NET使えんならパターンくらい覚えろや。
継承できないVBしか使い慣れてないからJ2EEを妬みたいのか?
- 120 名前：デフォルトの名無しさん [03/02/19 03:48]
- > 111
そう、トータルで検討しましょうということ。
ただ、事情によってEJBでよろしく！といってくる
依頼元があるかぎり、場合によってはデスマーチに
なったりするのです。それがよくお見受けする
営業と開発部隊の確執になったりするのです。
- 121 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:48]
- .NETパターンなるものは存在しないね。
フレームワークが完璧だから余計なパターンなど必要ない。
- 122 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:50]
- >>121
そのフレームワークもWin32 APIみたいなもんじゃ使い物にﾅﾗﾈ
- 123 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:50]
- >>114
元を正せば、ネット越しのTCP/IP送受信は遅いという、アプリ側ではどう
にもならないボトルネックが存在する状況で、少しでも早いシステムを作
る為のﾎｳﾎｳ論としては、ああいったパターンが必要になるのは当然の話し
だと思うが。
分散システムを作ったことがある奴なら、そういう発言にはならんと思う
なあ(ﾆﾔﾆﾔ
- 124 名前：63 [03/02/19 03:50]
- >>117
パターンは良く３つあると言われてます。
デザインパターン
アナリシスパターン
アーキテクチャパターン
GoF→デザインパターン
J2EEパターン→アーキテクチャパターン
他にもアンチパターンとかありますが。
- 125 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:51]
- >>117
似てないよ。ボトルネック回避のための苦肉の策なので、OO的には
全く綺麗ではありません。
- 126 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:51]
- >>124
アナリシスパターンってどういうの?
- 127 名前：デフォルトの名無しさん [03/02/19 03:52]
- sagatoku.fc2web.com/
あなたの探し物こちらで見つかります
- 128 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:52]
- 要はCOM+でとっくに確立してた手法をアホJava厨が仰々しく「パターン」とか名付けたんだろ？
- 129 名前：117 mailto:sage [03/02/19 03:53]
- >>126
さすがにそういうのはネットで調べた方が早いと思う...。
- 130 名前：63 [03/02/19 03:54]
- >>126
簡単に言うと
デザインパターン → 設計パターン
アナリシスパターン → 分析パターン
アーキテクチャパターン → その名のとおり
詳細は有名な人が書いた「アナリシスパターン」と言う本をみてくだされ。
おいらは読んでないです。
- 131 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:55]
- >>128
COM+? あんな糞APIの塊が確立だぁ?
アホ.NET厨のお前はJavaを妬んでM$製品に依存してるだけだろ
|
 |
