SQL Azure 是否适合桌面客户端应用程序答案

【问题标题】：Is SQL Azure suitable for Desktop client applicationsSQL Azure 是否适合桌面客户端应用程序
【发布时间】：2011-07-26 18:32:06
【问题描述】：

我有一个经营小型企业的客户。他们需要一个自定义数据库解决方案，我正在研究各种选项。我的经验仅限于使用本地 SQL Server（没有 ASP.NET）的 .NET，但是，这个客户端是非技术性的，并且可以从能够外包 DBA 任务中受益。我是一个完整的 Azure 菜鸟，我刚刚浏览了教程，它们似乎都针对开发 MVC ASP 解决方案。客户端不需要基于浏览器的解决方案。来自不同地理办公室的胖桌面客户端将是我能提供的最便宜的选择。我只是想节省一些时间来浏览所有教程和文档，只是发现这不是 SQL Azure 的意图。实际上，我的问题归结为：

我能否使用 Entity Framework 4 开发 C#/.NET WPF 桌面应用程序并让它访问 SQL Azure 而不是本地 SQL Server？
EF4 和 SQL Azure 是否存在任何已知问题？
使用 SQL-Azure 而不是本地 SQL Server 是否还有其他隐藏的开发成本/复杂性。
基本工具支持一样吗？我能想到的一个具体例子；是否获得用于故障排除的 SQL 分析器工具？
最后一个问题与安全相关，我不够老练，无法提出一个好问题，但是以这种方式访问 SQL Azure 数据库是否被视为安全问题？

【问题讨论】：

标签： wpf entity-framework-4 desktop azure-sql-database

【解决方案1】：

是的，您可以，但更合适的方法是使用 WCF 数据服务或其他形式的 Web 服务（asmx 或 WCF）作为应用程序的服务层。我喜欢这种用于业务线应用程序的方法。我讨厌用于业务线的 Web 应用程序，通过使用连接服务的 WPF 桌面应用程序，您可以获得在云中运行和拥有云产品而无需基于 HTML 的好处。
如今，SQL Azure 已全面支持 EF。过去有一些问题，但我这些天没有遇到任何问题。
在开发成本和复杂性方面 - 从开发的角度来看，Azure 桌面托管环境有点像 PITA，但我没有遇到大问题。除非您使用托管实例，否则您将无法共享本地 DEV SQL Server....当然，这会产生开发成本，因为您必须为使用付费。
好点！ SQL Azure 目前不提供 SQL Profiler 支持。我个人为此功能使用内置的 EF 跟踪支持。
从安全角度来看，直接公开 SQL Azure DB 并不是一个好主意。这就是为什么我建议在第 1 点中使用 WCF 数据服务（或其他 Web 服务）端点。

【讨论】：

我不确定您所说的无法共享本地开发 SQL Server 是什么意思？没有什么可以阻止您使用本地 SQL Server 或 SQL Express 进行开发（确实，这很有意义），只需更改连接字符串即可。你能解释一下吗？
感谢您的详细回复。我有一些 WCF 经验（仅限 LAN），所以这可能是要走的路。我应该提到我是 EF 的新手（尽管我有一些 Linq to SQL exp.）。观看了一些关于 EF 的培训，我被一些拖放 RAD 功能所吸引，但我可以看到从长远来看，使用服务层会更好。我仍然对 WCF 感到困惑的一件事是所有绑定选择（尤其是所有 ws* 风格）。在我的项目中，我只使用了 net.tcp ，但这在这里可能不合适。有什么建议吗？
我的意思是运行一个 Azure VM 并拥有一个其他人可以连接到的“真实”天蓝色环境。我想你可以并提供一个连接字符串......但我通常会按照你建议的方式运行常规 SQL 服务器。
我喜欢 BasicHttpBinding 的想法。它是交叉兼容和透明的，这很好。但它不支持回调（除非使用 PollingDuplexBindign）。我不太喜欢 wsHttpBinding。就是说，如果您使用 WCF 数据服务并公开它们，您将使用 REST 绑定。我个人更喜欢公开 WCF 数据服务 IQueryables 而不是传统的服务操作（有些人不同意这种方法）。要在这种方法中使用 DTO，我的 IQueryables 实际上并没有返回原始 EF 实体，而是投影到预先过滤的 DTO。
您还可以在 BasicHttpBinding 中使用二进制编码。虽然这不是交叉兼容的，但它确实通过二进制序列化提高了速度。 Net.Tcp 在性能上是最好的（虽然如果使用带有 Http 的二进制序列化效果不会好很多）......但根据我自己的经验，让我们的客户允许访问它是一件痛苦的事情。

【解决方案2】：

您可以开发使用 SQL Azure 作为数据库的桌面或本地应用程序。

您需要采取标准的 Azure 预防措施 - 假设会发生连接故障并确保您的应用程序具有重试逻辑来恢复操作。另请注意，SQL Azure 将终止任何耗时超过一分钟的操作，以便为其他用户保留服务。如果您有大量数据和一些讨厌的查询，那可能是相关的。

EF 在 SQL Azure 上运行良好。 SQL Azure 本身有一些限制，您可以从 Microsoft 网站上的文档中了解这些限制。如果您为 Azure 设计数据库，它可以在 SQL Server 或 SQL Express 上正常工作（但不一定相反）。

除了数据库的每月费用外，您还需要为离开数据中心的数据付费。仔细设计您的应用程序，以尽量减少从数据库中检索的数据量。您不再需要为进入数据中心的数据付费，这很有帮助。

您仍然可以在 Visual Studio 中使用 SQL Management Studio 和数据连接。但是没有 SQL Profiler。有一些恼人的事情你不能用 Management Studio 做，但没有什么是不可克服的。

您必须打开防火墙规则才能访问数据库，但希望它们会受到限制。身份验证是通过 SQL Server 凭据进行的，而不是集成身份验证。

我不倾向于这样做，但它确实有效。

【讨论】：

感谢您指出“标准 Azure 预防措施”，因为我是新手，在我了解文档的同时了解这一点是件好事。您关于为离开数据中心的数据付费的评论让我感到惊讶。在发布之前，我虽然了解每月费用from the pricing and Metering section。您是否有显示额外数据费用的链接？
请参阅 microsoft.com/windowsazure/pricing - 标题为“以 GB 为单位测量的数据传输（与 Windows Azure 数据中心之间的传输）”的部分。