c# - 您对这种数据库工作有何看法？

Question

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

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

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

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

这种方式有什么优缺点？这对我来说似乎很不确定。

Answer 1

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

最重要的:

• 一旦获得服务，您就不信任来电者。那可能是您的应用程序，但也可能是某人刚刚查看了该应用程序，看到了它所连接的内容，并正在通过他们自己的代码 使用您的服务。您不能信任进入服务应用程序的任何。当然不是SQL。这与您(大概)不会将原始 SQL 作为隐藏输入放在 HTML 页面上然后在 Web 应用程序中执行的方式相同:同样，因为您不信任调用者。

还有:

• 安全性:调用者可以/不能访问什么？他们可以发出 "delete from Orders" 吗？你没有能力来清理调用者能做什么/不能做什么
• string[] 参数 - 并非所有值都是明确的字符串；这表明不了解数据模型 - 只是“东西”
• 返回 object - 好吧，这不是数据协定无论如何，所以在大多数 WCF 绑定(bind)下都不起作用 - 虽然 NetDataContractSerializer 如果感觉慷慨，可能会原谅你

但是，再次声明，这不是 API。 API 将使用类型化参数在众所周知的受控服务下公开谨慎的数据。有十二种方法可以设置像样的 API - 从单独的方法(在“受控”端)到 OData 之类的方法(在“开放”端) - 但没有将传递 SQL。

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