帮助IT团队快速构建符合jt808协议部标的基于java技术的GPS和视频平台(2379423771@qq.com)

好事要做到底,我们需要full stack的API设计

full-stack 的设计,意味着各层能够无缝的集成在一起,遵循的DRY原则(don't repeat yourself),将各层共用的东西,抽取出来,并通过自顶向下的设计,无缝的集成在一起,粘合在一起,达到更高层次、更粗粒度的重用,同时为了保证灵活的可扩展性,在更高、更粗的粒度上遵守开放-封闭的原则,在各层的各个关键点,要提供诸多的钩子,回调的接口,供使用者扩展。full-stack的设计,在层与层之间,并不一味的追求松散的机制,而是相反,在层与层之间增强一定的内聚性,粘合力,以此来达到粗粒度的封装与重用。

  可以说full-stack 的设计,其爆发出的威力是巨大的,相对普通的单一层面的设计,在开发效率上不是一个层次上的,基于28原理的设计,可以满足80的调用者直接开发,19%的调用者,通过扩展点进行扩展来满足需求,对于1%钻角尖的需求,自己去造轮子。

  spring, ruby on rails, Zend都是这样的工业级强度的full-stack的设计,我们的设计如果以他们为中心,生产力得到了极大的提高。

  但是我现在厌倦了,屁大的事,就要装模做样的写一个DAO,写一个Service,写一个Action,再写一个JSP,八股文式的开发模式,味同嚼蜡。我们的代码仍然在急速的膨胀了,我们仍然感觉很累,我们的千行代码出错率仍然没有减小,这不是个好事情。

  我做电子商务应用N年了,无论是管y理还是技术,都非常的有挑战性。

  从用户角度,前有看不见摸不着、挑剔的、脾气暴躁的互联网用户,后有工作量巨大、业务繁忙的后台业务部门用户,他们狠不得,用魔法棒,一指,网站上就会有这个功能,时间不等人。

  可是电子商务网站角度来讲,不同于一般的内容门户网站,出个错没有什么大不了的,当用户在我们的网站上看到的一切东西都是有法律效力的,当用户下单成功交易的一瞬间,这种关系已经实施,出个错,谁也担当不起,大家不记得DELL门事件,网上直销价格报错了,引出了多大麻烦,在外面,有公司担当着,在公司内部,估计当事人,也是痛苦的不得了。 

  我们即要追求快速开发,以用户为中心,拥包变化,又要保证工业级的强度的稳定。

  一般的发包,从需求收集,明确,整理,发布release计划,拉分支,开发,内部测试,提交功能测试,压力测试,on stage, on production,上线跟踪测试, 合并分支, 这样的流程,一个环节都不能少,不能出漏子(当然只是从理论上保证)。
   这样即使一个月发一个包,开发时间不过10多天左右,这样的发包速度,还是满足不了要求。当我们对他们说,这个功能,下个月才能上线,用户会无辜的睁大双眼,看着你。
   所以在设计这个层面上,我们需要更多的重用,更多的粗粒度的,工业强度更强的重用,可以更高层次的在大大提高我们的开发生产力同时,减小我们出错的概率,当你的程序出错的时候,你一般不会就认为是springe的BUG造成的吧,是自己的代码出错。 

      我们需要的是full-stack的设计,  我们需要的是基础扎实的,有热忱的设计师,能够真正的帮助开发人员解决问题,提高生产力,而不是那种只提供约束、规范,不提供方法,不解决问题的人。 

   full-stack设计体现的是一种设计思想,是要在不管是微观还是宏观层面上,去应用这种思想,并不是要一定要设计出像spring那样大的东东来,也不可能。 

   我以一个电子商务系统当中的业务基础数据字典子模块的设计(很多人都做过,可以做一个对照),在一个三层切面,论述一下full-stack的设计的具体应用:  

1.抽象描述层需求

(1)表现形式:下拉框、单选框,多选框,列表框,表格,文字
    不同的数据有不同的展现形式,  同一数据在不同的页面,也有不同的表现形式
    例如:我们在旅游网站上看到的,有的网站在选择城市时,是下拉框选择的,有的是弹出窗口,并将所有的城市按表格的形式列出来的, 还有的就是列表框显示的

    对于多选框,一般都需要自动添加一个全选的checkbox,并生成全选事件,不要调用者自己再写。
    如果是下拉框,要能够自动添加一个“请选择”的option或者从传参数中指定一个header. 

    默认选中值,当传入默认值时,能够设置默认选中。

(2) 控件事件模式
  要能够提供Callback,如Listener、Observerable模式的事件注入。 

(3)基础数据在页面上的布局方案,
   基础数据是放在Table的TD单元当中,还是DIV当中
   对于多选框的展现与布局,当多选框多的时候,使用表格来布局,来保证换行时,自动对齐。

(4) 数据转换与渲染

   在页面上,能够将ID值,转换成用户可读的文字值,如订单状态1转换成已成交,2已配送,3,已取消的形式。 

(5) 前后台数据交换机制:

    你可以使用异步应用,如ajax来解决问题,也可以使用同步的如JSP标签来解决问题。

    基于ajax的前后端数据交换格式:XML, JSON, DWR, 自定义等等。
   作为你自己的单独的应用,没有必要这么花哨,无论那一种,都可以。但如果是作为开源的、或者是商业产品,给未知的应用调用,就要考虑可扩展性,让调用者可以扩展,使用自己熟悉的方式,如EXT提供了XML,JSON都多种reader,你也可以扩展与DWR集成。 

2.抽像后台需求

(1)多数据源的屏蔽:XML文件配置、properties配置、本地数据库表、远程Webservice接口。

    如果是基于页面指定的查询条件,动态查询的接口,如类似于ibatis的查询接口

    List ds.queryForList(queryID, paramMap)   
  

(2)排序

   a、不同的基础数据在页面显示时,有不同的排序需求

      如城市是按拼音排序的,
      订单操作步骤数据是按序列号来排序的
      没有要求的,默认是按录入顺序来排序的  

   b、排序即可能在后台排序,也可能在页面上基于javascript排序
   所以无论是在前端,还是在后台,都要提供一个倒钩接口,让调用者可以按自己的要求对数据进行排序。 

(3)分布式环境的要求
    分布式在中大型的电子商务当中,几乎是必须的,作为底层的支持,为其它分布在不同服务机器上的应用都要提供共用的的基础数据,同时要缓存,当数据修改后,要刷新缓存,并要通知第三方的应用。如机票、酒店、自由行、呼叫中心、配送、结算中心等等十几个子系统应用都要调用城市、支付网关列表等数据。

(4) 数据管理
  添加、修改、删除基础数据的权限.
  数据排序处理。

(5) 缓存
  缓存是一定要有的,一个是数据中心的缓存,当远程调用者又在本地做缓存时,数据变化时就要提供远程通知的接口,否则调用者客户羰的数据就不会自动刷新。

  缓存,可以基于spring+EHCache,配置缓存方案和策略。也可以通过适配器外接到其它的缓存配置方案上。

设计实施:

BasicData.config:{

    type:'select',//*下拉框、单选框,多选框,列表框,  文字, tbody

    id: 'select_id', //*指定绑定的控件ID,如果ID不存在,则系统会创建指定类型的控件,否则就绑定

    name:'city',//控件名称,不是必须的

    parentID:'div_city', //*父类容器ID,如果容器ID是tbody,则数据会自动填充到表格当中

    defaultValue:'1,2,3', //默认值,对于多选框,多个默认值时有逗号隔开

    resourceId:'', //*传给后台的基础数据标识,根据此代码,可以获取到指定的基础数据,如送票城市、转账银行等。

    autoCreaeSelectAll:'y', //是否自动生成全选 

    header:'请选择',//如果是下拉框或列表框,要生成一个header

    event:{name:'onchange', event:'changeChild'}, //事件监听

    comparator:'compare',//排序比较函数,

    cssStyle:'', //CSS风格

    paramMap:{} //用于后台动态查询的查询参数

    datasource:ds//设置数据源,可以为空,系统自动使用默认

}

 

调用者:

 /**

 *获取信用卡列表,进行复选框排列

 *@divID 你设置的DIV的ID号或其它父控件ID

 *@paramName 控件名称

 */
function setCreditCardList(divID_, paramName_, defaultValue_) {

    xBaseData.draw({type:'select', id:paramName_, name:paramName_, parentID:divID_, dfaultValue:defaultValue_});
}

 

整个方案实施的效果
  1.几乎是一劳永逸的解决了基础数据的需求问题
  2.开放者只需要在页面,一行JS代码或一行标签,就解决了问题,不用关心其它的东西了。
  3.使用者已经忘却以往的诸多不便,对一个局部的编码者而言,变化是小的,对于设计者,从全局几十个子系统,上百名开发者而言,效率的提升是显著的。所以设计者的格局要大。

  4.关于基础数据出错的概率,当然减小了。

posted on 2008-01-01 15:27 Speed 阅读(2038) 评论(0)  编辑  收藏 所属分类: 框架设计


只有注册用户登录后才能发表评论。


网站导航:
 

导航

留言簿(15)

随笔分类

值得一看的博客

积分与排名

最新评论

阅读排行榜