关于这样的数据库工作你能说些什么？

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.这意味着他们需要对数据库的乱伦了解.所以它违反了封装.但是,还有其他严重问题:

最重要的:

• 一旦你有了服务,你就不信任来电者.这可能是你的应用程序,但可能是有人只是看了看应用程序,看到它连接到什么,并从他们自己的代码使用你的服务.您不能相信服务应用程序中的任何内容.当然不是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服务.