cassio wrote:

marciosantri wrote:Pelo menos vc tem a "vantagem" (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

O desenvolvimento é para consumo interno, "produto caseiro". Digamos que o preço está incluso em meu salário

Minha dúvida é em como fazer a integração entre o que está pronto em Java com o que já existe com o Qt. Para uma nova tela em Java, por exemplo, abriria a mesma através da criação de um novo processo no Qt? Ficaria lento eu acho.... e cada tela minha precisaria ter um main()...
Pelo menos até migrar tudo...

Idéias?

Obrigado a todos pelas respostas!

louds wrote:Reescrever o sistema TODO é loucura. É jogar muito dinheiro no ralo. Já pensaram em utilizar uma solução híbrida? Mantenham a aplicação como está, e embutam o runtime de uma linguagem moderna, desenvolvam as novas features usando esta linguagem e, por fim, vão migrando as funcionalidades antigas conforme for surgindo oportunidade.

Migrar tudo é uma enorme burrada, vai custar uma fortuna, vai criar uma enormidade de bugs novos, vai descontentar todos stack holders pois verão pouco retorno nesse investimento. Utilize Java ou .NET embarcado, vai ser muito mais prático. Você pode utilizar, por exemplo, o qtsharp para facilmente fazer a aplicação em código gerenciado conversar com o QT, com Java vai ser via a tortura do JNI. De uma olhada em como embutir o mono, uma implementação open source do .net, você vai ficar surpreso em como é simples e leve - diferente do JRE da Sun.

marciosantri wrote:

cassio wrote:

marciosantri wrote:Pelo menos vc tem a "vantagem" (isso depende do ponto de vista) de parte da
regra de negócios estar no banco de dados. Facilita qualquer conversão.

Ao contrário de que disseram por aqui, não acho que uma aplicação Web tenha
mais recursos que uma desktop e sim o contrário. Ainda acho browser muito lento
mesmo com Ajax e se for uma aplicação para rede fechada não tem porque a
obrigatoriedade. Mas é uma possibilidade.

Se for migrar, sugiro que vá fazendo o que for surgindo de novo no Java (se for
a linguagem escolhida) e ir fazendo pouco a pouco as funcionalidades já
existentes. Sem traumas.

Este tipo de processo deve custar uma nota. O cliente está disposto a pagar?

O desenvolvimento é para consumo interno, "produto caseiro". Digamos que o preço está incluso em meu salário

Minha dúvida é em como fazer a integração entre o que está pronto em Java com o que já existe com o Qt. Para uma nova tela em Java, por exemplo, abriria a mesma através da criação de um novo processo no Qt? Ficaria lento eu acho.... e cada tela minha precisaria ter um main()...
Pelo menos até migrar tudo...

Idéias?

Obrigado a todos pelas respostas!

Eu não faria integração entre programas. Pegaria uma funcionalidade do programa e a faria
totalmente no Java, sem dependências do Qt.
A maneira de fazer os sistemas conversarem é o banco de dados.
Por exemplo: um cadastro de clientes que chama umas 2 ou 3 telas. Não fique chamando
as telas do Qt, faça-as completamente no Java. Facilita seus testes e essa rotina não
precisará ser "ajustada" posteriormente.

marciosantri wrote:Agora entendo melhor seu problema. Realmente telas muito dependentes são complicadas
de manter ainda mais de migrar. Eu nunca mexi com QProcess. Ao que me consta não é uma
biblioteca da MicroSoft? A troca de informações do QProcess entre os programas garante
que o que sair de um lado vai chegar EXATAMENTE do outro? Digo isso porque já tive problemas
com ferramentas do tipo, lembrando que não sei quase nada (ou nada) de QProcess.