直接连接到 SQL Azure 与通过 API 服务层连接？答案

【问题标题】：Direct connect to SQL Azure vs connection via API service layer?直接连接到 SQL Azure 与通过 API 服务层连接？
【发布时间】：2016-10-12 10:11:58
【问题描述】：

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

我们讨论了访问数据库的问题。有两点：

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

你会选择和推荐什么，为什么？

几点注意事项：

【问题讨论】：

【解决方案1】：

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

我希望这会有所帮助。谢谢你。伙计

【讨论】：

【解决方案2】：

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

灵活性

推出新版本的 API 很简单：您要么只有一个部署，要么拥有类似 Octopus Deploy 的东西，它可以同时部署到几个实例。部署客户端应用程序通常更多涉及：创建安装程序、分发它们、确保用户安装它们等。

如果您构建 API，您将能够对数据库进行更改，并通过修改 API 实现对客户端应用程序隐藏这些更改，但保持 API 接口不变。 展望未来，这将大大简化您团队的任务。

一旦您在系统中拥有不同的角色/权限，如果您直接连接到数据库，则需要使用数据库安全功能来实现它们。这可能适用于简单的情况，但即使这样也很难管理。

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

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

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

【讨论】：