- 1 名前：デフォルトの名無しさん [03/02/16 21:37]
- 実際どっちがええの？なんか同じことできそうだけど。
.netはまだ生まれたてだから
JDK1.1の頃のようにバグだらけなんかな。
実績で言ったらJ2eeかえ？
- 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$製品に依存してるだけだろ
- 132 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:56]
- EJBは所詮1998年のMTSレベルのアーキテクチャだしね。
- 133 名前：デフォルトの名無しさん [03/02/19 03:56]
- 大体ASPでWebアプリ作るとスパゲッティになってメンテしにくいだろ
- 134 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:57]
- >>113
BC4Jって、Swingとか使ったファット・クライアントで、
画面操作に連動したDB参照/更新を、
SQL書かずに自動化したり、RADツールで自動生成するための
フレームワークだと思った。
ORマッピングの出来は良さそうなんで、
EJBっぽい応用を試してみた人はいないのかな？
＃パフォーマンス悪そうだけど
- 135 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:57]
- >>133
ASP.NETですべて解決しました。
- 136 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:57]
- で、最近あった .NET の案件はどんなんよ?
- 137 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:58]
- >>128
J2EEパターンなる名前がついているのは、作ったのがSunの社員だからな(ﾜﾗ
MSがつくってたらDCOMパターンだったかモナ〜。
個人的には、分散システム構造パターンとか、そんな感じの汎用的な名前で
こういうのがあるといいと思うけど。この名前だと、J2EE専用だと勘違いし
てまうよね。
- 138 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:58]
- J2EEもVB.NETに追い抜かされて大変だな
- 139 名前：デフォルトの名無しさん mailto:sage [03/02/19 03:59]
- >>132
EJB1.0 (1998) ＝ MTS
- 140 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:00]
- >>135
アフォ、全然解決してねーだろ。
コントローラも腐ってビューだけ便利そうなおもちゃか?
- 141 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:00]
- EJBってCOM+と同じことをどうしてもSolarisでも実現したかったから無理矢理作ったんだよね？
- 142 名前：63 [03/02/19 04:01]
- 誰か>>63にも意見をﾖﾛｼｸ
- 143 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:01]
- >>138 残念ながらあなたが妄想しているVB.NETにはJ2EEを追い抜く機能は全然ありません。
- 144 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:02]
- >>136 チビ企業限定
- 145 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:02]
- >>141
COM+って、CORBA＋分散トランザクション を、
MSの専売特許という形でどうしても実現したかったから、無理矢理作ったんだよね？
- 146 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:03]
- ADO.NETみたいにコネクションレスのアーキテクチャでないと柔軟性がなくて駄目だね。
- 147 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:04]
- >>63
CORBAの失敗(M$を取り込めず、M$が暴走した)を教訓としてるとは思うけど、
CORBAほど重くならないように、相互互換性のみに焦点を当てて、実装方法は勝手にせい、
というスタンスだと思う。
- 148 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:05]
- >>132
で、M$の最新のアーキテクチャはどんなアーキテクチャなんだい?
あんたの話によればEJBより凄いらしいな。
- 149 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:05]
- >>146
ほぅ、面白そうなお話だね。語ってもらいましょうか(藁
- 150 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:06]
- >>146
JDBCだけではで問題があるからEJBを選んでいるというのに
お前は何もわかってないな。
- 151 名前：63 [03/02/19 04:06]
- .NETって単にWINDOWS DNAとかいう
わけ分からん統一感のない技術がWEBサービスに対応しただけでしょ。
しかもJVMパクッてCLR上で動かすのはいいけど、WINDOWSのみって。
サーバも出てないし。またサービスパックの嵐になりそうだし。
- 152 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:06]
- VB の延長で「わーい .NET だー」っていう勘違いプロジェクトならあるけどな…
分散システムで作ってるのは J2EE か CORBA(C/C++) しか知らないし他に聞かない。
- 153 名前：デフォルトの名無しさん [03/02/19 04:07]
- > 134
そう、サーバサイドだけでなく全部に適用する開発環境/フレームワークで
話の流れ上、データの扱いに関してEntityBeanとの違いを
言いたかったのであのような説明になったのれす。
基本的にDB屋さんなんで、Viewのことはあまり気にしてないっす
- 154 名前：63 [03/02/19 04:07]
- >>147
なるほど。そんな感じします。
- 155 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:09]
- .NETに無知なアホが必死にJ2EEの話してて面白いな。(藁
- 156 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:10]
- いっぱい相手してもらってよかったな。
- 157 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:10]
- >>132
Microsoft Transaction Server (MTS)なんて
大袈裟なM$独自の用語で説明してM$独自仕様と比較されてもね。
- 158 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:11]
- >>155
J2EEに無知なアホが必死に.NETの話してて面白いな。(藁
- 159 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:11]
- .NET ＝ J2EE ＋ Webサービス
- 160 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:12]
- WSDPの話出てこないな(ﾜﾗい
- 161 名前：デフォルトの名無しさん [03/02/19 04:12]
- だから.NETがJ2EEより優れてるところをJ2EEユーザに分かるように教えてくれ。
抽象的過ぎて分からん。
- 162 名前：デフォルトの名無しさん [03/02/19 04:12]
- >>159
J2EE ＝ .NET − Webサービス
- 163 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:12]
- JWSDPやAXISの話でてこないな(ﾜﾗい
- 164 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:13]
- >>161
Microsoftなところ
- 165 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:13]
- .NET 2.0 ＝ J2EE 1.4
- 166 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:13]
- J2EEってJMSでSOAP通信含んでなかったっけ？
- 167 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:15]
- お前らさあ、Sun自身がこんなもん使えねーとか言ってるものをよく喜んで使えるな。
おめでたいというか。
- 168 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:15]
- >>165
どちらもまだ商品が出ていない
- 169 名前：デフォルトの名無しさん [03/02/19 04:15]
- Webサービス＝J2EE − .NET
- 170 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:16]
- Windows DNA って、商品出ないうちに廃止になったんだっけ？
Windows .NET Server って、商品出ないうちに廃止になったんだっけ？
- 171 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:17]
- >>170
名称が廃止になっただけでコンセプトは健在。
- 172 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:17]
- >>166
Webサービス・アーキテクチャってなレベルのもんではないでそ
- 173 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:17]
- >>159
「Webサービス」、「 XML Webサービス」なんて用語はM$が勝手に解釈した用語だ。
M$独自の中途半端な仕様というところだな。
- 174 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:18]
- 「.NETってなんですか」 M＄信者の心の叫び
- 175 名前：デフォルトの名無しさん mailto:sage [03/02/19 04:19]
- BizTalk ってまだやってんの?
アクティブチャンネルはどこ逝ったの?
|
 |
