基于mfc的pc客户端源码阅读笔记

最近因工作需要，临时去维护了PC端的一个客户端软件。之前在pc软件方面的开发经验尚为空白，在大致的浏览了代码，完成功能添加后，写写我对于此项目工程的看法吧。

 

一 整个工程分为三大模块，分别为应用模块，解码模块，网络模块。其中解码模块和网络模块以库的形式提供源码。工程定义了一个公共的头文件夹common_include，上层应用模块调用底层的网络模块与解码模块函数时，链接此 common_include文件夹。

 

 

二  整个工程没有提供的公共的函数库，一些常用的字符串转换和时间获取函数常常 是多处定义。

 

 

三 应用模块将部分底层实现代码与用户界面交织在一起（这应该是后期维护人员所添加的，早先的设计者应是按照标准的mvc架构进行代码组织的）。以前就有过这样经历， 我们的工程源码是面对所有开发人员全部开放的，其中业务功能的实现原来定义是由指定的人去维护，结果在实际中， 谁都可以去任意添加代码， 其结果是，代码越来越乱，状态变量满天飞，直接影响后期的维护和开发。

 

 

四 Ui界面，关于控件布局， 有不少控件是完全手工设定坐标，很是麻烦。我对mfc的控件位置布局，没有深入了解，但如此手工的指定每一个控件坐标，我想应是没有必要吧。

 

 

五 mfc多国语言的实现更是变态， mfc内部语言的编码为非unicode编码，每一种语言对应一个资源文件， 当程序启动时， 根据选择来确定加载哪一个语言包。 当同时有多国语言文字要显示时， 往往会引发冲突， 部分国家的语言会显示为乱码，以前有同事在解决此BUG时采用的方案是不同语言选项采用图片的形式显示。还是QT多国语言的开发方便， QT内部语言编码全部采用unicode编码，同时提供完善的多国语言开发工具。

 

六 该项目中应用模块，创建一个全局访问的类，该类主要职责有1.能够全部访问ui界面所有的对话框， 2 与外部模块（网络模块与解码模块）交互。此种设计，个人首次见到（没办法，看过的源码不多）。

 

 

大约总结了以上几点， 呵呵。

PS:虽说总结的好像大多是不足之处， 但是我个人还是整个工程质量还是很高，值得我深入的学习。