你对这样的DB工作有什么看法?

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

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

最重要的:

• 一旦你有了一个服务，你不信任调用者。这可能是你的应用程序，但也可能有人只是查看了应用程序，看到了它连接到什么，并从他们自己的代码使用你的服务。你不能信任任何进入服务应用程序的。当然不是SQL。就像你(大概)不会把原始SQL作为隐藏输入放在HTML页面上，然后在web应用程序中执行一样:同样，因为你不相信调用者。

也

:

• security:呼叫者可以/不可以访问什么?他们能出具"delete from Orders"吗?你有没有能力来清理调用者可以/不可以做什么
• string[]参数-并非所有值都是明确的字符串;这表明对数据模型没有理解——只是"东西"
• 返回object -好吧，这不是一个数据契约无论如何，所以不会在大多数WCF绑定下工作-尽管NetDataContractSerializer可能会原谅你，如果它感觉慷慨

但是，同样，这是而不是一个API。API将在众所周知的受控服务下公开离散的数据，并带有类型化参数。有十几种方法可以建立一个像样的API——从单个方法(在"受控"端)到像OData这样的东西(在"开放"端)——但是没有一个会传递SQL。

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