1

我正在审查他的 WCF 服务中的一些人的代码：

[ServiceContract]
public interface IDBService
{
    [OperationContract]
    void DBUpdateInsert(string sql, params string[] parameters);

    [OperationContract]
    object DBSelect(string sql, params string[] parameters);
}

每个需要调用 SQL 代码的函数都使用该服务。

这种方式有什么好处和坏处？这对我来说似乎很不确定。

4

1 回答 1

8

不寒而栗。那不是 API - 它是一个漏洞。SOA 的部分要点是隔离不同的部分——允许对数据库进行细微更改而不会影响服务调用者。在这里，调用者提供原始 SQL。这意味着他们需要数据库的乱伦知识。所以它违反了封装。但是，还有其他严重的问题：

最重要的：

  • 一旦你有了服务，你就不信任调用者了。这可能是您的应用程序，但也可能是某人只是查看了该应用程序，看到了它所连接的内容，并且正在从他们自己的代码中使用您的服务。你不能相信任何进入服务应用程序的东西。当然不是 SQL。与您（可能）不会将原始 SQL 作为隐藏输入放在 HTML 页面上的方式相同，然后您在 Web 应用程序中执行：再次，因为您不信任调用者。

还：

  • 安全性：调用者可以/不能访问什么？他们可以发行"delete from Orders"吗？您无法清理呼叫者可以/不能做的事情
  • string[]参数 - 并非所有值都作为字符串明确；这表明不了解数据模型 - 只是“东西”
  • 返回- 好吧，无论如何object这不是数据合同，因此在大多数 WCF 绑定下都不起作用 - 尽管如果感觉很慷慨可能会原谅你NetDataContractSerializer

但是，这又不是API。API 将在众所周知的受控服务下公开带有类型参数的谨慎数据。有十几种方法可以设置一个像样的 API——从单个方法（在“受控”端）到 OData（在“开放”端）之类的东西——但这些方法都不会传递 SQL。

如果我不得不猜测：这个开发人员正在编写一个具有直接 SQL 访问权限的富客户端应用程序，并被告知通过服务公开数据。他们没有实际编写服务，而是简单地在 WCF 层公开了现有的 SQL 代码。那是倒退。他们现有的 SQL 代码（谨慎的 SQL 操作GetCustomer等）应该已经成为WCF 层。调用客户端应该忘记它知道的所有 SQL，而是绑定到 WCF 服务。

于 2013-05-29T11:34:49.503 回答