Aplicativo e site com o mesmo banco de dados

Voce tem duas escolhas:

1. acessar o banco de dados diretamente (lembrete: use ssl).
2. Criar as tuas duas aplicações (web e local), onde a aplicação web acesse o banco de dados localmente (localhost) e que esta implemente um WS (ebj, spring, Rest etc) para a aplicação local.

Eu prefiro a segunda, pois assim vc centraliza o acesso aos dados em uma única aplicação. Caso a sua lógica de negócios for alterada (provavelmente será), você vai precisar alterar apenas uma aplicação.

[]s,
Thiago

Não entendi essa parte.

tempos atrás tive a mesmo dúvida que vc.
minha resposta se resume numa sigla(dentre as muitas existentes no mundo java):
EJB

Eu quis dizer que uma das tuas aplicações seria a “façade” de acesso aos dados.

Imagine que vc tenha a aplicacao X e a Y:

• A aplicação X acessa o banco de dados diretamente.
• A aplicação Y não sabe nem que um banco de dados existe. A aplicação Y recebe todos os dados que precisa via aplicação X.

Imagine que X é uma aplicação web e Y, desktop. Em X existe um webservice (ejb/rest/soap/rpc etc) “getUsers”:

• a X chama X.getUsers para popular uma grid
• a Y chama (Remote)X.getUsers pra popular outra grid (desktop)

Na primeira versao de getUsers, o sistema não se importava com o tipo de usuário logado. Ou seja, qualquer usuário que chamasse “getUsers” receberia a lista de todos os usuários do sistema. Numa segunda versão, o cliente resolveu que apenas os usuários “admin” receberiam a lista de todos os usuários via “getUsers”. Os outros usuários receberiam apenas a lista de usuários logados e não “admin”.

Se vc tiver uma “façade”, a única coisa que vc precisará alterar é a implementação do método “getUsers” na aplicação X. A aplicação Y nem ficará sabendo da mudança.
Se vc escolher a conexão direta com o banco de dados, vc precisará duplicar a lógica em duas aplicações. Na verdade, qualquer alteração na lógica de negócios deverá ser duplicada (concurrent calls, logging, alterações na estrutura de dados etc).

[]s,
Thiago.

Olá Thiago,

Primeiramente, muito obrigado pela ajuda.

Acho que entendi, mas como não especifiquei melhor como é o sistema, não ficou muito claro.
É o seguinte: o site servirá basicamente como apresentação da empresa, só tendo interação com a abertura de chamados (que serão armazenados no banco de dados x da hospedagem mesmo). E o sistema desktop (que terá um banco de dados y próprio, pois terá uma lógica de negócio totalmente diferente), acessa o banco de dados x apenas para buscar estes chamados. Ou seja, pelo meu ponto de vista, nunca vai haver grandes alterações (se algo mudar no banco de dados x, terei que alterar a parte web e a parte desktop, porém, é uma parte mínima do sistema, a qual não sofrerá grandes alterações com o passar do tempo).

O que você acha? Vira gambiarra isso? E nesse caso específico, qual opção você escolheria?

gambazinho,

Pode ser uma ótima alternativa, mas infelizmente não vai dar por questão de tempo (visto que nunca trabalhei com EJB na vida).

Novamente muito obrigado a vocês.

Abraços.

amigo, vai por mim, EJB é muito fácil. eu tinha o mesmo receio que vc, imagina ser algo de outro mundo… mas é bem simples de se trabalhar, toda a complexidade os containers é que se viram pra resolver. antigamente era realmente trabalhoso, mas hoje em dia uma simples annotation resolve tua vida @Stateles @Local