Bacana a iniciativa,parabéns!!!
Mas,qual a necessidade de EJB?
[quote=MarkKnopfler]
Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).
Com relação ao peso da aplicação, se eu fizer com EJB (que já falaram que é uma boa escolha), vou ter o servidor de aplicação (Glassfish, JBoss, sei lá). Se eu fizer com o Spring (container, Remote, integração com Hibernate, etc.), aí dá-lhe JAR! É uma opinião nesse sentido que eu quero. Permitam-me detalhar melhor:
- Priorizarei interface Desktop, a interface já está compilada, o servidor nem terá o trabalho de gerar HTML. Se eu resolver disponibilizar algo para os alunos em web, acho que posso fazer na forma de webservices (ex.: REST) e meu PHPzão acessa os serviços
- Leveza: o que é mais leve, os jars do Spring ou o servidor Java EE com EJB?
- Curva de aprendizado: comprei o livro de Spring do Kico, gostei d+++, mas queria algo sobre o Remote. Baixei a apostila de EJB da K-19 e vou estudá-la. Lembrem-se que estou fazendo isso para aprender como se faz na ralação mesmo![/quote]
Desculpe acho que vc esta fazendo algumas confusões, adicionar meia dúzia de jars a mais ou a menos não vai ser o determinante pra uma aplicação ser rápida ou lenta, vc esta falando em escolher uma arquitetura baseado em ter que colocar um jar a mais, estamos em 2013, 1GB de ram vem de troco no mercado. Não existe isso de Java puro ou não, uma plataforma se integra com diversas tecnologias, e conhecer pelo menos a mais usadas no mercado é nosso dever, um pouquinho de html e css não vai fazer vc não ser programador Java.
EJB + Spring + Swing + REST + PHPzão… percebe o tamanho da gambiarra que vc esta se enfiando? A quantidade de coisas que vc vai ter que manter, evoluir e integrar?
Se tu faz web, é uma vez só pra tudo, atualizou uma vez todo mundo já tem acesso, pode acessar local, remoto, na lua, em marte, com ipad, sem instalar nada, sem peso nenhum pro cliente. Em swing vc ainda obrigado o cara instalar o Java na máquina, que é cheio de bugs de segurança e é um pé no saco pra end user ficar atualizando, tem que pensar tbm nas atualizações desse cliente swing, como vai garantir que TODOS estão usando a última versão?
Se não conhece nada de JSF, não faça em JSF, vai ficar lento do mesmo jeito, e como já falaram, a culpa será do JSF, não é só arrastar um componente bonitinho e ta tudo pronto e maravilhoso, tem que conhecer a arquitetura, como ela funciona, os componentes, claro que isso vc estudando um pouco já consegue se virar sozinho, nada impede.
Essa é apenas MINHA opinião e visão do seu projeto, boa sorte, seja como definir fazer, e coloque suas dúvidas conforme surgirem.
[]s
É só vc configurar para ele não fazer redeploy toda vez que vc salvar algum arquivo da sua aplicação…
+1
[quote=Luiz Aguiar][quote=MarkKnopfler]
Porque possivelmente terá alguma coisa acessível pela web (ex.: serviços aos alunos).
Com relação ao peso da aplicação, se eu fizer com EJB (que já falaram que é uma boa escolha), vou ter o servidor de aplicação (Glassfish, JBoss, sei lá). Se eu fizer com o Spring (container, Remote, integração com Hibernate, etc.), aí dá-lhe JAR! É uma opinião nesse sentido que eu quero. Permitam-me detalhar melhor:
- Priorizarei interface Desktop, a interface já está compilada, o servidor nem terá o trabalho de gerar HTML. Se eu resolver disponibilizar algo para os alunos em web, acho que posso fazer na forma de webservices (ex.: REST) e meu PHPzão acessa os serviços
- Leveza: o que é mais leve, os jars do Spring ou o servidor Java EE com EJB?
- Curva de aprendizado: comprei o livro de Spring do Kico, gostei d+++, mas queria algo sobre o Remote. Baixei a apostila de EJB da K-19 e vou estudá-la. Lembrem-se que estou fazendo isso para aprender como se faz na ralação mesmo![/quote]
Desculpe acho que vc esta fazendo algumas confusões, adicionar meia dúzia de jars a mais ou a menos não vai ser o determinante pra uma aplicação ser rápida ou lenta, vc esta falando em escolher uma arquitetura baseado em ter que colocar um jar a mais, estamos em 2013, 1GB de ram vem de troco no mercado. Não existe isso de Java puro ou não, uma plataforma se integra com diversas tecnologias, e conhecer pelo menos a mais usadas no mercado é nosso dever, um pouquinho de html e css não vai fazer vc não ser programador Java.
EJB + Spring + Swing + REST + PHPzão… percebe o tamanho da gambiarra que vc esta se enfiando? A quantidade de coisas que vc vai ter que manter, evoluir e integrar?
Se tu faz web, é uma vez só pra tudo, atualizou uma vez todo mundo já tem acesso, pode acessar local, remoto, na lua, em marte, com ipad, sem instalar nada, sem peso nenhum pro cliente. Em swing vc ainda obrigado o cara instalar o Java na máquina, que é cheio de bugs de segurança e é um pé no saco pra end user ficar atualizando, tem que pensar tbm nas atualizações desse cliente swing, como vai garantir que TODOS estão usando a última versão?
Se não conhece nada de JSF, não faça em JSF, vai ficar lento do mesmo jeito, e como já falaram, a culpa será do JSF, não é só arrastar um componente bonitinho e ta tudo pronto e maravilhoso, tem que conhecer a arquitetura, como ela funciona, os componentes, claro que isso vc estudando um pouco já consegue se virar sozinho, nada impede.
Essa é apenas MINHA opinião e visão do seu projeto, boa sorte, seja como definir fazer, e coloque suas dúvidas conforme surgirem.
[]s[/quote]+1
eu acho que foi por isso que ele descartou o JSF de bate pronto. [=
Pessoal, eu ainda estou só escolhendo o que vai ser usado!
Pra começar, uma das minhas primeiras escolhas é entre EJB x Spring. Ou seja, não pretendo usar os 2 juntos. Estava lendo um material sobre EJB, mas acho que Spring vai se encaixar melhor. Comparando os JARs deles e outros + que eu vier a usar (Hibernate, por exemplo), vai ser realmente bem + leve do que o servidor!
Para a parte que será em web, Rest foi uma opção para eu poder integrar com o legado, que é feito em PHP. Mas pelas considerações colocadas pelos colegas, eu posso optar sim por um JSF sem problemas.
Sim, estou considerando todas as tecnologias citadas. Talvez eu falando “escolhi Swing por isso, isso, e aquilo”, o pessoal entende “não, eu quero fazer com Swing e pronto”. Bem, estou sim (ainda) com muita vontade de fazer em desktop pelas razões que eu citei, mas a parte que vai ser na web eu ainda não bati o martelo. O JSF está na minha lista de estudos aqui, só tenham calma que é muita coisa rsrsrsrs
O objetivo maior é meu aprendizado, não mais que isso. Ainda estou aprendendo, não sei o que é melhor para esse projeto e por isso estou pedindo a opnião de vcs. Atender pura e simplesmente a necessidade da escola, eu atenderia com Delphi, PHP, Java desktop com Swing, Java web com VRaptor, Turbo Pascal ou QuickBasic. Não importa se a tecnologia é antiga ou nova, o cara tem que conhecer profundamente, e esse é meu objetivo, ganhar vivência com alguma tecnologia que ainda desconheço. Não pretendo desenvolver com o Delphi até o dia q eu morrer.
[quote=MarkKnopfler]Fala-se muito mesmo que interfaces desktop estão sendo deixadas de lado em favor de interfaces web. E sim, a interface do meu sistema não será 100% desktop, mas onde se aplicar eu prefiro esta por n razões:
[/quote]
As suas razões, são as razões erradas 
Então vejamos. Java FX , é padrão SE no java 7 (se não está usando o java 7 o que vc está fazendo ?) Tem suporte no netbeans. O lookand feeel é CSS.
[quote]
Como complemento à questão do design, a interface web vira uma salada de linguagens: HTML, CSS, JavaScript… o objetivo é usar Java, compilado em .class! Acho que isso tudo tem lugar quando o objetivo é fazer um site mesmo, divulgação para o público. Já tenho site, passei o link. É básico, mas está lá e funciona. Feito em PHP mas com uma boa arquitetura (podem me bater, mas eu gosto mais de PHP do que de Java para fazer aplicaçòes web! E está na minha agenda aprender o Ruby on Rails, ô linguagenzinha boa dimái da conta o Ruby!)
O meu foco é resolver o problema da escola, e uma aplicação tradicional janelinha-menu-botão me permite ir + direto ao ponto.[/quote]
Veja bem, implementar swing remoto não é trivial. Nada trivial. Hoje em dia nem sequer é aconselhado. hoje em dia se quer desktop use JavaFX com JWS. JWS é que é o segredo. Ainda para mais se o seu sistema vai ter uma parte web, vai ser ainda mais fácil integrar o JWS. Mas não é trivial.
Se o seu sistema tem uma parte web porque não tudo web ? É um desperdício usar duas tecnologias. Não é DRY. E vc não apresentou uma razão real para usar desktop. Pense melhor.
Hoje em dia tem tecnologias web que são tão faceis de programar quanto desktop e têm look and feel e tudo isso. Dê uma olhada no Vaadin e no ZK. É muito mais melhor bom que swing. Eu adoro swing, veja bem, mas hoje, é muito trabalho. Uma opção (se insiste no swing) é usar o projeto Griffon. É em groovy feito pelo pessoal do spring source e é equivalente ao rails/grails para desktop.
Eu usaria Vaadin rodando em tomcat e spring. É mais do que suficiente. Dá um look bem Desktop sem ser. A Web já torna o sistema distribuido por natureza.
Mas detalhes, o Vaadin é para o backoffice. Para o front-office vc pode usar o Spring MVC. e achar complicado use o Vaadin apenas onde for fortemente orientado a cadastros.
Cara vc esta comprando jars? Qual projeto tem mais ou menos? Desculpe mas está tudo errado isso, precisa rever seus conceitos sobre desenvolvimento Java pra poder sim aprender o máximo possível com esse projeto e pode usar esse aprendizado profissionalmente depois, nunca vi nenhum material didático sobre Java usar alguma abordagem como essa.
Veja que a maioria dos amigos aqui já experiente esta lhe dizendo que o caminho que vc esta indo não é a opção “correta”, mas óbvio que fica a seu critério decidir o que fazer, mas avalie a ajuda que estão lhe oferecendo.
[]s
Entendi, o que eu estava querendo no início é isso mesmo. Sugestões de tecnologias. O Herbert deu a dica do JSF e o Sérgio, do JavaFX/JWS/Vaadin/Griffon (q tanto!). Eu já sei da existência do JavaFX, mas não sabia que ele é padrão no Java SE 7. Sim, estou usando o Java 7. Eu não sabia que Swing é ruim assim para acesso remoto, mas eu consegui acessar sem grande dificuldade (claro, apanhei um pouco para pegar as manhas, mas uma vez aprendido foi blz). Com relação a não ser trivial, não se preocupe, eu estou querendo é apanhar um pouco mais com tecnologias novas, acho que depois de umas boas leituras vc tem que ralar pondo a mão na massa.
A questão é que, debate-vai-debate-vem, o que era para virar um filtro de opções acaba abrindo mais opções ainda. Juro que queria ter tempo para ler sobre tantas coisas, mas eu preciso fazer alguma coisa aqui.
Bem… agradeço de coração a todos pelos toques, vou dar mais umas estudadas e pesar prós e contras. Daqui pra frente é por minha conta, logo estarei postando uns protótipos no GitHub. Abraços
[editando]Eu quis dizer comparando o “peso” desse conjunto de jars e o peso de um servidor Java EE. Os jars me parecem mais leves.[/editando]
[quote=MarkKnopfler]Entendi, o que eu estava querendo no início é isso mesmo. Sugestões de tecnologias. O Herbert deu a dica do JSF e o Sérgio, do JavaFX/JWS/Vaadin/Griffon (q tanto!). Eu já sei da existência do JavaFX, mas não sabia que ele é padrão no Java SE 7. Sim, estou usando o Java 7. Eu não sabia que Swing é ruim assim para acesso remoto, mas eu consegui acessar sem grande dificuldade (claro, apanhei um pouco para pegar as manhas, mas uma vez aprendido foi blz). Com relação a não ser trivial, não se preocupe, eu estou querendo é apanhar um pouco mais com tecnologias novas, acho que depois de umas boas leituras vc tem que ralar pondo a mão na massa.
[/quote]
Vc fala que não é problema apanhar. Ok. então faça em C++ :twisted:
Vc quer aprender. Tudo bem. Mas suponho que tb queira um negocio funcionando. Senão, what’s the point ?
Veja que as tecnologias mencionndas se excluem mutuamente. Não é JavaFX e JWS e Vaadin e Griffon . É JavaFX + JWS ou Vaadin ou Griffon.
Swing não é ruim. É que não é o futuro. O futuro é JavaFX. Griffon é uma casca que permite vc programar sem saber se é swing ou swt. Vc escreve um codigo mais agnóstico. Mas ainda vai gerar um desktop no final. É uma forma de acelerar o processo, é uma ferramenta. Se vc quer aprender do zero, não vale a pena aprender swing porque está obsuleto. Eu sei swing, então para mim é mais dificil usar javafx que tenho que aprender do que usar algo que conheço. Mas para vc , deveria escolher o que é novo.
O swing não é ruim para acesso remoto. Ele não faz acesso remoto. É vc que tem que criar esse design . O swing é só a UI. Mas num sistema cliente=servidor, o cliente é mais que a UI. Ele contém logicas para comunicar com o servidor. Seja qualquer o protocolo.
Existem padrões antigos e existem padrões modernos. Porque vc vai perder tempo aprendendo o antigo ? Não é mais eficaz aprender o que é moderno ? Por exemplo, pq usar RMI se pode usar REST ? Ninguem programa sockets mais, se usam tecnologias de mais alto nível. Quanto mais alto mais simples.
Por ordem de simplicidade e parta do principio que as opções são excludentes
Só Web
MVC modelo 2 : Spring MVC ou algum outro framework web + Spring IoC + Web container (tomcat) + JSP. Simples. O problema é que tem que ser mais ou menos bom de html e css.
MVC modelo 3 : JSF + CDI + Web container (tomcat). Simples. O problema é que tem que ser mais ou menos bom de html e css e JSf é mais complexo que JSP e MVC, mas também não é nada do outro mundo.
Tendencia : Vaadin + Spring IoC + web container. Não precisa programa html nem css nem javascript. É tudo java. Só java. Os padrões são os mesmos usados no swing , swt e outros frameworks dektop. Então isso lha dá um conhecimento de como seria a UI do desktop, mas sem o problema de criar todo o protocolo de comunicação. O ZK é uma opção ao Vaadin. Ai é questão de gosto, talvez…
Desktop sem web
Cliente : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : JEE . Uso de EJB remote para a comunicação.
Desktop com web
Cliente : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : Web container. Uso de REST para a comunicação.
Desktop com web + Modulo de acesso pelo Browser
Cliente Desktop : JavaFX para a UI + Spring IoC para organização + JWS para distribuição. Servidor : Web container. Uso de REST para a comunicação.
Cliente Browser :um de “Só Web”
Existem realmente muitas opções. Vc poderia aprender todas e decidir depois. Mas pragmaticamente isso é impossível. Aliás, por isso que vc veio perguntar aqui. A principio eu lhe diria para usar o que já conhece,mas como não conhece nada, então esse conselho não serve. Então o próximo passo é : exclua o que é velho. O que é mais novo é mais dificil. Vc vai encontrar menos ajuda na net. Mas sendo que vc quer ralar, isso é o ideal para vc.
Independentemente da tecnologia pense na aquitetura e no design primeiro. Depois escolha a tecnologia que mais o ajudar a montar seu design. Tenha em mente que numa aplicação distribuída cada nodo tem as mesmas camadas que o outro, mas não necessariamente implementadas da mesma forma. as camadas padrão são
Cliente UI (a parte que realmente integra com o usuario e ele vê. Por ser o swing, o swt, o jvafx, o html , etc…) Vc tem que usar uma tecnologia para pegar os gestos e itenções do usuário e devolver a informação.
Apresentação. Esta parte é independente do Cliente. Então, qualquer cliente deve encaixar nesta camada. Esta camada contém as regras de apresentação. Navegação, desabilitação, foco, mensagens popup, etc… e delegação à camada de baixo
Dominio. Aqui estão as regras verdadeiras que podem ser chamadas de diferentes apresentações em diferentes clientes e nodos. É o core. É o sistema realmente dito.
Integração. Chamadas as outros nodos. Ao sistema de arquivos. Ao OS. Ao banco de dados. No servidor isto é normalmente a ligação ao banco. No cliente isto é a ligação ao servidor.
Recursos. Isto são os dados em si. Arquivos de configuração. Arquvios de imagem. Bancos de dados. Indexes do lucene. etc… Algums dados têm que viajar de nodo para nodo, outros não.
Não é apenas uma questão tecnológica. É uma questão de design. Por isso que eu falei que as suas razões eram erradas. Vc quer abraçar o mundo. Não precisa.
Comece por baixo. Veja funcionando. Depois vc expande. Por exemplo, o desktop é muito legal e pode paracer que vai dar uma melhor user experience , mas qual é a razão real para usar desktop ? Hoje em dia web faz tudo que o desktop faz e é muito mais rápido de criar. Tem que haver uma razão para ir para o desktop. Sem ela é tudo um exercício fútil. uma razão que eu sempre penso é integração com periféricos. Impressora, scanner, essas coisas. Se isso é necessário então o desktop é mais recomendado, de fato. Mas a pergunta tem que ser : preciso mesmo disso ?
Apanhar pra aprender, não pra fazer rsrsrsrs! Lógico que eu quero um negócio que, uma vez aprendido, me permita trabalhar com mais fluidez.
E tb só listei os exemplos de tecnologias q vc mencionou, não quer dizer que vou usar tudo junto!
Mas eu gostei das suas sugestões, era exatamente o que eu gostaria de saber. Só falar “o seu está errado, usa X que é melhor” não me convence, vc foi o primeiro a categorizar e embasar as opções de uma maneira bem didática. Pelas suas colocações, interessei-me pelo JavaFX. Ele me permitiria então criar interfaces tanto desktop sem quanto com web, segundo sua lista.
Só que eu já conheço alguma coisa sim, embora pouco. Com meus conhecimentos atuais, eu sou capaz de desenvolver em MVC Web Modelo 2 e em DSCG (Desktop Swing Cliente Gordo), que eu quero evitar.
Às vezes eu acho difícil conversar com o pessoal aqui, pq eu falo X e interpretam Math.pow(X * melancia, 1/2). Vou tentar falar numa linguagem q vcs entendem:
Forum forum = GUJ.getForum();
Tecnologia[] interfaces = forum.perguntaPraGalera(TecnologiaInterface.class);
Tecnologia[] iocs = forum.perguntaPraGalera(TecnologiaInversaoDeControle.class);
Tecnologia[] persistencia = forum.perguntaPraGalera(TecnologiaPersistencia.class);
Tecnologia[] distribuicao = forum.perguntaPraGalera(TecnologiaDistribuicao.class);
// Aqui algoritmo para decidir-se entre as tecnologias de distribuição
TecnologiaDistribuicao escolhiDistribuicao = ... ;
TecnologiaInterface escolhi = null; // Ainda não me decidi ;)
for (TecnologiaInterface i: interfaces) {
if ( i.pareceDesktop() && i.facilDeIntegrarComDistribuido(escolhiDistribuicao)) {
escolhi = i; // É esta ;)
break;
}
}
Acho que vcs interpretaram q eu quero aprender Swing tb. Swing eu já sei, quero aprender a fazer aplicações distribuídas e com uma arquitetura pelo menos com IoC.
[quote=MarkKnopfler]
Acho que vcs interpretaram q eu quero aprender Swing tb. Swing eu já sei, quero aprender a fazer aplicações distribuídas e com uma arquitetura pelo menos com IoC.[/quote]
Tecnologias para distribuição também ha várias. tudo depende do tipo de interação que o servidor vai ter com o cliente. Hoje com websockets e tal é bem mais fácil que antigamente.
Eu fi uma vez uma aplicação swing com jws com servidor jboss ejb 2.1 que usava serialização via http( e não rmi para poder passar por firewalls) e JMS. O JMS era para o servidor poder enviar eventos para o cliente.
Se vc precisa de enviar eventos para o cliente é um tipo de distribuição , se não, é outro. Existem tecnologias como JXTA para distemas distribuidos em clusters ou do tipo emule/kazaa.
Um problema que eu tinha era com os dados e a latência da rede. Tive que incluir um mecanismo de cache do lado do cliente.
Hoje não sei se faria isso. É muito complexo. Demasiado complexo. O Browser é cada vez mais o cliente por default e hoje em dai com mobile é mais simples. Claro que uma aplicação nativa é mais bonita e tal, mas acho que web pode ser bem bonito também. Não é só porque o desktop não tem CSS e vem com o llok and feel que todos os problemas de grafismo estão resolvidos. Um designer é sempre bom. Em qualquer plataforma. E se manjar de UX ainda melhor.É isso que realmente faz a diferença. Colocar o componentna tela é fácil. Colocá-lo no lugar certo que é dificil