目前的系统中,前端的变化越来越多样。光web前端而言,HTML+JS,JQuery,Ext以及其他的各种框架等。曾经Ext刚出来时,我们为其美观、整洁的样式所吸引,但当我们开始熟悉并使用Ext时,却发现其界面让人审美疲劳。前篇一律的界面,让人觉得没有创意。
最终,我们又回到原来前端的开发模式,通过美工设计界面和样式。然后用JQuery控件,来实现设计的这种表单、列表等。Ajax模式和Post提交模式目前还是共存,考虑到安全性、性能等各种问题,还是不能某种前端技术就能主导整个系统的实现。
手机App终端出现后,我们发现又有新的前端实现,来访问。我们设计使用HttpClient来提交和获取服务器数据,或者直接用HTML5来设计前端界面。
单当我们希望HTML5等帮我们统一手机、浏览器等多种终端时,却发现HTML5的展现效果,并不令人满意。特别是现在低版本IE的问题等。
相对而言,后台的服务程序开发,相对而言框架没有那么容易变化。SSH框架,基本可以满足大部分项目的要求。
当面对前端的要求时,我们针对具体的界面要求,设计Form类,Bean类、Action以及Hibernate相关的配置文件和类。这种模式由于现在技术成熟,相应的技术人员也多,因此我们可能感觉相对简单。
但是这种模式也存在问题,对于一个简单的页面应用,可能具有大量的class以及大量的xml配置文件。而且对于不同的前端,我们基本上会配置不同的Struts配置,并且创建新的类。虽然工作简单,代码也重复,但是庞大的文件数目,也使得维护非常困难。
因此我们需要有个设想,能不能针对一种服务,不管是多种前端来访问,后来实现上只需要一个文件就可以搞定。一项服务对应一个文件,当服务内容变更时,只需要改动一个文件的内容,就可以满足多个终端的需要。
基于这种设想,我们需要定义每个前端,都用标准的接口。这一块我们需要定义统一的url来接收服务,同时通过参数来区分返回的格式。返回格式包括Json、XML、HTML、JS等。
定义了统一接口之后,我们如何实现一个文件来对应实现一个服务呢。这一块我们需要借助规则引擎的实现。
规则引擎通过一个规则包文件,来定义传入的接口数据、需要处理的数据库对象、临时变量或者对象、业务处理逻辑以及返回的接口数据。
通过一个文件这种设计方式,可以极大简化系统的整个架构。架构师可以将每个界面上需要与服务器端交互的功能,统一用单一的服务来加以设计。使得设计文档中的功能和最终实现的文件,一一对应。
通过面向服务编程,彻底屏蔽了后台数据库的实现,对于前端界面而言,只需要按照交互的要求,来和服务接口打交道。之后后来的服务,是采用关系型数据库存储、还是采用云存储、还是采用NoSQL存储,就变得无关紧要。可以随时对数据库实现加以调整。
但是面向服务编程,还有一个轻量级和重量级的问题。对于纯粹的前端而言,URL访问方式没有性能问题。但是如果是后台服务本身之间的相互调用,那就变成负担了。这种情况下,就需要通过后端相互调用的接口。使得接口本身会自动判断,如果是本地的话,就是native方式调用,如果是远程服务,就通过url方式调用。
最终实现轻量级的面向服务编程。