■CGIは死滅。これからは.NETできまり■

CGIなんて死滅技術つかってんなよ。Javaも問題外だ。
これからはゲイツ様の.NET。これ最強。
馬鹿みたいにいつまでもCGIなんて使ってるな。
PERL最悪
こらからはC#
はい、みなさんもご一緒に

自分で会社おこせや

>>173-174
禿同
最低でもJavaは標準のドキュメントをMSDN並にしてほしいよ
Javaやってるけどやることなすことくっさく思えるね。

オープンソース(以下OSS)、本当に騙している?

ハロウィン文書( http://cruel.org/freeware/halloween.html )によれば
Ｍ弗はOSSを恐れているらしい。
金があってもテクノロジがない組織の製品は、そんなに長寿な信頼性を維持できないだろう。最近ハロウィン文書7が公開されたところによるとM＄がOSSを恐れていることが確実になったらしい。

JavaがOSに依存しないのに対してC#(.Netの中心?)は言語に依存しないらしい。
しかしこれには大きな落とし穴が...。

COBOLしか使いたくない者とVBしか使いたくない者、C#だけしか、Javaだけしか、FORTRANだけしか、、、などといっている者同士が団結してまともに大規模プログラミングなどできるのだろうか?

バグとりがとても恐ろしいことになりそうだ。
「言語にこだわらない」なんて向こう見ずになりすぎると、みずほ銀行(COBOLやFORTRANを使っていたらしい)の二の舞になると思う。

(Webプログラミング向けとしての)CGIがいずれ廃れるのはほぼ確実か?

Sunのスコットマクリーニは来日したとき(今年春頃) .NETのことを ドットノットと馬鹿にしているようだし.NETはウィルスだと相変わらず強烈な毒舌を吐いたようだ。

>177
落とし穴も何も、.NETの「言語に依存しない」から、多数の言語でシステム
作る奴なんて、実践する奴いないだろ。
ありゃ、ただのマーケティングだろ。おかげで、富士通はCOBOLを作り、
ボーランドはDelphiを作るわけだ。コアは、Windowsなんだから万々歳だろうな。

こちらは、これまでのC++のCOM + VBのプログラミング程度の
認識でいれば、何の問題もないだろう。

まっとうなマネージャーだったら、２種類以上のマルチ言語なんて許さない。
作った奴がいなくなったらメンテできないようなマイナー言語を使わせる馬鹿が
どこにいる。

COBOLは知らん。COBOLから抜け出せない奴は、言語の書き方ではなく、
オブジェクト指向の設計で悩むんじゃないのか？

ちなみに、ＭＳがNetscapeやRealNetworksをタダ製品でメタメタにしたのと同じく、
自社のコアビジネスモデルであるOSとDBをタダにするオープンソースが怖いのは
当たり前だよな。労働の対価にお金を貰うという、単純なビジネスモデルが曖昧だから、
玉砕的に見えるのは確かだしね。

言語に依存しないも何も、C# なんかで作った GUI アプリは結局 Win 以外じゃ
動かないじゃん。NOMO 連中もさじ投げて WINE 入れれっつー事になったし。
エミュもどきいれて動きますって言われてもただの詐欺だろ。

金があれば優秀な人材を雇えるのを忘れなる。そんなこともわからんのか、
三流馬鹿が。M$にはお前より優秀な人材は五万といる。っていうか
おまえがすげープログラマーなら向こうは実力にあった給料で
迎えてくれるぜ。というと信者と言われるが、仕事はLINUXでやってる

>180
誤爆？
誰に言ってるんだろ。誰もMS社内の心配なんてしてないと思うけど。

ﾌｪﾗﾃｨｵ

>180
確かに忘れてはならないと思います。

M$が甘い汁で迎えてくれても、(経済的に余裕があれば)拒否するかも。迎えてくれるほどの能力はいまは無いけど。
金があるだけじゃ、夢を実現できぬ。
金だけでなく技術も必要。夢や技術だけじゃ金は入ってこないけどさ。

>178
マルチ言語を許さない。やはりこれからの時代は、既存のコードを再利用しない限り、そうあるべきですね。M＄の.NETは多くの技術者にとってM$の誇大な宣伝、情報操作、戦術としか見えないんですね。
ということは、これからはC#と.NETできまりとは言い切れない?

参考になりました。Thank you.

金があるー＞優秀な技術者を雇えるー＞優秀な技術を作れる

SUNなどがリストラするなか、M＄だけが利益を拡大させてる。
金があれば、東大、京大、MIT,ハーバード卒の学生、経験者も
余裕でやとえる。もちろんM$が嫌いな奴はやとわれんが、
この時代金だろ。

>>178
しかしですよ、C#で作ろうが、VBで作ろうが、コンパイル後の動作はほ
ぼ一緒という結果が出ている限り、できるだけ作業効率の高い言語を
使うべきではないかと思いますよ。
ASPからASP.NETに移行して、全部C#で書き直していますが、へぼ
プログラマにとっては超えにくい壁に結構あたって大変なんですわ。
なので考えるのがめんどくさいところは全部VBで書いたクラスに引
数渡すことにしてるであります。

C#くらい使えろよ、ヽ(・＊・)ﾉｱﾅﾙ野郎

>> 185
コンパイル後の動作とは、速度のことですか?
もし速度だとしたら、
速度を重視するよりもオブジェクト指向的な拡張性、可搬性、コードの可読性を重視するからVBではなくC#を使うのでは?

VBは型の概念が曖昧だから、余裕ができたらC#に移した方が良いかと。

型が曖昧な言語は大規模化(複雑化)するとソースが読みづらく、何が起こるか、どんな潜在的なバグが発生するかわかりにくくて怖い。

M$側もVBプログラマをいかにしてC#に移行させるか、ということを心配しているようですし。

C#もJavaよりも余計に余分な機能が付いているのが、かえって仕様を複雑にしコードの可読性を低下させる素を持っているかのようで奇異にみえます。

>>173

どんまい。

ＭＳの上手さを感じるよ。
昔JSP+Servletをやって、わけあってやめたんだが、その「わけ」の部分に対する回答がかなり盛り込まれている気がするんだよね。
１５９とそのへんは同じ感覚なんだろうな。

ASP+RemoteScripting+DHTMLについて、ASP + RemoteScriptingってところまでは有りだと思うんだよ。
そこに+DHTMLってのがかなり辛そうだ。
DHTMLってのも込み入ってくると、DOMレベルのバグなんだかコードのバグなんだか判断が面倒になる上にリモートの要素まで関わってくるからな。
そうしたほうが良さげなケースでも、どうしても避けざるを得なかった。
加えてjavaに関する不信感かなあ・・・（笑）

>>174

うん、その一貫したクラサバのアーキテクチャの鯖側にWebアプリケーションがあるってのがずっと求められてきた姿だと思うんだ。
それを実現するためのプロトコルがSOAPであり、またXMLでもあった。
ただこれらの土台ができあがっているにもかかわらず、それを有効に実装する岩盤みたいな存在が不足してたんだよね。
あまたの企業が寄ってたかって料理しようとしたけれど、結局はたいしたものは出来上がらずにここまで来た。
１５９が言うように、Flashでクラサバ復活云々なんてのは寝言以外のなにものでもなくって、まさに.Net的な総合的（総合的ってのが大事）アプローチが大事で、それさえ著に付いたばかりだ。

矛盾しているようだけど、「高機能なダム端末」なんだよね、ブラウザの使命って。
それ以外にWinForms+SOAP、あるいはモバイルベースのWinForms+SOAPの実装が見えてきてこそ、Webアプリケーションの存在価値が上がるってもんだね。
UIを入れ替えるっていうか、できるだけデータ交換のレベルでアプリケーションが動作しているように設計していくことが望ましいと思うし、それこそが.Net的であるんだろうね。
お互いに頑張ろう！

>>189
「高機能なダム端末」
まさにtarantella

>>187
オブジェクト指向的な拡張性、可搬性、コードの可読性はVB.NetとC#そこまで大きく差があるとは思えない。
また可読性って事に関しても、それはあくまで主観的な問題であろうし、どんな言語で書いても善し悪しが出るのは個人差ではなかろうか？
.Netに関する板だからあえて言うけれど、.Net以後のVBで型は曖昧ではない。
それからMSはC#にいかに移行させるかなんて心配はしていないと思う。
最大の関心事は、「いかに膨大な数のVBプログラマーをそのまま.Netに移行させるか」だ。
言い換えれば、これは「いかにVBからVB.Netに移行させるか」と捉えるのが自然。
またC#javaよりも余計に余分な機能が付いているってのもなんだか不自然に聞こえる。
機能ってのはあくまでclassからの派生のことでしょう？

>185
自分達でコンセンサスが取れてれば、ＶＢ使おうが、ＣＯＢＯＬ使おうが
かまわないと思いますよ。それが.NETのメリットなわけだし。

しかし、１年後に、ソース書いた奴が、会社、やめちゃったりして、
後日、クラスのソース開いて、いきなりCOBOLで書かれてたら途方に暮れるだろうなぁ。

あと、VBとC#で、ループのカウンタの取り扱いとか変わったりしない？
忘れちゃったが、VBのuboundとC#のlengthって違う値になるんだっけか？
仮に、それが違ってたとして、そういう細かいところで、エラーにならない
不具合を作っちゃったら最悪だし。作業効率とは裏腹に、間違いの可能性
を減らすってのも、避けたい理由かなぁ。

>>192
でもCOMコンポーネントと同じ感じで完全パッケージ化させてしまえば中の言語なんてどうでもいい。
その辺を考えれば単純に１つのプロジェクトだけで考えるんじゃなくって過去の共通クラスを流用とか、
コントロールクラスを持ってきてバージョンあげていったりとかできるわけよね。

C#てソフト開発からWEBプログラミングまで出来るんですか？

>>194
おう

>193
Basp21のように完結した汎用モジュールなら、それもアリだが、
実際は、流用して改造したり、後日オーバーロードして拡張したくならない？
（継承ではなく・・・。）

ＭＳもカプセル化による隠蔽が多言語利用の前提になってるような気がする
んだが、そこまでの汎用化は、漏れ的には、考えてる暇はないので、
最終的には、拡張、拡張で汎用モジュールの機能アップを実現したいので、
「完全パッケージ化」という発想自体が、なかなか理想的な話だとは思う。

漏れ的には、汎用モジュールであっても、後日の情報共有のしやすさ、
カスタマイズのしやすさを重視したいなぁ。

その辺は、どのようにプログラミングするか？という話なので、あくまで
「ウチの場合は」ですけどね。しっかり隠蔽して流用できるものが作れるなら
おっしゃるとおり。

>>196
でもC#でしか作るきないけどね。
今までのMSの言語体系って

C++,MFC <=上級者
VB <=初心者、中級者

っていう扱い

でも、この全部を内包してC#に移行できるだけのパワーがC#にはあると思うよ。
結局全社で統一させる場合にはC#かVB.Netでしょう。

でも、私としてはどっちの言語で書かれていても同じことだからかまわないなぁ。

XMLWebサービスなんか言語は外からわからないしね。
COBOLのバッチプログラム -> COBOL.NetによるXMLWebサービス

こんなんができれば最高だとは思う。

http://www.agemasukudasai.com/bloom/

>>191
確かに個人差が無いとはいえない。集団でプログラミングするときコーディング規約、ある程度はガイドラインを定義すればどうにかなるかもしれませんね。

C#がJavaより余分な機能があるというのは、
class からの派生とかではなく、
Javaでは複雑になるからとC/C++あった機能を排除したが、
C#では復活している機能(仕様?)があるということです。(機能とは言わない?)
JavaにはないがC#にある仕様(機能?)を適当に列挙
- Cとはちょっと異なる構造体の復活
- unsafe 修飾子によってそのスコープ内でCのようなコード(ポインタ、アドレス操作可能なコード)の埋め込みが使える。
- 列挙型の復活
- JavaBeansに相当するプロパティ機能がデフォルトで使える、set, get修飾子使用。
- メソッドの引数の種類(参照引数、出力引数、可変長引数)が余分に増えた - デレゲート
- 演算子のオーバーローディング
- インデクサ
- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。

続き
便利とはいえ、こんなに余計な機能が多くあるとこれらを使ったソースコードの解読、修正、バグ検出するとき、Javaで書いたのと比べると苦労しそう。なんでもできるということはその反面ソースコードを読みにくくする。

余計な機能を追加するくらいならクラスとして提供すればいいのではないか、というのがC#の仕様を見たときの感想。

C#で集団で新規にコーディングするときにこの機能は使うな、と規定を定めればどうにかなるかもしれません。
しかし、誰か個人がコーディングしたこれらの機能をフルに使用したコードを流用したいときがあるかもしれない。そのときそのコードがどれだけ正確か、などを確認することも起こりうると思われる。

Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。

Javaならクラスの継承を意味する修飾子は、extends、インターフェースの継承を意味する修飾子は implementsでありこれをみるだけですぐにクラスかインターフェースかがわかる。

続き
C#だと :: なのでわからないためにインターフェース名の頭にIをつけているのだろう。::の方短縮できるからいいだろう、C++プログラマのために、と思ってこのようにしたと思われるが。言語仕様の設計そのものに問題があるようなきがする。

クラスやインターフェースがあれば構造体も列挙型もいらないような気がする。これらは、速度を高めるために、Javaのプリミティブ型に相当する新しい型を定義する取り入れられた機能と思われる。
オブジェクト指向的な観点で言えば、本来型はすべて参照型にすべきと思われる。が、C#の構造体は値型。継承できない構造体とクラスをうまく使い分けるっていうもの大変そうだ。

演算子のオーバーローディングもクラスとメソッドを定義すればいらないだろう、と思う。記述方法が短縮できる以外にメリットは無い。逆にコードの可読性が低下するという欠点がある。
速度を気にしなければ構造体も列挙型も不要と見える。

C#をプラットフォーム非依存にさせると目指しているM$の発言にも不信感を感じる? 言語非依存にすればC#以外の言語でかかれたものがプラットフォーム非依存な言語であればWin以外の他のOSでは使えない。.NETも同様?

連続投稿の最後です
.NETの利便性というのは殆どがWinに依存しており、セキュリティ性、プラットフォーム非依存性の犠牲の上に成り立っていると思う。
.NETで開発するときはこのあたりを大いに覚悟しなければならないと思う。

>>199

そうだね、確かに数々の指摘はその通りだと思うよ。
それらは機能というより仕様だね（レスに書いてくれたけど）。
インターフェイスに関する存在の冗長性やオーバーローディングの曖昧性も、仕様としてはかなり不細工に感じるのは自然だと思う。
ただ、それぞれにはそれなりの存在理由があるので、言語として整理整頓されましたということが自慢できた時代とは異なる昨今でプライオリティが低かったのではないかな。
それから保守などについてだけれども、圧倒的多数のコードの寿命が極端に短くなった現在、次々と新しく書き直されることがより求められている気もする。
C#をもっとブラッシュアップしてしまえば良かったのにって思うけれど、VBについては、まあこの程度でよしとして良いんじゃないかな。
セキュリティもひっくるめたあらゆる利便性がWin依存というのはなかば当然だと思う。
もっとも、これはC#などに限らずあらゆる言語や環境に言える事じゃないかな。
たとえ言語がオープンであっても、圧倒的多数のクライアント環境はWinであり、Winには固有のシェル環境があり、またインターネットへの一般的窓口であるブラウザはIEが多い。
最適化した実装を施したいと考えればその縛りは必ず受けざるを得ないよね。
この企業の姿勢は「客」という存在を絶対的な立場から見てどこにあるかとらえて徹底した征服を行い、誰しもがそれに依存せざるを得ない状況を作り上げることにある。
それが今後も変わるとは思えない（善し悪しということではなく単純に考えての話ね）。
それに、恐らくＭＳのセールストークを全部信じてわくわくしている開発の現場って限りなくゼロに近いんじゃないだろうか。

言語の話からはそれるレスだけど、ASP.NETが吐き出す自動生成サーバー
連携HTMLは、HTML3.2の仕様を満たすんだったけ？

.NETが最初に発表されたころのセミナーで聞いた話だから、実際
古いネスケ4.04とかで、どう動作するのかは検証してないけど、
サーバーサイドオブジェクトなどのイベントモデルを作った最大の
メリットは、POSTを主体としたサーバー通信を自動化しているところで、
その目的は、IEに依存しないというところだと思う。

そういう部分では、.NETという枠組みでは、普遍的なところへの
チャレンジがあって、これ自体は、とてもMSっぽくないなと思って
わくわくした。（ただ、FAQになりそうなのが、サーバーサイドの
プルダウン選択したら、FlashやEmbedのWMPが初期化されちゃいました。
バグですか？・・・とか。）

ところで、IE EmbedできるActiveX OCXって、作れないん
だよねぇ・・・。アプレットの入れ替えとか言って、
サンドボックスのセキュリティとかになってしまうと、
困るんだけど。ActiveXは、わかってて使う、悪魔の魅力こそが魅力なので。

たとえばJavaになくってC#にある機能っていうのはJavaの開発してたらなんでやねん、
なんでないねんていう機能ばかりじゃないか？
- Cとはちょっと異なる構造体の復活
Javaで同じValueClassを書くのは無駄にコード量が増えるだけ

- unsafe 修飾子によってそのスコープ内でCのようなコード(ポインタ、アドレス操作可能なコード)の埋め込みが使える。
これは基本的にしちゃいけないから、かなりガードは高い。
でもやりたい時には最悪許してあげるっていうスタンスかな？

- 列挙型の復活
これも同じことをしようとすると意味もなくコード量が増える

- JavaBeansに相当するプロパティ機能がデフォルトで使える、set, get修飾子使用。
VBと同じような機能
何でもありの変数はgetter, setterを書く必要なんかない。
publicにしたらいい、チェックが必要になったりしたときにプロパティにして
コードを書けばいい

- メソッドの引数の種類(参照引数、出力引数、可変長引数)が余分に増えた - デレゲート
関数ポインタがないためにJavaでは何をしていたか、しているかを考えれば当然

- 演算子のオーバーローディング
これは賛否両論あるけど、文字列比較がすっきりしなきゃ言語としてどうかと思う。
Java: stringA.equals("ABC")
C#: StringA == "ABC"
VB.Net: StringA = "ABC"

=なんかの演算子には等価という意味合いが強く現れるので、構文的にはC#とかの方がいいと思わない？

続き

- インデクサ
java: a.get(1)
C#: a[1]
Cのchar*なんかの時と似てるけど、レコードはインデクサなんかが似合ってると思わない？

- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。
これはちょっと問題かもしれない。
CLRでは動くけど、CLIでは動かない範囲ですね。

わたしはこれらのunsignedは使わないと思うけど、最悪ガリガリのチューニング用か？


>Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。
昔はクラスにCをつけるようにとなっていたよね。
Javaをしていると継承関係がややこしくてインターフェースかクラスかわからなくなるよ。
でも.Netのように現在は入り組んでないライブラリでも、今後入り組んでいくとおもう。
その時に真価を発揮すると信じているよ。

どうせならコンパイルオプションではじける設定もほしい

あと忘れ物だ
!!!throws!!!

これってあんまり役に立っていないと最近思う。
RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだって。
この機能はスパッと切って正解だったと思うよ。

!!!ボクシング／アンボクシング＆すべてがobjectを継承していない!!!
javaでは値型が特殊な変数になっているためにVectorなんかにそのまま入れれない。
これって誰も言わないんだけど致命的な設計ミスじゃない？

んじゃ

厨が長文オナニーしてるのはこのスレですか？

論理的に説明してる気かも知れないが長々と主観を連ねただけだな。

今時の高等言語はどれをとっても一長一短でしょ、いずれにしても。
無駄な関数や多少の冗長性があっても大した問題ではないしね。
表面的な実装がどうであるかよりもむしろ深層部分で変数・型をどう扱っているかとか、もろもろ無茶苦茶細かい部分に関する部分が気になるでしょ。
そうして、そのような箇所はそれなりに時代に合わせた設計が為されているしね。
ここ１０年の流れとしては、「どの言語がどれだけ素晴らしいか」ということでなく、「どの言語がどれだけ<<実効性のある総合的環境>>を持つか」じゃない？
Javaにしてもそうだったし、インタープリタがあらゆるブラウジング環境に実装されだした流れにしてもそうだった。
今後もそうとう長い期間、そんなＭＳ的なるアプローチが支配的であるように思うな。
理念の先行や重厚な布陣よりも、即効性とゲリラ戦が主流でしかあり得ないだろうし。

.NET も寒々としとるなぁ。

.NETでDBを扱う場合、DBがSQL Serverの場合とOracleの場合って何か違いがありま
すか？.NETやるならSQL Serverの方がイイ！っとかあります？

>>212

そもそも現時点ではSQLServerとOracleでは扱うライブラリが違う。
ADOみたいに１種類のライブラリでSQLServerもOracleも同じ操作でアクセスできるということはない。
現時点では、
・SQLServerを使うならADO.NETと呼ばれるライブラリ（System.Data）
・Oracleを使うならOLE DB .NETと呼ばれるライブラリ（System.Data.OleDb）
を使い分ける必要がある。
クラス名からメソッド名からみんな違うので注意が必要。

現時点では.NETではSQLServerが最適と考えたほうがいい。というか他のRDBベンダ（OracleやSybase、IBM）に
.NET専用のライブラリを提供しようという気がない。（OracleはMSが対応ライブラリ出したらしいけど）

>>213
SQLサーバは System.Data.Sqlclient
Oracleはオラクル用のドライバが出たからSystem.Data.OracleDriver?かなんかで使える。
クラス名は違うけど基本的に同じだから置換するだけでつかえる。

ただ移植度はADOより下がっているのは事実かもしれないね。

これから選ぶっていうならSQLServerだとは思うけど、Oracleだから敷居が高いなんてことはないから安心して。

>>212,213
Thanx!
うちはプチOracle使いからプラチナマスターまで揃ってるOracleマンセーな
ところなので.NETはイカンのかと思ってましたよ。
移植度が下がるってのはどういうことでしょうか？うちだとSQLでselect文も
DDLもDMLも書いて、ADOでレコードセット開いたり、コネクションで実行して
ましたよ。それができないって事はないんでしょうけどどの辺が下がるんです
か？

>>214
System.Data → System.Data.Sqlclient
補足してくれてthanks。

>>215
>移植度が下がるってのはどういうことでしょうか

たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
ADOだったらConnectionStringを変更するだけで95%くらい移植可能だったんだけどね。
ちなみにうちの会社ではOracle＋.NETのシステムをこの前作ったよ。ASP.NETじゃないけどね。

訂正。
漏れは>>212じゃなくて>>213だった。

>>216
>たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
それもそうなんだが、たとえばレコードセットで,movenextだ .updateだって使っていた場合には
接続文字列の変更だけなんだけど、.Netの場合自動生成でSQL文が出来るやり方があるし、それが主流
そうなると、どうしてもDB固有の機能が出てきちゃったりする。

私はDB固有の機能を使うの賛成なんでDBかわったらとうぜんソース修正して、最適化すべきだと思う。
シーケンスとIDENTITYとかもあるしね。

わかりにくくてごめん

皆さんレスどうもです。
.NETにはSQL Serverじゃないとイカンのか！？という問題は、
.Oracleも可。ただし、.NETではADOを使わない(使えない？主流ではない？）ので
SQL Server<->Oracleの移植性は落ちる。
って事でしょうか。
.NETでのDBの扱い方とか色々勉強になりました。どうもです。

>>219
.NetではCOMを利用できるからADOも当然利用は可能。
どうしてもサーバカーソルが必要な時になんかしか使わんときましょうっていうのが路線です。

SQL文がOracleとSQLさーばで互換性がないんだからその辺の移植性は仕方ないよね。
OracleとSQLサーバしか知らんけどDB2とかPostgreSQLとかどうなんかな？

RCWやCCWなんて本当に使い物になるの？

>>220
どもども。大変勉強になります。
ありがとうございました。

ウィンドウズベースでならM$　SQLつかっとけば？

>>219

ADOはADO.Netになっているねえ。
その辺のことはリファレンスにきちんと書いてある。
やっぱさ、一通りでいいからリファレンスって読むべきだと思う。
.NetになってからCOMをどう使うかってのも、各種資料では優先的な課題としていくつも例が挙げられているよ。

>>220

共通仕様ののSQLの範囲であればどれも一緒だけれど、各ベンダーはもれなく独自の関数やメソッドを持っているよ。
だからOracleとSQL Server程度に互換性はない。

>>225
ま、そういうところやろうね。
ADOでRecordsetでのアクセスであってもほとんど、MoveNextとかを駆使する方法じゃなくって
更新はConnection.Executeでやっているのがほとんどだろうから、ADOと大して変わらない
という説明でもいいかもね。

aspがLINUXサーバーで使用できるなら
C#使ってもいいよ
WINDOWSサーバーは高いしセキュリティー貧弱で
ウィルス攻撃の的になってるから
aspは流行らない

>>227
Windowｓを攻撃したいのね。
難癖つけて

【ついに】Winnyで逮捕者【でた】
愛知県で初の逮捕者！
↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓
http://choco.2ch.net/test/read.cgi/bobby/1038742045/238

↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓（うｐ済み
http://comic.2ch.net/test/read.cgi/gcomic/1035547729/741

>>229
それもう古い。
新しいネタ考えろ能無し

>>225
しかしDB2はストアドプロシージャの記述がSQL鯖・オラクルとは違うような印象がありますです。

>>220
サーバカーソルってことは、.NETでフツーに開発するとDBへの問い合わせが遅
くなるんですか？
>>224
うちはまだ.NET使ってないからドキュメント無いんですよ。MSDNのWEBやCDに
入ってるかな。見てないや。

２２７がC#使ってもどうなるわけでもないし
その前にC#つかえこなせないだろ藁

>>232
逆。
ADO.NETはサーバとは非同期型のクライアントカーソル。
ADOはサーバと同期を取るクライアントカーソル。

>>234
>>>232
> 逆。
> ADO.NETはサーバとは非同期型のクライアントカーソル。
> ADOはサーバと同期を取るクライアントカーソル。

おしい。

ADOはクライアントカーソルと、サーバカーソル両方使えるのが正解。

>>235
スマン。ADOのほうはクライアントカーソルは意図的に省いた。
ADOの場合、主流（というかデフォルト）はサーバカーソルだし、
UseClient（だっけ？）モードの実装はベンダに委ねられているので、
確かプロバイダによってはクライアントカーソルをサポートしてないものも
あるらしいと聞いたので。

>>234-236
勉強不足で同期型、非同期型ってのは聞いたことないっす。あとで調べるか。
つまり（強引か？）ADO.NETだと速くなると？

>>236
同期を取るクライアントカーソルと書いてありますが・・・
ま意図はよくわかります。



>>237
要はADOは細かくDBとアクセスする。
ADO.Netは最初と最後にどかんとアクセスする。

だから、ADO.Netの場合にはアクセスの数が少ないから早いけど、シリアライゼ
ーションで若干問題がある。

バッチ処理なんかはADOを使わざるを得ないかも（試してないんでわからんが）

>>231
えーと、だから共通仕様のＳＱＬってのはＳＱＬ９２のことね。
ＤＢ２には当然ＤＢ２の方言があるんだからオラやMSSQLとも違って当然っしょ？

>>228
プアーなLinux厨なんだからいちいち反応せずともヨロシ。
言ってることド素人なんだから放っておけよ。

>>232
.Net Framework SDKにかなりのボリュームの資料があって、これがなかなか参考になるんだ。
例題も豊富なので、是非目を通してくれ。

>>236
ADOの主流がサーバカーソルなのではないぞ。
サーバカーソルはあくまでデフォルトであるだけで、クライアントサイドにカーソルを実装しなければならいケースが非常に多いので、かえって逆だろうと思う。

>>203
シェアは殆どがWin。クライアントマシン側ではそうですね。

しかしアプライアンスサーバ至上ではサーバOSのシェアはLinuxのほうが上という結果もでているそうです(今は違う?)。これはM$KKの阿多氏も認めていたような..(違うかもしれない)。

中国ではTurboLinuxのシェアが7割りという発表が数年前の記事にありました。

>恐らくＭＳのセールストークを全部信じてわくわくしている開発の現場って限りなくゼロに近いんじゃないだろうか。
学生個人が勉強する上では、VB, VC++経験者が、信じてわくわくしながら楽しんでいる学生が多かったりということはありそうです。
初心者な人も結構信じていそうです。

学生アルバイトを紹介し他者に派遣するある派遣会社の社員は、
「これからはC#だ、C#だ、JavaはC#によって廃れていく」と学生に言い回っていました。
Javaのことをよく知らない人たちが多く、ASPのことをよく知っている人たちが多かったので、そのことを鵜呑みにする学生が数人はいました。
学生たちは、JSPとLinuxという言葉を聴くだけで嫌な顔をしていました。
Javaは遅いからASP以外はいらない、と思い込んでいる人もいるようでした。ASP以外は勉強したくないと。

中小企業では.Netを使う企業が多いのでは無いかと思います。
Sunがハイエンド企業をターゲットにした戦略を練っているのに対し、M$は中小企業をターゲットにしているようにみえます。

お金に困っているIT系中小企業の多くがM$からの圧力により.NET, C#を迫られて開発に使用しているように見えます。実際、「M$からの圧力によりJavaからC#への以降を迫られている」というある小企業もいました。

>>205
> たとえばJavaになくってC#にある機能っていうのはJavaの開発してたらなんでやねん、
> なんでないねんていう機能ばかりじゃないか？
> - Cとはちょっと異なる構造体の復活
> Javaで同じValueClassを書くのは無駄にコード量が増えるだけ
> - 列挙型の復活
> これも同じことをしようとすると意味もなくコード量が増える

それは個人の主観と思う。

最近のXP(eXtreme Programming), RUP(Rational Unified Process)な観点から見れば、コード量が増えてでもソースコードは他人に読みやすい方が良いのでは、と思う。

このクラスは継承できる、と思ったら構造体だった、というのも...。
また、構造体や列挙型はUMLで的確に表現できるのでしょか?

>>205
> - 演算子のオーバーローディング
> これは賛否両論あるけど、文字列比較がすっきりしなきゃ言語としてどうかと思う。
> Java: stringA.equals("ABC")
> C#: StringA == "ABC"
> VB.Net: StringA = "ABC"
>=なんかの演算子には等価という意味合いが強く現れるので、構文的にはC#と
>かの方がいいと思わない？

== のほうがすっきりするといえばしますね。
しかし、 == とequalsとを使い分けたいときには面倒なことになると思います。オブジェクトの中にある特定の変数が同じであっても、それを別のものとみなして扱いたいときにはこの機能はちょっと困り者です。

ある==がJavaのequalsに相当するものか、それともJavaの==相当するものなのか、を区別するにはどうすればいいのか、というときに困りそうです。
"Javaの鉄則" という本にはオブジェクトの等値の扱いについて注意すべき項がよく載っている。
例えば、クラスAのオブジェクトと、クラスAを継承したExtendedAのオブジェクトを比較するとき、equalメソッドをどちらのクラスに実装するかを考えなければならない。
また、親クラスと子クラスのオブジェクトを同一とみなすか同かも自分で定義しなければならない。下手に instanceof 修飾子を使うのも良くない。

かといってC#のようなオーバーローディングだけはどちらの等値メソッドを使うかという使い分けをすることができない。
こういう状況にあるときだけ、==と定義したeqauls()メソッドを使い分けてもいいが、"Javaの鉄則" に載っているような状況にでくわしたとき、
equal()メソッドの実装について悩む上に、==の定義についても余計に考えなければならないとか、
勝手に==をオーバーロードされるのは余計なお世話言いたくなる状況も出てくる。

>>206
>を継承するとき、クラスとインターフェースどちらを継承しているかわか
>らないのでインターフェース名の頭にIをつける、これは厄介そう。
> 昔はクラスにCをつけるようにとなっていたよね。
> Javaをしていると継承関係がややこしくてインターフェースかクラス
>かわからなくなるよ。
> でも.Netのように現在は入り組んでないライブラリでも、今後入り組
>んでいくとおもう。
> その時に真価を発揮すると信じているよ。
> どうせならコンパイルオプションではじける設定もほしい
そのときこそUMLが真価を発揮する?
この、頭にCやIをつけるガイドラインは悪しき習慣、ハンガリアン記法の伝統ではないかと。

インターフェースとクラスの区別もUMLクラス図を見れば一目でわかるし、
継承する側は上の説明のとおりimplements, extendsを見れば一目で解るし、
Javadoc API によって生成したドキュメントを見れば一目でわかる。

たいていの場合、複数のクラスやインターフェースは、一つのファイルにつき一つのクラス、インターフェ−スを記述しているはずだ。
そうすれば、同じディレクトリ内に入っているクラス、インターフェースを見るだけで区別にそれほど苦労しない、と思う。

膨大なクラスやインターフェースが沢山あると区別しにくいのではと思うかもしれないが、
同じディレクトリに膨大なのクラスやインターフェースのファイルを入れる方法はソフトウェア管理手法として効率的でない。
デザインパターンを深く学んでいくと、クラスやインターフェースをpackageに入れて分けることの重要性に気づく。
Javaならpackage, C#/C++ならnamespaceで管理し、package, namespaceの違いはディレクトリ(フォルダ)の違いとして判断させる。

>>207
> あと忘れ物だ
> !!!throws!!!
> これってあんまり役に立っていないと最近思う。
> RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだ
>って。 この機能はスパッと切って正解だったと思うよ。
これは超重要ですよ!!
C#でこれ無くしたことはある意味、ミッションクリティカルで大規模なプログラミングでは致命的ではないかと。

RuntimeException 以外にも、特にファイル入出力では FileNotFuondExceptionとかIOExceptionとかかなり重要なものもありますよ。

throwsはずすのはさすがにまずと思われます。
C#では すべてのメソッドは Javaの throws Exception に相当することをやっているというわけで、どの例外が投げ出されるか具体的に判別できなくなります。
throwsに加える例外はできる限り詳細に並べよ、というのが(これまた) "Javaの鉄則" に載っています。

>>207

class AException extends Exception {}
class AAException extends AException {}
class AAAException extends AAException {}

class ExceptionDemo {
method() throws Exception {
//何かの実装
throw new Exception();
//何かの実装
throw new AException();
//何かの実装
throw new AAException();
}
}
これではmethod()がAAExceptionやAExceptionをスローしたとしても返ってるのはExceptionのみ。なぜなら、これらの例外クラスはExceptionのサブクラスで同一とみなされる。

具体的な例外を知りたいときは以下のようにしなければならない。
class ExceptionDemo {
method() throws Exception, AException, AAException {
//何かの実装...大幅に省略
}

というわけでthrowsは重要であり、C#でこれがなくなったということはバグの検出を非常に困難にしているのではないかと思います。

throws節をはずしたことによる問題点が議論されています。
http://www.users.gr.jp/ml/archive/CS/391.asp

簡単なプログラムでははずした方がよくても
複雑になると、これをはずすというのはバグ捕りのしやすさに影響が出ると思われます。

万が一のことを考えるとthrows節はあった方が良いと思います。
throws節で例外クラスを指定しないということは、
他人がコーディングしたC#のコードを解析、ライブラリをインポートするときにどのような例外がスローされるのか想定しにくい。
throwsされる例外クラスからどのような例外が起こりうるかと想定してコーディングできなくなります。


throws節はプログラマに契約を守らせる上で重要だと思います。


C#が発表されたとき、オブジェクト指向を超越した、エージェント指向な、アスペクト指向なプログラミング言語が出現すると期待していたんですが、全然違っていますね。これも C#が .NETによる多言語の互換性のために作られたということなのですね。

.NETの中心に据えられていると考えられるC#についてさらに意見を追加
virtual 修飾子は余分。
virtual修飾子をつけつけないに影響する速度の問題など気にするべきでない。
これも.NET政策のためにC++との下位互換性維持のために速度重視のためにあえて付けられたと推測。

Javaだとvirtualを意図しないときはfinal属性をつける

速度問題よりもむしろ、UMLにマッチするような、すっきりしたソースコードを書くほうが重要。


interfaceで宣言されてるメソッドをinterfaceを介して呼ぶ出すなら
常にvirtualメソッドと見なされるので、クラス中のメソッドの定義のデフォ
ルトがvirtualか否かはそれほど重要な問題ではない、ともいえる

デザインパターンを意識するならば、構造体、列挙型は極力使わないようにすべきと思います。
ついでに、#がトリップパスに代わったので修正。

>>207
> !!!ボクシング／アンボクシング＆すべてがobjectを継承していない!!!
> javaでは値型が特殊な変数になっているためにVectorなんかにそのま
>ま入れれない。
> これって誰も言わないんだけど致命的な設計ミスじゃない？
ボクシング／アンボクシング
自動的に変換するというのも奇異です。
これも過去の言語の型との互換性をどうにかしたかったために用意されたものではないかと。
unboxingについてよく理解していないのですが、ラップクラスに相当するものを呼び出さなくても自動的に変換できることでコード量が短縮できるという利点があるだけに見えます。
値型をどうにかするには、dobule型なら、DoubleクラスなどでラップしてからVectorに add() すれば、C#よりコード量がちょっと多いことを除いて同じことではないかと思います。

この程度のコード量などオブジェクト指向的な観点から見れば気にするべきではないと思います。
この程度のコード量の多さを気にしていてはインターフェースや抽象クラス、例が処理のtry-catch節などまともにかいていられません == オブジェクト指向性を失う。

>>207
Smalltalkから見たらJavaのプリミティブ型というのは失敗だったのですね。
型はすべて参照型でint, long doubleなど使わずに最初からInteger, Long, Doubleなどのラップクラスのみで定義すべきだったということですね。

私にはJavaにプリミティブ型(値型)が存在すること自体が致命的なミスではないかと思います。
型キャストも簡単にできてしまうのもミスだと思います。

J2SE1.5からJavaGenericによりC++のテンプレートに相当する機能が使えるようになりこれによりコレクション系インターフェースの型キャスト問題を解消できると期待しています。

Javaのプリミティブ型は唯一Objectクラスを継承しないものですね。

結論をいうと、 .NETというもは古い言語プログラマのため、古い言語を再利用したいためにあるものということが、C#の仕様からわかります。

新規にプロジェクトを開始するときに一種類の言語しか使う予定が無い、古い言語で書かれたコードもすべて新しい言語で書き直す方針、ならばC#よりJavaのほうが良いかな、と思える。

古い言語を再利用し、書き直さずに利用する予定がある場合にはJavaよりC#が向いている、と思える。

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここはネタスレ・隔離スレなんだから誰もそんな作文よまねーよ。

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここは厨板・過疎板なんだから誰もそんな論文よめねーよ。

>>243

アプライアンスの市場や組み込みOSの市場のシェア見積もりはかなりいい加減だと思うよ。
それぞれの大本営発表だから無理もないけれどね。
特にエンタープライズ市場などは販売網にしても昔ながら投網形式で、最大手が最大手を一網打尽。
外からはまったく見えないところで何事かが進んでいくので、まあ正確なところは見えなくなっているよ。
Linuxもオープンソースの皮を被ったしたたかな商人の巣窟だから、昔のような誠意のあるレポートも望めない。
ある面では堂々とガメているＭＳよりもたちが悪い。

ＭＳトークに萌え萌え的な学生はいても不思議はないと思うよ。
そのたりを冷静に見ているのは、あくまで第一線級の現場の話ね。
ところで、自分は別の意味でJSPとLinuxは絶対にもうやりたくないけれどね。
TomcatとApacheで散々作ってみてその不安定さとパフォーマンスの悪さに懲りた。
商用レベルで複雑なロジックを持つアプリはちょっとぞっとするなあ。
あれはもう偏見か愛がなければ支持され得ないプラットフォームであるとさえ思った（笑）。

新しい環境はがたいの大きな市場にはなかなか採用されないと思う。
.Netが零細企業や中小レベルから浸透するのは当然だと思うな。
Javaの時だってそうだったじゃない。
大きな所はまず様子見だよね。

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここには暇な奴はいないんだから中身の無い徒然書きなんか読まねーよ。

C#とJavaの違いって各地で色々論議されてるし、漏れも参加してるんだけどJavaらしいことを
J#.Netでできるんだよねー

とくにthrows。
でもthrowsって言っても下位で利用しているツールが何をはくかなんてあんまり興味ない。
続行可能か不可能かくらいなんだよ。
その辺があるとシステム固有の例外に集約して投げなおすだけになっちゃうことが多くて
ほとんど意味を成していない。

.NetであればSystemからのthrowsは知りたいとは思うけど、それを自分で書くのはどうかと思う。
勝手なこといってるけど。



それよりJavaはクライアントに本気でswinguiとかで浸透させようとか思っているの？
それに比べて.NetやKylixだっけ？の方向性はあっていると思うんだけど・・・

この板は時々長文を書く「わ」がいるな。
いくら力説しても、ここには.NET好きなんて知恵遅れな奴はいないんだからMSﾏﾝｾｰ洗脳文なんか読まねーよ。

C# vs Javaという言語でどっちが良いか悪いかという構図に興味はないな。

現状は、まだビジネス的にLinuxをどう考えるか？で決まるのに、
なんだかんだ言っても、なんの生産性ももたらさずに、いらんストレスを
生むだけのような気がする。

C#やJavaの言語設計に関わるエンジニアなら、話は別だが。

ところで、ここはWebProg板なのでWebアプリベースで語るが、

今、.NETやASPなどを使うのは、レガシーエンジニアの救済策や、Unixが
使えないからというネガティブな印象があるのは事実。

果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
選択肢が、有効な手段とみなされる日は来るのだろうか？
Webサービスも、結局、Apache + J2EEで実験してる人たちがほとんどらしいし。

>>259
J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？

ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
いっぱいあるのもどうかと思う。

結局互換性ないしね。

>260
逆に教えてほしいんだけど、NECとか富士通、その他、いわゆる大手SIは
Java率高くないんですか？

NECは、とにもかくにもWebLogicベースというイメージもありますが。

互換性というのは、同じAppサーバーのWinとLinux版で動けば、とりあえずＯＫ
だと思ってます。
より性能の高い、J2EEサーバーが要望されたときは、最低限の工数で移植が
可能であれば問題ないと思います。
ホントに、Run Anywhereを信じるほどピュアじゃないし。商用appサーバーが、
差別化していく上では、MS的に、互換を崩して、他社を出し抜き、ユーザーを
囲い込むのは、ビジネスとしてあるべき姿だと思っています。

あと、有効か？と言う論点には、なんらかの判断基準が必要かと思いますが、
「使っていて、シェア向上に寄与している」だけではダメなんでしょうね。

とりあえず、ちゃんとクラス設計すれば、複数人開発で分担しやすく、
単体デバッグもやりやすく、確実で、最後に組み合わせると、ちゃんと動いてくれれば、
「オブジェクト指向らしく有効である」とは思ってて、
あとは、LinuxとWinで動けば、「Javaらしく有効」とか思ってるんですけど、
どうですか？

>>261
大手SIにからんだことはないんだけど今のプロジェクトはWeblogic

差別化はわかるんですよ、ただ便利になっているというのが実感できない。
一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
純粋に使いにくいと思います。

XMLも手書きしろという姿勢もね。

J2EEである必要のない局面で使うのは全体的に手間が掛かるだけではないかと
分散サーバ環境でも何でもないところなのに、そのための手続きを書くのか？とか

あとDBサーバを有効に使わない方向は個人的には嫌いです。
高い金払ってDBサーバ買ってるんだから最大限機能を引き出してやりたいと思うんですけどね。

>262
質問です。

> 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> 純粋に使いにくいと思います。

これは、大きいところも小さいところも.NETで統一すればいい
という理由になりますか？

確かに、オープンソース系の複雑さは、大企業のオープンソースの熱が
一段落したら表面化してくると思います。

やはり、オープンソースは良い意味で、自分でケツがふけて、
工数がかかることも厭わないオタクのおもちゃだと思います。
フレームワークの乱立なんて、まさしくその辺の表れだと思いますし。

もちろん、大きなところも安定して動く信頼感を得ることがMSには
もっとも重要な責務で、そこ次第だとは思いますが。鯖管やってる
ような人は、Windowsを使ったこともないで否定する人も少なくありません。

>>263
Microsoftのいいところでもあり悪いところ？でもあるのが単純化。
Unix -> Dosもそうだとおもうんだけど、単純化して使いやすくしてくれる。

一般ユーザのレベルなんてLinuxがああいう雰囲気のままだと一生触らないよ。
簡単さがない、よくても悪くても単純に一本化してくれるから逆にJava陣営も
ある程度単純、一本化できないのかなぁ？と。

あと日本語化にどこも熱心じゃないでしょ？
Javaもいままでうけいれられなかったのはそれが原因かなと、そしてすでに.Netの日本語情報の
方が多い現実。

ライバルとしてがんばってほしいとは思うけどね。

>>262
> 質問です。
> > 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> > 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> > 純粋に使いにくいと思います。
> これは、大きいところも小さいところも.NETで統一すればいい
> という理由になりますか？

ごめん質問に答えてなかった。

大きいところも小さいところも.Netで統一よりは、小さいところもJavaが受け入れられるように
なんとかしろよと。
.Netはすごい勢いで制圧しちゃうかもしれないよ？っと。

技術提供の会社では大企業はWeblogic、一般向けにはtomcatじゃ全然別の環境を用意しなくちゃ
いけないし、TCO的にもWindows環境に負けてる。

オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。

>>259

＞果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
＞選択肢が、有効な手段とみなされる日は来るのだろうか？

市場はそういう対立軸は意識せずに、単純にアプリケーションを要求するだけでしょう？
その要求を見越して.Netが有効であると判断すれば採用すればいいだけだよね。

>>265

＞オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。

そこをうまく騙すというマーケティングがオープンソースの戦略の骨子だから無理もない。

環境：Win2000、VB.NET、OLEDB

VB.NETからCrystalReportを用いて帳票を出したいのですが
帳票を出力する前に、ユーザ名やパスワードを入力する
ダイアログボックスが出て困っています。
次のような記述で、データベースに繋ぐのに必要な情報を
送っているつもりなのですが・・・。

Dim logOnInfo As New CrystalDecisions.Shared.TableLogOnInfo()
Dim CryRep As New CrystalReport1()

logOnInfo.ConnectionInfo.ServerName = "xxx"
logOnInfo.ConnectionInfo.DatabaseName = "xxx"
logOnInfo.ConnectionInfo.UserID = "xxx"
logOnInfo.ConnectionInfo.Password = "xxx"
CryRep.Database.Tables.Item(0).ApplyLogOnInfo(logOnInfo)

回避する方法を教えてもらえないでしょうか？

あげげ

.NETですか。ﾌﾟﾌﾟ
どうせaspがらみで糞みたいなツールﾌﾟﾌﾟ
セッション管理も相変わらずマイクロソフトテイストでﾌﾟﾌﾟ


バカが。php最強伝説

別に適材適所でいいんじゃないの？
○○最強なんていってるのはタダの馬鹿にしか思えない。

>>255
>ところで、自分は別の意味でJSPとLinuxは絶対にもうやりたくないけれどね。
>TomcatとApacheで散々作ってみてその不安定さとパフォーマンスの悪さに懲りた。

そのときこそstruts, JSPカスタムタグライブラリが役に立つのでは?
さらにパフォーマンスは悪くなりますが、設計しやすさはかなり向上します。
struts-config.xmlファイルの修正がちょっと面倒ですが(Caminoなどのツールを使うことが解決できる)、コードが煩雑になりやすいスクリプトレットに悩まされる心配もなくなり、
真の意味でのデザインとロジックが分離できることです。デザイナはstruts専用のJSPカスタムタグを使うだけで、プログラムの知識なしで簡単に掲示板を作れる。
従来のように、デザイナがHTMLファイルの作成を待ってまらプログラマがHTMLをJSP化してHTML内にJavaコードを埋め込むという手順を踏まなくて済むようになる。
先にロジックを作成してからデザインすることもできるという利点がstrutsにはあります。

あと、JSPを使うなら、Servlet,Servlet無しのJavaユーティリティクラス、Beanも併用した方がいいですよ。
strutsはActionクラスを継承することでServletの代用ができ、ActionFormクラスを継承することでBeanを作ることができます。
それにstrutsタグを使ったJSPファイルを用意し、専用のstrutsタグだけで、
Actionクラスを継承したクラスを呼び出し、ActiobFormクラスを継承したBeanにデータを格納する。

全部JSPコード内にロジックを埋め込むのは考え物です。


中小企業からの浸透ですか。Sunの場合はハイエンド企業をターゲットにして市場を展開しているのに対し、
M$は中小企業をターゲットに展開しているという両者の違いについての説明をどこかの記事で見ました。
大手企業はM$に逆らうだけの余力が残っているので、各企業同士(SunとOracleなど)で同盟を結び巨大帝国に立ち向かい、中小企業はお金が無いので仕方がなくM$に従うという構図をもっていると思う。
実際、いくつかの中小企業は、M$から相当の圧力と資金が流れているのではないでしょうか。M$以外の競合製品を使わないなら苛めるなんてこともしていると思われる。

>>257
> C#とJavaの違いって各地で色々論議されてるし、漏れも参加してるんだけどJavaらしいことを
> J#.Netでできるんだよねー
J#ってRMIが使えないのがちょっと。Windows限定はね、他OSへの移植が面倒くさいのではないかと。

> でもthrowsって言っても下位で利用しているツールが何をはくかなんてあんまり興味ない。
メンテナンス性に影響でないかな? もともとそういうプログラムを作る必要がないなら興味がわいてこないのも無理も無いと思う。

> 続行可能か不可能かくらいなんだよ。
> その辺があるとシステム固有の例外に集約して投げなおすだけになっちゃうことが多くて
> ほとんど意味を成していない。
複雑なプログラムを書いているとそうも言っていられないものです。

> .NetであればSystemからのthrowsは知りたいとは思うけど、それを自分で書くのはどうかと思う。
> 勝手なこといってるけど。
C#のSystemってクラスでなくパッケージ名(namespace)だったんですね。
System.out.println()とSystem.Console.WriteLine()で騙されました。

CompositeやVisitorパターンでは、自作例外クラスは必須です。
非常に便利です。あのパターンで、スーパークラスのメソッドで例外を無条件でスローさせて、サブクラスがそのメソッドをオーバーライドしたときのみ
スローさせないという仕組みに感動した!
Exceptionクラスしか投げないというのは情報が少なすぎです。

> それよりJavaはクライアントに本気でswinguiとかで浸透させようとか思っているの？
> それに比べて.NetやKylixだっけ？の方向性はあっていると思うんだけどSwingの普及は長期的な作戦が必要だと思う。
いずれマシンのスペックが向上し、Swingを使おうとそれ以外を使おうとほぼ変わらないとすれば、ポータビリティの高い言語で作られたSwingがいずれ浸透すると思う。現状ではとても無理でしょうが。
使い捨てでないプログラムであれば、Swingは使い道あると思う。
といっても今は、IBMのSWTの方がいいかな?

Kylixはどれだけ普及しているのだろうか。Linuxをちょっと改造するために作られたように見える。

>>260
> J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？
>>259ではありませんが、
もろにあります。>>261 の企業のほかに、
IBM, 東芝、あとどこだったかな。
製造業、工場、金融機関、医療機器だったかな。
ミッションクリティカルな現場ではよく使われているらしい。
オークションサイトでも使っているところがある。
一見JSPしか使っていないように見えるけれど、Solaris上で動き、J2EEも使っているらしい。○○王ーク○○ンというサイトだったかな。
お金が絡みますからね、ちょっとしたミスも許されない環境を構築するには信頼性の高いJavaがよく適しているようです。

> ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
> いっぱいあるのもどうかと思う。
>結局互換性ないしね。

Webサーバの違いによる互換性はさほど影響にならない。
バージョンの違いによる互換性の悪化は、
モジュールを自分でmake(WinならVC++のmsdevか?)すればよい。
他はちょっと修正を加えればよい。
100PureJavaが実現されなくとも他の言語と比べほぼ100%近いポータビリティを実現できるというのが優れている。