Aplicacao desktop

Olá

Todos podem ser usados. A recomendação é que não rode exclusivamente na mesma máquina que a aplicação desktop. Se for para fazer programas com o banco de dados exclusivamente na mesma máquina use VB ou Clipper

[]s
Luca

Luca:

Olá

Todos podem ser usados. A recomendação é que não rode exclusivamente na mesma máquina que a aplicação desktop. Se for para fazer programas com o banco de dados exclusivamente na mesma máquina use VB ou Clipper

[]s
Luca

obrigado

mais em aplicacaoes desktop para rodar na msm maquina? qual banco que é mais utilizado ???

Amigo utilize o postgre ele atende
aplicacoes de pequeno medio e grande porte.E muito bom
e facil de usar

Não conheço o postgree mas tenho testado o MySql e esta me atendendo muito bem…
Criei um aplicação para teste usando um banco na mesma máquina e acessando um banco em outra máquina nos dos casos foi muito bem.

Estou criando um banco com tabelas com 1M de registros pra testes, quero ver como ele se sai.

Luca
Não entendi porque você que se fosse pra usar um banco exclusivo e na mesma maquina pra usar Clipper ou VB… que diferença faria ? Porque não poderia usar Java ?
E até onde sei existem o que não faltam são aplicações em VB acessando bancos remotamente… como client/server.

Um abraço a todos.

Olá

Sim, é verdade. Existem aplicações em VB client/server.

Mas é exatamente por client/server ser coisa do milênio passado, disse para não usar Java. Com Java tanto faz o banco de dados estar na sala ou lado ao na Conchinchina. Fazer uma aplicação para acessar o BD exclusivamente na própria máquina ou confinado na rede local é uma bobagem contra a qual venho lutando desde 2001 e ainda tem gente que teima em fazer isto com Java.

Meu conselho neste caso: Use Clipper, FoxPro ou VB. Vai dar menos trabalho e funcionará melhor.

Use Java quando quiser alguma coisa que sirva neste milênio com todo mundo conectado.

[]s
Luca

Ola Lucca,

Infelizmente para fins de estudos estou desenvolvendo uma aplicação desktop com acesso a BD remoto num esquema client/server…

Nesse caso qual modelo você aconselharia ?

Considerando que a aplicação não é Web.

[]s

Dê uma olhada no DB4Object: http://www.db4o.com/

Olá

Meu conselho? Que não faça isto nem como fim de estudo.

Se ainda não aprendeu servlet, nem mexa com banco de dados. Estude outras coisas importantes do Java como collections, threads e sockets. Procure exemplos na web para estudar.

Depois que que aprender servlets e HTTP, tente acessar o banco de dados via http usando classes como URLConnection.

MUITO IMPORTANTE!

Se é para fim de estudo, estude logo como usar o JUnit e desenvolver orientado a testes. Veja minha assinatura. Entre no blog do Guilherme Chapiewski, baixe os slides da apresentação dele sobre TDD e veja os links. Um dia você me agradecerá este conselho.

[]s
Luca

Luca:

Olá

Zeed01:

FoxPro
[]s
Luca

FoxPro funciona bem tb para pontos bastante remotos, pelo menos até onde vi. Apesar de seus paus doidos, é possível usar O.O, porém não tão bem qt java.

Marck.

po bom topico… assim pelo que conseguir entender… e o que Luca falou… nao é recomendavel… fazer um programa para desktop e o BD rodar na mesma maquina? como acontece em outras linguaguens? como delphi, VB? eu teria que montar outra maquina para rodar o BD e a maquina do cliente… conectaria a ele? pensei que isso seria somente essencial… com web… mas desktop recomenda isso?

Recomendo o uso do HSQLDB. Se você quiser usar uma solução que permita trabalhar de forma simples nesse deployment e permita evoluir para uma arquitetura com servidor Java EE no backend, use o genesis

Na medida do possível sim, mas e se seu aplicativo for “desconectado”?
ai vc tbm pode se perguntar, pq faria hoje uma aplicação “desconectada”?

minha resposta pessoal, pq o Brasil ainda é desconectado, mas o nicho “conectado” é muito grande já.

FIREBIRD 2.x

LPJava:

po bom topico… assim pelo que conseguir entender… e o que Luca falou… nao é recomendavel… fazer um programa para desktop e o BD rodar na mesma maquina? como acontece em outras linguaguens? como delphi, VB? eu teria que montar outra maquina para rodar o BD e a maquina do cliente… conectaria a ele? pensei que isso seria somente essencial… com web… mas desktop recomenda isso?

Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.

Olá

marciosantri:

Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.

Exatamente. Obrigado por traduzir o que eu disse e que talvez não tenha ficado claro.

A turma precisa lembrar em qual ano nós estamos. Até 2001, a arquitetura com tudo confinado na rede local era a última Coca-Cola do deserto. Hoje cheira mal em qualquer parte do mundo, mesmo na minha casa em Paraty, no meio da mata atlântica, só com acesso à Internet discada.

[]s
Luca

Luca:

Olá

marciosantri:

Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.

Exatamente. Obrigado por traduzir o que eu disse e que talvez não tenha ficado claro.

A turma precisa lembrar em qual ano nós estamos. Até 2001, a arquitetura com tudo confinado na rede local era a última Coca-Cola do deserto. Hoje cheira mal em qualquer parte do mundo, mesmo na minha casa em Paraty, no meio da mata atlântica, só com acesso à Internet discada.

Quer um exemplo? Dentre os novíssimos componentes SwingX, estão o JXLoginPanel e JXLoginDialog. E entre as classes envolvidas nesse processo está a JDBCLoginService que, como o nome já dá a entender, autentica um usuário se ele/ela conseguir se conectar ao banco de dados.

Também é possível utilizar JAAS para embasar o mecanismo de autenticação/autorização do software, que é flexível o suficiente para outras arquiteturas.

Olá

Exato. E pior: a Sun teima em chamar estes programinhas de aplicação desktop.

E estão trabalhando em componentes como aqueles antigos do Delphi que acessam banco de dados diretamente da tela.

A Sun continua gastando energia onde não deve. Se querem incentivar aplicações desktop competitivas, deveriam se concentrar em melhorar a API de impressão e a de conexão com dispositivos, onde o Java ainda continua perdendo de goleada para os concorrentes como o C# por exemplo.

Como eu estou cansado de dizer por aqui há muitos anos, Firefox, Firebird, Netbeans, Eclipse, Adobe Reader são aplicações desktop. E todos eles se conectam com a Internet.

Eu acho que se eu fosse desenvolver algo como um tocador de mp3, faria com que se conectasse à internet para baixar músicas. Mas se rodasse isolado como o Windows Media Player, jamais faria em Java.

E agenda sem que eu possa acessá-la de qualquer parte do mundo é pior do que meu celular. Justo agenda os “professores” dão como tarefa para os alunos fazerem programinhas Java desconectados.

[]s
Luca

Mas tem o lado bom, Luca.

O que o Michel disse é bem possível, e ainda podemos utilizar o HSQLDB ou o Derby/JavaDB para armazenar dados locais e trabalhar em cima deles off-line.

Se fizer o "dever de casa" direito, um software pode começar como

1. cliente -&gt servidor de banco de dados
   e evoluir para
2. cliente -&gt middleware -&gt backend.

Um exemplo de como isso pode ser útil (senta que lá vem históra):

Suponha que um micro-empresário possui quatro lojas espalhada por três cidades diferentes. Ele não tem um software que apóie o seu negócio - ou tem alguma coisa que não o faz direito - então é preciso percorrer todos os dias as 4 lojas, não necessariamente sozinho, para administrar o andar da carruagem.

Poderíamos ter um repositório central, um servidor de aplicativos que lida com esse banco de dados e diversos rich clients que acessam os componentes de negócio nesse middleware.

São diversos tipos de cliente: para ponto-de-venda, administração. Esse último, utilizado pelo empresário para acompanhar o estado global de seu empreendimento, em sua própria casa. (Imagine-se aí em Parati acompanhando vendas, custos, etc. numa loja no Rio, outras 2 em Sampa, outra no ABC. 8) ).

Mas é claro que isso tem um custo, e dificilmente esse empresário vai perceber que vale a pena. Então, como alternativa, pode ser sugerido a arquitetura 1 e direcionar esforços de venda para entregar ao cliente um software com a arquitetura 2.

Daí pra frente, quem sabe o software não se conecta com outros sistemas de informação, possivelmente de fornecedores. Dá até pra "empurrar" uma loja virtual…

Bem, se você estiver se referindo ao Beans Binding (JSR-295), eu não vejo isso dessa forma. Aliás, quando penso em bindings para Swing, como o do Genesis e do JGoodies, nem passa pela minha cabeça banco de dados e acredito que seja assim com a maioria dos desenvolvedores Swing.

A missão aqui é eliminar os maledetos métodos fireAlgumaCoisaMudou para amarrar dois widgets, como uma combobox e uma tabela, uma lista e um campo de texto. Usar observer pra isso é no mínimo massante.

[editado] Entenda eliminar no contexto do desenvolvedor. Eles estarão lá, mas não teremos mais que lidar com eles. [/editado]

Já o Databuffer é outra história e está relacionado com o que você está dizendo.

Até onde sei, esse projeto existe para aplicativos stand-alone, e não sistemas de informação. Se vão usar para isso (e vão), é outra história…

Luca:

A Sun continua gastando energia onde não deve. Se querem incentivar aplicações desktop competitivas, deveriam se concentrar em melhorar a API de impressão e a de conexão com dispositivos, onde o Java ainda continua perdendo de goleada para os concorrentes como o C# por exemplo.

Eu me pergunto sempre (em tom quase que deseperado): Porque, meu Deus, a Sun não dá moral pra essas coisas… Porque…

O módulo shared do genesis permite fazer isso sem mudar uma linha de código

mister__m:

RafaelRio:

O que o Michael disse é bem possível, e ainda podemos utilizar o HSQLDB ou o Derby/JavaDB para armazenar dados locais e trabalhar em cima deles off-line.

Se fizer o "dever de casa" direito, um software pode começar como

1. cliente -&gt servidor de banco de dados
   e evoluir para
2. cliente -&gt middleware -&gt backend.
   

O módulo shared do genesis permite fazer isso sem mudar uma linha de código :-)

Nesse caso eu teria os componentes de negócio dentro dos clientes, mesmo que executassem no servidor (ou estou viajando ?). O ideal não seria migrar esses componentes para o servidor, utilizando, talvez, EJB 3.0?

Só pra não fugir muito do tópico :lol:
se o banco for embarcado, eu uso HSQLDB; se não, PostgreSQL.

Exato.

Uma coisa interessante na arquitetura é que você pode continuar tendo lógica local nos seus objetos de negócio, i.e., métodos não-anotados com @Remotable. Assim, toda a lógica de negócios fica num lugar só.

No caso do genesis, por exemplo, em modo remoto os seus componentes são executados dentro de um Stateless Session Bean, sem que assim você esteja “amarrado” com essa tecnologia. Os aspectos permitem abstrair a tecnologia real usada debaixo dos panos para execução dos componentes, o que dá essa flexibilidade do modo local também.

Luca,

me desculpe ressucitar esse tópico, mas tive uma dúvida: TODOS os sistemas que tem acesso a um banco de dados devem possuir esse banco em outro lugar e acessar ele pela Internet? No caso, o BD poderia ficar num servidor na minha empresa e ele acessa a partir da empresa dele. Funcionaria assim? Se ele não tiver conexão com a Internet ele tá fudid* então? E o software funcionaria obrigatoriamente num navegador e mesmo assim utilizaria swing?

Boa noite colegas !

Acho que internet não pode ser considerado o unico meio para isso.
Acredito que existam sistemas de uso exclusivamente interno que não necessitam de acesso via internet, acho até que algumas coisas as próprias empresas nem querem que possam ser acessadas vai internet, mesmo porque isso sempre irá gerar um custo maior com segurança.
Mas o que acho que o Luca quis dizer é que mesmo em sistemas construidos em uma arquitetura considerada ultrapassada como cliente/servidor não é recomendável que o BD fique na mesma máquina que a aplicação por motivos como performance, segurança, politicas de backup, manutenção do BD, acesso por mais de um usuário.

Agora se você esta pensando em um sistema pequeno, controle de caixa de uma padaria, por exemplo, que vai ser instalado num único ponto, e que por limitações de custos ou outros, é conveniente que fique tudo numa máquina só… acho que é possível sim.

Claro, como disse estamos falando de um sistema pequeno, que pode até ser acessado por outra estação, mas que vai ter uma perfomance comprometida pela capacidade da máquina que hospeda aplicação e servidor de BD.

Quanto ao software acessando um BD em outra máquina poderia ser web ou swing, eu acho. Mas se for swing não seria executado dentro do navegador, mas como aplicação separada, com um .JAR em cada máquina.

Hehehehe… por favor comentem essa besteirada toda que falei !

[]s

Zeed,

Eu concordo com cada palavra que você disse, mas pelo visto é coisa do milênio passado

Abraço.

Bom dia colegas !

dedejava:

Acho que tem gente que ainda vai ganhar muito dinheiro com essas coisas do milênio.

Hehehe…

[]s

Poisé.

Acho que o Luca é uma delas