项目重构之路

这段时间在忙着给公司,一个WPF项目做一些功能,该项目的背景介绍

  1. 两年以上的运维和迭代历史
  2. 有一点点“三层”架构感觉,有View(WPF具体窗口,基本上所有逻辑多在这),Model(没有明确的定义ViewModel,还是数据Model),Bll(提供给View 的是DataSet,DataTable,只是一个提供数据给View封装的地方)
  3. 由于是C/S结构的项目,部署环境考虑,通过WebService 来实现程序和数据库沟通,提供的数据结构,是不易于操作的DataSet,DataTable。
  4. 对象实例化都是通过,单例模式,未加Lock考虑,业务类职责不单一。
  5. WPF窗口后台逻辑太多,各种私有方法,各种事件,堆积在里面,一个窗口后端代码行数 700~1000 之多。
  6. 功能开发前期,分析不够,没有考虑将来的发展设计开发,导致后期运维,在原来的功能上改来改去,是原来成熟功能模块出Bug风险增加。
  7. 没有经过测试流程匆匆发布上线

综上,就是现在这个项目技术背景,和一些现状。

我是因为在里面新增了几个功能模块,在过程中发现开发起来太痛苦,太吃力,才萌生了想重构这个项目想法,但是由于项目还在使用,而且一种特殊环境下,比较依赖一个系统,不能够一下全部重构了,只能一步一步来,在实践中进行重构(拿了一个用户不会使用,但是开发人员会用来配置的功能模块)。

一.已经重构的部分

  1. 新增DataSet,DataTable,DataRow 转换成实体集合和实体 扩展的公共的 Dll(为什么要单独Dll呢,以后所有的扩展方法多可以放在里面,不过我还是给大家推荐一个开源的,写的不错的组件,Z.ExtensionMethods 很牛逼哦,我这个DLL也是参照他的源码写的),之所有要单独加这么Dll,主要有几个用途

(1)  原来的转成实体这个工具,在应用层,就是具体WPF项目,就不能够给BLL 使用,会出现循环引用的问题。

(2)  我的想法是BLL 要回归它应尽责任上来,负责逻辑的事情,而不是单单去调用一下WebServices 把DataSet,DataTable 直接再转到应用层去,现阶段重构任务是想把调用WebService 返回DataSet,DataTable,转到 实体&实体集合,毕竟操作实体比DataSet,DataTable 用得多,首先更加接近于OOP思想,编写逻辑更加得心应手。

  1. 新增 ViewModel Dll,由于原来Model 没有准确定义到底是视图模型,还是数据模型,结构也是比较乱,也不想动到里面东西,而影响其他功能,所有单独新增了这么一个ViewModel 层,来负责视图与Bll 直接数据交互。
  2. 把原来Bll 层,责任担当给提起来,将WebService 返回DataSet,DataTable 转换成实体&实体集合,把应用层后端业务逻辑,移到BLL层。
  3. 建立开发版,测试版,发布版分支,严格走测试流程。

二.未重构的部分的一些想法

  1. 业务层,具体每个类,实例化都用单例模式,从直观来讲,业务类不应该自己负责实作实例化工作的代码,而应该交由使用方来实作。(其他什么高深理解我暂时没有。。),所有将来我的想法

(1)  新增 业务接口组件,与现在业务层呼应

(2)  在应用层,通过IOC 框架,依赖注入来实例化具体业务逻辑,计划使用Autofac 组件。

  1. WebService 换成WebApi,主要考虑WebService 太过笨重,对于这种C/S 架构的项目,我觉得用WebApi 提供json 数据结构,会比较轻量,易于操作,性能也好点,特别是现在JSON 比 XML 流行的时代
  2. WebApi 负责提供数据,但是不再是DataSet,DataTable 数据结构,而是Json。再编写一个HttpClient 帮助类库,来封装调用WebApi 方法,且利用方能的泛型,将Json序列化成具体 实体&实体集合。
  3. 利用MVP & MVVM 架构模型,来架构更加清爽点,比喻窗口中 控件事件,其他的一些控制逻辑,移到具体的一层里面,是窗口不至于太多代码。
  4. 功能实现时,把用到相关部分尽量设想未来是否在哪里也能够使用到,要封装成公用的组件,以供其他功能重用。
  5. 业务逻辑层,尽量做单元测试。减少Bug产生几率,提供项目品质。

以上最近项目中的总结和想法,由于能力有限,有些地方还只是想,没有实践过,希望大家多交流。

 

posted @ 2016-04-01 23:42  改變世界  阅读(834)  评论(7编辑  收藏  举报