JDBC 与 Android 的 Web 服务 [英] JDBC vs Web Service for Android

问题描述

有人可以回答我的困境使用哪种方法将 Android 设备连接到 mySQL 或 Postgresql?

Can someone answer on my dilemma which method to use for connecting Android device to mySQL or Postgresql?

两种方式我都可以做到，没有任何错误和问题，没有明显区别，但每个人都推荐使用 web service 而不是使用 jdbc 驱动程序和直接连接，

I can do it in both ways without any errors and problems, with no noticeable difference but everyone recommend web service instead of using jdbc driver and direct connection,

有人可以用一些事实来解释原因吗?

Can someone explain why with some facts?

我没有提到它更简单，而且通过 jdbc 完成它需要的时间更少.那么，为什么是 Web 服务，或者为什么不呢?

I did'n mention that is more simple and needs less time to do it over jdbc. So, why web service, or why not?

推荐答案

您认为使用 JDBC 更简单、更快捷，因为您没有考虑手机和便携式设备的真实操作环境设备.他们通常通过有问题的流量重写代理和疯狂的防火墙来实现不稳定的连接.他们通常使用具有高且可变的丢包率和延迟的网络传输层，这些延迟在短时间内会在多个数量级上发生变化.TCP 在这种环境中真的不是很好，尤其是在长期连接的情况下.

You think it's simpler and faster to do it with JDBC because you aren't considering the real world operating environment of phones and portable devices. They often have flakey connectivity through buggy traffic rewriting proxies and insane firewalls. They're typically using a network transport layer that has high and variable packet loss rates and latencies that vary over many orders of magnitude in short spans of time. TCP really isn't great in this environment and particularly struggles with long lived connections.

Web 服务的主要优势在于:

The key benefit of a web service is that it:

• 具有最短状态的短连接连接，因此当设备切换 WiFi 网络、进出蜂窝网络、短暂失去连接等时，很容易回到原来的状态；和

• Has short-lived connections with minimal state, so it's easy to get back to where you were when the device switches WiFi networks, to/from cellular, loses connectivity briefly, etc; and

可以通过除最糟糕和最严厉的网络代理之外的所有代理

Can pass through all but the most awful and draconian web proxies

您将经常遇到直接 JDBC 连接的问题.一个挑战是可靠地超时死连接，重新建立会话并释放旧会话持有的锁(因为服务器可能不会在客户端确定它已死的同时).另一个是数据包丢失导致操作非常缓慢、数据库事务长时间运行，以及随之而来的锁定持续时间和事务清理任务的问题.您还将在阳光下遇到各种疯狂和损坏的代理和防火墙 - 支持 CONNECT 的代理，但结果却假设所有流量都是 HTTP，如果不是，则将其破坏；带有错误状态连接跟踪的防火墙会导致连接失败或进入半开僵尸状态；您可以想象的每个 NAT 问题；运营商有帮助地"生成 TCP ACK 以减少延迟，不用担心丢包发现和窗口大小导致的问题；古怪的端口阻塞；等

You will routinely encounter problems with a direct JDBC connection. One challenge is reliably timing out dead connections, re-establishing sessions and releasing locks held by the old session (as the server may not decide it's dead at the same time the client does). Another is packet loss causing very slow operations, long-running database transactions, and consequent problems with lock durations and transactional cleanup tasks. You'll also meet every variety of insane and broken proxy and firewall under the sun - proxies that support CONNECT but then turn out to assume all traffic is HTTPs and mangle it if it isn't; firewalls with buggy stateful connection tracking that cause connections to fail or go to a half-open zombie state; every NAT problem you can imagine; carriers "helpfully" generating TCP ACKs to reduce latency, never mind the problems that causes with packet loss discovery and window sizing; wacky port blocking; etc.

因为每个人都使用 HTTP，所以您可以期望它会起作用 - 至少比其他任何方法都有效.现在尤其如此，即使在移动网络应用中，常见网站也使用 REST+JSON 通信方式.

Because everyone uses HTTP, you can expect that to work - at least, vastly more often than anything else does. This is particularly true now that common websites use REST+JSON communication style even in mobile web apps.

您还可以使用唯一的请求令牌将 Web 服务调用编写为幂等.这让您的应用程序可以重新发送修改请求，而不必担心它会对数据库执行两次操作.请参阅 幂等性 和 定义幂等.

You can also write your web service calls to be idempotent using unique request tokens. That lets your app re-send modification requests without fear that it'll perform an action against the database twice. See idempotence and definining idempotence.

说真的，来自移动设备的 JDBC 现在看起来可能是个好主意 - 但我什至考虑的唯一方法是，如果移动设备都在我直接控制的单个高可靠性 WiFi 网络上.即便如此，如果可能的话，我也会出于数据库性能管理的原因避免使用它.您可以使用类似 PgBouncer 之类的东西在服务器端的许多设备之间建立连接池，因此连接池不是一个大问题，但清理丢失和废弃的连接是一个大问题，这是使其工作所需的 tcp keepalive 流量和长期停滞的来自废弃连接的交易.

Seriously, JDBC from a mobile device might look like a good idea now - but the only way I'd even consider it would be if the mobile devices were all on a single high-reliably WiFi network under my direct control. Even then I'd avoid it for reasons of database performance management if I possibly could. You can use something like PgBouncer to pool connections among many devices at the server side so connection pooling isn't a big problem, but cleanup of lost and abandoned connections is, as is the tcp keepalive traffic required to make it work and the long stalled transactions from abandoned connections.

这篇关于JDBC 与 Android 的 Web 服务的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！