项目重构方案设计

最近接手到一个已经成型的项目,然后我们的任务就是对它进行重构,这个项目是一个功能很齐全的WPF视频播放器(附带很多其他功能),在仔细研究了项目的背景和架构以后,初步做出了一下的重构方案:

目前现状:

虽然整个系统做得很漂亮,代码也写得不错,但仍有以下不足:

  1. 架构有待改善。虽然看似MVC架构,却没有遵循MVC的模式,里面逻辑和UI耦合很高,没有清晰的规律。
  2. 没有充分用到WPF的特性。WPF除了给我们很多炫丽的效果外,还给我们提供了诸如Binding,command等特性,这些特性可以帮我们隔开耦合,同时减少代码量。
  3. 代码和文件没有组织。代码、dll、样式文件和资源文件等没有统一的组织,到处都有,这样看起来就会很混乱。
  4. 没有建立公用代码库。没有把公用的代码库独立出来,很多地方都是另外在写,这样既增加了代码量,同时维护和重构也带来了麻烦。
  5. 逻辑处理不应暴露在Client端。项目是一个C/S架构的系统,没有必要把所有的逻辑都暴露在Client端,应该用分布式把Logic放在服务器端,这样可以更安全同时使客户端变小。
  6. 没有单元测试。这样一个庞大的程序,没有单元测试是非常危险的,我们不可能做到100%的覆盖率,但是我们可以对主要的逻辑和Function做单元测试,这样既减少了测试人员的工作量同时整个系统的安全、稳定和可维护性得到了大大的提高。
  7. 性能不够优化。启动项目,通过WPF性能工具Perforator和Visual Profiler分析得出,程序启动和界面操作都导致CPU很高,内存也消耗比较多。

解决方案

    1. 针对缺陷1的“架构问题”。做法是采用MVP或者MVVM模式,目前正在对比和考虑。
    2. 针对缺陷2的“WPF特性”。做法是充分利用Binding,command等特性。
    3. 针对缺陷3的“代码和文件没有组织”。做法是建立一些单独的工程或者文件来分类和组织这些代码,并且充分隔离耦合。
    4. 针对缺陷4的“没有建立公用代码库”。做法是把一些公用的代码和常用的代码做成单独的Dll,并且有完整的单元测试,这样才能提高效率。
    5. 针对缺陷5的“逻辑处理不应暴露在Client端”。做法是用WCF做为中间层,把业务逻辑全部进行封装,通过WCF提供统一的接口供项目调用。
    6. 针对缺陷6的“没有单元测试”。做法是不管用MVP还是MVVM,我们起码保证对逻辑组件的代码有充分的单元测试覆盖,同时对一些公用的组件也要有单独的单元测试代码。
    7. 针对缺陷7的“性能不够优化”。这个我会单独做一个性能优化列表出来,针对耗资源的操作和其他有损害性能的操作,我们应该避免。
    8. 那么我们就可以结合实际情况搭建如下的结构
    9. 因为使用了MVVM模式,所以UI结构图就做如下调整
    10. 由于整个项目客户部希望我们引用第三方的组件或者工具,所以很多功能都只能通过企业库实现,比如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,向数据服务器发送数据操作命令和数据.

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

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

  整个架构采用迭代的方式进行开发,这样方便客户进行实时反馈,由于现在还没有开始,所以有很多时间进行准备,如果园子里有这方面经验的朋友,也可以畅所欲言,谢谢!

版权声明:本文为博主http://www.zuiniusn.com原创文章,未经博主允许不得转载。

时间: 2024-10-09 13:45:30

项目重构方案设计的相关文章

一次项目重构的心得体会

接手一老项目,经过几个月之后,实在顶不顺原来的架构,一样事情要干两件活,代码冗余复杂,给维护工作带来很多问题和隐患,趁着前段时间新需求比较少,遂与产品负责人沟通之后暂停新需求,先进行项目重构.于是就花了近一个月的时间对其架构进行重构,首先是将接入部分和业务处理部分分离,其次是将业务处理部分集中,再次是引入内存数据库,实现业务处理部分无状态,将所有状态保持在内存数据中,从而使得业务处理进程可以多个进程并行,并且可以进行业务处理模块的无间断更新.重构完之后可以说是脱胎换骨了,其中有些心得和体会分享一

iOS 基于 MVC 的项目重构总结

关于MVC的争论 关于MVC的争论已经有很多,对此我的观点是:对于iOS开发中的绝大部分场景来说,MVC本身是没有问题的,你认为的MVC的问题,一定是你自己理解的问题(资深架构师请自动忽略本文). 行文过程中查阅了互联网上的大量文档,其中水平良莠不齐(最常见的就是MVC改个名就当MVVM的),当然也有许多非常有价值的参考资料,在文末会逐一列举,以供参考. iOS中的MVC和MVP Cocoa版本的MVC 根据官网上的描述, Cocoa中的MVC是这样的: Model Objects Encaps

Android 项目重构之路:实现篇

前两篇文章<Android项目重构之路:架构篇>和<Android项目重构之路:界面篇>已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之

Android 项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

iOS开发笔记--iOS基于MVC的项目重构总结

关于MVC的争论 关于MVC的争论已经有很多,对此我的观点是:对于iOS开发中的绝大部分场景来说,MVC本身是没有问题的,你认为的MVC的问题,一定是你自己理解的问题(资深架构师请自动忽略本文). 行文过程中查阅了互联网上的大量文档,其中水平良莠不齐(最常见的就是MVC改个名就当MVVM的),当然也有许多非常有价值的参考资料,在文末会逐一列举,以供参考. 原文地址:http://www.cocoachina.com/ios/20160519/16346.html iOS中的MVC和MVP Coc

关于项目重构,知道真相的程序员眼泪笑了出来

本文授权转载,作者:非著名程序员(公众号:smart_android) 其实过完年回来,我们的项目也一直在强调重构,在实践重构中,但是到目前为止,基本没啥进度.关于项目的重构,我说:基本上大部分都是骗人的.你们信不信?那你可能会问:为什么一开始不把代码写的更好一些,逻辑更严密一些呢?那欢迎大家看我写的这篇文章<代码质量差,bug多?我们都是被逼的 >,看完你会深有同感的. 关于项目重构的问题,为什么一直做不完呢?直到我在浏览微博时,看到了一个非常好玩的对话,可谓是:感同身受,深有同感.知道真相

(转)Android项目重构之路:实现篇

前两篇文章Android项目重构之路:架构篇和Android项目重构之路:界面篇已经讲了我的项目开始搭建时的架构设计和界面设计,这篇就讲讲具体怎么实现的,以实现最小化可用产品(MVP)的目标,用最简单的方式来搭建架构和实现代码. IDE采用Android Studio,Demo实现的功能为用户注册.登录和展示一个券列表,数据采用我们现有项目的测试数据,接口也是我们项目中的测试接口. 项目搭建 根据架构篇所讲的,将项目分为了四个层级:模型层.接口层.核心层.界面层.四个层级之间的关系如下图所示:

(转)Android项目重构之路:界面篇

在前一篇文章<Android项目重构之路:架构篇>中已经简单说明了项目的架构,将项目分为了四个层级:模型层.接口层.核心层.界面层.其中,最上层的界面,是变化最频繁的一个层面,也是最复杂最容易出问题的一个层面,如果规划不好,很容易做着做着,又乱成一团了. 要规划好界面层,至少应该遵循几条基本的原则: 保持规范性:定义好开发规范,包括书写规范.命名规范.注释规范等,并按照规范严格执行: 保持单一性:布局就只做布局,内容就只做内容,各自分离好:每个方法.每个类,也只做一件事情: 保持简洁性:保持代

【转】vue项目重构技术要点和总结

vue数据更新, 视图未更新 这个问题我们经常会遇到,一般是vue数据赋值的时候,vue数据变化了,但是视图没有更新.这个不算是项目重构的技术要点,也和大家分享一下vue2.0通常的解决方案吧! 解决方案如下: 1.通过vue.set方式赋值 Vue.set(数据源, key, newValue) 2. 通过Array.prototype.splice方法 数据源.splice(indexOfItem,1, newValue) 3.修改数据的长度 数据源.splice(newLength) 4.