高分请教一个消息传递的简单问题，两日内一定给分！

[ysli]

客户机和服务器之间用socket规范作为支撑，进行消息通讯。这种情况下其消息体和消息号是否都是根据业务具体规定呢？如把：查询书名、查询作者作为消息号等。那么可否在一个成熟、庞大的系统中直接传递SQL语句呢？即在客户机上生成sql语句，通过消息传达到服务端执行？？？请帮忙分析一下这样的可行性！！另外在BS结构下浏览器向应用服务传递的是什么机制？谢谢！！

[ysli]

另外我们的C/S之间不准备用BDE等连接，只准备用自己写的socket支撑函数，拜托各位了！

[xzou]

当然要根据业务定义消息号和消息体，需要的功能定义为功能号，参数定义在消息体内，最好不要在客户机上生成sql语句，这样的话会加重网络负担（数据量明显增大）。
BS我只知道是三层结构的一种，其余就不知道了。

[ysli]

那请问有没有传SQL语句的成功或不成功的例子呀？？
因为我们的业务很复杂，如按传统方法，其事件号一定成千上万，怕维护、开发时工作量太大难以承受，多谢xzou，并请继续讨论！

[xqiqi]

1、定义功能号；
2、消息体的头部信息（长度、日期、时间、版本号等 ...）；
3、对消息体本身，把SQL作为字符串放在消息体中，前面放的整数标明SQL语句的长度；在服务器端先读长度，再把消息体取出。

[xzou]

除非你不定义功能号，直接发送包含sql语句的包，不然，就一条复杂的查询而言，传一些查询的参数和传整个查询语句之间的数据量相差是很大的，不定义功能号不利于系统的升级，维护，调试，所以最好还是要定义的，功能的定义对以后的开发很关键的，做好了，以后的工作就简单了。
具体的就看你们的数据库设计（特别是数据字典的定义）是不是完善了。

[ysli]

欢迎继续！
并特别想知道各位在实际开发过程中是：1、只定义接口，2、只传递sql语句包，3、两种都有？它们在实际中会有哪些问题，如客户端维护量、开发难度等。
分不够再加！

[gzlucky]

为什么不直接对远程的数据库进行操作？

不会是想做application server吧？

[hellion]

to ysli(落叶松)：
你想做的我都做了，只要做后台数据库与Client了。不过涉及公司机密，不好说。

[ysli]

to lucky:可能偶没说清楚，我们是想做三层结构中，客户端与应用服务之间的消息传递。
to hellion:这事好办，来偶们公司就行了，呵呵。。。
你不用说具体的业务啊，我是觉得传sql语句不用定义N K个接口，看起来简单且两端不需进行接口翻译，但不知实际会有什么意想不到的地方。其实两种实现起来都没有难度，主要想选择最优方案，可否指点一二呀？？

[hellion]

应该定义接口。我做过这样的东西，有600多个功能（接口），应该够复杂了吧，定义好了之后做起来很爽。

[ysli]

再等一天

[hellion]

定义接口后可以做到与后台数据库无关，方便升级等，传SQL语句不行；
传SQL语句不安全，其中传一个删除数据等什么的你也不好控制；
传SQL语句中间层做不到处理优先级。