- 締切済み
VBの不安点
こんにちは。 4拠点計500ユーザ規模のシステム構築（ホストの焼き直し）を考えています。 上司から開発言語にVB（.NET）を提案されたのですが、元々ホストがCOBOLなので、PC版のCOBOLでやればバッチ処理もカバー出来、資産の流用もある程度は可能かと私は考えております（PC版のCOBOLはこれ以上の規模で数年開発をやっておりました）。 そこで皆さんにご質問させていただきたいのですが、VBでこの規模のシステム開発は可能なのでしょうか？私はVBだと小さなものしか作ったことがなく、不安です。 Windows、Office、Ie等、別製品のバージョンに依存したりして動作しなくなるといったことはあるのでしょうか？ どなたか経験ある方、回答をお願いします。
- mk2_pbylw
- お礼率0% (0/4)
- その他（プログラミング・開発）
- 回答数4
- ありがとう数13
- みんなの回答 （4）
- 専門家の回答
みんなの回答
- equinox2
- ベストアンサー率48% (321/660)
>NETでは画面遷移時のメモリ使用に不安があるということでしょうか？VBは重いという話はよくききますが・・・。 VB6までと比較すると、複雑な画面ほどEXEの立ち上がりが遅いので、 同一EXEで画面遷移する際は性能的な問題は少ないですが、別EXEを 頻繁に起動することになると遅さが目立ちます。 ＃逆に、繰り返し処理のロジックではVB6より早い >Windows、Office、Ie等、別製品のバージョンに依存したりして動作しなくなるといったことはあるのでしょうか？ これについては、VB6までとVB.NET以降ではまったく別物と考えてください。 VB6までは、OCXやDLLのバージョンが変わることの弊害をいつも気にする 必要がありましたが、.NETの場合は.NetFrameworkは共存できます。 また、.NETで作成したDLLは同一名でもバージョン管理で別物として 管理できますので、VB6のころよりは少しは良いです。 いずれにせよ、PC COBOLの場合には、HOST COBOLの資産が生かせるの でしたら、.NETにしてまったく新たに開発するリスクを冒してまで 選択するほどのメリットがあるとは思えません。
- equinox2
- ベストアンサー率48% (321/660)
情報が少なすぎて具体的な話はできないので、限られた情報の範囲内で・・ ＃可能であれば、トランザクション数やジョブ数を教えてください PC版COBOLと比較されているので、以下は.NETをC/Sで使用されるという前提です。 (1)オンライン主体の業務の場合 ・画面数は数百画面以上あっても問題はないですが、業務の最低単位毎に 画面や入出力資源が違い、別EXEにする必要があるのなら、頻繁に 実行EXEを変える必要があるので、.NETでは不安です。 （逆に、同じ業務（入力など）を繰り返すタイプなら問題なし） (2)バッチ主体の場合 ・.NET、は複数のEXEを順次起動させるような処理には向きません。 かとって、まとめてしまうと、単純再ランがしにくいので運用に 問題があります。 (3)その他一般論 ・.NETのメリットは他の言語より比較的簡単にC/SとWeb、Webサービスを 作成できることですが、当然、本格的な規模の業務に使用するには、 それなりのミドルウエアを採用するか開発するなどが必要になります。 そして、COBOLなどの開発では普通に行なわれているように、開発標準を 決めて組織的に開発する必要があります。 その結果、.NETのメリットが半減する可能性もありますが、ちゃんと 保守していくためには、どんな言語であろうとその考慮は必要です。 ・COBOLと違い、.NETではオブジェクト指向での開発が前提となり、 それを十分に生かす設計が高生産性の秘訣です。 そのためには、VB6までの設計・開発者だけでは役に立ちません。 むしろ、Javaの経験者などを参加させることが有効です。
- lv4u
- ベストアンサー率27% (1862/6715)
補足です。 さきほどの回答は、ユーザ数を無視し、「同等の機能のソフトを開発する」という点だけでのものです。規模の面、つまりパフォーマンスとか、運用管理の利便性が、ホストと同程度になるかどうか？は考慮していません。 ただ、最近のマシンはパワーがあるので、適切な設計を行えば、問題ないのでは？って思ったりします。 あと、ご存じのように、ホスト系は運用管理のシステムがしっかりしていますが、ＰＣ系は、ほぼそういう方面のソフトは、ゼロみたいなものですので、なかなかＶＢで作成すると大変なことになるのではないか？なんて思います。
補足
お返事が遅れてしまい申し訳ありません。 基本的に、機能面はホストと同レベル、ただGUIの部分を使いやすくという感じでやりたいと思ってます。 ですので、私的にはPC版COBOLで十分と感じているのですが、上司が言うには、これからの時代COBOLはだめだとか、VBだと情報がたくさん出回っているからやりやすいとか、PC版COBOLの販売元が販売をやめたら困るとか、表面だけで判断している節が多く、実務を任される私には正直邪魔な意見でしかありません。言ってることはわかるんですけどね・・・。（愚痴になちゃってすみません。） バージョン依存はやはりそうですか・・・。これでVBをNGとする理由は十分ですね。ユーザ数が多い＝バージョン管理も大変、と考えているんで、これは致命的ですね。 あとはパフォーマンスですね。VBが重いという話はよく耳にします。ネットワークを利用すると重い、余計なメモリを使用する、等何か理由があるのでしょうか？ できれば教えてください。よろしくお願いします。
- lv4u
- ベストアンサー率27% (1862/6715)
>>そこで皆さんにご質問させていただきたいのですが、VBでこの規模のシステム開発は可能なのでしょうか？私はVBだと小さなものしか作ったことがなく、不安です。 昔、ＶＢ６とＰＣ版のＣＯＢＯＬで開発やっていました。 ＶＢとＣＯＢＯＬは、かなり差があります。とはいえ、ソフトウエアですので、ものすごーーく、時間をかければ、同様なものが完成するという意味では、「可能です」といえるでしょう。でも、いろいろと「機能追加する」とか「使いやすくする」ということは考えず、単にホストでやっていたことを、ＰＣでやるだけなら、ＰＣ版のＣＯＢＯＬで作成されたほうがいいと思います。 ちなみに、以前いたソフト会社では、ＣＯＢＯＬ－＞ＶＢへの移植をやりはじめたものの、なかなか開発が終わらず、一時期、経営的に大変な状況になったという話を聞いたことがあります。 >>Windows、Office、Ie等、別製品のバージョンに依存したりして動作しなくなるといったことはあるのでしょうか？ VB(.Net)での開発経験はないのですが、ＶＢ６の開発をやっているときは、不可解な現象に悩まされたものです。バージョンはやはり考慮しておかないとまずいと思います。それから、.Netでは、Frameworkのバグフィックス版があるのを知らずトラブルに悩んでいる同僚がいました。PC版COBOLでの開発よりも、バージョン依存が増えるのは確かだと思います。
補足
お返事が遅れてしまい申し訳ありません。 ＞＃可能であれば、トランザクション数やジョブ数を教えてください 私が赴任して間もないため、トランザクションやジョブ数に関して、まだ把握できていないところが正直なところです。 ＞業務の最低単位毎に画面や入出力資源が違い、別EXEにする必要があるのなら、頻繁に実行EXEを変える必要があるので、.NETでは不安です。 .NETでは画面遷移時のメモリ使用に不安があるということでしょうか？VBは重いという話はよくききますが・・・。 ＞.NET、は複数のEXEを順次起動させるような処理には向きません。 かとって、まとめてしまうと、単純再ランがしにくいので運用に 問題があります。 やはりバッチ処理は厳しいのですね・・・。いろいろ考えてはいるのですが バッチ処理をなくすことはできないような気がしています。 ＞本格的な規模の業務に使用するには、 それなりのミドルウエアを採用するか開発するなどが必要になります。 やはりそうですか・・・PC版COBOLだと問題なく運用でしたのですが、VBだとそうはいかないのですね。開発者の意図しない部分でVB以外の部品が多く使われているようですし、バグも多そうですし・・。 素直にPC版COBOLで推してみようと思います。 ありがとうございました。