full-stack 的设计,意味着各层能够无缝的集成在一起,遵循的DIY原则(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.关于基础数据出错的概率,当然减小了。
相关推荐
《Fullstack React》是一本专注于ReactJS和其生态系统的全面指南书籍,由Anthony Accomazzo、Ari Lerner、Nate Murray、Clay Allsopp、David Guzman和Tyler McGinnis共同编写,并得到了Sophia Shoemaker的技术支持。...
《Fullstack React:The Complete Book on ReactJS and Friends》是一本全面深入介绍ReactJS及其周边技术的书籍。本书由Anthony Accomazzo、Ari Lerner、David Guttman、Nate Murray、Clay Allsopp和Tyler McGinnis...
《fullstack-react-book-r36》是一本全面且深入的指南,专注于React及其相关的技术生态。这本书旨在帮助读者成为ReactJS领域的专家,提供最新的、详尽的教程和实践指导。以下将详细介绍React及其朋友们的核心概念和...
If you’d like to report any bugs, typos, or suggestions just email us at: react@fullstack.io1. Chat With The Community! There’s an unofficial community chat room for this book using Gitter. If you’...
"fullstack-tutorial" 是一个开源项目,旨在为开发者提供全方位的全栈开发教程。这个项目的目的是帮助初学者和有经验的程序员系统性地学习和掌握全栈开发技能。通过参与此项目,你可以从基础到高级,一步步学习如何...
《Fullstack React:ReactJS和相关技术的完全指南》是一本专注于React技术栈的教程书籍。本书更新至第36版,支持React版本16.3.0,其发布日期为2018年4月2日。该书的作者包括Anthony Accomazzo、Ari Lerner、Nate ...
Fullstack Rust: The Complete Guide to Building Apps with the Rust Programming Language and Friends epub 格式 请使用 calibre 打开,其他的软件可能打不开
通过"fullstack-vue-book-r8",读者可以期待全面学习Vue.js的各个方面,包括基础语法、高级特性、组件设计、状态管理、路由配置、全栈项目实战,以及相关的最佳实践。这份资源对于想要掌握Vue.js全栈开发的开发者来...
该书在2018年初版的基础上,不断修改增补,2021年更新为Vue 3.x,主要介绍Single-file components、Custom Events、Vuex and Server、Form Handling、Routing、Composition API、GraphQL等。共625页,内容详细全面,...
Fullstack.Vue.r8.2018.8
“The Full Stack Developer Your Essential Guide to the Everyday Skills Expected of a Modern Full Stack Web Developer” Excerpt From: Chris Northwood. “The Full Stack Developer.” iBooks.
fullstack react 2019.1 最新教程,react最好的教程。
Full Stack AngularJS for Java Developers Build a Full-Featured Web Application from Scratch Using AngularJS with Spring RESTful
Full Stack AngularJS for Java Developers 英文无水印原版pdf pdf所有页面使用FoxitReader、PDF-XChangeViewer、SumatraPDF和Firefox测试都可以打开 本资源转载自网络,如有侵权,请联系上传者或csdn删除 查看...