none
ASP.NETとWindowsフォームアプリケーションについて(VB2010) RRS feed

  • 質問

  • 顧客管理システム(Access2000)をVB2010+SQLserver2008R2またはSQLserver2012で再構築する予定です。
    システム動作環境としては、下記の通りです。
    ・本社と3営業所に設置しているパソコンは各5台程度。(Windows7)
    ・本社と3営業所はインターネットVPN(NTT光フレッツnext)で接続されている。
    ・本社にWindowsServer2008R2また2012R2(SQLserverをインストール)を設置、各パソコンからアクセスする。

    再構築するに当たり、考慮すべき点としてWAN(インターネットVPN)を経由しデータベースにアクセスするので、
    なるべく回線に負担を掛けないような仕組みを開発する必要があります。

    よって以下どちらかで開発する事になると考えており、どちらが良いか迷っております。

    1.ASP.netで開発。Webアプリケーションとして再構築。
    ・開発経験が豊富でなく、開発に少し時間がかかるかもしれない。
    (セキュリティを意識した開発を行う必要がある)
    ・画面の見た目はWindowsフォームアプリケーションに比べ劣ると思っている。
    ・クライアントにプログラムをインストールする必要はなく、ブラウザがあればよい。

    2.WAN間のSQLのやり取りを最小限に抑えるためSQLserverのスアドプロシージャを使用したWindowsフォームアプリケーション
    (出来るだけサーバ側で処理をさせる)
    ・Windowsフォームアプリケーションの開発経験は豊富であるため、開発し易い。
    ・画面の見た目はASP.netより良いと思っている。
    ・クライアントにプログラムをインストールする必要がある。

    知識不足で、まだ情報収集している段階ですが、知恵を拝借したいと思います。
    ・どちらのツールを使用して開発すればよいか?
    ・Windowsフォームアプリケーションで出来て、ASP.netで出来ない機能があるかどうか?

    以上です。 

    2015年7月1日 5:51

回答

  • WindowsフォームアプリケーションとWebアプリケーション、具体的にどちらが…というのも、正直なところ作り次第かなと思います。


    例えばWebアプリケーションにしても、シンプルに必要最低下のものをクライアントに返すようにすれば軽く作ることは可能な一方、ASP.NET Web Formであまり考えなしで作ってしまったり画像を多用したり等してしまうと、通信量はとても多いものになりがちです。

    Windowsアプリケーションでも頻繁にデータを取って来たりデータベースサーバ上でデータを絞り込まずクライアントアプリ側でデータを絞り込んだりするような作であれば通信量は非常に多くなると思いますし、逆にビューやストアドプロシージャなども効果的に的に使いながら最低限のデータのやり取りだけするように作れば、Webアプリケーションよりも通信量を抑えることも可能と思います。


    強いて言うならば、都度都度の通信を抑える工夫(たとえばキャッシュ等)を仕込みやすい、Windowsアプリケーションの方が有利な設計にできる点が多いかもしれません。
    (もちろん、たとえばグリッドに毎回数千件のデータを読み込むような作りにしてしまうと、台無しになってしまいます(^^;)


    きよくらならみ

    • 回答の候補に設定 星 睦美 2015年7月8日 7:54
    • 回答としてマーク hige3 2015年7月13日 8:20
    2015年7月3日 11:39
  • ASP.NETを選択肢に挙げられている理由は、クライアントにプログラムをインストールしなくても良いというのが最大の理由のように受け取れます。しかし、構築されようとしているシステムはイントラネットのようですから、ClickOnceを使えば簡単にクライアントにインストールし、バージョンアップも行うことができます。つまり、アプリケーションの配置は集中管理できます。ちなみにClickOnceがインターネットでは使えないということではありません。
    一方で、ASP.NETの場合はインストールが要りませんが、実行環境のブラウザの種類やバージョンを揃えることができないのであれば、Webアプリの表示や動作が統一できなくなる可能性も残ります。

    さて、新規で開発されるのであれば、Windowsフォームアプリケーションではなく、WPFをお勧めします。特にAccessのシステムを移行されるのでれば、Accessのような画面を作成することはWPFでないと難しくなります。例えば、Excelのような表形式ではなく、サブフォームを使って一覧表示するようなことはWPFでは簡単ですが、Windowsフォームではかなり難しいことになります。この場合、通常は有料のコンポーネントを購入することになるでしょう。

    ストアドプロシージャを多用することは良い選択だと思います。例えば将来的にスマホやタブレットのアプリの開発、追加で一部ASP.NETのアプリを開発する、または将来的にアプリケーションを別テクノロジーで作成することなどを考えた場合、サーバー側にロジックが蓄積されているのはアドバンテージになり得ます。また、書かれていらっしゃるようにトラフィックを減らしたり、通常、サーバーのパフォーマンスにも好影響を与えます。

    現在、Accessのアプリを使用されているということは、ASP.NETに変った場合、ユーザーへの印象はかなり大きいと思われます。
    折角新しく構築されるわけですから、ユーザーに取って「新しくなって良くなった!」というエクスペリエンスをさせてあげたいものです。
    最後に、バーコードリーダーなどの周辺機器、印刷や印刷プレビューなど、トータルでご検討下さい。AccessはAccess一つでできてしまうところがありますが、.NETアプリケーションの場合は、必要に応じて有料、無料を問わず、コンポーネントなどを組み合わせて実現することも一般的に行われます。


    ★良い回答には回答済みマークを付けよう! MVP - .NET  http://d.hatena.ne.jp/trapemiya/

    • 編集済み trapemiyaModerator 2015年7月1日 7:07 加筆&修正
    • 回答の候補に設定 星 睦美 2015年7月8日 7:54
    • 回答としてマーク hige3 2015年7月13日 8:21
    2015年7月1日 6:45
    モデレータ

すべての返信

  • ASP.NETを選択肢に挙げられている理由は、クライアントにプログラムをインストールしなくても良いというのが最大の理由のように受け取れます。しかし、構築されようとしているシステムはイントラネットのようですから、ClickOnceを使えば簡単にクライアントにインストールし、バージョンアップも行うことができます。つまり、アプリケーションの配置は集中管理できます。ちなみにClickOnceがインターネットでは使えないということではありません。
    一方で、ASP.NETの場合はインストールが要りませんが、実行環境のブラウザの種類やバージョンを揃えることができないのであれば、Webアプリの表示や動作が統一できなくなる可能性も残ります。

    さて、新規で開発されるのであれば、Windowsフォームアプリケーションではなく、WPFをお勧めします。特にAccessのシステムを移行されるのでれば、Accessのような画面を作成することはWPFでないと難しくなります。例えば、Excelのような表形式ではなく、サブフォームを使って一覧表示するようなことはWPFでは簡単ですが、Windowsフォームではかなり難しいことになります。この場合、通常は有料のコンポーネントを購入することになるでしょう。

    ストアドプロシージャを多用することは良い選択だと思います。例えば将来的にスマホやタブレットのアプリの開発、追加で一部ASP.NETのアプリを開発する、または将来的にアプリケーションを別テクノロジーで作成することなどを考えた場合、サーバー側にロジックが蓄積されているのはアドバンテージになり得ます。また、書かれていらっしゃるようにトラフィックを減らしたり、通常、サーバーのパフォーマンスにも好影響を与えます。

    現在、Accessのアプリを使用されているということは、ASP.NETに変った場合、ユーザーへの印象はかなり大きいと思われます。
    折角新しく構築されるわけですから、ユーザーに取って「新しくなって良くなった!」というエクスペリエンスをさせてあげたいものです。
    最後に、バーコードリーダーなどの周辺機器、印刷や印刷プレビューなど、トータルでご検討下さい。AccessはAccess一つでできてしまうところがありますが、.NETアプリケーションの場合は、必要に応じて有料、無料を問わず、コンポーネントなどを組み合わせて実現することも一般的に行われます。


    ★良い回答には回答済みマークを付けよう! MVP - .NET  http://d.hatena.ne.jp/trapemiya/

    • 編集済み trapemiyaModerator 2015年7月1日 7:07 加筆&修正
    • 回答の候補に設定 星 睦美 2015年7月8日 7:54
    • 回答としてマーク hige3 2015年7月13日 8:21
    2015年7月1日 6:45
    モデレータ
  • WindowsフォームアプリケーションとASP.NETのアプリケーションの違いはもちろん多々あると思います。出来る/出来ないもありますし、実現は出来るにしてもパフォーマンスや考慮すべき点が異なってくることが往々にしあります。それらをここで一つ一つ列挙するのは私にはちょっと難しいです。

    (一例をあげれば…例えばACCESSからWebアプリケーションへの移行では、帳票印刷関連の機能で、仕様の調整や妥協、考え方や場合によっては業務フローの変更を迫られる…などが起きやすいポイントになります)


    またこういった決断は単純な技術要素の比較だけでは難しいとも思っています。ですので、部外者の視点では一概にはなかなか判断が難しいです(そういった判断を下すには、要員のスキルですとか、開発にかけられるコストや期間ですとか、保守すべき既存の資産ですとか、今後の要員教育計画等々……までからむことが少なくないと思うからです)。


    敢えてお答えするなら……。ご質問にあげられているような状況で、私が上記の情報だけで対応を決断するのであれば、まずはWindowsフォームを優先で考えると思います。ACCESSとWindowsフォームの様々な特性の差と、ACCESSとASP.NETでの様々な特性の差を考えれば、前者のほうが差が少なく、また想像できる要員スキルなどからもリスクが少ないと思えるためです。


    それでももし、Webアプリケーションを採用したい別の理由や(たとえば展開の労力を減らしたいので可能であればWebアプリケーションにシフトする戦略をとりたい、等)があったり、もっと突っ込んで検討したいのであれば……。

    移行後のシステムで実現したい機能を整理したうえで、例えば『現行システムにある○○の機能はなくしたくないが、Webアプリケーションとして実現可能か?』等の観点で調査し、わからない場合にそういった観点で改めてご質問されると、私ももう少し具体的なお返事が出来るかもしれません。


    きよくらならみ



    • 編集済み Kiyokura 2015年7月1日 9:09 誤字の訂正
    • 回答の候補に設定 星 睦美 2015年7月8日 7:55
    2015年7月1日 6:55
  • trapemiya様、Kiyokura様

    回答ありがとうございます。大変参考になります。

    ユーザのスキル、開発要員のスキル、使い慣れたACCESSの画面イメージに近い、帳票種類も多い…等で開発ツールは
    Windowsフォームの方を選択する可能性が高いです。
    (ActiveReport等の有償コンポーネント、ClickOnceでの展開も検討しようと思います。)

    あと気になるのは、WAN間のレスポンスです。

    以下のような事を実施し、回避している他ユーザ事例もあるほどです。
    ・サーバにWindowsフォームアプリケーションをインストールし、クライアントからリモートデスクトップで接続し実行。
     または、ターミナルサーバを準備し、クライアントからリモートデスクトップで接続し運用。

    WAN間のレスポンス優劣の観点から、どちらの開発ツールが良いとかありますか?

    以上、宜しくお願いします。

    2015年7月3日 9:19
  • WindowsフォームアプリケーションとWebアプリケーション、具体的にどちらが…というのも、正直なところ作り次第かなと思います。


    例えばWebアプリケーションにしても、シンプルに必要最低下のものをクライアントに返すようにすれば軽く作ることは可能な一方、ASP.NET Web Formであまり考えなしで作ってしまったり画像を多用したり等してしまうと、通信量はとても多いものになりがちです。

    Windowsアプリケーションでも頻繁にデータを取って来たりデータベースサーバ上でデータを絞り込まずクライアントアプリ側でデータを絞り込んだりするような作であれば通信量は非常に多くなると思いますし、逆にビューやストアドプロシージャなども効果的に的に使いながら最低限のデータのやり取りだけするように作れば、Webアプリケーションよりも通信量を抑えることも可能と思います。


    強いて言うならば、都度都度の通信を抑える工夫(たとえばキャッシュ等)を仕込みやすい、Windowsアプリケーションの方が有利な設計にできる点が多いかもしれません。
    (もちろん、たとえばグリッドに毎回数千件のデータを読み込むような作りにしてしまうと、台無しになってしまいます(^^;)


    きよくらならみ

    • 回答の候補に設定 星 睦美 2015年7月8日 7:54
    • 回答としてマーク hige3 2015年7月13日 8:20
    2015年7月3日 11:39
  • Kiyokura様

    今後の開発での参考とさせて頂きます。
    ありがとうございました。

    今後も宜しくお願いします。

    2015年7月13日 8:23