应用程序框架的组成

应用程序框架是用来支持应用程序开发的,它就好像一个保姆,在开发的每一个细节对程序员呵护倍至。那么,应用程序框架应该包含哪些内容呢?原则上来说,只要期望能够复用的所有东西,都可以进入你的框架。

开发新手与经验丰富的老手,其中一个重要的区别在于复用代码的方式不同。开发新手喜欢复制粘贴,而老手则更倾向于抽象和封装。曾经听人说,复制代码是魔鬼,为什么这么严重?

当你把那几句代码四处复制粘贴,然后突然意识到需要修改一下,这时候悲剧就发生了,你需要找到所有的代码,然后挨个地方的改,这是一个体力活,如果粘贴的地方有点多,比如100个地方,那就要忙一阵子。不过这还不算严重,更严重的问题是可能会有漏网之鱼,一个不留神,漏掉一个地方,当场肯定发现不了,因为你不大可能重新把代码检查一遍,更不要说把所有的地方都测试一遍。这就埋下一个地雷,就看什么时候踩到了,不过一般都不会在短期内发现。有可能过了三个月,有人发现一些很诡异的BUG提交给你,于是你打开VS,不停的断点调试寻找错误,花了大把时间之后,终于找到了,然后你笑着告诉自己,“没什么,上次漏了个地方没改,一个小BUG而已”。这就好比搞财务的,只是把小数点打偏了一位,对他来讲没什么,不是技术上有问题,但结果很严重。

如果经常被复制粘贴搞得莫名其妙,并想改善一下方法,说明你开始寻找解决方案了。对于复制粘贴,一般需要两个解决方案来应付。一是抽象和封装,二是根据模板生成代码。

哪些代码值得你封装?

首先考虑技术性的,比如文件上传下载,为什么要封装这些东西呢,那几句代码虽然不复杂,但你随时都能记得住吗,每次敲这么多代码不累吗,关键一点是,你是否需要复制粘贴呢。技术性的代码被封装以后,有一个响当当的名词——公共操作类,一般会在类名上加个Helper,表示帮助类。当形成了大量的公共操作类后,开发过程将大幅简化,它的目标是帮助你摆脱技术上的困扰,把更多精力放到业务上。

第二,考虑如何增强现有系统,比如通过扩展方法来提供更易用API。另外需要提供系统健壮性支持,比如日志跟踪,全局异常捕获、依赖注入、安全机制等。

第三,考虑哪些代码是每个业务类都具有的,抽象到基类,如果使用DDD架构,按DDD分层架构和构造块建立基类。

第四,对表示层的支持,可以对界面上的元素进行封装,以提供更独特的功能。比如某个按钮,需要有权限才显示,这时候你需要在表示层写一个判断,如果他没权限会隐藏这个控件,如果很多地方有类似需求,你就会发现表示层充斥大量的判断。把这些独特功能封装到控件中,可以获取更清晰的代码。

第五,看看业务上有哪些类比较通用,例如地址,包括国家、省份、城市、区县、街道、 邮政编码等信息,哪怕换一个项目,地址还是这些内容。另外将行业性的东西抽取封装,很多项目都可以受益。

第六,对第三方业务系统进行封装,比如第三方应用平台、硬件设备提供的API等,封装之后,使用第三方接口,就好像调用本地的API一样。

第七,把一些通用性强的模块封装起来,可以显著提升进度,比如权限管理,部门管理,员工管理。

当你进行了各个层面的抽象和封装之后,你会发现还是有相当一部分代码需要来回复制粘贴,仔细观察这些代码,它们的结构都差不多,可能只是由于数据库的字段不同,所以要改一下,最常见的就是CRUD操作。由于信息系统归根结底就是CRUD操作,所以几乎每个数据库的表都会有对应的操作。不过还是那个老毛病,复制粘贴的方式不保险,而且效率低下,特别是在分层架构下,问题更严重,因为代码要跨越很多层。更好的方式就是创建模板,通过代码生成器要建立基础代码,不仅速度快得多,而且质量有保障。

下面,总结一下应用程序框架应该包含的范围:

  • 公共操作类(Helper,第三方技术框架封装)

  • 系统功能增强与扩展

  • 层超类型(技术基类)

  • 表示层控件封装

  • 通用业务类与业务基类封装

  • 第三方业务接口封装

  • 通用模块封装

  • 配套代码生成器

总之,能复用的都放进去。

应用程序框架实战