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.关于基础数据出错的概率，当然减小了。
本文来源于http://www.blogjava.net/oneeyewolf