呵呵，对数据库不熟。但是，我觉的这里的层次划分有些问题。 WebService应该提供的是业务逻辑的封装，否则，就不需要抽象WebService层了。直接在ASP页面中调用数据库操作不是性能更好。 按照这样的思路，WebService上提供业务逻辑的封装，所以，传递的应该是业务实体对象。而不是SQL语句的结构化表示。然后，每个不同的WebService方法，使用特定的方式将业务实体对象转换为SQL语句，进行查询。这样可以有效的保证WEBService的安全。减少各种基于SQL的攻击（当然，避免这些攻击时需要更多的开发或架构技巧的） 回到你的思路上来，我觉的如果你传递的是一个SQL语句，就不要做什么结构化了，增加的数据的传输量，降低了程序的性能（虽然微乎其微），不值。传SQL语句是最灵活，最快速，最直接的。 举个例子，你要提供一个俱乐部管理的WebService,应该如下： [Serializable] public class UserInfo { public string UserName; public string Email; } [WebService] public class ClubManageService { [WebMethod] public int Register(UserInfo user) { // 调用存储过程，将user中的属性作为参数传入 return newUserId; } [WebMethod] public void Lock(int userId, bool lock) { // 调用存储过程，将userId和lock作为参数传入 } // 其他业务相关的WebMethods }