项目重构之路

这段时间在忙着给公司，一个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产生几率，提供项目品质。

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