界面与逻辑--多进程或单进程
大家好,我要介绍的所有知识点都是WINCE/windows触摸屏DUI开源框架constvar(点击下载代码)开发过程中遇到的比较有讨论价值的问题。
本文要讨论的是业务逻辑与界面的实现与进程数量划分的一些关系．
一．单进程
对于比较复杂的应用程序，有可能包含比较多的功能独立的模块，假设用单进程去实现，即所有业务＋所有界面都在此进程中，看上去是最简单的．因为：
1. 单进程就没有进程间通讯, 程序之间的通讯相对来说是比较麻烦，跟人与人打交道一样，都是耗时专业户．
2. 界面可以高效的访问业务数据，并且数据界面渲染缓冲等都只需要有一份，会大量结省内存空间．
3. 运行时更高效．同上所述，因为省去了通讯与数据同步及多份数据拷来拷去的过程等等，理论上单进程运行起来是更高效的，实际上，如果是用DIRECTUI的话，效果差异可以达到能感受得到的级别．单进程只需要一个真窗口就行了．更不用一会儿SHOW一会儿HIDE．
4. 假设实现的程序员有一定经验，可以在单进程内更容易把业务和逻辑分离得比较好，在这里必须强调的是，业务和逻辑的分离度与在不在同一个进程之内是没啥关系的．之所以说它更好分，是因为原理简单的东西本来就比复杂的东西好分。
单进程的缺点也很多，比如：
1. 需要开发或维护人员对整个应用程序的所有功能有一个全局整体性的认知．这就让程序的维护和扩展复杂度增加了．
2. 更麻烦的是，对于任一模块的修改都将影响到整个程序．光每次全部编译还算轻的，一但出错，就全崩了，因为只有一个程序，崩了就啥都没有了，问题也更难定位。
3. 实际因人为因素可操作性差，功能会耦合得比理论大得多，修改扩展会非常不便．对于需要定制频繁的软件系统来说，此问题就会凸显出来．软件的版本也会变得很复杂，尤其不同版本之间差异比较非常麻烦．
4. 最关键最重要的是，单进程在多人协作式开发时缺点超级明显．不利于有专长的程序员干自己专长的事情，也会增加程序员之间的交互时间．
所以单进程这种，属于软件整体功能不多，功能需求增加不大，并且开发人员较少且单兵作战能力极强的项目中．最好不要多于2个人，我认为1个人最好．
二 多进程，每个进程都带自己的UI
为解决单进程的缺点，把模块按功能划分，独立的模块各自有自己的EXE或者是相关的模块组成一个EXE. 这样单进程的大部分缺点就得到了解决． 针对单个模块的更新也更加方便了．修改，版本问题也简化了，团队合作也更方便了等等．
但是单进程那些优点同时也没了， 比如带来了进程间通讯， 交流是最复杂的，一交流就需要协议(规则)，一有协议就有无节操的调试．很容易出现问题一个人改不了要多个人同理处理这种奇葩的情况，要是相互协作没那么愉快，可以说项目极不好进展．我觉得能一个人做的事，千万不要让2个以上的人去做．
还有假如每个进程对应的模块(1个或2个以上)都带有UI的话，那UI缓存也会增多．程序间切换不便和低效就不用再累述了．光去控制进程的前台后台，窗口的前前后后，哪个模块优先级高这些都是一大堆的新问题。
但总体来讲，这种多进程方式比单进程普遍得太多了．因为模块更容易趋于稳定，出啥问题，谁崩了也一目了然．无论是开发，维护的速度，稳定性，都是比单进程的有优势的．所以这一种应该说是主流．因为复杂没关系，只要不是没完没了就可以了。相对来说，单进程就更像是没完没了类型的。
三 多进程，一个UI进程， N个业务进程
相对于方式二，此种实现方式更加极端一些．它有一个就极为突出的的优点是更利于功能模块进程的稳定．因为只有功能，没有UI，就不用谈啥界面分离了都，只要功能需求不改，稳定了就是稳定了，有问题也是改一个少一个．UI改变成啥样都不会影响到功能．
底层业务相对于界面来说需求变动是小的．业务容易稳定，而越上层的界面需求变化是很大的．这样分法有利于业务模块的稳定．而把需求定制多的界面放在单独的进程中，在整个系统实现定制需求的时候更简单．
同时，界面切换和绘图缓冲啥的也与单进程一样高效低碳了．但它的最明显缺点是进一步复杂了通讯．可以说复杂了太多，原本同一个进程带UI，UI模块直接访问本进程的数据．
现在因为分离，也需要通过通讯来实现．数据多存了2份不说，效率，多出来的工作量和增加的复杂度是可想而知的．
但是一但功能稳定，界面定制就比前2种有优势了，因为影响功能模块的概率比其它2种都低很多很多。
总的来说， 一和三必须要有一个真正的高手才能HOLD住，HOLD住了，这2种方法我觉得都比二好， 但是方法二则对开发人员要求相对没有那么高，所以二是主流，就这么简单。