Boa tarde pessoal recebi a missão de migrar um sistema comercial (Vendas, Finanças) de Delphi para J2EE mais como ainda não tenho muito dominio sobre os diversos Frameworks existentes e possibilidades que o mundo JAVA oferece estou meio perdido na minha escolha.
Pretendo continuar utilizando este layout no projeto em J2EE também.
Já verifiquei que com TILES eu consigo manter este layout, está é a melhor opção ? Velocity pode me ajudar em alguma coisa ?
Já tenho um certo conhecimento em Struts estou pensando em continuar utilizando ele porque seria mais facil e rapido pra mim… mais também me vem a cabeça se devo partir logo para EJB ou não…
Resumindo estou pensando em utilizar o seguinte:
Struts
Velocity
Hibernate
Tomcat
Eclipse
Hibernate-tools
Sysdeo, Lomboz, JBoss-IDE… qual melhor opção rssss ?
Bom como devem ter percebido to meio perdido mais acho que é normal no Delphi era bem mais simples esse tipo de escolha rsss
é realmente necessário fazer a interface web? Não compensa o tempo de estudo para fazer a interface em Swing ou semelhantes? Mais robusto, confiável e bonito.
quando começar a pensar em EJBs, tenha certeza que você precisa deles. Sua aplicação contém muita lógica de negócios? Ou é só um “front end para a database”? Os servidores são distribuídos? Ou fica tudo numa máquina só?
Minhas sugestões caso resolva seguir o caminho que indicou:
Se tiver tempo para estudar, use WebWork.
Use Jetty ao invés do Tomcat. Simplesmente melhor e mais rápido.
Sobre Velocity eu uso, gosto e recomendo. Mas pelo que olhei por aí o FreeMaker parece uma opção mais cheirosa, mas não posso dizer muito, pois não usei ainda.
Mas opinião pessoal:
Pela telinha que você mostrou, parece que swing é mais interessante!!! Daí vc pode usar o Java Web Start para iniciar a aplicação mesmo à partir de um brownser!!!
Se tiver se ser web, então meu conselho é vc usar Hibernate dependendo do tamanho da aplicação. Webwork e Struts caem bém (O pessoal aqui curte bastante webwork… e muitos não suportam e odeiam Struts… pense nas probres foquinhas…).
Se sua aplicação for distribuiída, pense um milhão de vezes antes de usar EJB! Provavelmente um container leve como Spring ou PicoContainer poderá ser mais que suficiente para resolver seus problemas!!!
Vocês tem mania de desvalorizar a interface web.
Dá para fazer interfaces web completamente confiáveis, bonitas, leves
e simples.
No caso de interface não é a escolha do framework que irá determinar
como ela ficará, mas o seu conhecimento em tecnologias client-side como
html, javascript,css,etc.
É lógico que os frameworks ajudam se possuem components server-side de view.
dê uma olhada no struts-layout, uma extensão pouco divulgada do struts que fornece components server-side para criar treeviews, listviews, grids e ainda ajuda na criação do layout, dispensando você do conhecimento das tecnologias cliente-side. http://struts.application-servers.com/
Já interfaces web ficarem iguais a interfaces desktop e compátives a maioria dos browsers.
jprogrammer, não sei quanto a você, mas todos os projetos que me envolvi até o anterior ao atual optamos por interfaces web, com HTML ou XUL.
E neste último estamos desenvolvendo com Swing. Não tem como comparar. Nada de refreshs e redirects. Componentes que são objetos de verdade, e não tags <inputs>. E o melhor: sem protocolo http. Só por isso já é infinitamente superior na minha opinião.
Na verdade acontece o contrário… Todo mundo só que saber de fazer na WEB e esquece de recursos swing, que dependendo do caso, seria o ideal para satisfazer a necessidade de nosso amigo!
O que quero ressaltar que com a tecnologia client-side que temos hoje, não precisamos mais ficar dando refresh, redirects.
É lógico que vocês vão falar: mas é usando gambiarra.
Mas o que importa é para o usuário. O que ele vê.
Gosto do swing, mas temos que pensar que podemos ter máqunas com pouco poder de processamento como client.
XMLHttpRequest não é gambiarra (pelo menos já é uma gambiarra oficial e documentada).
HTTP não foi feito para criar aplicativos, foi feito para compartilhar documentos em hypertext. Esse é o problema. Você notou que existem vários métodos não usados no HTTP? É por isso.
Aliás, um protocolo web novo e desenhado apra isso faria um bem grande.
Máquinas menos possantes para rodar a aplicação client???
Não… esse não é o principal problema…
O Swing não é o principal problema pelo mau desempenho das aplicações. É claro que swing não vai rodar em um 486… mas as maioras das máquinas que temos por ai roda swing …
Que adianta vc ter uma máquina rodando um cliente super rapidamente e a parte server ser super lerda??? Nem interface no modo texto deixia a aplicação mais rápida.
O que vai definir o sucesso do projeto não é apenas o que o cliente vê, e sim quanto ele terá que esperar para receber a resposta do sistema!!!
Mas a tecnologia server do java (JSP/Servlets) bem aplicada contribui para o bom desempenho da aplicação.
Não é por ser web que ficará lenta, mesmo tendo um processamento
centralizado.
Outra vantagem da interface web é portabilidade para máquinas
que não possuem JVM.
Já tive problemas no windows XP. Não era permitido instalar mais nada.
Cada cliente tem seu gosto.
Discordo completamente desta afirmação. Manter toneladas de código em JavaScript é uma desgraça, por mais cuidado que a equipe tenha ao desenvolver. Isso é amenizado com o Firefox e seu JavaScript debugger, mas ainda assim é muito dolorido. Claro que é muito importante o resultado final, mas não é tudo.
Já tentou rodar o Firefox ou a última versão do IE num computador com 16 de ram? Concordo que dependendo do tipo de aplicação uma interface HTML é mais leve, mas nem sempre.
Além do que o shoes falou, eu fico muito irritado todos os dias quando me vejo lidando com um monte de texto ao invés de Objetos. Frameworks jogam perfume na merda, mas como diz o cv, continua sendo merda. Existem protocolos de comunicação muito melhores que http para desenvolver aplicações. Como disse o shoes, ele é bom para fazer o que se presta: enviar documentos. Se posso usar estes outros protocolos, por que não?
No mais concordo com as suas observações, contudo os prós de desenvolver aplicações utilizando Objetos e não texto e tags html superam dificuldades decorrentes da instalação a JVM nos clientes.
