2.实用开发模式研究--思想概述.docVIP

实用开发模式研究(一) ? ? 目标:希望将自己的开发经验进行一系列的总结，从中提炼出一种实用的开发模型(模式)。(后记：希望能都不断向模式的高度去发展) ? 前言： 在这里将不会去讨论贫血模型和充血模型孰好孰坏这样的口水纷争， 这边以期从实用主义的角度出发，考虑如何帮助开发人员更快速的构建应用. 保证高效、高质量的完成预期的任务。 在这里先解释一下 因下面有讲到实体类解决方案的时候，在我的解决方案中建立的实体类既不是贫血模型也不是充血模型。 而是一个较标准三层架构开发模式下的实体类更加实用的数据建模思想。 ? 接下来讲，实用开发模式目前主要研究了哪些问题？ 我们先从第一个实例开始：先带领大家去感受一下 ? 先命题如下一个非常普遍的应用场景： 开发一个查询功能,要求如下:(整个项目要求一致) 1.提供查询条件 2.查询条件有重置功能 3.查询条件有记忆功能(以后进入此页面， 上次的查询条件和结果依然在,此功能应运场景非常的广泛) 接口化支持—灵活的配置(意即：通用是要此功能；但是不是固定的) 4.查询结果显示在表格控件中 5.表格控件要支持真数据库分页 6.表格控件要支持排序 7.表格控件要支持标题栏固定 8.表格控件要求支持指定前几列固定 9.表格控件要求支持分页大小可调整 10.表格控件要求支持数据库全排序 11.表格要支持选择 12.表格要支持全选和全不选 13.查询条件能够隐藏，从而为查询结果提供更多的空间 14.隐藏的状态要既有后台记忆功能，而非下次又复原 ????? …… ???? 针对如上需求，对于一个初级程序人员来说也不什么难事,用流行的话来说简直就是小菜 or “Small Case”。 你也许就按部就班的开发了，一点一点的实现了设计说明书上要求的内容了。60%以上，甚至更多，基础维护资料不用说，很多的维护画面也是基于上述的查询结果然后进行相关的后续操作功能实现。 你去实现一个不难，100个呢，你会去复制相当于100份，而后在各个页面进行后续开发。 ???为什么要复制代码，用重构的思想--“有且只有一次原则”，这样的代码就是出现了“坏味”， ?? 需要加以改造的代码。(当然重构的思想是没有问题，但是重构也是从粗到细一步步来， ?? 我们也不能完全用原则来套，走进另一个极端，设计过度也是一种缺陷，度这个东西，看不见、摸不着， ?? 我们也不去展开重构这个话题，这里只希望从实用的角度出发，侧重阐述如何建立一种能帮助开发人员 ?? 针对问题、解决问题的行之有效的解决同类问题的模式。 ? 针对如上的查询页面，如若需要增加一个功能呢？怎会如何应对？ 例如： ?? 需要这个分页大小要有记忆功能（以后进入此画面要能自动应用上次的应用设置),这个要求我认为也非常之合理。 ?? 我也希望能够站在用户的角度，为用户考虑解决此问题，可是，面对那么多的页面，何以下手，就算硬着头皮去 ?? 做，虽然不是难事，恐怕你想要一时半会解决掉，那恐怕就是难事了。 ? ???说到这里就出了问题了，这只是功能扩展的问题，还不包括本身复制代码的繁杂问题，同时怎样保证copy不走样， ?? 修改不遗漏，不同人员开发风格不一致等诸多老大难问题。 ?? 给开发效率、代码质量、代码可读性、后期维护性都带来很大的问题。 ?? ? 鉴于诸如此类的问题，我希望对相关功能进行抽象，提炼出一个完整的解决方案。 我会将问题分成是技术实现问题还是业务问题 1.技术实现问题:有设计人员设计一套完整的解决框架解决.让更多时间参与到公司核心价值：业务流程梳理和设计中去。 这里提到框架，大家会想到这个项目的框架。当然总体项目要建立框架系统，此框架非彼框架(最后我们会将这里的所有细节的解决方案融入到整个项目的框架内)。 具体开发中的一系列解决方案，我们可以逐步封装，提供一个针对解决具体问题的框架。 2.业务问题:丢给开发人员实现，因每个页面的业务需求是不同的，要分别实现(这里面才是公司的核心价值)。我们不需要机械的Coder，可以说高中水平的人经过XXX培训都可以胜任一般的coding工作。 我们需要将coding 的工作变成一种固定的模式，从而可以工厂化，批量生