■CGIは死滅。これからは.NETできまり■
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
02/06/03 17:59ID:4sLvUkB0これからはゲイツ様の.NET。これ最強。
馬鹿みたいにいつまでもCGIなんて使ってるな。
PERL最悪
こらからはC#
はい、みなさんもご一緒に
0136nobodyさん
02/07/11 22:16ID:Zm0ibmf3統合環境ってなんとなく解る。
やっぱM$で環境構築すれば.netにVSSなどのソース管理、データベースなど、
全てM$製品で統合されてるもんね。
でもやっぱセキュリティー的にどうしてもIISは厳しいね。
まあSUNが何かやってくれるさｗ（注なんとなく）
0137nobodyさん
02/07/12 01:48ID:nhVIZGe1複数のツール立ち上げてウインドウ複数並べて作業する
ようになると重くてでかくてうざくなってくる。
viって慣れてくると画面あんまり見ないで作業できるように
なるんで目が疲れないよ。
統合環境で細かい表示をジーッと見て作業するとこを、
天井見ながら時々画面をチラリチラリって感じ。
カーソルキーやファンクションキーなしの操作体系のなせる技。
0138nobodyさん
02/07/12 02:58ID:???はっきり言って押しつけがましいね。
エディタは emacs メイク、コンパイルはエディタから perl とかの
スクリプト起動してメイク自動生成→コンパイル。
ソースファイル管理は rcs とか…
データベースは oracle とか、postgre 使い分け。
みたいな感じで、ここの環境が独立して無くて、全ていっしょくたにして
それを無理やり押しつけている所が終わってる
0139JAVA派
02/07/12 02:59ID:ergjW3giある意味VBより楽かも
0140nobodyさん
02/07/12 03:22ID:???0141nobodyさん
02/07/12 17:56ID:hAbFEuiX0142nobodyさん
02/07/12 21:29ID:???Servletみたいなオモチャは論外だし...
0143nobodyさん
02/07/12 22:01ID:???0145nobodyさん
02/07/16 06:07ID:Ry1Lbpnm0147nobodyさん
02/07/17 17:36ID:U/wUJaxQ0148コギャル＆中高生
02/07/17 17:39ID:mpYxsadtお役立ちリンク集
必ず役立ちます
コギャルとＨ出来るサイトはここ
ヌキヌキ部屋へ直行便
↓
http://kado7.ug.to/wowo/
0149nobodyさん
02/09/05 13:48ID:LICGBdA8servletより遥かに簡単で楽なんですけど、
参考にするべくサンプルとか探してみても
ASPもWSHもVBScriptばっかで嫌になります。
JScriptは迫害されているのでしょうか。
それはともかくアパッチでASP.NETが
使えるようになる日が早く来て欲しいです。
0150nobodyさん
02/09/06 23:53ID:???本気でサンプルを探してるんなら、CodeProjectを見るのが一番速い。
あとはGotDotNetの日本語版を読めば、大抵の事は 2日で出来るようになる。
だれか、展開・折りたたみのできるDataGrid教えてくれ…。
プラス、マイナスマークを押したら、カテゴリー単位で表示・非表示が制御したいのです。
0151nobodyさん
02/09/09 11:11ID:aL7nmFw80152nobodyさん
02/09/09 16:16ID:???まぁそれなりに便利です。.netはどうですか？
0153nobodyさん
02/09/09 19:17ID:???0155nobodyさん
02/09/10 00:20ID:???void main()
{
while(1){
printf("\<\<1必死だな(藁<br>\n");
}
}
0156nobodyさん
02/09/11 17:21ID:fAKQNhXHWindowsのApacheまたはIISのモジュールにできるほか、
単体のexeにコンパイルすることも可能。
このexeは簡易Webサーバとしての機能も持つ。
exeのサイズは大きくなるものの、単体で動作可能だ。
要するにIISは不要ということだ。
セキュリティ的に危険度の高いIISを排除できる。
さらにネイティブコンパイルされているため、
ランタイムは不要であり、高速に動作する。
鯖にexeファイルを置いて実行させるだけの手軽さ。
簡易Webサーバと言ってもBasic認証などの機能があり、
プロパティを設定するだけで利用可能。
このWebアプリケーションをRADスタイルで開発できるの
だから、ASP.NETなんて利用する気も起きないね。
Kylix 3（Delphi言語版）も同梱！
http://www.borland.co.jp/delphi/del7/feamatrix/
.NETランタイム無くても良くて、Linuxにも逝こう出来ちゃうなんて。
.NETがDelphi/VCLをコピーしたかと思ったやさき。
C#やVBはM$囲い込みの道具だからLinuxどころかWin32ネイティブも出来ないんだからねえ。
0157nobodyさん
02/09/11 20:13ID:uxjNwnEp0158nobodyさん
02/09/15 21:55ID:OQ+lbN8D概念だが、JSP + ServletのRequestDispatcherとかStrutsみたいな
MVCモデルは、システムとして用意されてないの？
同じオブジェクトを使って、違うcontent-typeの出力をしたいんだが、
いざtext/htmlのページだけ作って、そういうのがないことに気がついた。
結構、controllerという概念、仕様書書きやすくて好きなんだけど。
0159nobodyさん
02/09/16 03:05ID:sO0PTaDQ疲れと共に、だんだん、むかついてきた。
・VS.NETが遅すぎる。セレ650のVaioSRX3だが、このスペックで
この遅さだと1GHzでもきっと速くないと思われ。
aspxのコードビューの編集とデバッグモードは遅すぎ。
・Web鯖のポート変えたら、プロジェクトそのものが開けなくなったぞ。
どうやって変更するんだ??? 変なところに依存してんじゃねーよ。
いろんなところラッピングしやがって独自テクノロジーが意味不明すぎ。
Unixなら、先人の文化だから勉強する気になるが、MSの作った仕様で
苦労したくない。苦労しないのが唯一のＭＳの魅力だろ。ASPの簡単さに
比べると、無駄に複雑な印象。
WebFormsはWebを知らない人にと作ったものらしいが、Web知ってる
人には複雑で、もどかしい。やりたいことができなくて、結局、getで値の
やりとり実装してるし・・・。そういうのはやらずに済むのかと思ってた。
しかし、鯖イベントは、HTMLを読めないと意味が理解できないのでは？
クラと鯖のイベントが、未だにわからない奴が多量にいる現状では、
なんかワケワカになる奴続出に違いない。
・・・というわけで、商売に、特別なメリットなしに.NETを導入するのは、
やめようかと思った。
0160nobodyさん
02/09/16 21:08ID:???いやみとかでなく、あんまり盛り上がってないようなので・・・
0161nobodyさん
02/10/15 21:07ID:???0162nobodyさん
02/11/02 10:50ID:VTz+k6IE＞・VS.NETが遅すぎる。
初回アクセス時のコンパイル終われば早いよ。
＞・Web鯖のポート変えたら、プロジェクトそのものが開けなくなったぞ。
テストサーバや稼働サーバのポート変えれば、どっかで設定するのはどんなツールでも共通っしょ？
＞WebFormsはWebを知らない人にと作ったものらしいが、Web知ってる
＞人には複雑で、もどかしい。やりたいことができなくて、結局、getで値の
＞やりとり実装してるし・・・。そういうのはやらずに済むのかと思ってた。
禿同。
実にｲﾀｲんだよこのへんが。
＞しかし、鯖イベントは、HTMLを読めないと意味が理解できないのでは？
＞クラと鯖のイベントが、未だにわからない奴が多量にいる現状では、
＞なんかワケワカになる奴続出に違いない。
これまた禿同。
手の届かない場所のイベントが取れるとは無理が過ぎる。
ここで切る
0163nobodyさん
02/11/02 10:50ID:VTz+k6IEWebFormsについて多くのメリットや解説を裂いている現状が問題なのであって、.NETそのものが寒いとは思わない。
まず大事なことは、「スパゲッティコードよさようなら」的なまやかしを信じないことだ。
あるいは「DLLヘルはなくなる」なんてことも。
これは「オープンソースは次代を救う」的な屁の突っ張りにもならない神話をUNIXｦﾀが信じ切った過ちに似ている（結局は商売上手に新たなるﾈﾀを提供したに過ぎない＝悪い事じゃないけどね）。
.NETの導入によってWebソリューションの開発が被った最大の恩恵は、まともなオブジェクト指向の一枚岩の開発環境だと思う。
真の再利用可能なコンポーネント指向もやっと実現できた。
今までのCOMベースでは、結局は再利用ってものが単にOLEオブジェクトのインストールと変わらないようなレベルであったように思う。
純粋にクラスなんだかよくわからない参照を使ったり、そういう曖昧さや誤魔化しなどは二次的なレベルに追いやられつつあると感じる。
WebFormsのようにｶｽで使えないものは捨てちまえばいいんだが、これが生きる場面もある。
たとえば.Net Framework SDKのサンプルにもあるが、DetaSetをページ上のエレメントにバインドする作業（便利でありかつテンプレート指定による柔軟性も高い）。
これをコードパート＜＝＞レンダリングパートの行き来をせずにスマートに行えるのは好ましい。
また、コードビハインドも制作物をより取り扱いやすくしてくれたと感じる。
分離されたコード部は記述もよりネイティブな書き方（端的な例がImportsなのかImportなのか）が出来、俺は好きだ。
長くなりそうなので切るけど、細かい部分でも最適化が進んでパフォーマンスも良くなっているよ。
たとえばstringbuilderなんかも良い例だね。
逆にADO.Netは悲観的ロックの未実装など課題も残しているのも事実。
いずれにしても、「やめようかと思った」っていうそのセンスはある意味正しい。
だが、実際にそのままやめてしまうには惜しいよ。
もう少しでイイからいじってみな。
見えてくるものがあるはずだ。
あんたならきっと活用できるし、その価値はある。
0164nobodyさん
02/11/02 14:26ID:???.NETは産まれる前から死んでたがな。
0165nobodyさん
02/11/15 22:16ID:Y4BGXbI0VS.NET買ったけど、インストールすらしたことないよ。
.NET Frameworkについてくるリファレンスだけで結構事足りない？
0166nobodyさん
02/11/16 00:28ID:???インストールもしてないのに必要ないって言ってる・・・
まずはインストールしてみて
オブジェクト名のあとに . を打ったり
newのあとに半角スペースを打つ楽しさを感じてください。
それでもダメなら本当に必要ない人なんじゃない？
0167nobodyさん
02/11/16 01:17ID:???VBライクな開発ができるし、インテリセンスが利くし、本当に便利。
ただ、デバッグが致命的に重い。あれでステップインするくらいならデバッグプリント入れたほうがマシ。
というかそもそも今までWeb開発してきた人はデバッグプリント入れるほうがデバッグ手法として慣れているから、あの重さのままではあれでデバッグする人は少ないと思う。
0168nobodyさん
02/11/17 03:35ID:T8HBoF4m１６５じゃないけど。
確かにそれは楽なんだけれど、どうもVS.NETってがさばるような気がするんだよね。
0169nobodyさん
02/11/17 04:11ID:LInhlSssネタを提供してくれ (w
> 電子政府は脱ウィンドウズへ OSに公開型導入の動き［11/16］
>
> 1 ： ◆y9CAMELxSM ＠キャメルφ ★ ：02/11/16 06:06 ID:???
> ■電子政府、脱ウィンドウズへ ＯＳに公開型導入の動き
> 政府は、インターネットを通じて申請や検索ができる「電子政府」の安全性を高めるため、
> 政府内ネットワークのコンピューターで採用する基本ソフト（ＯＳ）の見直しに乗り出す。
> 設計内容が公開され、独自に安全対策を講じられる「オープンソース」と呼ばれるＯＳの
> 採用を想定。現在は政府内コンピューターのＯＳの大半を占めるウィンドウズから切り替え
> が進む可能性が高い。
>
> オープンソースＯＳでは、設計図にあたるソースコードが無料で公開されている。「リナッ
> クス」が代表例。利用者はライセンス料を支払う必要がない。プログラムの変更も可能で、
> トラブルに対応するためのシステム管理がしやすいとされ、世界的に導入の動きが出ている。
>
> 暫定ソース：
> http://www.asahi.com/paper/front.html#top
0171nobodyさん
02/11/17 09:35ID:6Mbqwujtっていうかソース読めない奴。俺も読めないけど。
0172nobodyさん
02/11/17 19:02ID:c1yf+WkVあんたの書くASP.NETのソースが、
1.Request
2.Requestパラメータの処理
3.DBのアクセス
4.Responseデータ作成
5.Response
で終わるならエディタで十分かと。要は、元来ASPが担っていた
メインの用途だ。
それよりも、１階層でも深いクラスの階層を作っていこうと思うなら、
絶対に統合開発環境があったほうが良い。
ASP + COM（メインはCOMだが）で、WebServiceToolKitを試したときは、
途方に暮れたぞ。
0173１５９
02/11/18 02:12ID:nWPPDALB一ヶ月半も前の書き込みのレスだから、気がつかなかったよ。ｽﾏｿ
今度、プルダウンメニューに連動して動的にテーブルを切り替える処理を
JSP + Servletでやらなきゃならない。ASP.NETなら、こういうのすげー
楽だよなぁ。何せ、ベタなform + JavaScriptのやりとりを自動生成
してくれるわけだから、工数削減には確実に寄与する。実際、同じやり取りをする
JSP<-->Servlet連携の設計書書くのがバカバカしい。
で、漏れじゃないが、昔、同じ実装をASP + RemoteScript + DHTMLでやってしまったんだ。
それのメンテは最悪だよ。まさにパズルを解くようなデバッグをしなきゃいけない。
鯖側の通信Objectが理解できないと何も帰ってこないし。
そんな技術を作るMSもMSだが、あぁいうDHTMLの発想がASP,NETの発想の原点
ではあるなとは思う。そういうのを経験してるから、漏れ自身はASP.NETの
イベントの発想はとても進歩を感じてるよ。ようやく、まともな開発ができる！って。
0174１５９
02/11/18 02:13ID:nWPPDALBあと、これだけは間違いないのは、とても便利なクラスライブラリが、
一パッケージに標準として入っているのは、すごく使いやすいのは確か。
恥ずかしながら、ドキュメント日本語っつうのも含めて。
最近のお気に入りクラスライブラリは、XMLのソートが簡単に
できる奴だな。週末プログラムでソートなんて地味な処理書きたく
ないんで、とても役に立ったよ。
また、最近思うことだが、鯖はUnix Java or ASP,NET、クライアントは.NETのWinFormsを
使い、インターフェースはSOAPを使って、Webの管理ツールや簡単な業務系でクラサバ的に
Webアプリを組む発想が復活するんじゃないかな。
Flashのことを日経ではクラサバの復活とかほざいてるが、そのレベルでクラサバ
云々言っていいのなら、UIの完成度も生産性もFlashの比ではないんだから、
こっちこそが本命だろう。
次に設計する予定の奴もJava鯖ベースなんだが、ゆくゆくはUIを、ヘボいブラウザ
だけじゃなく、WinForms＋SOAPに入れ替えられるように設計するつもり。
0175nobodyさん
02/11/18 03:55ID:ww2xQXdX0176nobodyさん
02/11/18 10:19ID:CV5zPk7h禿同
最低でもJavaは標準のドキュメントをMSDN並にしてほしいよ
Javaやってるけどやることなすことくっさく思えるね。
0177nobodyさん
02/11/19 00:13ID:H3GSXYedハロウィン文書( 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はウィルスだと相変わらず強烈な毒舌を吐いたようだ。
0178nobodyさん
02/11/19 01:32ID:GBmVLJin落とし穴も何も、.NETの「言語に依存しない」から、多数の言語でシステム
作る奴なんて、実践する奴いないだろ。
ありゃ、ただのマーケティングだろ。おかげで、富士通はCOBOLを作り、
ボーランドはDelphiを作るわけだ。コアは、Windowsなんだから万々歳だろうな。
こちらは、これまでのC++のCOM + VBのプログラミング程度の
認識でいれば、何の問題もないだろう。
まっとうなマネージャーだったら、２種類以上のマルチ言語なんて許さない。
作った奴がいなくなったらメンテできないようなマイナー言語を使わせる馬鹿が
どこにいる。
COBOLは知らん。COBOLから抜け出せない奴は、言語の書き方ではなく、
オブジェクト指向の設計で悩むんじゃないのか？
ちなみに、ＭＳがNetscapeやRealNetworksをタダ製品でメタメタにしたのと同じく、
自社のコアビジネスモデルであるOSとDBをタダにするオープンソースが怖いのは
当たり前だよな。労働の対価にお金を貰うという、単純なビジネスモデルが曖昧だから、
玉砕的に見えるのは確かだしね。
0179nobodyさん
02/11/19 01:40ID:???動かないじゃん。NOMO 連中もさじ投げて WINE 入れれっつー事になったし。
エミュもどきいれて動きますって言われてもただの詐欺だろ。
0180nobodyさん
02/11/19 03:13ID:Ug40ElFc三流馬鹿が。M$にはお前より優秀な人材は五万といる。っていうか
おまえがすげープログラマーなら向こうは実力にあった給料で
迎えてくれるぜ。というと信者と言われるが、仕事はLINUXでやってる
0181nobodyさん
02/11/20 00:39ID:???誤爆？
誰に言ってるんだろ。誰もMS社内の心配なんてしてないと思うけど。
0182nobodyさん
02/11/20 01:12ID:6FfOwQwn0183nobodyさん
02/11/20 02:24ID:OBXJBU+B確かに忘れてはならないと思います。
M$が甘い汁で迎えてくれても、(経済的に余裕があれば)拒否するかも。迎えてくれるほどの能力はいまは無いけど。
金があるだけじゃ、夢を実現できぬ。
金だけでなく技術も必要。夢や技術だけじゃ金は入ってこないけどさ。
>178
マルチ言語を許さない。やはりこれからの時代は、既存のコードを再利用しない限り、そうあるべきですね。M＄の.NETは多くの技術者にとってM$の誇大な宣伝、情報操作、戦術としか見えないんですね。
ということは、これからはC#と.NETできまりとは言い切れない?
参考になりました。Thank you.
0184nobodyさん
02/11/20 02:40ID:6FfOwQwnSUNなどがリストラするなか、M＄だけが利益を拡大させてる。
金があれば、東大、京大、MIT,ハーバード卒の学生、経験者も
余裕でやとえる。もちろんM$が嫌いな奴はやとわれんが、
この時代金だろ。
0185nobodyさん
02/11/20 03:07ID:G3Is552Vしかしですよ、C#で作ろうが、VBで作ろうが、コンパイル後の動作はほ
ぼ一緒という結果が出ている限り、できるだけ作業効率の高い言語を
使うべきではないかと思いますよ。
ASPからASP.NETに移行して、全部C#で書き直していますが、へぼ
プログラマにとっては超えにくい壁に結構あたって大変なんですわ。
なので考えるのがめんどくさいところは全部VBで書いたクラスに引
数渡すことにしてるであります。
0186nobodyさん
02/11/20 03:28ID:6FfOwQwn0187nobodyさん
02/11/20 04:02ID:TSmqHzBZコンパイル後の動作とは、速度のことですか?
もし速度だとしたら、
速度を重視するよりもオブジェクト指向的な拡張性、可搬性、コードの可読性を重視するからVBではなくC#を使うのでは?
VBは型の概念が曖昧だから、余裕ができたらC#に移した方が良いかと。
型が曖昧な言語は大規模化(複雑化)するとソースが読みづらく、何が起こるか、どんな潜在的なバグが発生するかわかりにくくて怖い。
M$側もVBプログラマをいかにしてC#に移行させるか、ということを心配しているようですし。
C#もJavaよりも余計に余分な機能が付いているのが、かえって仕様を複雑にしコードの可読性を低下させる素を持っているかのようで奇異にみえます。
0188163
02/11/20 13:35ID:9V10m3eFどんまい。
ＭＳの上手さを感じるよ。
昔JSP+Servletをやって、わけあってやめたんだが、その「わけ」の部分に対する回答がかなり盛り込まれている気がするんだよね。
１５９とそのへんは同じ感覚なんだろうな。
ASP+RemoteScripting+DHTMLについて、ASP + RemoteScriptingってところまでは有りだと思うんだよ。
そこに+DHTMLってのがかなり辛そうだ。
DHTMLってのも込み入ってくると、DOMレベルのバグなんだかコードのバグなんだか判断が面倒になる上にリモートの要素まで関わってくるからな。
そうしたほうが良さげなケースでも、どうしても避けざるを得なかった。
加えてjavaに関する不信感かなあ・・・（笑）
0189163
02/11/20 13:45ID:9V10m3eFうん、その一貫したクラサバのアーキテクチャの鯖側にWebアプリケーションがあるってのがずっと求められてきた姿だと思うんだ。
それを実現するためのプロトコルがSOAPであり、またXMLでもあった。
ただこれらの土台ができあがっているにもかかわらず、それを有効に実装する岩盤みたいな存在が不足してたんだよね。
あまたの企業が寄ってたかって料理しようとしたけれど、結局はたいしたものは出来上がらずにここまで来た。
１５９が言うように、Flashでクラサバ復活云々なんてのは寝言以外のなにものでもなくって、まさに.Net的な総合的（総合的ってのが大事）アプローチが大事で、それさえ著に付いたばかりだ。
矛盾しているようだけど、「高機能なダム端末」なんだよね、ブラウザの使命って。
それ以外にWinForms+SOAP、あるいはモバイルベースのWinForms+SOAPの実装が見えてきてこそ、Webアプリケーションの存在価値が上がるってもんだね。
UIを入れ替えるっていうか、できるだけデータ交換のレベルでアプリケーションが動作しているように設計していくことが望ましいと思うし、それこそが.Net的であるんだろうね。
お互いに頑張ろう！
0191163
02/11/20 13:54ID:9V10m3eFオブジェクト指向的な拡張性、可搬性、コードの可読性はVB.NetとC#そこまで大きく差があるとは思えない。
また可読性って事に関しても、それはあくまで主観的な問題であろうし、どんな言語で書いても善し悪しが出るのは個人差ではなかろうか？
.Netに関する板だからあえて言うけれど、.Net以後のVBで型は曖昧ではない。
それからMSはC#にいかに移行させるかなんて心配はしていないと思う。
最大の関心事は、「いかに膨大な数のVBプログラマーをそのまま.Netに移行させるか」だ。
言い換えれば、これは「いかにVBからVB.Netに移行させるか」と捉えるのが自然。
またC#javaよりも余計に余分な機能が付いているってのもなんだか不自然に聞こえる。
機能ってのはあくまでclassからの派生のことでしょう？
0192nobodyさん
02/11/21 01:23ID:???自分達でコンセンサスが取れてれば、ＶＢ使おうが、ＣＯＢＯＬ使おうが
かまわないと思いますよ。それが.NETのメリットなわけだし。
しかし、１年後に、ソース書いた奴が、会社、やめちゃったりして、
後日、クラスのソース開いて、いきなりCOBOLで書かれてたら途方に暮れるだろうなぁ。
あと、VBとC#で、ループのカウンタの取り扱いとか変わったりしない？
忘れちゃったが、VBのuboundとC#のlengthって違う値になるんだっけか？
仮に、それが違ってたとして、そういう細かいところで、エラーにならない
不具合を作っちゃったら最悪だし。作業効率とは裏腹に、間違いの可能性
を減らすってのも、避けたい理由かなぁ。
0193わ ◆nZptw02DTU
02/11/21 01:34ID:Ddc96KDpでもCOMコンポーネントと同じ感じで完全パッケージ化させてしまえば中の言語なんてどうでもいい。
その辺を考えれば単純に１つのプロジェクトだけで考えるんじゃなくって過去の共通クラスを流用とか、
コントロールクラスを持ってきてバージョンあげていったりとかできるわけよね。
0194nobodyさん
02/11/21 05:39ID:OuOZoNxz0196nobodyさん
02/11/21 08:21ID:hkX17jeKBasp21のように完結した汎用モジュールなら、それもアリだが、
実際は、流用して改造したり、後日オーバーロードして拡張したくならない？
（継承ではなく・・・。）
ＭＳもカプセル化による隠蔽が多言語利用の前提になってるような気がする
んだが、そこまでの汎用化は、漏れ的には、考えてる暇はないので、
最終的には、拡張、拡張で汎用モジュールの機能アップを実現したいので、
「完全パッケージ化」という発想自体が、なかなか理想的な話だとは思う。
漏れ的には、汎用モジュールであっても、後日の情報共有のしやすさ、
カスタマイズのしやすさを重視したいなぁ。
その辺は、どのようにプログラミングするか？という話なので、あくまで
「ウチの場合は」ですけどね。しっかり隠蔽して流用できるものが作れるなら
おっしゃるとおり。
0197わ ◆nZptw02DTU
02/11/21 09:40ID:WZB8FmKXでもC#でしか作るきないけどね。
今までのMSの言語体系って
C++,MFC <=上級者
VB <=初心者、中級者
っていう扱い
でも、この全部を内包してC#に移行できるだけのパワーがC#にはあると思うよ。
結局全社で統一させる場合にはC#かVB.Netでしょう。
でも、私としてはどっちの言語で書かれていても同じことだからかまわないなぁ。
XMLWebサービスなんか言語は外からわからないしね。
COBOLのバッチプログラム -> COBOL.NetによるXMLWebサービス
こんなんができれば最高だとは思う。
0198bloom
02/11/21 09:55ID:kapC4rRRhttp://www.agemasukudasai.com/bloom/
0199nobodyさん
02/11/22 02:37ID:8l2TihZU確かに個人差が無いとはいえない。集団でプログラミングするときコーディング規約、ある程度はガイドラインを定義すればどうにかなるかもしれませんね。
C#がJavaより余分な機能があるというのは、
class からの派生とかではなく、
Javaでは複雑になるからとC/C++あった機能を排除したが、
C#では復活している機能(仕様?)があるということです。(機能とは言わない?)
JavaにはないがC#にある仕様(機能?)を適当に列挙
- Cとはちょっと異なる構造体の復活
- unsafe 修飾子によってそのスコープ内でCのようなコード(ポインタ、アドレス操作可能なコード)の埋め込みが使える。
- 列挙型の復活
- JavaBeansに相当するプロパティ機能がデフォルトで使える、set, get修飾子使用。
- メソッドの引数の種類(参照引数、出力引数、可変長引数)が余分に増えた - デレゲート
- 演算子のオーバーローディング
- インデクサ
- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。
0200nobodyさん
02/11/22 02:49ID:8l2TihZU便利とはいえ、こんなに余計な機能が多くあるとこれらを使ったソースコードの解読、修正、バグ検出するとき、Javaで書いたのと比べると苦労しそう。なんでもできるということはその反面ソースコードを読みにくくする。
余計な機能を追加するくらいならクラスとして提供すればいいのではないか、というのがC#の仕様を見たときの感想。
C#で集団で新規にコーディングするときにこの機能は使うな、と規定を定めればどうにかなるかもしれません。
しかし、誰か個人がコーディングしたこれらの機能をフルに使用したコードを流用したいときがあるかもしれない。そのときそのコードがどれだけ正確か、などを確認することも起こりうると思われる。
Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。
Javaならクラスの継承を意味する修飾子は、extends、インターフェースの継承を意味する修飾子は implementsでありこれをみるだけですぐにクラスかインターフェースかがわかる。
0201nobodyさん
02/11/22 02:54ID:8l2TihZUC#だと :: なのでわからないためにインターフェース名の頭にIをつけているのだろう。::の方短縮できるからいいだろう、C++プログラマのために、と思ってこのようにしたと思われるが。言語仕様の設計そのものに問題があるようなきがする。
クラスやインターフェースがあれば構造体も列挙型もいらないような気がする。これらは、速度を高めるために、Javaのプリミティブ型に相当する新しい型を定義する取り入れられた機能と思われる。
オブジェクト指向的な観点で言えば、本来型はすべて参照型にすべきと思われる。が、C#の構造体は値型。継承できない構造体とクラスをうまく使い分けるっていうもの大変そうだ。
演算子のオーバーローディングもクラスとメソッドを定義すればいらないだろう、と思う。記述方法が短縮できる以外にメリットは無い。逆にコードの可読性が低下するという欠点がある。
速度を気にしなければ構造体も列挙型も不要と見える。
C#をプラットフォーム非依存にさせると目指しているM$の発言にも不信感を感じる? 言語非依存にすればC#以外の言語でかかれたものがプラットフォーム非依存な言語であればWin以外の他のOSでは使えない。.NETも同様?
0202nobodyさん
02/11/22 02:56ID:8l2TihZU.NETの利便性というのは殆どがWinに依存しており、セキュリティ性、プラットフォーム非依存性の犠牲の上に成り立っていると思う。
.NETで開発するときはこのあたりを大いに覚悟しなければならないと思う。
0203nobodyさん
02/11/22 07:29ID:???そうだね、確かに数々の指摘はその通りだと思うよ。
それらは機能というより仕様だね（レスに書いてくれたけど）。
インターフェイスに関する存在の冗長性やオーバーローディングの曖昧性も、仕様としてはかなり不細工に感じるのは自然だと思う。
ただ、それぞれにはそれなりの存在理由があるので、言語として整理整頓されましたということが自慢できた時代とは異なる昨今でプライオリティが低かったのではないかな。
それから保守などについてだけれども、圧倒的多数のコードの寿命が極端に短くなった現在、次々と新しく書き直されることがより求められている気もする。
C#をもっとブラッシュアップしてしまえば良かったのにって思うけれど、VBについては、まあこの程度でよしとして良いんじゃないかな。
セキュリティもひっくるめたあらゆる利便性がWin依存というのはなかば当然だと思う。
もっとも、これはC#などに限らずあらゆる言語や環境に言える事じゃないかな。
たとえ言語がオープンであっても、圧倒的多数のクライアント環境はWinであり、Winには固有のシェル環境があり、またインターネットへの一般的窓口であるブラウザはIEが多い。
最適化した実装を施したいと考えればその縛りは必ず受けざるを得ないよね。
この企業の姿勢は「客」という存在を絶対的な立場から見てどこにあるかとらえて徹底した征服を行い、誰しもがそれに依存せざるを得ない状況を作り上げることにある。
それが今後も変わるとは思えない（善し悪しということではなく単純に考えての話ね）。
それに、恐らくＭＳのセールストークを全部信じてわくわくしている開発の現場って限りなくゼロに近いんじゃないだろうか。
0204nobodyさん
02/11/22 09:52ID:???連携HTMLは、HTML3.2の仕様を満たすんだったけ？
.NETが最初に発表されたころのセミナーで聞いた話だから、実際
古いネスケ4.04とかで、どう動作するのかは検証してないけど、
サーバーサイドオブジェクトなどのイベントモデルを作った最大の
メリットは、POSTを主体としたサーバー通信を自動化しているところで、
その目的は、IEに依存しないというところだと思う。
そういう部分では、.NETという枠組みでは、普遍的なところへの
チャレンジがあって、これ自体は、とてもMSっぽくないなと思って
わくわくした。（ただ、FAQになりそうなのが、サーバーサイドの
プルダウン選択したら、FlashやEmbedのWMPが初期化されちゃいました。
バグですか？・・・とか。）
ところで、IE EmbedできるActiveX OCXって、作れないん
だよねぇ・・・。アプレットの入れ替えとか言って、
サンドボックスのセキュリティとかになってしまうと、
困るんだけど。ActiveXは、わかってて使う、悪魔の魅力こそが魅力なので。
0205わ ◆nZptw02DTU
02/11/22 10:04ID:gx0Fd/Vkなんでないねんていう機能ばかりじゃないか？
- 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#とかの方がいいと思わない？
0206わ ◆nZptw02DTU
02/11/22 10:07ID:gx0Fd/Vk- インデクサ
java: a.get(1)
C#: a[1]
Cのchar*なんかの時と似てるけど、レコードはインデクサなんかが似合ってると思わない？
- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。
これはちょっと問題かもしれない。
CLRでは動くけど、CLIでは動かない範囲ですね。
わたしはこれらのunsignedは使わないと思うけど、最悪ガリガリのチューニング用か？
>Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。
昔はクラスにCをつけるようにとなっていたよね。
Javaをしていると継承関係がややこしくてインターフェースかクラスかわからなくなるよ。
でも.Netのように現在は入り組んでないライブラリでも、今後入り組んでいくとおもう。
その時に真価を発揮すると信じているよ。
どうせならコンパイルオプションではじける設定もほしい
0207わ ◆nZptw02DTU
02/11/22 10:07ID:gx0Fd/Vkあと忘れ物だ
!!!throws!!!
これってあんまり役に立っていないと最近思う。
RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだって。
この機能はスパッと切って正解だったと思うよ。
!!!ボクシング／アンボクシング＆すべてがobjectを継承していない!!!
javaでは値型が特殊な変数になっているためにVectorなんかにそのまま入れれない。
これって誰も言わないんだけど致命的な設計ミスじゃない？
んじゃ
0208nobodyさん
02/11/24 00:22ID:???0209nobodyさん
02/11/24 02:37ID:???0210nobodyさん
02/11/24 02:59ID:???無駄な関数や多少の冗長性があっても大した問題ではないしね。
表面的な実装がどうであるかよりもむしろ深層部分で変数・型をどう扱っているかとか、もろもろ無茶苦茶細かい部分に関する部分が気になるでしょ。
そうして、そのような箇所はそれなりに時代に合わせた設計が為されているしね。
ここ１０年の流れとしては、「どの言語がどれだけ素晴らしいか」ということでなく、「どの言語がどれだけ<<実効性のある総合的環境>>を持つか」じゃない？
Javaにしてもそうだったし、インタープリタがあらゆるブラウジング環境に実装されだした流れにしてもそうだった。
今後もそうとう長い期間、そんなＭＳ的なるアプローチが支配的であるように思うな。
理念の先行や重厚な布陣よりも、即効性とゲリラ戦が主流でしかあり得ないだろうし。
0211nobodyさん
02/11/29 04:43ID:???0212nobodyさん
02/12/02 23:54ID:EErAQyXcすか？.NETやるならSQL Serverの方がイイ！っとかあります？
0213nobodyさん
02/12/03 00:08ID:???そもそも現時点では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が対応ライブラリ出したらしいけど）
0214わ ◆nZptw02DTU
02/12/03 01:11ID:hVpUQfs8SQLサーバは System.Data.Sqlclient
Oracleはオラクル用のドライバが出たからSystem.Data.OracleDriver?かなんかで使える。
クラス名は違うけど基本的に同じだから置換するだけでつかえる。
ただ移植度はADOより下がっているのは事実かもしれないね。
これから選ぶっていうならSQLServerだとは思うけど、Oracleだから敷居が高いなんてことはないから安心して。
0215nobodyさん
02/12/03 07:32ID:vjdfg6sRThanx!
うちはプチOracle使いからプラチナマスターまで揃ってるOracleマンセーな
ところなので.NETはイカンのかと思ってましたよ。
移植度が下がるってのはどういうことでしょうか？うちだとSQLでselect文も
DDLもDMLも書いて、ADOでレコードセット開いたり、コネクションで実行して
ましたよ。それができないって事はないんでしょうけどどの辺が下がるんです
か？
0216212
02/12/03 08:31ID:???System.Data → System.Data.Sqlclient
補足してくれてthanks。
>>215
>移植度が下がるってのはどういうことでしょうか
たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
ADOだったらConnectionStringを変更するだけで95%くらい移植可能だったんだけどね。
ちなみにうちの会社ではOracle＋.NETのシステムをこの前作ったよ。ASP.NETじゃないけどね。
0218わ ◆nZptw02DTU
02/12/03 10:48ID:hVpUQfs8>たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
それもそうなんだが、たとえばレコードセットで,movenextだ .updateだって使っていた場合には
接続文字列の変更だけなんだけど、.Netの場合自動生成でSQL文が出来るやり方があるし、それが主流
そうなると、どうしてもDB固有の機能が出てきちゃったりする。
私はDB固有の機能を使うの賛成なんでDBかわったらとうぜんソース修正して、最適化すべきだと思う。
シーケンスとIDENTITYとかもあるしね。
わかりにくくてごめん
0219nobodyさん
02/12/03 23:20ID:vjdfg6sR.NETにはSQL Serverじゃないとイカンのか！？という問題は、
.Oracleも可。ただし、.NETではADOを使わない(使えない？主流ではない？）ので
SQL Server<->Oracleの移植性は落ちる。
って事でしょうか。
.NETでのDBの扱い方とか色々勉強になりました。どうもです。
0220わ ◆nZptw02DTU
02/12/04 00:01ID:WXrBnaal.NetではCOMを利用できるからADOも当然利用は可能。
どうしてもサーバカーソルが必要な時になんかしか使わんときましょうっていうのが路線です。
SQL文がOracleとSQLさーばで互換性がないんだからその辺の移植性は仕方ないよね。
OracleとSQLサーバしか知らんけどDB2とかPostgreSQLとかどうなんかな？
0221nobodyさん
02/12/04 00:12ID:???0222nobodyさん
02/12/04 07:25ID:T4RIHtvZどもども。大変勉強になります。
ありがとうございました。
0223nobodyさん
02/12/04 10:16ID:+N9MX2bC0224nobodyさん
02/12/04 10:58ID:???ADOはADO.Netになっているねえ。
その辺のことはリファレンスにきちんと書いてある。
やっぱさ、一通りでいいからリファレンスって読むべきだと思う。
.NetになってからCOMをどう使うかってのも、各種資料では優先的な課題としていくつも例が挙げられているよ。
0225nobodyさん
02/12/04 11:00ID:???共通仕様ののSQLの範囲であればどれも一緒だけれど、各ベンダーはもれなく独自の関数やメソッドを持っているよ。
だからOracleとSQL Server程度に互換性はない。
0226わ ◆nZptw02DTU
02/12/04 13:15ID:7l5VzXUOま、そういうところやろうね。
ADOでRecordsetでのアクセスであってもほとんど、MoveNextとかを駆使する方法じゃなくって
更新はConnection.Executeでやっているのがほとんどだろうから、ADOと大して変わらない
という説明でもいいかもね。
0227nobodyさん
02/12/04 13:49ID:6UTJMisLC#使ってもいいよ
WINDOWSサーバーは高いしセキュリティー貧弱で
ウィルス攻撃の的になってるから
aspは流行らない
0229nobodyさん
02/12/04 16:26ID:YylN9yEh愛知県で初の逮捕者！
↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓
http://choco.2ch.net/test/read.cgi/bobby/1038742045/238
↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓（うｐ済み
http://comic.2ch.net/test/read.cgi/gcomic/1035547729/741
0232nobodyさん
02/12/05 00:44ID:yBeK83mMサーバカーソルってことは、.NETでフツーに開発するとDBへの問い合わせが遅
くなるんですか？
>>224
うちはまだ.NET使ってないからドキュメント無いんですよ。MSDNのWEBやCDに
入ってるかな。見てないや。
0233nobodyさん
02/12/05 01:00ID:PHFUTRWIその前にC#つかえこなせないだろ藁
0235nobodyさん
02/12/05 09:34ID:???>>>232
> 逆。
> ADO.NETはサーバとは非同期型のクライアントカーソル。
> ADOはサーバと同期を取るクライアントカーソル。
おしい。
ADOはクライアントカーソルと、サーバカーソル両方使えるのが正解。
0236234
02/12/05 21:32ID:???スマン。ADOのほうはクライアントカーソルは意図的に省いた。
ADOの場合、主流（というかデフォルト）はサーバカーソルだし、
UseClient（だっけ？）モードの実装はベンダに委ねられているので、
確かプロバイダによってはクライアントカーソルをサポートしてないものも
あるらしいと聞いたので。
■ このスレッドは過去ログ倉庫に格納されています