Tô com uma dúvida aqui, a qual eu acho que sei a resposta, mas melhor perguntar pra vocês que são mais experientes do que arriscar a fazer gambiarra: vou fazer uma aplicação e um site (os dois em java), sendo que ambos utilizarão o mesmo banco de dados (mysql, que estará no servidor de hospedagem contratado, como locaweb, por exemplo).
Agora a pergunta: seria adequado fazer o aplicativo receber os dados do banco de dados por web service, ou já fazer a conexão remota diretamente e buscar os dados?
No meu ponto de vista, acho mais interessante buscar os dados diretamente, visto que web services foram criados (ao meu entender) pra fazer uma “ponte” entre aplicações em diferentes linguagens.
O que vocês recomendam nesse caso?
acessar o banco de dados diretamente (lembrete: use ssl).
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.
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).
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).
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
