有没有人仍然使用客户端服务器架构
我一直在写软件几十年，现在一切都是网络。
在网络之前，我们有客户端服务器应用程序，这些应用程序基本上是直接与数据库对话的胖客户端应用程序。他们有一些缺点，比如部署很麻烦，没有规模，因为数据库处理所有流量。当然，当时的应用程序分发仅限于在企业网络上的桌面上。这些应用程序的好处是，它们层数较少，开发速度很快。有没有人仍然使用客户端服务器架构
有些时候，需求需要在具有专用数据库和相对较少数量的客户端的防火墙后面调用应用程序。我建议（有时在StackOverflow上）旧的客户机/服务器类型体系结构，每个人看起来像我有3条腿和6条臂。
使用现代技术可以自动部署应用程序和我们今天的工具。这种技术不可行的原因是什么？新一代的开发人员是否只知道网络内容？
我敢肯定厚客户端仍在开发中，即使在今天。
话虽如此，选择一个基于Web的架构是不是“新世代的开发商”只知道网络的东西，你得到了很多好处，如果你可以让你的应用程序基于Web的：
- 部署非常简单。即使有像ClickOnce，自动更新等等，没有什么比只刷新页面以获得最新版本
- 您可以使用Silverlight之类的东西来获得桌面应用程序的99％的好处（就运行能力而言代码在客户端）
- Web应用程序可以比桌面应用程序更容易地远程使用（许多公司现在有远程工作者，建立VPN是一个痛苦，如果你想要做的只是访问工资单（或什么））
但在一天结束时，这一切都是关于工作的正确工具。当您想要为Office（Word，Outlook等）编写插件时，Web应用程序无法提供帮助，但如果您必须控制自定义硬件（POS终端等），则它们无法提供帮助 - 尽管您可以将它写入服务器案件...），也可能还有其他几个案例。
我至少能想到两个大十岁上下的市场中，客户端 - 服务器仍然是大的：
- 在线游戏和虚拟世界，如战场或第二次生命。通常你需要一个胖客户端加上到共享服务器的连接。
- 定制科学软件。复杂的技术或科学软件，尤其是如果需要交互式图形用户界面（可直接操作）的软件，有时也会以这种方式编写。
我们有一些Flex应用程序与基于XML的Web服务进行通信，这些应用程序非常接近旧学校的客户端服务器应用程序。但不是使用SQL，而是使用自定义XML语言并呈现SOAP响应。
然后你需要编程，维护和管理整个中间层。 XML很麻烦。它是许多应用程序的工具，但我试图说服人们，我们已经摆脱了简单化，有时更简单的解决方案仍然是最好的。我也写GWT应用程序以及网络应用程序，所以我理解这些机制。 – 2010-06-30 02:20:19
我们目前每年开发和部署大量的客户端/服务器应用程序。开发过程简单而且自动化。我们不仅限于我们能够部署的数据库技术。客户端/服务器部署计算速度更快，形式更新和报告更快。基于Web /云的应用程序的响应性低于在客户端工作站（胖客户端）上运行的应用程序。
这是因为CPU负载的分布。尽管服务器端应用程序要求服务器执行所有计算，但客户端可以在本地计算机上运行此操作。随着任何系统变得越来越复杂，用户必须等待结果的时刻增加。员工时间的这些时刻更加昂贵，因为他们涉及更多的有薪雇员。这些时刻在一个组织内累积了一年多的“工时”。
与更新的问题是我们的开发工具集内解决。就像你打开你最喜欢的浏览器时一样，它注意到你使用的版本并不是最近我们在客户/服务器应用程序中嵌入了同样的过程。实际上，我们不会给他们更新的选择。由于更新可能会多次需要更改数据库，因此我们强制在用户被允许运行软件之前进行更新。
为了改善我们所提供的定制开发具有特定应用，例如现场调度或客户支持论坛集成到桌面客户端/服务器应用程序的网站包含我们的自定义客户端/服务器系统中的信息的可视性。从我的角度来看，我看到客户端服务器和响应式Web应用程序的完整集成在未来几年中占据了更好的位置。
什么，从来没有听说过的Access应用程序？ – Earlz 2010-06-29 23:53:28
嘿，你的孩子！从我的草坪上离开！ – Stephen 2010-06-30 00:12:48
在这些日子里，我呛每当有人说浏览器是瘦客户端......他们并没有在插件列表偷看我的FF ... – 2010-06-30 05:34:05