你 * 认为 * 用JDBC做这件事更简单、更快，因为你没有考虑电话和便携设备的真实的操作环境。它们通常通过有缺陷的流量重写代理和疯狂的防火墙进行连接。它们通常使用一个网络传输层，该层具有高且可变的丢包率和在短时间内变化多个数量级的延迟。TCP真的在这种环境下并不好，特别是在长期连接方面。
Web服务的主要优点是：

• 具有具有最小状态的短暂连接，因此当设备切换WiFi网络，进入/离开Hive网络，短暂失去连接等时，很容易回到您所在的位置;以及
• 可以通过所有的，但最可怕的和最严厉的网络代理

在直接JDBC连接时，您会经常遇到问题，其中一个挑战是可靠地对死连接进行计时，重新建立会话并释放旧会话持有的锁（因为服务器可能不会在客户端确定它死的同时确定它死了）。另一个是数据包丢失导致非常缓慢的操作，长时间运行的数据库事务，以及随之而来的锁持续时间和事务清理任务的问题。你也会遇到阳光下各种疯狂和破碎的代理和防火墙-支持CONNECT的代理服务器，但最终会假设所有流量都是HTTP，如果不是，就会破坏它;带有错误的状态连接跟踪的防火墙，导致连接失败或进入半开僵尸状态;你能想象到的每一个NAT问题;运营商“有帮助地”生成TCP ACK以减少延迟，更不用说丢包发现和窗口大小调整导致的问题;古怪的端口阻塞;等等。
因为每个人都在使用HTTP，所以你可以期待它的工作--至少，比其他任何东西都要频繁得多。现在，即使在移动的Web应用程序中，常见的网站也使用REST+JSON通信风格，这一点尤其如此。
您还可以使用唯一的请求令牌将您的Web服务调用编写为 * 幂等 *。这使您的应用可以重新发送修改请求，而不必担心它会对数据库执行两次操作。请参阅idempotence和definining idempotence。
说真的从移动终端使用JDBC现在看起来可能是个好主意--但我唯一会考虑的方法是移动设备都在一个高--在我的直接控制下可靠的WiFi网络。即使这样，如果可能的话，出于数据库性能管理的原因，我也会避免使用它。您可以使用PgBouncer之类的东西在服务器端的许多设备之间池连接，这样连接池就不会这是一个大问题，但是清除丢失和放弃的连接是一个大问题，因为这是使其工作所需的tcp keepalive流量，以及来自放弃连接的长期停滞的事务。

我能想到几个原因
1.JDBC android驱动程序支持为您的数据库。
1.跨各种Android设备的连接池很难监控和限制它们。
1.从数据库发送到android的结果集将消耗大量的带宽和电池电量。
1.代理通常允许HTTP访问您的设备。
1.直接向客户端公开数据库会带来安全问题。
Web服务可以在JDBC连接之上提供额外的功能，如身份验证/服务质量/授权/条件GET请求/错误处理等。

除了克雷格林格说的所有事情，我完全同意，JDBC还有另一个问题：它会强制将你的数据库暴露给全世界，如果你想让android设备访问它，你将需要为你的应用提供数据库凭据，数据库将必须具有公共访问权限。
使用WebService或RESTful API显然是确保应用程序安全的方法。

另一种选择是使用数据库同步工具，如SymmetricDS。
这将使您在服务器上拥有Postgres数据库，并在平板电脑上拥有SQLite数据库。
当连接可用时，SymmetricDS将通过HTTP同步数据库。当然，您不必同步整个数据库，只需同步相关部分。
（我没有加入SymmetricDS）

当创建一个公共领域/通用应用程序的playstore之类的东西，我主要是与我的同胞响应.开放您的数据库“每个人”（特别是当权限配置不好或根本没有）通常不是一个好主意！！
然而（！），故事可能完全不同，当你例如创建一些内部使用的您的公司的网络边界，像Android手持设备的物流，库存等.在这些情况下，我甚至会明确建议大部分时间使用JDBC或类似的直接连接.原因是：

• 又少了一个失败点
• 少了一件需要维护和更新数据结构的事情
• 少了一件事要保持和运行，CI/CD，测试等。

我的拙见是，这可能比（实现一次）连接池、重建等工作更糟糕（如果它真的变得不必要-小心过早优化）。
但是对于公共项目，如果它们只需要读访问权限，我也可以想象，或者如果只允许添加某些表，但不允许删除或修改。（允许添加但不允许读取某个表、触发器的ID秘密，以及其他表的一般读取等），但是关于这些有很多要思考的，也有很多要错过的。所以一般来说，我会说让你的公共域客户端掌握你的SQL连接是不好的做法。但是，别让这妨碍你问问自己（并理解）“为什么”，看看具体情况。甚至可能有很好的原因/用途。特别是因为它是“少”，这通常也更好。这当然要看情况而定。
只是要小心，并意识到（即使权限设置正确）很多可能被滥用（只有很少的阻碍），在您的客户端直接连接。（加上可能的连接问题要照顾。）

作为旁注：这些考虑因素中的很多都与使用像 GraphQL 这样的技术有关，它们有一些相似之处（但是没有连接问题，并且具有更安全的控制）。

还有像**行级安全性（RLS）**这样的特性也是这样的（例如，在无服务器应用程序中）通过移动安全性（从数据库或表级别）到数据库中的行的单独规则。必须为此实现某种级别的身份验证，通常允许“匿名”用户/连接某些权限登录或阅读一般帖子。例如，规则可以是只允许编辑行，如果用户是该帖子/条目的作者（即"tablename.authorId = @CURRENT_USER"）。