欢迎来到天天文库
浏览记录
ID:45750493
大小:177.04 KB
页数:30页
时间:2019-11-17
《2实用开发模式研究--思想概述》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库。
1、实用开发模式研究(一)目标:希望将口己的开发经验进行一系列的总结,从中提炼出一种实用的开发模型(模式)。(后记:希望能都不断向模式的高度去发展)前言:在这里将不会去讨论贫血模型和充血模型孰好孰坏这样的口水纷争,这边以期从实用主义的角度出发,考虑如何帮助开发人员更快速的构建应用.保证高效、高质屋的完成预期的任务。在这里先解释一下为什么会突然提出贫血和充血的概念。因下面有讲到实体类解决方案的时候,在我的解决方案屮建立的实体类既不是贫血模型也不是充血模型。而是一个较标准三层架构开发模式下的实体类更加实用的数据建模思想。接下来讲,实用开发模式H前主要研究了哪些问题
2、?我们先从第一个实例开始:先带领大家去感受一下先命题如下一个非常普遍的应用场景:开发一个查询功能,要求如下:(整个项H要求一•致)1•提供查询条件2•查询条件有重置功能3•查询条件有记忆功能(以后进入此页面,上次的查询条件和结果依然在,此功能应运场景非常的广泛)接口化支持一灵活的配置(意即:通用是要此功能;但是不是固定的)4•查询结果显示在表格控件屮5•表格控件耍支持真数据库分页6•表格控件要支持排序7•表格控件要支持标题栏固定&表格控件要求支持指定前几列固定9•表格控件要求支持分页大小可调整I0.表格控件要求支持数据库全排序II•表格妾支持选择12•表格
3、要支持全选和全不选13•查询条件能够隐藏,从而为查询结果提供更多的空间14•隐藏的状态要既有后台记忆功能,而非下次又复原RMSBMM-±«-“•0*NUM¥IIr区K代MK>tBit-±l厂CNXL4rCNTW尸CNSEA事・fKil叵cnika■■tutaiiutrCXMXArn.imsirCXJtSAowewtrCNEAAraiutrCNW■IO»•wan厂CN*AASltUtrOXtAlkt申■H.IMrKO毎W・"rC5X2Xrfl中Mta^4iu«au4、Lbr»O%w»,Otnt^ogrwwrwxj»《S«vfr*ro9WT?v>0□tMSVSH•祸,訂I喋円i・±r转#*[口5匸]400*针对如上需求,对于一个初级程序人员来说也不什么难事,用流行的话来说简直就是”小菜”or“SmallCase%你也许就按部就班的开发了,一点一点的实现了设计说明书上要求的内容了。OKnoproblem通常在一个项冃中如上这样的页面,保守估计占•整个项冃的60%以上,甚至更多,基础维护资料不用说,很多的维护画面也是基于上述的查询结果然后进行相关的后续操作功能实现。你去实现一个不难,100个呢,你会去复制相当于100份,而后5、在各个页面进行后续开发。为什么要复制代码,用重构的思想■■“有冃只有一次原则”,这样的代码就是出现了“坏味”,需要加以改造的代码。(当然重构的思想是没有问题,但是重构也是从粗到细—步步來,我们也不能完全用原则来套,走进另一个极端,设计过度也是一种缺陷,度这个东西,看不见、摸不着,我们也不去展开重构这个话题,这里只希望从实用的角度出发,侧重阐述如何建立一种能帮助开发人员针对问题、解决问题的行之有效的解决同类问题的模式。针对如上的査询页面,如若需要增加一个功能呢?怎会如何应对?例如:实际应用过程屮发觉,数据表格控件日前是支持分页大小可调整的,现在问题出来了:需6、要这个分页大小要有记忆功能(以后进入此画面要能自动应用上次的应用设置),这个要求我认为也非常Z合理。我也希望能够站在用户的角度,为用户考虑解决此问题,可是,面对那么多的页面,何以下手,就算硬着头皮去做,虽然不是难事,恐怕你想要一时半会解决掉,那恐怕就是难事了。说到这里就岀了问题了,这只是功能扩展的问题,还不包描木身复制代码的繁杂问题,同时怎样保证copy不走样,修改不遗漏,不同人员开发风格不一致等诸多老人难问题。给开发效率、代码质量、代码可读性、后期维护性都带來很人的问题。鉴于诸如此类的问题,我希望对和关功能进行抽象,提炼出一个完整的解决方案。我会将问题分7、成是技术实现问题还是业务问题1•技术实现问题:有设计人员设计一套完整的解决框架解决•让更多时间参与到公司核心价值:业务流程梳理和设计小去。这里提到框架,大家会想到这个项冃的框架。当然总体项冃要建立框架系统,此框架非彼框架(最后我们会将这里的所有细节的解决方案融入到整个项目的框架内)。具体开发中的一系列解决方案,我们可以逐步封装,提供一个针对解决具体问题的框架。2•业务问题:丢给开发人员实现,因每个页面的业务需求是不同的,要分别实现(这里面才是公司的核心价值)。我们不需要机械的Coder,可以说高中水平的人经过XXX培训都可以胜任一般的codingT作。我们8、需耍将coding的工作变成一种固定的模式,从而可以工厂化,批量生
4、Lbr»O%w»,Otnt^ogrwwrwxj»《S«vfr*ro9WT?v>0□tMSVSH•祸,訂I喋円i・±r转#*[口5匸]400*针对如上需求,对于一个初级程序人员来说也不什么难事,用流行的话来说简直就是”小菜”or“SmallCase%你也许就按部就班的开发了,一点一点的实现了设计说明书上要求的内容了。OKnoproblem通常在一个项冃中如上这样的页面,保守估计占•整个项冃的60%以上,甚至更多,基础维护资料不用说,很多的维护画面也是基于上述的查询结果然后进行相关的后续操作功能实现。你去实现一个不难,100个呢,你会去复制相当于100份,而后
5、在各个页面进行后续开发。为什么要复制代码,用重构的思想■■“有冃只有一次原则”,这样的代码就是出现了“坏味”,需要加以改造的代码。(当然重构的思想是没有问题,但是重构也是从粗到细—步步來,我们也不能完全用原则来套,走进另一个极端,设计过度也是一种缺陷,度这个东西,看不见、摸不着,我们也不去展开重构这个话题,这里只希望从实用的角度出发,侧重阐述如何建立一种能帮助开发人员针对问题、解决问题的行之有效的解决同类问题的模式。针对如上的査询页面,如若需要增加一个功能呢?怎会如何应对?例如:实际应用过程屮发觉,数据表格控件日前是支持分页大小可调整的,现在问题出来了:需
6、要这个分页大小要有记忆功能(以后进入此画面要能自动应用上次的应用设置),这个要求我认为也非常Z合理。我也希望能够站在用户的角度,为用户考虑解决此问题,可是,面对那么多的页面,何以下手,就算硬着头皮去做,虽然不是难事,恐怕你想要一时半会解决掉,那恐怕就是难事了。说到这里就岀了问题了,这只是功能扩展的问题,还不包描木身复制代码的繁杂问题,同时怎样保证copy不走样,修改不遗漏,不同人员开发风格不一致等诸多老人难问题。给开发效率、代码质量、代码可读性、后期维护性都带來很人的问题。鉴于诸如此类的问题,我希望对和关功能进行抽象,提炼出一个完整的解决方案。我会将问题分
7、成是技术实现问题还是业务问题1•技术实现问题:有设计人员设计一套完整的解决框架解决•让更多时间参与到公司核心价值:业务流程梳理和设计小去。这里提到框架,大家会想到这个项冃的框架。当然总体项冃要建立框架系统,此框架非彼框架(最后我们会将这里的所有细节的解决方案融入到整个项目的框架内)。具体开发中的一系列解决方案,我们可以逐步封装,提供一个针对解决具体问题的框架。2•业务问题:丢给开发人员实现,因每个页面的业务需求是不同的,要分别实现(这里面才是公司的核心价值)。我们不需要机械的Coder,可以说高中水平的人经过XXX培训都可以胜任一般的codingT作。我们
8、需耍将coding的工作变成一种固定的模式,从而可以工厂化,批量生
此文档下载收益归作者所有