通过API服务层直接连接到SQL Azure vs连接？

Question

目前我们的数据库在客户的本地网络中工作，我们在C＃上有客户端应用程序来使用数据。由于一些业务需求，我们下令开始将所有内容移至Azure。数据库将转移到Azure SQL。

我们讨论过访问数据库。有两点：

1. 一个人说我们必须在我们的应用程序（将在最终用户PC的Azure外部工作）和SQL Azure之间再添加一层。换句话说，他建议添加API服务，将所有请求转换为DB，即app(on-premises) -> API service (on Azure)-> SQL Azure。这种方法看起来更可靠和安全，因为我们将SQL Azure隐藏在API服务的外观之后，应用程序仅与我们的API服务进行对话。它看起来更像是一个反向代理。显然，在这个API背后，我们可以构建更复杂的DB结构。
2. 另一个人建议直接连接到DB，即app(on-premises) -> SQL Azure。到目前为止，我们还没有计划改变数据库结构，甚至增加数据库的数量。他声称它更简单，我们可以以同样的方式确保我们的连接。有额外的服务只是将我们的查询重新转换为数据库并返回看起来就像浪费时间。将来，如果需要，我们会添加此API。

您会选择和推荐什么？为什么？

很少注意到：

• 我们将使用Azure AD对用户进行身份验证。
• 我们的应用程序也将转移到Azure，但是稍后（1 - 2年），我们计划创建REST API并转移到瘦客户端而不是我们现在拥有的胖客户端。
• 良好的表现是我们的目标，我们不想添加可以减少它的额外东西，但安全性也是我们最重要的目标。

Answer 1

当然，中间层是一种方法。没有足够的细节可以肯定，但我想知道为什么你不尝试第二种选择。通常一些重建是正常的。但如果没有它就可以逃脱，并且你获得了足够的表现，那就更好了。

我希望这会有所帮助。 谢谢。 盖

Answer 2

如果您的应用程序不仅仅是原型（听起来不是原型），那么我建议您构建中间API。主要原因是：

灵活性

推出新版本的API很简单：您只有一个部署，或者您有类似Octopus Deploy的内容，可以同时部署到几个实例。部署客户端应用程序通常更多更多参与：创建安装程序，分发它们，确保用户安装它们等。

如果您构建API，您将能够通过修改API实现来更改数据库并从客户端应用程序隐藏这些更改，但保持API接口相同。 继续前进，这将大大简化团队的任务。

安全

只要您的系统中有不同的角色/权限，如果直接连接到数据库，则需要使用数据库安全功能实现它们。这可能适用于简单的情况，但即便如此，管理也是一种痛苦。

使用API​​，您可以使用C＃在API中实现授权。像这样，您可以构建您需要的任何内容，并且您不受数据库提供的安全功能的限制。

此外，如果您不需要特别注意这一点，最终可能会将数据库凭据暴露给客户端应用程序，这将是一个主要的安全漏洞。

结论

构建中间API。除非您有充分的理由不这样做。与建筑方面的考虑一样，我确信有些情况下上述要点并不适用。如果您决定走直接路线，请确保您了解所有影响。