Webアプリケーションプログラミングを理解する（そしてそれに移行する）ために、クライアントサーバープログラマーが直面する（克服しなければならない）困難について、少し光を当てていただけませんか？
Windowsフォームを作成している人が少なくとも10年間クライアントサーバーデータベースアプリケーションを形成していると考えてください。
1 に答える
0
HTTPの性質上、サーバーはただそこに座ってクライアントの応答を待つだけではありません。できません。（ASP.netは可能なように動作しますが、これはフレームワークによって提供される錯覚/抽象化です。証拠：
If IsPostBack。）各HTTP要求は互いに分離されているため、サーバーに何をしていたかを思い出させるために、各要求に十分な情報を含める必要があります。 。ここではセッションCookieが少し役立ちますが、重要な点は、入力が必要になるとすべてが停止し、次のリクエストですべてが最初からやり直されるということです。ファットクライアントで行うほとんどすべてのことは、Webサーバーで行われるようになります。つまり、1台のサーバー（DBサーバーも数える場合は2台）がほとんど/すべての面倒な作業を行っています。ファットクライアントで機能していたその恥ずかしいほど遅いソリューションは、現在、すべてのユーザー間で共有されているCPUサイクルを使い果たしています。パフォーマンスとスケーラビリティを二次的な目標として念頭に置いてください（機能させるための背後にあります）。
アプリのUIは、もはや直接制御することはできません（ただし、ジャッカスになり、IE6を要求する場合を除きます。その場合、Webアプリを長期間開発することはありません）。さまざまなブラウザでテストする必要があります（少なくとも最新バージョンのFFとChrome、およびバージョン7〜9のIE。可能であればSafari / Macも。携帯電話のブラウザをサポートする場合はさらに多く）。そして、それぞれに癖があります。動作しなければならないものについては最小公分母に固執し、余分な小数のためにブラウザの癖だけを使用することをお勧めします。また、すべてのブラウザでピクセルが完全に同一であることを試みないでください。特に古いバージョンのIEや電話などをサポートする必要がある場合は、そのように狂気に陥ります。代わりに、レンダリングのわずかな違いが大きな問題にならないように、十分に柔軟なレイアウトを試してください。
ほぼ定義上、2つの異なる環境（ブラウザーとサーバー）で3つの異なる言語（HTML、Javascript、およびサーバー側言語）を同時に使用する場合があります。コードがいつどこで実行されるか、およびコードが実行されている間はどのような制限があるかを常に意識する必要があります。サーバーコードとクライアントコードの間には少し壁があり、デフォルトでは変数を共有しません。それらが必要な場合は、そうする方法を提供する必要があります。
于 2011-06-07T01:08:24.407 に答える