Ricardo e Marcio,


    Concordo plenamente com a opinao do Ricardo.
    Estou desenvolvendo um sistema em java e inicialmente
    usei o Visual Cafe, depois passei para JBuilder2.0 ( Copia para avaliacao)
    voltei para o visual cafe apos o prazo de avaliacao do JBuilder2.0.

    Recuzei-me a utilizar os componetes premoldados existentes nos RADs,
    Eles normalmente usam uma abordagem de duas camadas
    acessando diretamente Tabelas nos SGBDs e acabam introduzindo
    alguns conceitos proprietarios que fazem com que seu sistema so funcione
    em conjunto com outros produtos do fornecedor do RAD - o que ja foi muito bem
    descrito pelo Ricardo.

    Eu necessitava de um isolamento total entre camada visual e de logica de negocio e 
que nao
    me amarrasse a ninguem.

    Colocar logica de negocio dentro de tratamento de eventos dos objetos
    visuais como a maioria dos RADs nos induzem a fazer nao considero uma boa 
politica. 
    O reuso, a manutenibilidade e flexibilidade sao normalmente muito agredidos.
    Sem falar na introducao de codigo frequentemente desnecessario a essencia dos 
sistemas,
    deixando a aplicacao maior e memos performatica. 

    A computacao distribuida, que e o futuro na minha opinao, exige de todos nos uma
    nova postura frente ao desenvolvimento. O reuso de codigo nao acontece por acaso
    ou simplemente pelo fato de estarmos utilizando uma linguagem Orientada a Objetos.
    O reuso deve ser pensado desde o inicio, na construcao de servicos genericos 
    que sejam disponibilizados via RMI/CORBA/DCOM... de forma cooperativa.
    Nada impede que um objeto seja provedor de alguns servicos e concomitantemente seja
   usuario dos servicos de outro.  As aplicacoes GUI que interagem com os usuarios 
finais
    seriam tambem usuarias destes servicos. Lancariam mao dos mesmos para 
    implementar as funcionalidades desejadas: popular os objetos visuais com os 
dados/informacoes
   adequados, persistir dados alterados / inseridos, etc.
  
    Bom, isto e apenas a minha opiniao e a coloquei aqui na lista apenas para 
compartilha-la, Ok?

   Atenciosamente,


Helio Rugani Brandao
Arquitetura de Sistemas e Tratamento da Informacao -
Telemar-MG - Tel.: 229-3243
mailto:[EMAIL PROTECTED]



 

    
 

----- Mensagem original -----
De:             ricardo [SMTP:[EMAIL PROTECTED]]
Enviada em:             Sexta-feira, 3 de Dezembro de 1999 9:46
Para:           Valverde, Marcio; [EMAIL PROTECTED]
Assunto:                Re: [SouJava-J] Ferramenta RAD para Java - JBUILDER

----- Original Message -----
From: Valverde, Marcio <[EMAIL PROTECTED]>


>
> Ricardo,
>
>
> Gostei de sua explanacao sobre o assunto em discussao, eu adiquiri
> rescentemente o JBuilder 3 Professional ( Inprise ) e gostaria de saber
sua
> opiniao sobre esta ferramenta, estou iniciando nela e tenho medo de nao
ter
> feito a melhor escolha !!
>
> Um grande abraco
>
> Marcio Valverde


Marcio,

Usar ou nao usar uma ferramenta RAD e uma questao de estilo de trabalho.
O JBuilder, entre as ferramentas que eu ja pude ver, e uma das melhores
ferramentas do mercado para quem quer usar RAD.

Agora se voce quer saber a minha opiniao sobre RADs, ai vai:

De todas as ferramentas RAD que ja vi, todas elas geram codigo pobre no que
diz respeito a interfaces graficas... Nao que o codigo nao funcione. Eu
tambem pouco me preocupei em analisar a performance do codigo gerado. O
problema, na minha opiniao e um so SUJEIRA.
Na minha opiniao o que faz de um design um BOM design sao ORGANIZACAO e
LIMPEZA.
Veja bem, porque o paradigma OO e tao util? Muitos podem erguer a mao e
gritar, REUSO... Tudo bem, reuso e legal, mas o que existe de melhor em OO e
a organizacao. OO permite que voce decomponha e organize seu codigo em
unidades logicas desacopladas. Se voce organizar bem seu codigo, tera mais
facilidade em lidar com ele. Por isso existem varios design patterns, que
ajudam a fazer uma boa organizacao do seu design.
No que diz respeito a codigo, a limpeza e fundamental na minha opiniao, por
isso tendo a rejeitar codigo gerado... Eles geralmente tem comentarios
especificos para a ferramenta geradora, ou no minimo, sao muito mais
complexos do que o codigo que voce escreveria para resolver o problema, pois
o codigo e gerado para o caso mais generico...

Alem disso, existe um negocio chamado flexibilidade e customizacao. Se voce
quer permitir que seu usuario customize seu software, voce provavelmente nao
encontrara apoio de nenhuma ferramenta na hora de escreve-lo. (Exemplo: Uma
GUI que o usuario possa configurar)

A coisa vai muito do perfil da aplicacao e do desenvolvedor. Se voce
desenvolver sempre pensando que VOCE tera de fazer alteracao no codigo, que
o software tera de evoluir, que talvez mais de um cliente use o software e
voce tenha de customizar algumas coisas..., voce provavelmente optara por
codigo flexivel escrito a mao ao inves de codigo gerado por ferramenta RAD.

Esse negocio de RAD e na verdade um problema gerencial. O gerentes dos
projetos querem que eles fiquem prontos logo e a um custo baixo... Mas e
quanto a qualidade, manutencao, etc...? E falta de visao.

Mas o meu maior medo em incentivar o uso de RAD, e que o desenvolvedor recem
chegado que usava VB, queira programar em Java, como fazia em VB ou Delphi,
ou sei la o que... Se fizer isso, ja era! Nada mudou, pode voltar pra
plataforma anterior... O legal de java, nao e so a portabilidade. E O
CONCEITO! COMPUTACAO DISTRIBUIDA!!!!

Por favor, nao facam programas que acessem diretamente um DB, pensem em
OBJETOS. Criem sempre uma camada de servicos, seja ela usando EJB, CORBA,
JINI, RMI, ... mas criem sempre uma camada de objetos. COMPUTACAO
DISTRIBUIDA e o FUTURO, nao, ja e o PRESENTE

Quanto a camada de servico, aconselho o uso de EJB com container managed
persistence e container demarked transaction. E mais simples de programar e
mais flexivel. Pense sempre em flexibilidade.



Ricardo Munhoz Santiago
Sun Certified Programmer for the Java 2 platform

Come and get some !!!


    --------------------------- LISTA SOUJAVA ---------------------------
    http://www.soujava.org.br  -  Sociedade de Usuarios Java da Sucesu-SP
    [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
    ---------------------------------------------------------------------

    --------------------------- LISTA SOUJAVA ---------------------------
    http://www.soujava.org.br  -  Sociedade de Usuários Java da Sucesu-SP
    [para sair da lista: http://www.soujava.org.br/forum/cadastrados.htm]
    ---------------------------------------------------------------------

Responder a