Зачем использовать веб-сервисы вместо прямого доступа к реляционной базе данных для приложения для Android?

Я искал в Интернете, как эффективный доступ к центральной базе данных в удаленном месте, и я встретил предложения использовать веб-сервисы вместо прямого доступа (например, JDBC и т. Д.) К базе данных. Мне интересно, причина этого и любые другие предложения ,

Добавление уровня веб-службы дает вам возможность сделать ваш клиент более легковесным как с точки зрения требуемой мощности процессора, так и пропускной способности, используемой во время обработки. Оба фактора чрезвычайно важны для конечных пользователей:

• Использование меньшего количества ресурсов процессора увеличивает срок службы батареи,
• Использование меньшей пропускной способности уменьшает ежемесячные платежи для пользователей с тарифными планами

Внедряя уровень веб-приложений, вы переносите основную часть обработки с переносного мобильного клиента с низким энергопотреблением, низкой пропускной способностью и низкой памятью на подключенный высокопроизводительный сервер с высокой пропускной способностью и большим объемом памяти, чем он. потребности - среда, в которой обработка и связь стоят дешевле, чем клиент.

Но подождите, в этом есть кое-что для вас: разделив систему, вы получите больший контроль над своими бизнес-правилами, структурой базы данных и версиями того, что там есть. Как только вы позволите мобильному клиенту подключиться непосредственно к базе данных, ваш дизайн «выйдет» за эту структуру базы данных: почти любое изменение нарушит обратную совместимость с клиентом, который может неохотно обновлять свое приложение.

Напротив, добавление веб-службы между ними позволяет развивать интерфейс для мобильных клиентов более управляемыми способами: например, вы можете сохранить старый интерфейс на месте, добавить новый, который работает «параллельно» с ним, а затем полностью реструктурируйте свою базу данных, не нарушая ни одного клиента.

Если вы будете следовать некоторым довольно базовым принципам проектирования при разработке веб-службы, вы также сможете получить значительные преимущества, повторно использовав развитую инфраструктуру на стороне сервера, которая была создана: например, вы можете получить кеш и прокси-сервисы бесплатно.

Наконец, это откроет двери для других разработчиков, открывающих ваше приложение для платформ, которые вы не можете обслуживать самостоятельно, в конечном счете, играя на пользу вашей компании.

Он помещает слой абстракции между приложением и БД. Это дает вам много преимуществ, таких как:

• Ограничение доступа к БД только теми частями, которые нужны приложению. Это одновременно упрощает код приложения и обеспечивает безопасность вашей БД.
• Относится к внутренней работе БД, поэтому, если вы позже решите изменить свою схему, запросы или даже всю базу данных, ссылка на ваше приложение не будет нарушена, если вы правильно поддерживаете средний уровень.
• Это позволяет вам добавить функциональность за пределы БД. Например, кеширование данных довольно постоянное. Бизнес-правила - это еще одна часть, которая должна быть отделена от БД.

Еще одна причина не выставлять БД напрямую - транспорт. Большинство реляционных баз данных, с которыми вы общаетесь с JDBC, вообще не предназначены для публичного интернета. Беспроводной интернет - ужасно ненадежный конец общедоступного интернета. Обработка исключений была бы кошмаром, и вы, вероятно, в конечном итоге написали бы обратный слой веб-сервисов внутри своего приложения, чтобы избежать потери транзакций.

Есть несколько новых видов баз данных, которые говорят на HTTP и могут быть подходящими для такого рода вещей. Они также склонны предлагать способы размещения своего рода кода приложения в базе данных. Возможно, вы захотите взглянуть на CouchDb или RavenDb - обе базы данных документов с возможностями сопоставления / сокращения, которые работают через json и http, очень похожи на многие современные веб-сервисы.