A minha opiniao eh parecida com a maioria das pessoas. Um software de
qualidade, principalmente os de grande porte, deve ser independente do
banco de dados, da ferramenta RAD, da interface grafica e de qualquer
outra coisa que alguem possa imaginar. O valor esta na camada de negocio.
Um padrao de projeto que busca separar interface do usuario ( seja ela
grafica, textual, pelo telefone - homebanking - ou o que seja ) eh o
Model-View-Control, que separa a camada de negocios da interface e ainda
divida a interface em controle e visao. Normalmente o controle eh sempre o
mesmo ( a forma como o usuario navega pelo sistema ). O que pode mudar eh
a forma como a interface eh mostrada para o usuario.
Dois artigos interessantes falando sobre separacao de interface e negocios
sao os seguintes:
Understanding JavaServer Pages Model 2 architecture
http://www.javaworld.com/javaworld/jw-12-1999/jw-12-ssj-jspmvc.html
e
Building user interfaces for object-oriented systems
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox_p.html
E vamos continuar a discussao sobre desenvolvimento de software que ela eh
importante.
Abracos,
Eduardo da Fonseca Melo
DI - UFPE
www.di.ufpe.br/~efm
On Fri, 3 Dec 1999, Helio Rugani Brandao wrote:
> 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]
> ---------------------------------------------------------------------
>
>
--------------------------- 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]
---------------------------------------------------------------------
