Microsoft スタック上でスマート クライアント (概念的には WCF/WS 対応) として開始されたアプリがあり、小さなクライアント アプリが展開され、アプリの残りの部分はプライベート クラウドで実行されています。唯一の本当の依存関係は、インターネット接続、.net 4、および Windows オペレーティング システムです。
今後のすべての開発のために、ブラウザ ベースのアーキテクチャに変換する必要に迫られています。私が取り組んできた他の Web アプリに基づいて、クライアントの IT 組織がブラウザーを制御できる方法が、私が実際に対処したい問題よりも多くの問題を引き起こすのではないかと懸念しています。
このような決断を下した経験はありますか？スマート クライアントとブラウザのどちらを採用するかを決定する際に考慮した技術的要素は何ですか? この決定に役立ったリソースは何ですか?
私のアプリはヘルスケア提供者 (病院など) を対象としたヘルスケア アプリであるため、どこに行っても、ヘルスケア CIO が肩越しに見ているのではないかと心配する必要があります。
面白い。もともと私は C# winform と WPF デスクトップ プログラマーの出身で、後に Web 開発を担当するようになりました。Smart Client はまだ触っていませんが、Native app とほぼ同じだと思います。経験に基づいて、考慮すべき技術的な事項は次のとおりです。
マルチブラウザ対応
特にレポートとグラフィック処理では、コンポーネント用のライブラリ/プラグイン/フレームワークがなければ、アプリのマルチブラウザーを維持するのは非常に困難です。特にcssスタイルで、javascriptではあまりありません。
クライアントプログラミング(javascript)
C# コントロールを使用してコントロールとアニメーションを作成する機能が失われます。代わりに、代わりに javascript (jquery またはその他のライブラリ) を使用する必要があります。Javascript は完全に OOP ではなく、言語を解釈する (コンパイル エラーがない) ため、処理が難しくなります (コーヒー スクリプトのような、まだ調べていないフレームワークがあるかもしれません)。また、後で説明するように、プロセスの合間にサーバーの要求/応答アクティビティが必要になるため、作成が難しくなります。
リクエスト / レスポンス クライアント サーバー アーキテクチャ
これは、クライアントのほとんどのプロセスがサーバーを要求する必要があることを意味します (表示するデータの要求、データの変更の要求など)。また、asp.net Web フォームを使用している場合でも、イベントを制御する機能が失われることを意味します (イベントを機能させるには、いくつかの微調整が必要です)。ただし、既に WCF を使用していると思いますので、この種のアーキテクチャは難しいに違いありません。
安全
パスワードなどの重要な情報をクライアントに保持しないでください (隠しフィールド、JavaScript 変数など)。概念はマルチテナント クライアントと同じである必要がありますが、ブラウザーでは、ユーザーは Web ページを自由にデバッグできます。
同時実行とマルチスレッド
ブラウザでは、マルチタブページの方が簡単で、同時処理が非常に発生しやすくなります。コードは、クライアント側のマルチスレッドを処理できる必要があります。サーバー側では、WCF を使用して同時実行を処理できます。
私の2セント。
Obviously the web application has its own challenges. I hope this link can help you in some aspects: http://msdn.microsoft.com/en-us/library/ee658099.aspx
Along with those you need to focus on non-function requirements like extensibility and scalability etc. too.