Java x Delphi para desenv. 2/3 camadas...desafio ao Java RAD

Programação Java
#1

Ola,

Tenho usado Java para desenvolvimento Web com Servlets
e Delphi para desenvolvimento realmente RAD para aplicacoes
C/S 2 e 3 camadas.

Ja olhei varios IDEs Java (JBuilder, JDeveloper, Eclipse, NetBeans,
Sun ONE, etc) mas duas coisas me causam preocupacao em afirmar
que elas sao realmente RADs:

  1. Desenvolvimento de interfaces pode ser chamado de SAD (Slow
    AD), pois é necessario escrever mais codigo e aquele esquema de
    layouts exige muito mais trabalho de design do que no Delphi. Tudo
    bem que podemos dizer que a visao do Java é muito mais ampla,
    multi-plataforma e tudo mais. Mas supondo que o objetivo é fazer
    uma aplicacao para Windows (digamos que a empresa nao vai usar
    Linux nas estacoes). Por que alguem faria em Java e nao em Delphi?

  2. Quando se analisa a questao no contexto de 3 camadas, a historia
    fica mais complicada ainda. No Delphi existem alguns componentes
    que deixam o desenvolvimento “mamao com acucar”, com os
    datawares na interface “thin-client” ligados a componentes de
    logica de negocio na “server-app”, que por sua vez estao ligados
    ao banco de dados.
    Apos analises em tudo que existe no Java, como EJB, Corba, RMI,
    JBoss, Hibernate, Torque, etc, etc, etc, achei que é necessario se
    programar MUIIIIITO mais do que no Delphi, e mesmo assim nao
    existem componentes “mastigados” para fazer, por exemplo, os
    “thin-clients”. Posso estar errado, mas faz uns 15 dias que tenho
    pesquisado na Internet, em sites, listas, newsgroups, e nao vejo
    nada que torne o desenvolvimento 3 camadas Java tao produtivo
    quanto o Delphi.

Gostaria que as pessoas que tem mais experiencia com Java para
desenvolvimento de aplicacoes comerciais me dessem uma ideia
se estou errado nisso mesmo ou nao, realmente o Java é bem
mais improdutivo que o Delphi.

#2

Edilmar, eh preciso separar as coisas. No Delphi, temos uma IDE e uma linguagem (ObjectPascal). Em Java, temos a linguagem, claro, mas ela nao depende de nenhuma IDE. Por isso, temos uma penca de IDEs, proprietarias ou nao.

Comparando apenas as linguagens, eu nao consigo pensar em nenhum motivo pra achar ObjectPascal mais produtivo do que Java. Delegates, talvez, mas eles nao fazem essa falta toda. E, pelo amor de deus, uma linguagem de tipagem forte criada ha menos de 10 anos sem excecoes checadas? ARGH! :smiley:

Agora, vamos ao seu ponto: IDEs. Se voce quer editor de tela, entao concordo, as IDEs que temos hoje pra Java sao uma bosta, mas vc nao pode julgar produtividade da plataforma toda soh pelo editor visual ou pelo monte de componentes do tipo arraste-o-Internet-Explorer-pro-formulario-e-faca-seu-proprio-browser.

Talvez Java nao seja a tecnologia ideal pra vc (afinal, se vc so quer desenvolver em Windows, nao se importa muito com OO e/ou nao esta muito ai pra robustez ou escalabilidade, pra que vc escolheu Java? :)). Mas isso nao significa que ela nao tenha meritos. Editores de telinha nao sao um deles, so isso.

#3

Ola CV,

A questao principal é a segte: imagine fazer um sistema comercial comum, tipo Controle de Contas a Pagar e Receber, Controle de Estoque, etc. Estes sistemas basicoes, quando feitos em Delphi, ficam prontos mais rapidos que feitos em Java (usando qualquer IDE). O meu maior dilema é descobrir uma forma de ter produtividade na criacao de telas, manipulacao de eventos, criacao de relatorios, etc.

Como em qq sistema, os usuarios de sistemas comerciais estao sempre no “nosso pé”, querendo sempre tudo pronto o mais rapido possivel, e sem bugs! Entao, por tudo que tenho desenvolvido com Delphi e com Java (usando JBuilder, Netbeans, etc), percebo que existem varios componentes no Delphi “mastigados” que nao encontro no Java. Nao estou comparando as linguagens em si, pois a linguagem Java é EXCEPCIONAL! Estou sim comparando IDEs e componentes “mastigados” que possam facilitar o nosso trabalho de desenvolvimento.

Resumindo, a pergunta principal é a segte: tenho componentes “mastigados” que facilitem o desenvolvimento de sistemas com bancos de dados, para telas de cadastro, consulta e geracao de relatorios, todos os componentes devidamente “dataware” como tem no Delphi? E para 2 camadas e 3 camadas?

#4

Minha opiniao…

Acho que vc deve desenvolver seu próprio framework.

Estou desenvolvendo um sistema em J2EE com clientes magros em Swing, (Não é tão magro assim, ainda tem alguns problemas com performance), desenvolvemos o próprio framework conforme as nossas necessidades.

Procure aplicar as boas práticas no desenvolvimento.

T+

#5

Eu tendo a concordar aqui, apesar de achar que esta ainda nao eh a melhor solucao. Criar seu proprio framework, a medida em que vc vai desenvolvendo, eh otimo, e costuma “se pagar” conforme o numero de projetos que vc vai fazendo. O ruim aqui eh que ate hoje nao se chegou a um consenso sobre um framework pra trabalhar com Swing que funcione bem em todos os casos - por isso nao tem nenhum na API hoje…

Uma ideia seria usar o XWork com ClientDispatcher, mas, ainda assim, tem muito trabalho a se fazer :wink:

#6

[quote=“edilmar”]Ola CV,

A questao principal é a segte: imagine fazer um sistema comercial comum, tipo Controle de Contas a Pagar e Receber, Controle de Estoque, etc. Estes sistemas basicoes, quando feitos em Delphi, ficam prontos mais rapidos que feitos em Java (usando qualquer IDE). O meu maior dilema é descobrir uma forma de ter produtividade na criacao de telas, manipulacao de eventos, criacao de relatorios, etc.

Como em qq sistema, os usuarios de sistemas comerciais estao sempre no “nosso pé”, querendo sempre tudo pronto o mais rapido possivel, e sem bugs! Entao, por tudo que tenho desenvolvido com Delphi e com Java (usando JBuilder, Netbeans, etc), percebo que existem varios componentes no Delphi “mastigados” que nao encontro no Java. Nao estou comparando as linguagens em si, pois a linguagem Java é EXCEPCIONAL! Estou sim comparando IDEs e componentes “mastigados” que possam facilitar o nosso trabalho de desenvolvimento.

Resumindo, a pergunta principal é a segte: tenho componentes “mastigados” que facilitem o desenvolvimento de sistemas com bancos de dados, para telas de cadastro, consulta e geracao de relatorios, todos os componentes devidamente “dataware” como tem no Delphi? E para 2 camadas e 3 camadas?[/quote]

Primeiro tem que se lembrar que java ate pouco tempo atras não focava o mercado de software corporativo, que é o único nicho onde o delphi possui algum valor.

A Sun resolveu mudar isso com o Project Rave, que faz exatamente aquilo que voce quer, desenvolver 99% da aplicação no clica-arrasta-empurra. Se lembro bem ele deve ser lançado por volta de q3/2004.

Alem disso existem algumas empresas que oferecem produtos que aceleram absurdamente o desenvolvimento do tipo de software que voce quer. Uma, por exemplo, é a Unify, tem um software para sistemas j2ee com clientes web.

Foi a questão levantada pelo cv, java nunca teve como objetivo ser uma plataforma para RAD. Voce provavelmente vai estar melhor servido usando VB/Delphi no windows.

#7

AHA! Pegou no calcanhar de aquiles da coisa. Pq ninguem usa C++ pra fazer sistemas de controle de estoque? Pela mesma razao que eh “ruim” usar Java: as plataformas nao foram feitas pra se desenvolver aplicacoes comerciais. Da pra fazer? Claro que dah, mas voce vai ter o trabalho de desenvolver uma aplicacao… erhm, com o perdao da palavra, simples, usando um conjunto de bibliotecas muito “baixo-nivel” (layout managers, por exemplo, nao fazem o menor sentido num controle de estoque, certo?).

Muitas vezes, usar Swing ou SWT dao a impressao de se estar trabalhando com a GDI ou com um socket direto no X Server, e eu ateh entendo que isso seja desejavel ou necessario em muitas situacoes. Mas so atrapalha quem vai fazer o controle de estoque :wink:

PS: deus do ceu, comprei uma briga gigantesca agora…

#8

Olá pessoal,

Hum… o conceito é bom, mas é arriscado. Se você faz as coisas com pressa a chance de erros nos programas, duplicação de código, erros nas rotinas de testes, erros em análise, gambiarras, aumentam consideravelmente.

O que eu acho é que o Delphi e essas ferramentas RAD, conduzem usuários inexperientes a programar “rápido” deixando de lado questões importantes como OO, Design Patterns, etc…

E como todo o bom programa, um dia ele ficará grande demais para essa arquitetura, e terá que ser reescrito. Aí começam os problemas.

Trabalho na mesma empresa do lcmetzger e como ele já falou, temos o nosso pŕoprio framework, com atribuições e qualidades específicas para nós. E aqui, todas as telas, são feitas na UNHA. É claro, que criamos uma série de facilidades para as criações, mas o usuário escreve tudo.
O usuário, quando faz uma tela, não pensa na lógica da aplicação, mas sim na lógica de apresentação, em outro passo ele colocará lógica de negócios em objetos de negócios.

Resultado disso? Uso total da OO. E com isso, muitos bugs são resolvidos.

Bom ou ruim, garantimos um software robusto e de qualidade.

#9

eu também trabalho muito com Delphi, fazendo esses sistemas de controles de estoque, vendas, etc etc etc.

o lance é o seguinte.

Você tem que saber qual tecnologia usar em determinada situação!!!

Se você vai desenvolver um sistema desktop para Windows, sistema simples, que irá rodar sozinho, sem comunicação com outros sistemas, use DELPHI!!!

Agora se você quer algo maior, com mais segurança, com muito mais tecnologia envolvida, com trocas de mensagens entre vários sistemas, com servidor robusto, até mesmo sendo um cluster de servidores de aplicação, etc etc etc, é Java na cabeça.

Não é porque Java é isso, ou é aquilo, que deve ser usado em todos os tipos de softwares. Antes de mais nada, devemos olhar a necessidade do cliente, e ae sim, escolhermos nossa ferramenta de desenvolvimento.

Aquela velha frase: Porque matar uma formigua com uma bazuca?

#10

[quote=“ManchesteR”]
Aquela velha frase: Porque matar uma formigua com uma bazuca?[/quote]

Nesse caso o mais correto seria: Porque usar armas biológicas quando voce quer explodir um prédio?

#11

Valeu, pessoal! :smiley:

Entendi a ideia… para sistemas comerciais digamos “mais comuns”, o negocio é usar RADs como Delphi, etc. A grande sacada foi uma das msgs que falou que ninguem usa C++ para um sistema desses, pois o trabalho é grande, e com o Java a ideia é a mesma!

Por enqto, para estes tipos de sistemas vou ficar com o Delphi mesmo e usar o Java apenas em aplicacoes Web com Servlets.

E aguardar ansiosamente IDEs como o Projeto Rave, para substituir em definitivo o Delphi, pois gosto muito da robustez e da codificacao em Java, e espero no futuro estar full-time somente com ela!

#12

Bom, pra nao deixar passar em branco, a Droga Raia tem o sistema de frente de caixa ( alias, acho que ate a parte “por tras de tudo” tambem ) feita em Java.

Rafael

#13

Eu vi uma rede de drogaria aqui do Rio (não lembro o nome) que o sistema era Web em JSP.

[]'s

#14

Eu desenvolvi uma metodologia para desenvolver em NETBEANS, utilizando swing em duas camadas, e que ficou bastante produtivo. É óbvio que em Delphi, desenhar os formulários é bem mais rápido, mas com a pratica você consegue ser produtivo no NETBEANS. Com isso consegui desenvolver uma aplicação PDV (ponto de venda), que imprime em impressoras fiscais (daruma e bematech) e TEF (transferência eletrônica de fundos). O sistema ficou bem rápido e fácil de operar. Testei esta aplicação com os seguintes banco de dados : MSSQLServer 7.0, PostgreSQL 7x, Firebird 1.5.

O segundo passo é substituir a camada de persistência que criei, pelo framework Hibernate (ainda estou pesquisando).

O terceiro passo, é mover as regras de negócios para a camada intermediária, onde a camada view poderá ser swing ou web. Neste caso, não sei se é viável utilizar um servidor de aplicação tipo JBOSS, ou criar um framework próprio (ainda estou pesquisando).

O quarto e último passo, seria desenvolver uma ferramenta para auxiliar no desenvolvimento da GUI (swing/web), classes de negócios e persitência e dados. A idéia é o analista crie uma base de conhecimento, durante o processo de análise, e com isso já vai desenhando as GUI, classes de negócios, normalizando a base de dados e depois mapear para o hibernate. Eu já tenho algo parecido para DELPHI.

A vantagem desse trabalho, é que não vou ficar amarrado em JBUILDER, ECLIPSE,NETBEANS, etc.

Eu programo em Delphi desde a primeira versão, o que posso dizer é que é uma ferramenta interessante, já vi grandes projetos sendo feito com ela. Eu estou programando em JAVA faz uns 6 meses, o que posso dizer é o seguinte “Estou vislumbrado com o potencial da linguagem JAVA, e não pretendo voltar para o Delphi”. Eu sei que tenho que absorver muitos conhecimentos tipo : desenho de padrões, etc. Mas dentro em breve, estarei tão produtivo qto em Delphi.

#15

Trabalho com pascal desde o Turbo Pascal 6, passei por todas as versões do Delphi, e nos ultimos 3 anos tenho trabalhado principalmente com Java/J2EE.

Posso te mostrar algumas opções, mas não sei se vai ser as melhores pra você. :wink:

[quote]Quando se analisa a questao no contexto de 3 camadas, a historia
fica mais complicada ainda. No Delphi existem alguns componentes
que deixam o desenvolvimento “mamao com acucar”, com os
datawares na interface “thin-client” ligados a componentes de
logica de negocio na “server-app”[/quote]

Quando trabalhei com Delphi em multicamadas, achei isso fantástico. Hoje percebo que há um grande erro conceitual na maneira que vc faz aplicações multicamadas em Delphi.

Se vc usar os componentes do Delphi (RemoteDataModule, Provider, ClientDataSet), tem uma DLL que faz toda a mágica pra vc, mas te deixa extremamente preso.

O Cliente fica extremamente acoplado ao servidor, de maneira que a menor mudança no servidor requer mudanças no client. preso às mudanças do servidor. Se vc mudar o nome de um atributo em uma tabela, terá que ir para o Client, apagar o nome antigo, importar o atributo com o nome novo, mudar os componentes na tela do clientee tal. Ter uma aplicação client que dependa da implementação do servidor é o fim da picada. Um Business Delegate (J2EE pattern) resolveria isto , mas aí vc não teria a vantagem do RAD, pois teria que escrever código.

O Delphi gera um arquivo TLB binário que somente a IDE do Delphi consegue entender. Em java é tudo declarado em um XML.

Se vc usa DCOM/COM+ a dor de cabeça com segurança é terrível, começa a história de se está em redes diferentes, vc tem que confiar uma na outra, etc (muitas coisas de Microsoft para funcionar).

Seu servidor deve ser uma máquina Windows :frowning:

e por aí vai …

No final das contas, muita coisa que um container J2EE (segurança, transações, pooling) te oferece vc tem que implementar quando usa aplicações multicamadas em Delphi vc tem que fazer na unha (a não ser que aceite como suficiente o que o COM+ faz). Tá aí um ponto que vc pode tirar proveito em produtividade.

A respeito de um ambiente RAD, se vc usa drag-and-drop de campos da tabela para a tela (arrastador de componentes) vc vai ganhar algum tempo a mais. O que leva tempo não é a camada de apresentação, mas a implementação das regras de negócio, e estas sendo em Delphi ou Java, inevitavelmente vc tem que cair no código. Não custa muito codificar um pouco a mais para pegar os dados do BD e entregar para o cliente de uma maneira padronizada, e o cliente pegue estes dados e apresente-os na tela, independente da camada de apresentação que vc esteja usando (desktop, web, etc).

Se quiser um servidor que atenda a quantidade de requisições que for necessário vá para J2EE, e se precisar de um programa Delphi que acesse as regras de negócio embutidas neste servidor, implemente uma classe intermediária em Delphi para se comunicar com o servidor e use o protocolo que vc achar mais confortável e que vc aceite o custo de performance. Tenho usado WebServices quando preciso que uma aplicação Delphi use regras de negócio q estão em um servidor J2EE. É a integração mais “mamão com açúcar”, mas tem problemas com performance. O pessoal daqui decidiu aceitar este custo, então como não quero me preocupar em ter que ficar programando uma ponte mais elegante em Delphi (quero java pô), faço assim para ficar livre disso o mais rápido possível :wink:

Tá bom, este post já ficou muito longo

[]s, Welington B. Souza

#16