为什么要使用网络服务而不是直接为Android应用访问关系数据库？

我在网上搜索了如何高效地访问远程位置的中央数据库，并且遇到了使用Web服务而不是直接访问数据库（例如JDBC等）的建议。我想知道这样做的原因以及其他建议。

添加Web服务层使您有机会使客户端更加轻巧，无论是在所需的CPU能力还是在处理过程中使用的带宽方面。这两个因素对最终用户都非常重要：

• 使用更少的CPU可以延长电池寿命，
• 使用更少的带宽可以减少按计划计费的用户的每月付款

通过引入Web应用程序层，您可以将大部分处理从手持移动低功耗，低带宽，低内存客户端转移到具有更多内存的插入式高功率高带宽服务器。需求-一种环境，处理和通信成本仅为客户端成本的一小部分。

但是，等等，还为您提供了一些东西：通过拆分系统，您可以更好地控制业务规则，数据库结构以及现有版本。一旦让移动客户端直接连接到数据库，您的设计就会“嫁接到”该数据库结构：几乎任何更改都会破坏对客户端的向后兼容性，而后者可能不愿升级其应用程序。

相反，在两者之间添加Web服务可以使您以更易于管理的方式将界面扩展到移动客户端：例如，您可以保留旧界面，添加与之“并行”工作的新界面，然后完全在不破坏单个客户端的情况下重组数据库。

如果在设计Web服务时遵循一些非常基本的设计原则，则还可以通过重用已经建立的成熟的服务器端基础结构来获得显着的好处：例如，您可以免费获得缓存和代理服务。

最后，这将为其他开发人员打开大门，使您的应用程序暴露于您无法自行维护的平台上，从而最终发挥了公司的优势。

它在应用程序和数据库之间放置了一层抽象层。这为您带来了许多优势，例如：

• 将对数据库的访问限制为仅应用所需的部分。这既简化了应用程序的代码，又确保了数据库的安全。
• 由于抽象了数据库的内部工作，因此，如果您以后决定更改架构，查询甚至整个数据库，则只要您正确维护中间层，就不会断开与应用程序的链接。
• 它使您可以在数据库范围之外添加功能。例如，缓存相当恒定的数据。业务规则是应该与数据库分开的另一部分。

不直接公开数据库的另一个原因-传输。大多数关系数据库（一种与JDBC交谈的东西）通常都不是为公共Internet设计的。无线互联网是上述公共互联网的可怕的不可靠的终结。异常处理将是噩梦般的，您可能最终会在应用程序内部编写相反的Web服务层，以避免丢失交易。

有一些更新的数据库确实支持HTTP，并且可能适合这种情况。它们还倾向于提供将各种应用程序代码放入数据库中的方法。您可能想看看CouchDb或RavenDb，它们都是具有map / reduce功能的文档db，它们可以在json和http上工作，就像许多现代Web服务一样。