É se você usar DBControls ligados diretamente a camada de persistência realmente é errado.
Mas quem disse que não existe outra maneira de fazer isso?
Ligando os DBControls ao seu modelo?
Acho que o problema de usar IDE´s RAD como Delphi, Netbeans, Visual Studio etc é o fato de deixar o programador preguiçoso. Acaba fazendo as coisas sem saber o que realmente acontece. Esses dias peguei um cara programando JSF com o Visual Web Pack do netbeans e o cara nem fazia idéia do que era um Managed Bean.
Nunca vou usar uma ferramenta cujo código gerado por ela não posso alterar. Nunca.
Não confio em tecnologias que são complexas demais para serem usadas sem um editor visual. Se é necessário um punhado de wizards para conseguir trabalhar com o treco, eu passo.
[quote=LIPE]Nunca vou usar uma ferramenta cujo código gerado por ela não posso alterar. Nunca.
Não confio em tecnologias que são complexas demais para serem usadas sem um editor visual. Se é necessário um punhado de wizards para conseguir trabalhar com o treco, eu passo.[/quote]
Bom… ae nao eh questão de “ser complexo demais”… e sim questão de performance… ler um XML é MUITO mais rapido que interpretar o codigo linha a linha…
questão de opção… preferem gastar menos memoria… mas se vc quiser usar eclipse amanhã… nada impede… o codigo vai funcionar…
A questão é… Tela em 90% dos casos nao tem o que “refatorar” , é tela… usando matisse vc faz rapidinho outra… é besteira deixar de lado 500% a mais de produtividade só prq vc nao consegue alterar o codigo na munheca…
Fora que se vc usar as propriedades no painel do lado vc consegue mudar MUITA coisa… praticamente tudo… consegue inclusive adicionar codigos antes e depois de cada componente… acho que isso é mais do que suficiente…
Fora que conforme a evolucao das tecnologias o Matisse até que te ajuda… ex: se vc usar JDK 1.5 ele usa o GroupLayout com uma biblioteca externa… se vc usar JDK 1.6 ele converte para GroupLayout do proprio JDK… sem ter que ficar se acabando…
[quote=Avante]
Acho que o problema de usar IDE´s RAD como Delphi, Netbeans, Visual Studio etc é o fato de deixar o programador preguiçoso. Acaba fazendo as coisas sem saber o que realmente acontece. Esses dias peguei um cara programando JSF com o Visual Web Pack do netbeans e o cara nem fazia idéia do que era um Managed Bean.
Onde está o erro? na IDE ou no programador?
[]´s[/quote]
E assim o mercado java vai ficar cheio de programadores, a IDE facilita o desenvolvimento, daqui a pouco vai ter nego fazendo CRUD completo com transações e segurança sem sequer saber o que é Hibernate
Na web é a mesma coisa, vai chegar uma hora que nego diz ser programador JSF por clicar na tabela do lado esquerdo do Netbeans (no Data Navigation), arrastar pra um table e dizer “sou programador web master fucking”
Se é pra discutir, vamos discutir algo que seja mais produtivo… :lol:
Aos que falam mal de Delphi: teve seu tempo, foi uma excelente ferramenta (tanto a linguagem, que é totalmente orientada a objetos, quanto ao RAD). Simplesmente desmerecer algo que era bom, talvez antes de você começar a programar, é tolice…
Aos que defendem o Delphi: programei em Delphi desde a segunda versão e percebi o seu declínio desde a quinta (ou quarta) versão… não conseguiu acompanhar as mudanças (como um dia o Java também não vai conseguir…), perdeu o foco, e se f****. E um grande problema de ferramentas que facilitam muito a vida dos programadores é que a média dos desenvolvedores nestas ferramentas se tornam mediocres, são ótimos pra arrastar-e-soltar… no mundo java o cenário é bem melhor.
Programar é profissão, não religião… Ok, Delphi tá morto, mas ainda tem gente que ganha dinheiro com Cobol, Clipper… e aí?
Hoje programo 100% do meu tempo com Java e curto muito isso, todas as necessidades que tenho hoje, Java resolve de forma bem melhor que Delphi. Isso é verdade pra mim, pode não ser pra outros… e ponto.
Estranho, todo mundo usa hibernate porque é pratico, economiza tempo em não ter que ficar fazendo toda aquela parafernália via JDBC, e ninguém reclama.
Realmente esse argumento já deu o que tinha que dar. Aliás, eu acho que o código nem deveria existir já que as telas seriam baseadas em resources.
Programariamos apenas o modelo.
[/quote]
Como assim resources?
Não deveria existir código pra tela?..e assim nascerão vários programadores q não sabem nem o q é um gerenciador d layout…[/quote]
Resources nao quer dizer que nao vai existir codigo de tela… mas sim que nao vai ser CODIGO JAVA. eh uma outra forma de expressar o posicionamento de objetos em tela… Matisse jah faz isso… ele tem seu .form… porem gera codigo java para poder funcionar em qualquer IDE…
E quanto a nao saber sobre layouts… eu nao tenho uma opiniao bem formada… mas acho que para QUE ficar complicando a vida ? pra que ficar programando na mao uma coisa que PODE SIM ser automatizada e as vezes quase eliminada ? Programadores sao pagos para programar coisas mais importantes que perder 30 anos em cima de uma tela de cadastro… dificilmente telinha é o que importa em um sistema hoje em dia…
Realmente esse argumento já deu o que tinha que dar. Aliás, eu acho que o código nem deveria existir já que as telas seriam baseadas em resources.
Programariamos apenas o modelo.
[/quote]
Como assim resources?
Não deveria existir código pra tela?..e assim nascerão vários programadores q não sabem nem o q é um gerenciador d layout…[/quote]
