C/S 一般建立在专用的网络上, 小范围里的网络环境, 局域网之间再通过专门服务器提供连接和数据交换服务。 B/S 建立在广域网之上的, 不必是专门的网络硬件环境,例与电话上网, 租用设备。 信息自己管理。 有比C/S更强的适应范围, 一般只要有 *** 作系统和浏览器就行。
2、对安全要求不同 :
C/S 一般面向相对固定的用户群, 对信息安全的控制能力很强。 一般高度机密的信息系统采用C/S 结构适宜。 可以通过B/S发布部分可公开信息。
B/S 建立在广域网之上, 对安全的控制能力相对弱, 面向是不可知的用户群。
3、对程序架构不同:
C/S 程序可以更加注重流程, 可以对权限多层次校验, 对系统运行速度可以较少考虑。
B/S 对安全以及访问速度的多重的考虑, 建立在需要更加优化的基础之上。 比C/S有更高的要求 B/S结构的程序架构是发展的趋势, 从MS的。Net系列的BizTalk 2000 Exchange 2000等, 全面支持网络的构件搭建的系统。 SUN 和IBM推的JavaBean 构件技术等,使 B/S更加成熟。
4、软件重用不同:
C/S 程序可以不可避免的整体性考虑, 构件的重用性不如在B/S要求下的构件的重用性好。
B/S 对的多重结构,要求构件相对独立的功能。 能够相对较好的重用。就入买来的餐桌可以再利用,而不是做在墙上的石头桌子
5、系统维护不同 :
系统维护是软件生存周期中,开销大。
C/S 程序由于整体性, 必须整体考察, 处理出现的问题以及系统升级。 升级难。 可能是再做一个全新的系统
B/S 构件组成,方面构件个别的更换,实现系统的无缝升级。 系统维护开销减到最小。用户从网上自己下载安装就可以实现升级。
6、处理问题不同:
C/S 程序可以处理用户面固定, 并且在相同区域, 安全要求高需求, 与 *** 作系统相关。 应该都是相同的系统
B/S 建立在广域网上, 面向不同的用户群, 分散地域, 这是C/S无法作到的。 与 *** 作系统平台关系最小。
7、用户接口不同
C/S 多是建立的Window平台上,表现方法有限,对程序员普遍要求较高
B/S 建立在浏览器上, 有更加丰富和生动的表现方式与用户交流。 并且大部分难度减低,减低开发成本。
最近几年小程序的生态越来越完善,各家的流量App也都在搭建自己的小程序生态。 抛开小程序的业务生态,单纯从技术的角度来说,小程序的远程派发和容器化的跨平台的技术实现对本人日常的架构思考和设计有很大的启示作用。在最近的工作中,我一直思考着一种客户端容器化架构,让Flutter、Web这两种跨平台的技术实现可以运行在像简化的Docker容器中,原生App提供容器的运行时。
为什么选择实现一个简单的小程序?
架构设计点:
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)