项目重构方案设计(1).pdf
98 浏览量
2022-12-25
17:34:58
上传
评论
收藏 139KB PDF 举报
项⽬重构⽅案设计项⽬重构⽅案设计
近期接⼿到⼀个已经成型的项⽬，然后我们的任务就是对它进⾏重构，这个项⽬是⼀个功能⾮常齐全的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做中间服务。使应⽤隔离开来，这样有利于扩展和维护。同事提⾼了整个应⽤程序的伸缩性。
资源评论
