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

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，八股文式的开发模式，味同嚼蜡。我们的代码仍然在急速的膨胀了，我们仍然感觉很累，我们的千行代码出错率仍然没有减小，这不是个好事情。

  有人说，这就是设计吗，这连头猪都会。

  我做了电子商务网站多年了，无论是管理还是技术，都非常的有挑战性。

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

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

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

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

   我们不需要供养着一批只是评审工具的、满嘴术语、动不动就用可用性、可扩展性之类的Matrix表格让我们看他们的评估结果的架构师。

   我们也不需要满口hign-performance、large-scale、群集、ajax，光说不练的家伙，对于一个成熟的电子商务网站来说，基于Scalability的架构已经趋于稳定，并有专有团队来维护，用不着你来天天搞群集。

   我们也不需要只会写个JAVA类的所谓的设计师。 

   我们需要的是full-stack的设计，我们需要的设计师，对于互联网应用来说，三层都应当相对精通，就像习武之人，任督二脉都打通那种高手，才是NB的高手，从front到database，都有要丰富的经验。

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

   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.关于基础数据出错的概率，当然减小了。

 

评论

7 楼 LucasLee 2007-12-26  

说得不错.我的想法跟你的有很多相似点.
关键还不是想不想得到,还得做出来啊.
等别人来做还是相对消极的.

6 楼 movingboy 2007-12-26  

楼主的想法很不错啊，只是在现实世界里，找到这样的有水平的人才、有远见的团队恐怕也不容易啊。
Java相关的技术很多，搭一个架子要融入多种技术，难度不低啊，看看国外的一些与楼主的想法类似的框架，非多年的积累不能成功。
个人对AppFuse相对熟悉一点，感觉这个框架仍在完善的过程中，除了仍有一些缺陷外，只能算一个CRUD的模板，自己仍然要用心写好业务代码，否则也是一团糟。
国内的环境可能更差，人心浮躁，公司短视，能真正静下心来搭架子的个人或团队不多啊，愿意把搭好的架子贡献给业界的就更是屈指可数了......

5 楼 pppppp 2007-12-26  

seam也不错啊

4 楼 han0332217 2007-12-25  

顶一个了先!

3 楼 nwangwei 2007-12-25  

rails可以算一个full-stack哦！

2 楼 hyhongyong 2007-12-25  

LZ理论不错，不过例子举得不够工业级强度啊。有时候封装没做好，还不如不封装。脚手架要从技术和业务两方面的通用性考虑，当一些基础业务方面发生变化时，要能比较良好地升级！

1 楼 sp42 2007-12-25  

谢谢楼主的帖子。的确，DIY原则（don't repeat yourself)是不二的法则，也是架构设计的指导思想之一。