Por que usar serviços da Web em vez de acesso direto a um banco de dados relacional para um aplicativo Android?

Pesquisei na Web como acessar de maneira eficiente um banco de dados central em um local remoto e encontrei sugestões para usar serviços da Web em vez de acesso direto (por exemplo, JDBC etc) a um banco de dados. .

A adição de uma camada de serviço da web oferece a oportunidade de tornar seu cliente mais leve, tanto em termos da energia da CPU necessária quanto da largura de banda usada durante o processamento. Ambos os fatores são extremamente importantes para os usuários finais:

• Usar menos CPU aumenta a vida útil da bateria,
• Usar menos largura de banda reduz os pagamentos mensais para usuários com planos medidos

Ao introduzir uma camada de aplicativo da web, você move a maior parte do processamento de um cliente móvel portátil de baixa potência, baixa largura de banda e pouca memória para um servidor conectado e de alta largura de banda e alta potência, com mais memória do que ele needs - um ambiente em que o processamento e as comunicações custam uma fração do que custam ao cliente.

Mas espere, também há algo para você: dividindo o sistema, você obtém mais controle sobre suas regras de negócios, a estrutura do seu banco de dados e as versões do que está por aí. Depois que você permite que um cliente móvel se conecte diretamente ao banco de dados, seu design é "casado" com essa estrutura de banco de dados: quase todas as alterações quebram a compatibilidade com versões anteriores de um cliente que pode estar relutante em atualizar seu aplicativo.

Por outro lado, adicionar um serviço da Web no meio permite evoluir a interface para clientes móveis de maneiras mais gerenciáveis: por exemplo, você pode manter a interface antiga no lugar, adicionar uma nova que funcione "em paralelo" com ela e depois inteiramente reestruture seu banco de dados sem quebrar um único cliente.

Se você seguir alguns princípios básicos de design ao projetar seu serviço da Web, poderá obter benefícios significativos reutilizando a infraestrutura madura do lado do servidor que foi implementada: por exemplo, você pode obter serviços de cache e proxy gratuitamente.

Por fim, isso abrirá a porta para outros desenvolvedores, expondo seu aplicativo a plataformas que você não poderia prestar serviços de manutenção a si mesmo, acabando por tirar proveito da sua empresa.

Ele coloca uma camada de abstração entre o aplicativo e o banco de dados. Isso oferece muitas vantagens, como:

• Limitando o acesso ao banco de dados apenas às partes que o aplicativo precisa. Isso simplifica o código do aplicativo e mantém seu banco de dados seguro.
• Asbstra o trabalho interno do banco de dados; portanto, se você decidir posteriormente alterar seu esquema, consultas ou mesmo todo o banco de dados, o link para seu aplicativo não será quebrado desde que você mantenha a camada intermediária corretamente.
• Permite adicionar funcionalidades fora do escopo de um banco de dados. Armazenamento em cache de dados que são razoavelmente constantes, por exemplo. As regras de negócios são outra parte que deve ser separada do banco de dados.

Um outro motivo para não expor o banco de dados diretamente - transporte. A maioria dos bancos de dados relacionais, os tipos de assuntos com os quais o JDBC conversa, não são projetados para a Internet pública em geral. Internet sem fio é um fim terrivelmente não confiável da referida Internet pública. O tratamento de exceções seria um pesadelo e você provavelmente escreveria o reverso da camada de serviços da Web dentro do aplicativo para evitar a perda de transações.

Existem alguns tipos mais recentes de bancos de dados que falam HTTP e podem ser adequados para esse tipo de coisa. Eles também tendem a apresentar maneiras de inserir códigos de aplicativos no banco de dados. Você pode querer observar o CouchDb ou o RavenDb - ambos são dbs de documentos com recursos de mapa / redução que funcionam sobre json e http, como muitos serviços modernos da web.