我几十年来一直在编写软件,现在一切都是网络 在Web之前,我们有Client Server应用程序,它们基本上是直接与数据库对话的胖客户端应用程序。他们有一些缺点,例如部署很麻烦,没有扩展,因为DB处理所有流量。当然,当时应用程序的分发仅限于在公司网络上的桌面上。这些应用程序的好处在于它们具有更少的层次并且可以快速开发。
有些时候,这些要求需要在具有专用数据库和相对少量客户端的防火墙后面调用应用程序。我建议(有时在StackOverflow上)旧的客户端/服务器类型架构,每个人都看着我,就像我有3条腿和6条臂。
借助现代技术,我们可以自动部署应用程序和工具。这项技术不可行吗?是新一代开发人员只知道网络内容吗?
答案 0 :(得分:7)
我能想到至少有两个客户服务器仍然很大的大型市场:
答案 1 :(得分:6)
我确信即使在今天,厚厚的客户仍在开发中。
话虽如此,选择一个基于网络的架构并不是关于“新一代开发人员”而只是了解网络内容,如果你可以使你的应用程序基于网络,你会获得很多好处:
但最终,这一切都是关于工作的正确工具。当你想为Office(Word,Outlook等)编写插件时,Web应用程序没有帮助,如果你必须控制自定义硬件(POS终端等)它们没有帮助 - 尽管你可以将它写入服务器中案件......),也可能还有一些案例。
答案 2 :(得分:1)
我们有一些Flex应用程序可以与基于XML的Web服务进行通信,这些服务与旧式的Client Server应用程序非常接近。但是,他们不是使用SQL,而是使用自定义XML语言并呈现SOAP响应。
答案 3 :(得分:1)
我们目前每年开发和部署大量客户端/服务器应用程序。开发简单且自动化。我们不仅限于我们能够部署的数据库技术。客户端/服务器部署在计算,表单更新和报告方面更快。基于Web / Cloud的应用程序的响应速度低于在客户端工作站(胖客户端)上运行的应用程序。
这是因为cpu负载的分布。服务器端应用程序要求服务器执行所有计算,而客户端可以在本地计算机上运行此计算。随着任何系统变得越来越复杂,用户必须等待结果的时刻也会增加。员工时间的这些时刻更加昂贵,因为他们涉及更多的付薪员工。这些时刻在一个组织中加起来就像许多人的工作时间一样。一年多了。
我们的开发工具集中解决了更新问题。就像您打开自己喜欢的浏览器时一样,它注意到您使用的版本不是我们在客户端/服务器应用程序中嵌入相同过程的最新版本。事实上,我们不会让他们选择更新。由于更新可能需要多次更改数据库,因此我们强制在允许用户运行软件之前进行更新。
为了提高我们的自定义客户端/服务器系统所包含信息的可见性,我们提供定制开发的网站,这些网站具有特定的应用程序,例如现场调度或客户支持论坛集成到桌面客户端/服务器应用程序中。从我的角度来看,我看到客户端服务器和响应式Web应用程序的完全集成在未来几年中处于更有利的位置。