JDBC против веб-службы для Android
Может кто-нибудь ответить на мою дилемму, какой метод использовать для подключения устройства Android к mySQL или Postgresql?
Я могу сделать это обоими способами без каких-либо ошибок и проблем, без заметной разницы, но все рекомендуют веб-сервис вместо использования драйвера jdbc и прямого соединения,
Может кто-нибудь объяснить почему с некоторыми фактами?
РЕДАКТИРОВАТЬ: я не упомянул, что это более простой и требует меньше времени, чтобы сделать это по сравнению с JDBC. Итак, почему веб-сервис или почему нет?
5 ответов
Вы думаете, что проще и быстрее сделать это с JDBC, потому что вы не рассматриваете реальную среду работы телефонов и портативных устройств. Они часто имеют нестабильную связь через прокси перезаписи трафика и безумные брандмауэры. Как правило, они используют сетевой транспортный уровень, который имеет высокие и переменные показатели потери пакетов и задержек, которые меняются на многие порядки за короткие промежутки времени. TCP действительно не очень хорош в этой среде и особенно борется с долгоживущими соединениями.
Основное преимущество веб-службы заключается в том, что она:
Имеет кратковременные соединения с минимальным состоянием, поэтому легко вернуться туда, где вы были, когда устройство переключает сети Wi-Fi, в / из сотовой связи, кратковременно теряет связь и т. Д.; а также
Может проходить через все, кроме самых ужасных и драконовских веб-прокси
Обычно вы будете сталкиваться с проблемами с прямым соединением JDBC. Одной из проблем является надежное определение времени ожидания мертвых соединений, повторное установление сеансов и снятие блокировок, удерживаемых старым сеансом (поскольку сервер может не решить, что он не работает одновременно с тем, что делает клиент). Другой причиной является потеря пакетов, вызывающая очень медленные операции, длительные транзакции базы данных и связанные с этим проблемы с длительностью блокировок и задачами очистки транзакций. Вы также встретите всевозможные безумные и сломанные прокси и брандмауэр под солнцем - прокси, которые поддерживают CONNECT но потом оказывается, что весь трафик - это HTTP и искажает его, если это не так; межсетевые экраны с ошибочным отслеживанием состояния соединения, которые вызывают сбой соединения или переход в полуоткрытое состояние зомби; каждая проблема NAT, которую вы можете себе представить; операторы "услужливо" генерируют TCP ACK для уменьшения задержки, не говоря уже о проблемах, связанных с обнаружением потери пакетов и определением размера окна; дурацкая блокировка портов; и т.п.
Поскольку все используют HTTP, вы можете ожидать, что это сработает - по крайней мере, гораздо чаще, чем все остальное. Это особенно верно сейчас, когда обычные веб-сайты используют стиль связи REST+JSON даже в мобильных веб-приложениях.
Вы также можете написать свои вызовы веб-службы, чтобы быть идемпотентными, используя уникальные токены запроса. Это позволяет вашему приложению повторно отправлять запросы на изменение, не опасаясь, что оно выполнит действие с базой данных дважды. См. Идемпотентность и определение идемпотентности.
Серьезно, теперь JDBC с мобильного устройства может показаться хорошей идеей, но я бы даже подумал, что все мобильные устройства будут находиться в одной высоконадежной сети Wi-Fi под моим прямым контролем. Даже тогда я бы избегал этого по причинам управления производительностью базы данных, если бы мог. Вы можете использовать что-то вроде PgBouncer для объединения подключений между многими устройствами на стороне сервера, так что объединение в пул соединений не представляет большой проблемы, но очистка от потерянных и потерянных подключений так же, как трафик keepalive tcp, необходимый для его работы и длительный останов транзакции из заброшенных соединений.
Я могу придумать несколько причин
- Поддержка драйвера JDBC для Android для вашей базы данных.
- Пул соединений между различными устройствами Android затрудняет их мониторинг и ограничение.
- Результирующие наборы, отправленные с БД на Android, будут потреблять большую пропускную способность и заряд батареи.
- Прокси обычно разрешают HTTP доступ к вашему устройству.
- Предоставление вашей базы данных непосредственно клиенту имеет последствия для безопасности.
Веб-сервисы могут предоставлять дополнительные функции поверх JDBC-соединения, такие как аутентификация / качество обслуживания / авторизация / условные запросы GET / обработка ошибок и т. Д. JDBC не может делать ничего из этого.
Помимо всего сказанного Крейгом Рингером, с которым я полностью согласен, у JDBC есть еще одна проблема: она заставит выставить вашу базу данных всему миру. Если вы хотите, чтобы устройства Android имели к нему доступ, вам необходимо предоставить приложению учетные данные базы данных, и база данных будет иметь публичный доступ.
Использование WebService или RESTful API - это, безусловно, способ сделать ваше приложение безопасным.
Другой вариант - использовать инструмент синхронизации базы данных, такой как SymmetricDS.
Это позволит вам иметь базу данных Postgres на вашем сервере и базу данных SQLite на планшете.
SymmetricDS будет синхронизировать базы данных по HTTP, когда соединение доступно. Конечно, вам не нужно синхронизировать всю БД, только соответствующие части.
(Я не связан с SymmetricDS)
TL;DR: Это зависит от обстоятельств!(Извините за всех, что "никогда не делали этого, прямые подключения всегда злы"- разработчики)
При создании общедоступного / общего приложения для игрового магазина я в основном работаю со своими товарищами по ответу. Открытие вашей БД для «всех» (особенно, когда разрешения плохо настроены или вообще не настроены), как правило, не лучшая идея !!
Однако (!) История может быть совершенно иной, когда вы, например, создаете что-то для внутреннего использования в пределах сети вашей компании , например, портативные устройства Android для логистики, инвентаризации и т. Д. В этих случаях я бы даже в большинстве случаев определенно рекомендую использовать JDBC или аналогичное прямое соединение. Причины того, что:
- На одну точку отказа меньше
- На один девелоперский (суб) проект меньше
- На одну вещь меньше, чем нужно поддерживать и поддерживать свою структуру данных в актуальном состоянии
- Еще одним делом меньше: CI/CD, тестирование и т. Д. (Вы получаете черновик)
Что, по моему скромному мнению, хуже, чем (реализовать это один раз) усилие по объединению соединений, восстановлению и т. Д. (Если это действительно становится необходимым, будьте осторожны с преждевременной оптимизацией).
Но для публичных проектов ... ну, если они когда-либо требуют доступа только для чтения, я мог бы также представить это, или если есть только определенные таблицы, которые вы разрешаете добавлять, но не удалять или изменять. Есть несколько уловок, которые вы можете применить, чтобы сделать его по-прежнему безопасным (позволяя добавлять, но не читать с идентификаторами-секретами для определенной таблицы, триггеры и общие чтения для других таблиц и т. Д.), Но есть над чем подумать и многое пропустить об этом. В общем, я бы сказал, что это плохая практика - позволять клиенту общедоступного домена получать ваше SQL-соединение. Но все же не позволяйте этому мешать вам спросить себя (и понять) «почему» и посмотреть на конкретную ситуацию. Для этого может быть даже веская причина / использование. Тем более что он «меньше», что тоже часто лучше. Это определенно зависит.
Просто будьте осторожны и знайте, что (даже если разрешения установлены правильно) многое может быть использовано неправильно (и лишь немного затруднено) при прямом подключении к вашему клиенту. (Плюс возможные проблемы с подключением, о которых нужно позаботиться.)
В качестве примечания: многие из этих соображений снова актуальны при использовании таких технологий, как GraphQL , который имеет некоторые общие черты (однако без проблем с подключением и с немного более безопасным контролем).