关闭

多进程的构架方法

标签: windowssocket数据库unixdll通讯
525人阅读 评论(0) 收藏 举报
分类:

  做了4、5年的开发,大大小小的项目也做了不少,但以前都有一个致命的问题,不知不觉就会写出一个巨大的主 程序出来,层次复杂,编码痛苦,调试困难。但似乎大家都认同这样的开发方式,虽然都知道界面和功能分离是好事情,但就是做不到。我自己也曾痛苦的思考过, 但没有什么收效,似乎在Windows下的开发只能是这么痛苦。

  一星期前买了<<unix编程艺术>>,这一周可谓改天换地,每天都在阅读和思考中度过,想必武侠小说中的武功大进也就是这个意思了。虽然书还没看完,但是有些话实在是不吐不快。

    什么是界面?界面就是功能的子集。没有哪个界面能反映所有的功能,但是若没有界面,对于最终用户来说又是不可忍受的,无论如何都不能指望让一个门卫学会输 入复杂的命令来完成工作,虽然最终用户也包括专业人士,但这世界上终究普通人更多。在这样的前提下,可以认为功能永远比界面更宽泛,更有适应性,而GUI 更狭窄,更具有特殊性,所以将界面和功能进行分拆也就成为一种必然趋势。

   但是如何分拆?在Windows的世界里,一个普遍观点就是DLL。DLL很好,但是还不够好,因为无法直接使用、调试以及升级,带来的问题远比好处 多。另一种方法就是在代码级进行分层,比如GUI一层,功能一层,再用胶合层将二者整合。且不论胶合层的不可复用和调试困难,就一条,如何能做到GUI崩 溃的时候却不影响功能的实现?以前我做过的项目都是这样处理的,直接的后果就是项目越到后期问题越多,代码越不接受变化。调试花费了大量的人力物力,收效 却未必好,功能的一点点小修改就会造成代码里出现意大利面条。你可以说只要前期的小心规划和仔细架构就能避免这些问题,但是谁能准确预测未来?无论做怎样 的努力,你也不能保证现在的功能永远不变,永远不变的恰恰就是变。如果不能保持实现的稳定性和较好的移植性,这样的项目下场一般都不太好。

  说了这么多废话,还是赶紧进入正题。谈谈这一周来的心得体会!

   首先,变化是渐进的,非突变式的。如果能将变化的所在约束在一个比较小的代码范围内,修改就不会成为噩梦。怎么约束?就一个要求:在保证完整性的条件下 让每个模块包含的功能尽量单一和足够小。首先是保证完整性,不是代码足够短,包含的实现足够少就是完整,要达到完整,就要让模块的各个部分做到不可分割和 无需添加,按照古人的说法,就是增一分则太多,减一分则太少。这个要求虽然看起来很好理解,其实并没有什么标准答案,每个人心里都有自己的回答,正所谓仁 者见仁,智者见智。其次是单一化和小型化,一般来说,范围太大的东西会造成人脑覆盖不全,比如一个功能,如果牵扯的部分过多,就会造成从底层到中间层,再 到上层,全部都要思考到,估计没有几个人能做到,即使做到了,将来的维护和修改也会变成噩梦。相反,只要功能的涉及面够窄,就很容易进行思考和修改,这个 道理应该没有什么问题。

  既然要保证模块单一、小型化和保证完整,也就意味着这个模块可以认 为是一个完整而单独的程序,无需外围程序的支持就可以单独运行和测试。从而引出我的最重要的观点:尽量用多进程来分拆程序。在Windows的世界里,多 进程似乎是天生被忽略和鄙视的,从unix的观点看,其主要原因是Windows的设计中对进程的快速创建支持不够,造成对多进程的天然排斥和害怕。但是 换一个思路看,多进程也许是目前最好的架构方式。底层的功能分拆成各个进程单独运行,通过ipc和上层的GUI进行交互,胶合层薄了,移植性增强了,调试 容易了,功能演进也不再成为噩梦。需求永远是渐变的,所以进程的渐变也就成为可控的行为。

    多进程间的传递方式一般有这么几种:共享内存,管道(pipe),信号,消息, socket。其中共享内存适宜于大量数据的即时传递,速度快,容量大。但使用共享内存时需要仔细考虑读写冲突问题,一般的解决办法是用全局锁,但是锁的 存在必然会造成效率的下降,所以能不用锁就尽量不要用。pipe的速度和容量都没有共享内存好,但是用来传递命令和返回值还是很适合的。信号和消息的方式 一般会和操作系统联系紧密,个人不太喜欢。最后是socket,对于异地交互而言,socket是目前很常用的手段,甚至本地进程间通讯也可以使用。但是 由于和网络有关,所以同步性不好保证,需要辩证的使用。

   说了这么多,举个例子说明一下。假设现在要做一套点菜软件供酒店使用,其基本功能包括人员管理,桌台管理,点菜管理,结账以及后台管理五个功能模块。按 照单进程的方式就是将所有功能整合在一起,系统启动时加载所有的功能,一旦某个模块出现问题,则必须重新启动程序,而且各个模块之间很容易发生资源冲突和 请求冲突。如果换成多进程方式,让我们看看有什么不同。首先是所有的功能最终目的地都是数据库,那么可以开发一个后台进程专门所有负责针对数据库的请求, 通过pipe或者共享内存来接收命令和返回结果,那么程序或者说具体代码块之间的接口就是单一的pipe或共享内存了。同时,即使某一个程序运行错误也不 会造成整体失败,只需要重起失败的部分即可。当然了,这种方式下存在一个问题,就是效率的降低,但是对于大多数的应用来说,稳定性的提高远比效率的降低要 重要,而且随着硬件水平的不断提高,效率总是可以达标的。

  数据库处理分拆出去后,剩下的就 很好处理了,人员、点菜、桌台等管理模块都作为单独的后台程序出现,最后GUI部分只需要和各个共享内存和pipe打交道即可,无需只要具体的逻辑处理和 功能实现,而且各个后台程序还可以复用,比如人员管理可以挪到客房服务系统中,甚至是其他系统。GUI随时可以替换,实现了功能和界面的分离,同时系统崩 溃的几率大大降低,升级和售后也方便很多,永远不要把最终用户想的太愚蠢,很多时候人们还是蛮有求知欲的。

  更多的细节需要自己整理,这里只是给出了一个框架,起码我现在的项目已经开始这样做,效果嘛,半年后就知道了。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:54981次
    • 积分:714
    • 等级:
    • 排名:千里之外
    • 原创:0篇
    • 转载:59篇
    • 译文:0篇
    • 评论:3条
    文章存档