客户端-服务器开发人员在理解 Web 应用程序/开发时面临哪些障碍？
你们介意透露一下客户端-服务器程序员为了能够理解（并能够转向）Web 应用程序编程而面临（必须克服）的困难吗？
想象一下某人已经编写 Windows 窗体客户端-服务器数据库应用程序至少 10 年了。
Would you guys mind to shed some light about what are the difficulties that a client-server programmer faces (has to overcome) to be able to understand (and be able to move to) web application programming?
Think someone that has been writing windows forms client-server database applications for at least 10 years.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
HTTP 的本质是服务器不会只是坐在那里等待客户端的响应。不可以。 （ASP.net 表现得好像可以，但这是框架提供的幻觉/抽象。证据：
If IsPostBack。）每个 HTTP 请求都是彼此独立的，因此您必须在每个请求中包含足够的信息请求提醒服务器它正在做什么。会话 cookie 在这里会有所帮助，但主要的一点是，一旦您需要输入，一切都会停止 - 并且下一个请求会重新开始一切。您在胖客户端中执行的大部分操作现在都将在 Web 服务器上完成。也就是说，一台服务器（或两台，如果也算上数据库服务器）正在完成大部分/所有繁重的工作。在胖客户端上运行的极其缓慢的解决方案现在正在耗尽所有用户之间共享的 CPU 周期。将性能和可扩展性作为次要目标（让工作正常运行）牢记在心。
应用程序的 UI 不再直接由您控制（除非您想成为一个混蛋并需要 IE6，在这种情况下您不会长期开发网络应用程序）。您需要在多种不同的浏览器中进行测试（至少是最新版本的 FF 和 Chrome，以及 IE 7-9 版本。如果可能的话，Safari/Mac 也是如此。如果您计划支持手机浏览器，则需要更多）。每一个都有其怪癖。对于必须工作的东西，您需要坚持最低公分母，并且仅使用浏览器怪癖来获得额外的乐趣。并且不要尝试在每个浏览器中实现像素完美的相同性。这种方式很疯狂，尤其是当您必须支持旧版本的 IE、手机等时。相反，请尝试使用足够灵活的布局，以便小的渲染差异不是什么大问题。
几乎根据定义，您有时会在两种不同的环境（浏览器和服务器）中同时使用 3 种不同的语言（HTML、Javascript 和服务器端语言）。您需要始终了解代码将在何时何地运行，以及它在那里时会受到哪些限制。服务器代码和客户端代码之间有一点隔阂，并且默认情况下它们不共享变量。如果您需要它们，您需要提供一种方法来做到这一点。
The nature of HTTP is such that a server won't just sit there and wait for a client's response. It can't. (ASP.net acts like it can, but that's an illusion/abstraction provided by the framework. Evidence:
If IsPostBack.) Each HTTP request is separate from every other, so you must include enough information with each request to remind the server what it was doing. Session cookies help a bit here, but the main point is that once you need input, everything stops -- and the next request starts everything over again.Most everything you'd do in a fat client will now be done on the web server. That is, one server (or two, if you count the DB server too) is doing most/all of the heavy lifting. That embarassingly slow solution that worked on the fat client is now using up CPU cycles that are shared between all the users. Keep performance and scalability in mind as secondary goals (behind getting stuff to work).
The app's UI is no longer directly under your control (unless you wanna be a jackass and demand IE6, in which case you won't be developing web apps for long). You'll need to test in a number of different browsers (at least the latest versions of FF and Chrome, and versions 7-9 of IE. Safari/Mac too if possible. More if you plan to support mobile phone browsers). And each one has its quirks. You'll want to stick to the lowest common denominator for stuff that has to work, and only use browser quirks for extra spiff. And don't try for pixel-perfect identicality in every browser. That way lies madness, especially if you have to support old versions of IE, phones, etc. Instead try for a layout flexible enough that small rendering differences aren't a big deal.
Almost by definition, you'll have times when you're working with 3 different languages at the same time (HTML, Javascript, and your server-side language) for two different environments (browser and server). You need to always be aware of when and where your code will run, and what limitations it'll have while it's there. There's a bit of a wall between server code and client code, and they don't share variables by default. If you need them to, you'll need to provide a way to do so.