1

中規模の標準 LOB アプリケーションを作成しています。現在は Web アプリケーションですが、デスクトップ リモート アプリケーションに改良するための提案を作成しています。これは、データベースとアプリケーション サーバーがリモート ロケーションでホストされることを意味します。クライアント アプリケーションは、インターネット経由でサーバーと通信します (WCF / Webservices / Remoting のいずれか)。

私の質問は次のとおりです。これを Web プラットフォームから移行する唯一の理由は、Web の制約によるものです (これらの制約を最小限に抑えるために AJAX または Java スクリプトを実行したくないため、JS/AJAX の推奨事項はありません)。私は従来のデスクトップ アプリケーションを作成しており、かなり高速ですが、リモート アプリケーションや分散アプリケーションを作成したことはありません。アプリケーションの速度が Web より速くなるかどうかはわかりません。

私が理解しているように、リモート デスクトップ アプリケーションの方がはるかに高速です。1つは、ポストバックが関係しないことです（私はポストバックが大嫌いです）。データはもちろんインターネット経由で来るので、その点ではスピードとパワーだけを求めてリモートデスクトップに移行した方が良いのでしょうか?

正しい方向への助けは素晴らしいでしょう。どうもありがとう。

ジーシャン

4

3 に答える 3

1

Web アプリケーションに対するデスクトップ クライアントの最大の利点は、UI 設計の自由度であり、クライアント環境の矛盾を心配する必要がないことだと思います。

個人的には、多くのユーザー インタラクションを必要とする Web アプリケーションは好きではありません。使用するのが楽しいアプリケーションもいくつかありますが、間違った方法で実行すると、バグが発生したり、応答が遅くなったりするのは非常に簡単だと思います。アプリケーション (おそらくブラウザーの非互換性のため、コンピューターに IE、Firefox、および Chrome がインストールされています。一部の Web サイトでは高速に実行されるため、1 つを使用し、他のサイトでは Web ページのみが正しく表示されるため、別の Web サイト用に使用しています) . これは、Silverlight クライアントでは問題にならないかもしれませんが。

ネットワーク速度の場合、バイナリ シリアライゼーション リモーティングを使用しても、ネットワーク上で行われるものによっては、かなりのオーバーヘッドが発生する可能性があります。たとえば、データとともに完全なクラス名、ライブラリ名、およびそれらのバージョンを書き込むため、少量のデータでもかなり大きく遅くなる可能性があります (それでも HTTP よりも小さいはずですが)。また、HTTP は同様のプロトコルを使用するため、信頼性の低い接続に対して HTTP と同じ問題を抱えています。あるプロジェクトでは、一部のオブジェクトに対してカスタム シリアライザーを作成する必要がありました。これは、バイナリ シリアライゼーションだけで 200K を生成していたのに、これらのオブジェクトのカスタム シリアライザーが 50K を生成していたためです。その後、独自のネットワーク プロトコルを作成することになりました。これは、ランタイムに付属しているネットワーク プロトコルが信頼性の低いワイヤレス ネットワーク上で頻繁に停止し、リモーティングが停止していたためです。

（リモートデスクトップとWebアプリではなく、リモートデスクトップとWebアプリについて質問していると思います。ポストバックに関するメモのため、リモートデスクトップセッションでは回避できません）

高速化のためだけにアプリケーションを書き直しますか? いいえ、おそらくユーザーは応答時間に大きな違いを感じないでしょう。

于 2009-12-24T09:35:25.173 に答える
1

用語がやや曖昧です。ユーザーのマシンで実行されるクライアント アプリが必要ですか、それともサーバーで実行され、ユーザーがリモート デスクトップ (RDP) 経由で接続するアプリが必要ですか?

WCF などを介してサーバーと通信するクライアント アプリについて話している場合は、標準の Web アプリよりも高速ですが、ネイティブ デスクトップ アプリよりも遅くなります。ポストバックがないためだけでなく、大量の HTML/Javascript をデータと組み合わせて送信するのではなく、純粋なデータをネットワーク経由で送信するため、Web アプリよりも高速になります。クライアント アプリにはいくつかのオプションがあるため、慎重に検討してください。Silverlight、WPF、またはネイティブの WinForms アプリのどれが必要ですか? それぞれにプラスとマイナスがあります。

ユーザーが RDP 経由でアクセスするサーバー上でクライアント アプリを実行することについて話している場合は、他にも考慮すべき点があります。同時ユーザーが 2 人を超える場合は、ユーザーがサーバーに接続できるように CAL の購入を検討する必要があります。この時点で、リモート デスクトップを使用する代わりに、ターミナル サーバーまたは Citrix タイプのセットアップを実行する必要があるかどうかも検討する必要があります。

編集

WAN (インターネット) 経由で WCF を使用する場合は、確実にセキュリティを確保する方法を検討する必要があります。WCF を使用すると、チャネルを保護するのは簡単になりますが、認証を行う方法を検討する必要があります。いくつかの方法がありますが、自分で簡単にググることができます。ユーザーのリソースやスキルセットが限られているため、どの方法を選択するかが重要になります。

何を書くかについては、それがあなたの経験である場合、Winformsと議論することはできません。個人的には、Web タイプのアプリケーションに ASP.NET/Ajax/etc を使用することは二度とありません。WPF または Silverlight をずっと使用します (単純な Web サイトには ASP.NET のみを使用します)。Visual Studio の高速 (無料) バージョンを使用して書き込むことができます。Expression は必要ありません (あると便利で、実際のコーディング側よりもデザイン側を対象としています)。アプリのデプロイは難しくありません。Silverlight または WPF xbap は Web 経由で配信されます。ユーザーは何もする必要はありません (Silverlight プラグインの簡単なインストールまたは WPF 用の適切な .Net フレームワークのインストールを除いて -このリンクを確認してください)。Winforms またはスタンドアロンの WPF は、もう少し作業が必要です。

どちらを選択する場合でも、開発にかかる時間を過小評価しないように注意してください (少し学習曲線が必要になるため)。また、テスト (特にセキュリティ面) に十分な時間を確保するようにしてください :)

于 2009-12-24T08:15:13.790 に答える
0

Winforms LOB アプリケーションから始めましたが、私も同様の状況にありました。

WinFormsで見つけたものは次のとおりです...

  • リリース サイクルですべてのクライアント マシンに展開するのは難しくなります。
  • WinForms は他のオペレーティング システムでは簡単に実行できません。(モノを除く)
  • WCF エンドポイントは複雑になる可能性があり、アプリケーションのリリース/バージョンのエンドポイントを管理する必要があります。
  • 認証、承認、およびセキュリティを正しく理解するのは難しい場合があります。

HTML Web アプリケーションに固執する必要がある理由は次のとおりです。

  • 1 セットの DLL を bin フォルダーにコピーするだけでよいため、デプロイが簡単になります。継続的インテグレーションまたはステージング サーバーからスクリプト化できます。
  • SSL証明書を使用することで、セキュリティが簡単になります。
  • Silverlight/Flash は、HTML が除外するギャップを埋める必要があります。

Microsoft はまた、接続されたシステムを .net 3.5 に統合し、現在は WCF (ASMX/Remoting/etc...) と呼んでいます。4〜5週間でかなりの学習曲線が得られます.

于 2009-12-24T08:24:08.950 に答える