.NET：Webベースのアプリケーションは、クライアントサーバーよりも本質的に構築が困難ですか？
現在、どのアプローチに移行するかについて議論が進んでいます。複数の古い環境を.NETアプリケーションに置き換えたいと考えており、2つの潜在的なアーキテクチャについて検討中です。
- クライアントサーバー（ 'fat-client'）：各クライアントにインストールが必要
- Webベース（「シンクライアント」）：どのブラウザーでも機能し、インストールは必要ありません。
「ステートレス」について心配する必要がなく、URLを介してAPI呼び出しを実行する必要がないため、クライアントサーバーは本質的に安定しており、開発が高速であるという主張もあります。一方、Webベースは、余計な手間をかけずに（存在する場合）、モバイルデバイス（およびWindows以外のマシン）で実行できます。
私は.NETでこれらの主張のいずれかを確実に確認または破棄するのに十分な経験がないので、ここで私の質問は次のとおりです。
Webベースのアーキテクチャは本質的にクライアントサーバーアーキテクチャよりも開発コストが高いですか？
答えはではなく必要な学習と経験の収集の影響を考慮すべきです-チームは歴史的にクライアントサーバーから来ているので、もちろん最初はウェブベースです難しくなり、より多くのトレーニングが必要になり、いくつかの問題が発生します。無視して。経験豊富で資格のあるチームを想定すると、アーキテクチャの1つは本質的かつ常に構築するためのより多くの努力ですか？
両方の種類のアーキテクチャの経験がある場合は、私がこの決定を下すのを手伝ってください。
もう少し背景：.NETの決定が行われました。すべてのデータはすでにOracle DBにあり、そこに残ります。ただし、Oracleに長期的に拘束されないようにしておくとよいでしょう。さまざまなサイズの既存のアプリケーションを約30個再スキン/再構築し、今後3年間（合計で約20人年）に約20個の新しいアプリケーションを作成して、やや統合されたソリューション環境にする予定です。すべてのアプリのすべてのユーザーは社内におり、これは一般向けではありません。私は（モバイルオプションのために）Webベースで行く傾向がありますが、間違った方向に進んだ2年後のことを知りたくありません。
Webアプリケーションの構築は、absolutelyの場合、クライアントサーバーよりも複雑で、構築が困難です機能のセット。私が特定の順序で説明しないさまざまな理由とアイデアがあります。
このサイトで常に最も投票された質問は Webアプリケーションのプログラマーがサイトを公開する前に考慮すべき技術的詳細は何ですか？ そこには数十の箇条書きがあり、一部は一般的ですステートメント、それらの大部分は確かにWebプログラミングに固有です。
「desktopアプリケーションのプログラマがサイトを公開する前に考慮すべき技術的な詳細はどこにありますか？」質問？なぜそれが存在しないのですか？そのリストにあるすべてのものは、一般にプログラミングに固有のものであり、Webプログラミングは、リンクされた質問の側面に加えて、それらすべてについて考慮する必要があるためです。
Webベースのアプリケーションとそうでないアプリケーションの類似した側面を比較してみましょう。私の意見では、クライアント/サーバーとデスクトップアプリケーションの違いは、それらとWebベースの違いに比べると取るに足らないものです。
- GoogleドキュメントまたはOffice 365とデスクトップMS Office *を比較します。 10年前（おそらく20年前のOffice 95）のMS Officeは、同時編集部分を除いて、機能と機能の面でどちらよりもはるかに優れています。
- 数年前のOutlook + Exchangeは、今日のどのWebベースの電子メールクライアントよりも優れています。
- JavaScript PDFビューアは、すべてJavaScriptであるという点で洗練されていますが、Adobe Acrobatは、恐ろしいにもかかわらず、かなり優れています！
- 計算できるものはすべてデスクトップアプリにすることができるのに対して、多くのソフトウェアは、Webベースのオファリングに実装することはまったく不可能または不可能です。 Web上でクライアント/サーバーアプリに実装できないものはありません（ブラウザーを明示的に必要とするものや、既存のWebサイトのコンテキストで実行されるものを除く）。
機能に違いがあるのは、Webベースのアプリケーションの構築がはるかに困難で複雑だからです。
多くの人々がnode.jsにうんざりしていますが、その主な価値は、同じ言語でWebアプリのフロントエンドとバックエンドを構築できることです。 Node.jsが最初にリリースされたのは2009年です。クライアント/サーバー/デスクトップアプリでフロントエンドとバックエンドに同じ言語を使用できるようになったのはいつからですか。ほとんどいつもから。なぜ人々はそれを使用していますか？ Web開発は非常に複雑であるため、サーバー/ブラウザインターフェイスの複雑さを軽減するために、人々はJavaScriptの問題と複雑さを取り入れようとしています。
ブラウザーとHTTPリンクにより、Webアプリケーションが大幅に複雑になります。スペースシャトルを飛ばすソフトウェアを書いているのでない限り、メモリアドレスや他のリソースにアクセスしようとするときにエラー404を心配する必要はありませんが、Webアプリケーションはよく使用します。多くの場合、ディスクへの完全なアクセスを失うことは、デスクトップアプリにとって重要な問題ではありません。通常、適切にクラッシュすることで十分と考えられます。 Webアプリでネットワークが失われることは、頻繁に繰り返されるだけでなく、適切に処理され、接続を再開することが期待されます。これは、サーバーサイドコードまたはフロントエンドコード内で発生する可能性があるすべての問題の上にあります。
ブラウザとhttpサーバー間の接続は、重要な状態を維持しません。クライアント/サーバーおよびデスクトップアプリでは、必要なだけの状態を簡単に維持します。数十のフレームワークと、その状態のギャップを賢明な方法で埋めようとしているWebフレームワークの定型文の山を考えてみてください。シッククライアントアプリなら、すべて無料で入手できます。
人々が賢明なWebページを表示するという厄介な手間と格闘している何百万人もの時間を考えてみてください。デスクトップアプリには独自の欠点がたくさんありますが、「2列を同じサイズにする」ことで人文科学の多くがデスクトップでの作業とWebでの作業を同じように吸い込んだほど簡単に見えるものはないと思います。クロスプラットフォームでの作業はクロスブラウザよりもかなり簡単だと思います。
ユーザーが使用するブラウザーを制限することでこの複雑さの一部を削減しようとしても、ユーザーが使用しているOSを制限することで、同様にシッククライアントアプリの複雑さを軽減できます。 Webアプリは常により独立して動作する部分を持つため、より複雑なソフトウェアになります。
最後に、.NETはこれには何の影響もありません。これらは、すべての言語に当てはまると私が信じている幅広い説明です。
追伸明らかに「ブラウザプラグイン」ルートがありますが、これは基本的に両方の最悪の側面を組み合わせているため、ここでアイデアを理解しようとするときに存在しないふりをします。
いいえ、必ずしもそうとは限りません。理解する必要があるのは、Webアーキテクチャがクライアントサーバーアーキテクチャであることです。ここにあるクライアントは、ユーザー（ブラウザ）に提供されているだけです。
本当の質問は、ブラウザはあなたの要件を満たしていますか？クライアントに必要なすべての操作を実行できますか？その場合、既存のクライアントを再利用する方が簡単な場合があります。それ以外の場合は、独自のクライアントを作成することをお勧めします。
私の経験では、Webアプリケーションを作成するためにそれ以上に高価である必要はありません。私たちは最近、自分の将来のプロジェクトに使用するアプローチを決定するためにいくつかの調査を行いました。
多くのWindowsアプリケーションの開発から、代わりにWebアプリケーションに移行することにしました。私の意見では、Webアプリケーションを使用することにはいくつかの大きな利点があります。
多くの場合、リリースがより簡単です。ブラウザはクライアントなので、誰もが最新バージョンを使用していることを確認できます。 GPOや配布は必要ありません。
モバイルデバイスで利用できます。これは、Win 10とユニバーサルアプリで多少変更された可能性があります。それでも。
OSに依存しません。ブラウザが異なると動作が異なる場合でも、OSのアップグレード時に大きな問題は発生しません。 Windowsアプリケーションを修正する必要があるx86 win7からx64 Win10に移行しています。 Webアプリケーションはそのまま使用できます。
そして今日、ウェブ開発をより速くするための素晴らしいライブラリがたくさんあります。ただし、リリース管理とオーバーヘッドを計算に取り入れることで、Webアプリケーションの総コストを再検討できます。どのくらいの頻度で新しいOSを展開しますか？ 5年ごと？アプリケーションをどのくらいの期間サポートする必要がありますか？ 10年？
ただし、欠点が1つあります。そして、それは経験の浅いユーザーです。多くのユーザーが、WindowsアプリケーションよりもWebアプリケーションの使用が難しいことに気づきました。しかし、個人的には、経験の浅いGUIデザイナーのせいだと思います。
編集：
私はいくつかの（おそらく無効な）仮定をしました。まず、私の答えは、それが組織の内部アプリケーションであるという事実に基づいています。パブリックユーザーが使用する必要のあるアプリケーションではありません。
第二に、私はあなたが開発コストではなく総コストに興味があると仮定しました。つまり、ソフトウェアのライフタイムの総コストです。更新と保守を含みます。
No-Web開発はネイティブアプリ開発と非常に競争力があります。
全体的なアーキテクチャ：
最新のファットクライアントアプリケーションのほとんどは、データベースと直接通信するのではなく、ミドルウェアと通信します。 .Netでは、ミドルウェアは通常SOAP Webサービスです。
最新のWebアプリケーションの多くは単一ページアプリケーションです。このアーキテクチャーでは、ブラウザーで実行されるJavaScriptクライアントがミドルウェアと通信しました。これは通常、REST Webサービスです。
したがって、アーキテクチャは基本的に同じです。また、RESTとSOAPは異なりますが、基本的に同じことを行います。サーバー側はどちらのアーキテクチャでも非常に似ています。実際には、ファットクライアントとWebクライアントの両方を同じバックエンドで簡単に実行できます。これを行う実際のアプリケーションをいくつか見ました。
したがって、選択は本当にフロントエンドにかかっています。 Webアプリにはいくつかの強力な利点があります。
- Windows、Linux、MaC OS、Android、iOSなど、さまざまなプラットフォームで作業します。
- Webクライアントの最新バージョンの配布は簡単です。ネイティブクライアントを最新の状態に保つのは難しい場合があります。
- Webページはサンドボックス内で実行されるため、ユーザーに完全に信頼するように求めているわけではありません。
主な欠点は、Webサイトがクライアントシステムに完全にアクセスできないことです。最近では、Webサイトで高度な3Dグラフィックスを実行したり、ローカルファイルにアクセスしたり、カメラやGPS座標を使用したりできます。 3Dアニメーションスタジオなど、非常に重いことをしている場合は、ネイティブになりたいと思うでしょう。しかし、ほとんどのアプリケーションはWebアプリと同じように正常に動作します。
また、Webアプリケーションとネイティブアプリケーションを構築するためのツールの品質の問題もあります。 JavaScriptフレームワークの優れた選択と複雑さについて多くの人々が不満を述べています。ただし、フロントエンドWebツールはかなり良い状態だと思います。ネイティブ開発（QT、wxWindowsなど）は成熟していて安定していますが、Web開発は俊敏で革新的です。 AngularJSやBootstrapなどのフレームワークを使用すると、強力で見栄えの良いアプリをすばやく作成できます。
また、次のことも考慮する必要があります。
セキュリティ、いかなる場合でもアプリケーションを脅威から保護する必要があり、この点に関してWebベースのアプリはインターネットに公開されているため不利です安全な場所です。システムに必要なセキュリティ機能を指定すること、および クラウドプロバイダー を使用する場合は重要です（これにより、自社よりも高いセキュリティを提供できます）。
パフォーマンストラフィックの大幅な増加は、Webベースのアプリでのエクスペリエンスを確実に遅くします。文字通り、データを送信するだけでなく、ユーザーインターフェイスも送信しているため、アプリが遅くなる可能性があります。
したがって、セキュリティとパフォーマンスの要件が高い場合、Webベースのアプリの実装が難しくなる可能性が非常に高くなります。
注：.NETで ClickOnce を使用して、すべてのユーザーのデスクトップベースのアプリを更新する問題に対処できます。