项目重构方案设计

Posted 2020-09-23 cynchanpin

近期接手到一个已经成型的项目，然后我们的任务就是对它进行重构，这个项目是一个功能非常齐全的WPF视频播放器（附带非常多其它功能），在细致研究了项目的背景和架构以后，初步做出了一下的重构方案：

眼下现状：

尽管整个系统做得非常美丽，代码也写得不错。但仍有下面不足：

1. 架构有待改善。

   尽管看似MVC架构，却没有遵循MVC的模式。里面逻辑和UI耦合非常高，没有清晰的规律。

2. 没有充分用到WPF的特性。WPF除了给我们非常多炫丽的效果外。还给我们提供了诸如Binding,command等特性，这些特性能够帮我们隔开耦合，同一时候降低代码量。
3. 代码和文件没有组织。代码、dll、样式文件和资源文件等没有统一的组织，到处都有。这样看起来就会非常混乱。
4. 没有建立公用代码库。没有把公用的代码库独立出来，非常多地方都是另外在写，这样既添加了代码量，同一时候维护和重构也带来了麻烦。

5. 逻辑处理不应暴露在Client端。项目是一个C/S架构的系统。没有必要把全部的逻辑都暴露在Client端。应该用分布式把Logic放在server端。这样能够更安全同一时候使client变小。

6. 没有单元測试。这样一个庞大的程序，没有单元測试是非常危急的。我们不可能做到100%的覆盖率，可是我们能够对基本的逻辑和Function做单元測试。这样既降低了測试人员的工作量同一时候整个系统的安全、稳定和可维护性得到了大大的提高。
7. 性能不够优化。启动项目,通过WPF性能工具Perforator和Visual Profiler分析得出，程序启动和界面操作都导致CPU非常高。内存也消耗比較多。

解决方式

1. 针对缺陷1的“架构问题”。

   做法是採用MVP或者MVVM模式。眼下正在对照和考虑。

2. 针对缺陷2的“WPF特性”。

   做法是充分利用Binding,command等特性。

3. 针对缺陷3的“代码和文件没有组织”。做法是建立一些单独的project或者文件来分类和组织这些代码，而且充分隔离耦合。

4. 针对缺陷4的“没有建立公用代码库”。

   做法是把一些公用的代码和经常使用的代码做成单独的Dll,而且有完整的单元測试，这样才干提高效率。

5. 针对缺陷5的“逻辑处理不应暴露在Client端”。做法是用WCF做为中间层。把业务逻辑所有进行封装。通过WCF提供统一的接口供项目调用。

6. 针对缺陷6的“没有单元測试”。

   做法是无论用MVP还是MVVM，我们起码保证对逻辑组件的代码有充分的单元測试覆盖，同一时候对一些公用的组件也要有单独的单元測试代码。

7. 针对缺陷7的“性能不够优化”。这个我会单独做一个性能优化列表出来，针对耗资源的操作和其它有损害性能的操作，我们应该避免。

8. 那么我们就能够结合实际情况搭建例如以下的结构
9.   
10. 由于使用了MVVM模式，所以UI结构图就做例如以下调整
11. 
12. 由于整个项目客户部希望我们引用第三方的组件或者工具。所以非常多功能都仅仅能通过企业库实现。比方AOP和IOC,log和exception对项目特征做了定制化，数据訪问通过企业库重写实现局部ORM,对性能要求比較高的应用仍然实现存储过程。对所有事务操作都转移到数据库。邮件使用JOB进行发送。

    大型数据和客户要求较高的实时操作。用MSMQ和SSB相结合的方式。

    层次依赖关系

UI: 功能模块使用时候,都会首先通过UI层次Security模块的安全验证(验证是通过Components模块里面的自己定义的用于页面功能以及功能点验证的控件触发), Security模块会通过服务层获取用户身份数据,用于页面验证.

功能模块的实际功能实现,假设须要数据库支持,那么依旧会通过服务层进行数据操作.整个架构基于MVVM模式。

Service:通过WCF做中间服务。使应用隔离开来，这样有利于扩展和维护。同事提高了整个应用程序的伸缩性。

Business Logic: 服务层内部之间的组合关系,主要体现再依赖和调用,由上往下调用,逐级依赖,最后Service底层边界Data Access模块将调用Framework中的Data模块,Data模块将调用MS.EntLib3中的Data,向数据server发送数据操作命令和数据.

Framework: 该层次提供很多基础的功能模块（七大块）,分别提供给UI,Service层里面的模块直接或者间接的调用,同一时候也能够看到Framework层次内部各模块之间再执行时也有互相依赖调用的关系存在.该层次的部分模块会依赖和调用Ms.EntLib3中的模块,通常是依照两个层次里面的模块名称,产生关系的.

MS.EntLib3: 该层次的各个模块是整个系统框架中最底层的,仅仅会在执行时被更高层次的模块依赖和调用,同一时候该层次内部各个模块之间也存在依赖和执行时调用关系.

 

　　整个架构採用迭代的方式进行开发。这样方便客户进行实时反馈，因为如今还没有開始，所以有非常多时间进行准备，假设园子里有这方面经验的朋友，也能够畅所欲言，谢谢！