记一次CS系统与BS的对接集成

年初，实施了一个小项目，需求简单描述如下：

客户单位有一个C/S结构的业务系统，已经运行和维护了五六年，而且分布在全省二百多个县市中，该软件是由第三方开发和维护。现需要增加一个GIS功能模块，能够在地图上查询和定位业务数据。考虑到软件采购成本和GIS数据维护的难度，决定采用WebGIS的方式提供服务，并把它与现有的系统做集成。类似于在已有的业务系统中调用百度地图来查询定位，只不过这个“百度地图”是由我们提供。

在前期与CS系统开发商的设计和讨论中，由于前期参与的同事经验不足，再加上该CS系统的开发商对GIS没有任何了解，只想着尽量把工作推给我们，得到的设计方案是，由我们提供一个地图网站，类似于百度地图，并且这个地图网站里同时提供现有CS的绝大多数业务功能，比如查询和录入等功能，全部实现一遍，然后在CS系统中只要有一个窗体嵌入WebBrowser控件，访问地图网站的URL即可。并且该开发商愿意把所有数据库信息和必要的CS源代码都提供给我们，还有关于数据库设计的文档，数据库大约有50多张表和100多存储过程。

当我被派往现场做技术指导的时候，同事正在认真的分析该业务系统的表结构，然后模仿着CS系统把功能移植到网站里，开发商在一旁休息和答疑。由于前期并未参与该项目，所以不清楚情况，当与同事了解了项目需求和背景之后，顿时觉得很震惊，因为按这样的设计来做，不只赔钱，还有可能严重超期和失败。况且这根本不能算是真正意义上的集成，只能算是在CS中嵌入了一个浏览器，浏览已经固定的一个网站罢了。

以我的经验，这似乎不符合集成和对接的原则，想到一个自认为更合理更简单的方案：
1.每个系统只应关注自身的功能，BS和CS程序的交互通过接口和消息来通信，不必再去把整个CS程序功能移植一遍。
2.两个系统集成在同一个界面中，并且能够交互，比如左边是CS的界面，右边嵌入地图浏览器。
3.两个系统的后台数据库分离，不能相互访问，以免增加数据库维护风险。

示意图如下：

于是，想推翻当初的设计方案，那该怎么办呢？
1.利用一个下午的时间，做了一个Demo，演示了两个系统界面集成在一起交互的效果(利用WebBrowser控件的脚本执行特性)，客户觉得很满意。
2.告诉客户原有方案的风险：项目延期和后期维护难度加大。
3.明确告诉开发商原先的设计不符合对接的原则，向他演示新方案的效果，把Demo示例讲明白，让他知道新方案的集成很容易，没有什么技术难度和工作量。

最终，客户和开发商都同意了新的方案，并且按该方案进行实施，两周时间就完成了。

总结：

个人认为系统对接应该遵守如下原则：

1.两个系统的集成，应该是能够交互和消息传递(服务调用)。
2.两个的业务和代码应尽可能的分离，每个系统只应关注自身的功能，双方的交互通过接口和消息来通信，这样避免将来系统崩溃时责任纠纷。
3.两个系统的数据库应当分离，不能相互访问，以免增加数据风险。

效果图如下：