当然,我见识有限,只能是回顾我所经历过的一些架构,定有不全之处,各位见谅。
回顾:
我从2001年开始接触企业信息化系统,之前做的是工业自动化领域的设备组态和控制系统。时间过得真快,都6年过去了。
最先了解的架构是两层c/s,其中的S 就是一个数据库,客户端通常都是vb/dephi或者pb开发的桌面程序。这种架构问题多多:部署、升级麻烦;开发时没有层次,客户端事件驱动的UI代码和数据库访问的SQL代码交织在一起,可读性和可维护性都很差。不过我并没有用这种架构开发过,但对微软提出的DNA三层c/s架构倒是稍有实践。
微软的DNA架构基于window server的com+组件服务器对两层c/s架构作了些改进,在这种架构下:把界面无关的核心业务逻辑定义在一系列接口中,然后实现相应的com+服务组件和访问代理组件,然后实现人机交互桌面程序,把人机交互程序和com+的代理组件部署到客户的桌面上,com+服务组件部署到windows server服务器的组件管理器中。这种架构相比两层架构还是有较大进步的:不必到处配置数据库连接了;如果改动界面无关的服务器端逻辑,在不改变接口的情况下,不必修改客户端程序,因此升级维护会方便一些;更重要的是层次比较清晰,把界面交互部分和业务逻辑部分有效隔离开了,类似于spring架构中service和mvc的分层,大大提高了程序的可读性可维护性。但相比几乎同时出现的瘦客户端架构来说,它的部署和升级维护还是太麻烦了。显然的,客户的核心业务逻辑变化不会太多太频繁,但界面程序的代码量和变化频率绝对大于60%。因此市场对受客户端架构接受更快,DNA架构很快落了下风。另外微软转变战略,准备用.net架构来和j2ee一争高下,DNA更是无人问津。
从2002年我开始用j2ee来架构和开发应用了。最初用j2ee的时候,系统的架构其实和DNA还是挺相似的,只不过客户端从桌面程序变成了浏览器,但宏观上还是UI层+service层+dao层。j2ee的大旗下,新技术新架构层出不穷。但宏观上依然没有多少变化,新技术主要改变局部的实现,比如hibernate改善dao层、struts和webwork改善UI层,spring是一个粘合剂,让你的多层架构更灵活,更少紧密耦合。ejb.x,有了解,但从来不曾在项目中使用过。从2002年到2005年,c/s架构和b/s架构在企业应用中都还是挺有市场的。注重客户体验的公司,倾向于使用c/s架构,注重部署和维护的倾向于使用b/s架构。但从2005年开始,随着ajax概念的提出天平开始向b/s架构倾斜。最初的b/s架构在客户体验方面的确无法和c/s架构媲美,因此b/s架构的先行者不得不大力钻研js/css/dom等技术,随着这批先行者对这些技术越来越得心应手的掌握,ajax的出世也就水到渠成了。在ajax概念出来之前,我所带领的团队已经大量采用xmlhtpprequest来获取数据,用js/css/dom来渲染界面了。ajax的出世,让我们在这方面更进一步。
展望:
随着ajax的普及和改进,b/s架构将基本取代c/s架构在企业应用中的地位。但这种取代不是简单地以浏览器取代桌面程序,而是从开发模式到用户体验这两个层面吸收c/s架构的优点,使b/s架构在这两方面达到甚至超越c/s架构。包括我们团队在内的很多开发者已经在这么做了。我们目前的开发模式是,用html来编写界面,用js来响应用户操作,驱动界面变化。在界面文件(html或者Jsp)中,基本上没有java代码和tab标签,只有js代码和html标签。js代码在响应用户操作的过程中,会使用xmlhttprequest来调用服务器端的业务逻辑,根据处理结果来驱动界面变化。这种开发模式,和使用vb/dephi来开发c/s应用是类似的。无非它们的client是用控件来编写界面,用vb/delphi来响应用户操作。
在使用ajax技术的b/s架构中,有一种做法是我所不赞同,但仍然有很多人在使用的:在响应用户事件的时候,调用服务器端接口是生成了一段html代码片断,用这个片断直接填充客户当前操作的页面,实现对界面的驱动。这种开发模式下需要服务器来生成界面,意味着你的服务器代码中不得不把html代码和java代码混合在一起,也就是业务逻辑和UI逻辑混杂而居。单这点而言,和DNA架构相比,是个倒退啊。我们的做法是大多数情况下,用户事件响应代码中,只用xmlhttprequest提交当前页面中的对象,返回的也是从服务器取回的对象。如果需要局部更新界面,只是把取回的对象或者对象图绑定到一个界面JS控件上就行了。当然,你也可能把当前界面改变会一个完全不同的新界面,这时候根本不需要xmlhttprequest,你只要iframe.href = url或者window.open(url),或者show一个dialog就行了。总之,在服务器端,混杂java代码和html代码来生成一个界面片断的做法是完全不必要的。
分享到:
相关推荐
中国联通云网融合研发回顾与展望 中国联通云网融合研发回顾与展望是中国联通发布的白皮书,旨在推动云网融合和SDN/NFV技术的发展。该白皮书概括了中国联通云网融合研发的历程和愿景,提出了一系列的技术创新和解决...
信息化是建筑设计院发展的必由之路——建筑设计院CAD及信息化发展回顾与展望.pdf
在第三章中,讨论了香港联交所VIE架构的新规则与案例回顾,包括适用情形、《外国投资法草案(2015)》相关风险应对措施及披露要求,并对2018年香港联交所审核通过的VIE案例进行了分析。 第四章探讨了香港联交所新...
数据库产品回顾与展望 本资源总结了 2008 年数据库产品的发展和展望,对 Oracle、IBM 和微软等主要商用数据库厂商的产品发布和发展进行了分析和评价。 知识点 1:数据库市场份额 * 2007 年,Oracle 以 48.6% 的...
总的来说,凸轮机构CAD/CAM研究的回顾与展望,不仅涉及到了凸轮轮廓设计的理论研究,还包括了凸轮机构运动学的分析、凸轮CAD/CAM系统的开发与应用,以及对未来发展趋势的预测。这一研究领域不仅涵盖了复杂的数学和...
安在讲堂 _ 直播实录:应急响应的回顾与展望 应用安全 法律法规 安全对抗 安全防护 数据安全
80286的发布引入了实模式和保护模式,实现了与前代处理器的兼容,并通过24位地址总线扩展了可访问的内存空间,达到16MB,这在当时是一个巨大的飞跃,为后来的x86架构奠定了基础。 接着,Intel推出了80386系列,其中...
标题中提到的“分布式水文模型的回顾与展望”揭示了文档主题聚焦在水文学领域,尤其关注分布式模型的运用、发展历史以及未来的发展方向。分布式水文模型是水文学中用于模拟流域内水文过程和水文要素时空变化的数学...
《Linux市场全面反弹——2004年中国Linux软件市场回顾与展望》这篇文章主要探讨了2004年中国Linux软件市场的繁荣景象以及未来的发展趋势。在这一年,Linux软件市场实现了快速增长,市场规模达到9644.4万元人民币,...
移动通信技术的发展历程是科技进步与市场需求相互推动的结果。自20世纪80年代以来,从第一代(1G)模拟通信技术发展至如今的第四代(4G)甚至第五代(5G)无线通信,每一次迭代都带来了显著的提升。 1G时代的移动...
这包括了对当前发展状况的总结和对未来发展的预测,为上海市乃至国内其他城市在天然气分布式能源领域的研究与应用提供了参考和借鉴。 基金项目和技术研究 该研究得到了国家重点研发计划“智能电网技术与装备”专项...
为了全面理解情报学教育的发展脉络,本文将对改革开放以来,特别是大数据时代背景下情报学教育的发展历程进行详细的回顾和总结。 首先,情报学教育自1978年恢复至今已经历40余年的发展。在这段时间内,情报学教育...
中小银行,尤其是那些资产规模不足以与大型商业银行竞争的机构,通过互联网贷款业务不仅能在激烈的市场竞争中获得一席之地,还能利用自身的灵活性和本土化优势,在金融服务领域探索出一条新的发展道路。 在互联网...
智能管理模式利用信息技术实现对糖尿病患者的个体化管理,包括个体化控制目标的设定、饮食和运动的监控与指导、血糖水平的实时监测等。通过智能设备和应用,患者的健康数据可以被实时收集并分析,为医疗决策提供依据...
《NetApp用户案例-新浪-IT基础架构回顾与展望》是由新浪网研发中心平台架构部总监编写的,这个案例深入探讨了新浪在IT基础设施建设上的实践经验与未来规划,尤其是在使用NetApp存储解决方案方面。NetApp是一家全球...
#资源达人分享计划#
#资源达人分享计划#
2. **系统架构**:构建了系列化的互联互通的数字图书馆应用系统,实现了资源的分布式管理和服务。 3. **资源整合**:通过各子项目和各级文献信息中心的建设,CADLIS整合了CALIS中心、高校图书馆和第三方资源商的...
CAD的应用范围覆盖了从产品的设计绘图、工程分析、到文档制作的整个过程,它不仅促进了设计效率的提升,同时也推动了各相关领域的技术革新。 CAD技术的关键基础技术主要包括图形处理技术、工程分析技术、数据管理与...
应急响应回顾展望》所涉及的内容,我们可以从几个核心的知识点来展开讨论:安全威胁、安全对抗、安全管理、端点安全、身份与访问管理,以及数据安全与治理、工控安全、渗透测试和系统安全安全架构。 首先,安全威胁...