好事要做到底，我们需要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.关于基础数据出错的概率，当然减小了。

 

评论

27 楼 sunli_qun 2008-01-14  

我觉得现在框架的问题可能在于，太过于考虑通用性，一个spring总是需要符合各种各样的需求，那就注定了它一定是抽象的！

楼主的想法我支持，可能有人担心这样的fullstack框架不能支持工业强度，
但是，如果你是做互联网应用的或者是其他的一个特定的行业的，可能你就没有必要担心这个，我的意思是说：

如果说开发这样一个fullstack框架并且满足所有通用需求很难做到的话，为什么我们不能做一个仅仅满足互联网开发的fullstack应用呢？（比如你正在做cms）
而且，增删改查CRUD页不仅仅在互联网领域有用，我想应该在80%的情况下都是有用的！

现在可以说每天都有新的网站诞生，这样的框架的出现会是有意义的！

ps:关注grails

ps再ps:我正在思考一个基于jackrabbit的cms系统，其中就有一些想法和lz的很像，比如在一个cms系统中，只要我定义一下一类对象（文章）的字段（作者，正文等）有那些，表现形式（单选，多选，对象关联等）是怎样的，我就可以录入了（自动生成crud），前台我就可以展示了，编程只出现在前台展示模版当中。lz 有兴趣的话我们可以沟通一下！

26 楼 Tin 2008-01-13  

这说的fullstack还是软件工厂的概念？还是基于组件的复用？这就是DIY么？

不觉得。其实你发现了你重复的劳动是为了解决核心的元数据的运行和表现的设施，企业级开发就是这样，你搞清了需求（领域模型）你就搞定了这个应用，后面的重复劳动使用fullstack的方案就够了。老曹带大家一起去搞Seam也是这种想法吧，让企业级开发少点重复，多享受沙发。

可是问题在于应用不一定都是基于同一个隐喻的，你所做的东西并非那么简单，如果考虑交互设计等更人本的问题，我想软件的设计就复杂了。

我觉得动态语言在描述领域模型方面更具优势，描述完了领域模型，后面的逻辑就放给框架去做吧。

前两天和朋友在城铁上面聊，他说决定企业应用成败的还是领域专家……追根求源还是模型隐喻的认识，模型和人机交互。

25 楼 lgx522 2008-01-11  

要求不要太高的话，RoR或者Grails大体上就能够full stack了。

24 楼 ajoo 2008-01-10  

DIY原则？？？

23 楼 Ihavegotyou 2008-01-09  

这篇文章不错.
如果所有认知分为两类,那么就应该是分类和总结。
楼主提到抽象,抽象也是一种总结(或分类),文中提到到
"装模做样的写一个DAO",就是抽象没有达到一定高度,
看看别人是怎么 "Don't repeat the DAO!",http://www-128.ibm.com/developerworks/java/library/j-genericdao.html

从这个角度说,能抽象到最大高度,也是需要本领的.

很欣赏楼主的务实作风,大家都是同道中人

22 楼 chm2920 2008-01-09  

盛大2008主打星－－《龙神传说》

    《龙神传说》是由盛大网络自主研发的一款由顶级漫画家担纲原画设定的2D MMORPG网游，其最大的亮点就是宠物：“一个网游玩遍所有宠物”，将于今年与国内的各位玩家见面。

    一款以宠物为亮点的网游，宠物的名字更是希望得到大家的认可和喜欢，为此《龙神传说》特意举办了“宠物征名”活动，现已收到诸多玩家的提名，真是千奇百怪、无奇不有。还没有参与进来的朋友，你想不想届时让五亿盛大通行证拥有你命名的宠物？

    让我们来看看目前玩家对于《龙神传说》宠物的奇思妙想：
    更多请进入活动页面>>> http://bbs.ls.sdo.com/

    财宝蟹网友取名：啊贵、聚财
    网友评语：既然都是财宝蟹了，当然要“聚财”才行喽，哈哈。
    一副蛮横的样子，一定是家财万贯、娇生惯养，自然叫“啊贵”啦！

（图片一）

    忍者猫网友取名：乱太、小影
    网友评语：突然想起动画片《忍者乱太郎》中那群在忍术学校里学习忍术的小朋友。
    《火影忍者》中卡卡西老师也时常摆出这样的战斗姿势哦！

（图片二）

    松鼠网友取名：馋馋、淘淘
    网友评语：刚看这角色，细心观察了会儿，她又拿食物又拿饮料，所以决定给她这个名字－“馋馋”。

    手里拿着，尾巴卷着，很淘气，是个捡东西的能手，所以叫“淘淘”。

（图片三）

    丘比兔网友取名：艾艾、丫咪
    网游评语：爱的同音，丘比特为爱神。

    爱神丘比特的宠物，常常躲在丘比特身后，丘比特常常取笑她是不懂得爱的兔子，只会说“丫咪~”；一次趁丘比特睡着，丘比兔偷偷带走爱神的箭走了，但是弓呢？啊吖，忘记拿了……丫咪丫咪。

（图片四）

    作为《龙神传说》那些惹人喜爱宠物的主人，你喜欢这些名字吗？如果你有更好的建议，那就快来大声说出你的想法……更多可爱的宠物同样需要你的建议，敬请关注。


《龙神传说》官方网站：
http://ls.sdo.com/

《龙神传说》官方论坛：
http://bbs.ls.sdo.com/

21 楼 huangpengxiao 2008-01-09  

看前面说的不错 但到具体措施上 系统的增量复杂度 也会使这种结构变的不full-stack. 感觉无论怎么样结果都差不多. 尤其‘对于1%钻角尖的需求’这部分需求由于需求分析人员的分析能力而变的需要占更多的百分比的时候.那是不是说这种full-stack 对developer的合作者要求有更高的能力和适应力?

20 楼 skydream 2007-12-29  

jackyz 写道

great demo! but, full stack = javascript level integrate?

应该是，毕竟目前ajax的使用使得javascript摆脱了原来使用范围局限于数据检测/页面动态效果的尴尬处境，ajax为了提高用户体验，必然会修改原有的设计和流程。

这里涉及到需求分析/页面流程规划/用户体验改良等要素，很难想像如果少了这些，full-stack的full能否full的下去。

19 楼 skydream 2007-12-29  

楼主的想法是很好，但是似乎，full-stack的人才太难找了吧？能从view一直做到control到model，这样需要的技术太多太杂了。一般java开发人员很少会这样来设计发展自己的知识点，大多有所侧重。

18 楼 [e-mail] 2007-12-29  

楼上平台也是一个full-stack工具！！

17 楼 jackyz 2007-12-29  

great demo! but, full stack = javascript level integrate?

16 楼 bybsky 2007-12-28  

movingboy 写道

只是在现实世界里，找到这样的有水平的人才、有远见的团队恐怕也不容易啊。

这样的人才在国内，也只能用“可能”不是很多来表示，关键是如果一个团队能够同心协力，我想超过一个“有水平的人才”还是绰绰有余的。

movingboy 写道

国内的环境可能更差，人心浮躁，公司短视，能真正静下心来搭架子的个人或团队不多啊，愿意把搭好的架子贡献给业界的就更是屈指可数了......

这句话有点走题 

另外：大家无论是编码还是设计，以满足用户需求为第一，即使老板舍不得花钱，老板的目标也是满足客户需求的，这样就需要相关负责人来做一个权衡了。

15 楼 114109796 2007-12-26  

好贴  受益匪浅

14 楼 rainshow 2007-12-26  

出发点有所不同，研发一个产品，为达到扩展性强，灵活性高，需要做很多抽象，不在乎多花点时间。

13 楼 Godlikeme 2007-12-26  

头一次看帖这么爽，写的太好了，评为良好有点可惜。

12 楼 OneEyeWolf 2007-12-26  

<p>

agile_boy 写道

我坚持认为设计尽量抽象，尽量不要过早的利用某些特定语言，框架，系统。设计只有能最大程度的体现业务，体现用户价值，体现高层的抽象，也就可以了。所以一个full-stack的设计的出发点也许本身就错误了，就提前绑定到某一框架（也许我对LZ的有误解），而且设计也不可能千篇一律，不通的需求会有不通的设计的。

</p>
<p>看来，你也应当加入SUN的JCP组织了，世界上最擅长抽象、制造标准的组织。</p>

11 楼 agile_boy 2007-12-26  

我坚持认为设计尽量抽象，尽量不要过早的利用某些特定语言，框架，系统。设计只有能最大程度的体现业务，体现用户价值，体现高层的抽象，也就可以了。
所以一个full-stack的设计的出发点也许本身就错误了，就提前绑定到某一框架（也许我对LZ的有误解），而且设计也不可能千篇一律，不通的需求会有不通的设计的。

10 楼 OneEyeWolf 2007-12-26  

引用

另外，引申出来的一个问题，前端架构如何更好full stack设计?不少开发者后端本领不错，但到前端上稍微不重视（甚至讨厌js）,随着AJAX普及和新一批OO JS的最佳实践（如YUI/EXT）,使我们不得不忽视以前未能细化的地方，无论“里、外”，都必须做得更好

前端的设计，在互联网应用当中，非常重要，是非常挑战你的创造力的地方。
<p>前端上稍微不重视（甚至讨厌js），是因为在没有掌握足够技能或准备的情况下，开发一到这个地方，花费的时间太多了，浪费在HTML标记和JS除错的地方，知难而退，还未有到一个光明的境界。</p>
<p>另外就是太忽视前后端良好结合，以用户为中心，提高用户体验所带来的巨大效益。</p>
<p>先看看JIRA的项目管理软件，再看看基于WEB2.0的项目管理应用<strong>Basecamp，会体验到两种不同思想。</strong></p>
<p> </p>
<p> </p>

9 楼 agile_boy 2007-12-26  

grails也是一个full-stack工具

8 楼 sp42 2007-12-26  

另外，引申出来的一个问题，前端架构如何更好full stack设计?不少开发者后端本领不错，但到前端上稍微不重视（甚至讨厌js）,随着AJAX普及和新一批OO JS的最佳实践（如YUI/EXT）,使我们不得不忽视以前未能细化的地方，无论“里、外”，都必须做得更好！