3957
社区成员
- 主页
- 问答
高分请教一个消息传递的简单问题，两日内一定给分！
客户机和服务器之间用socket规范作为支撑，进行消息通讯。这种情况下其消息体和消息号是否都是根据业务具体规定呢？如把：查询书名、查询作者作为消息号等。那么可否在一个成熟、庞大的系统中直接传递SQL语句呢？即在客户机上生成sql语句，通过消息传达到服务端执行？？？请帮忙分析一下这样的可行性！！另外在BS结构下浏览器向应用服务传递的是什么机制？谢谢！！
...全文
请发表友善的回复…
发表回复
hellion 2001-08-28
定义接口后可以做到与后台数据库无关，方便升级等，传SQL语句不行；
传SQL语句不安全，其中传一个删除数据等什么的你也不好控制；
传SQL语句中间层做不到处理优先级。
传SQL语句不安全，其中传一个删除数据等什么的你也不好控制；
传SQL语句中间层做不到处理优先级。
ysli 2001-08-27
再等一天
hellion 2001-08-25
应该定义接口。我做过这样的东西，有600多个功能（接口），应该够复杂了吧，定义好了之后做起来很爽。
ysli 2001-08-25
to lucky:可能偶没说清楚，我们是想做三层结构中，客户端与应用服务之间的消息传递。
to hellion:这事好办，来偶们公司就行了，呵呵。。。
你不用说具体的业务啊，我是觉得传sql语句不用定义N K个接口，看起来简单且两端不需进行接口翻译，但不知实际会有什么意想不到的地方。其实两种实现起来都没有难度，主要想选择最优方案，可否指点一二呀？？
to hellion:这事好办，来偶们公司就行了，呵呵。。。
你不用说具体的业务啊，我是觉得传sql语句不用定义N K个接口，看起来简单且两端不需进行接口翻译，但不知实际会有什么意想不到的地方。其实两种实现起来都没有难度，主要想选择最优方案，可否指点一二呀？？
hellion 2001-08-25
to ysli(落叶松)：
你想做的我都做了，只要做后台数据库与Client了。不过涉及公司机密，不好说。
你想做的我都做了，只要做后台数据库与Client了。不过涉及公司机密，不好说。
gzlucky 2001-08-25
为什么不直接对远程的数据库进行操作？
不会是想做application server吧？
不会是想做application server吧？
ysli 2001-08-25
欢迎继续！
并特别想知道各位在实际开发过程中是：1、只定义接口，2、只传递sql语句包，3、两种都有？它们在实际中会有哪些问题，如客户端维护量、开发难度等。
分不够再加！
并特别想知道各位在实际开发过程中是：1、只定义接口，2、只传递sql语句包，3、两种都有？它们在实际中会有哪些问题，如客户端维护量、开发难度等。
分不够再加！
xzou 2001-08-24
除非你不定义功能号，直接发送包含sql语句的包，不然，就一条复杂的查询而言，传一些查询的参数和传整个查询语句之间的数据量相差是很大的，不定义功能号不利于系统的升级，维护，调试，所以最好还是要定义的，功能的定义对以后的开发很关键的，做好了，以后的工作就简单了。
具体的就看你们的数据库设计（特别是数据字典的定义）是不是完善了。
具体的就看你们的数据库设计（特别是数据字典的定义）是不是完善了。
xqiqi 2001-08-24
1、定义功能号；
2、消息体的头部信息（长度、日期、时间、版本号等 ...）；
3、对消息体本身，把SQL作为字符串放在消息体中，前面放的整数标明SQL语句的长度；在服务器端先读长度，再把消息体取出。
2、消息体的头部信息（长度、日期、时间、版本号等 ...）；
3、对消息体本身，把SQL作为字符串放在消息体中，前面放的整数标明SQL语句的长度；在服务器端先读长度，再把消息体取出。
ysli 2001-08-24
那请问有没有传SQL语句的成功或不成功的例子呀？？
因为我们的业务很复杂，如按传统方法，其事件号一定成千上万，怕维护、开发时工作量太大难以承受，多谢xzou，并请继续讨论！
因为我们的业务很复杂，如按传统方法，其事件号一定成千上万，怕维护、开发时工作量太大难以承受，多谢xzou，并请继续讨论！
xzou 2001-08-24
当然要根据业务定义消息号和消息体，需要的功能定义为功能号，参数定义在消息体内，最好不要在客户机上生成sql语句，这样的话会加重网络负担（数据量明显增大）。
BS我只知道是三层结构的一种，其余就不知道了。
BS我只知道是三层结构的一种，其余就不知道了。
ysli 2001-08-24
另外我们的C/S之间不准备用BDE等连接，只准备用自己写的socket支撑函数，拜托各位了！