Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
sim, fiz tudo... usei BDE...
criei NEW CONNECTION, dei um EDIT, selecionei STANDARD (piradox), mandei gravar
no PATH c:\, Show Build, SELECT ALL BUILT DATABASE...
Sim, fiz tudo começei a cadastrar, fones, cadastrei a cidade normal... só que
quando vou dar OK em um dos dois que te falei deu este erro...
Luiz Escobar
Analista/Desenvolvedor:
WEB - HTML/JavaScript/PHP/MySQL
WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase
DOS - Clipper/Assembler xBase
SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k
LINUX - LAZARUS/Kylix/MySQL;
http://www.megasistema.com.br
- Original Message -
From: Joao Morais
To: delphi-br@yahoogrupos.com.br
Sent: Thursday, December 07, 2006 7:38 AM
Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz Escobar wrote:
Baixei, criei tudo bzl.. durante o cadastro seja pessoa ou compania da o
seguinte erro:
troque os 'X9s' pelos respectivos codigos dos object ehheehe...
Error storing object TPerson('x9x9x9'): Field 'Address' not found
Error storing object TCompany('x9x9'): Field 'Address' not found
Qual banco? Você executou o Build-Show Build Sequence-Build Database?
--
João Morais
[As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
o zeos ai do exemplo serve para MySQL 5.0.21 ou superior ??? Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Thursday, December 07, 2006 3:39 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Luiz Escobar wrote: sim, fiz tudo... usei BDE... criei NEW CONNECTION, dei um EDIT, selecionei STANDARD (piradox), mandei gravar no PATH c:\, Show Build, SELECT ALL BUILT DATABASE... Sim, fiz tudo começei a cadastrar, fones, cadastrei a cidade normal... só que quando vou dar OK em um dos dois que te falei deu este erro... hmmm... foi mal Luiz. A culpa é do meu modelo, do jeito que ele está não aceita flat table. Tem que ser um conector SQL. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Bom gente não sei o que esta acontecendo, a pagina esta lá, testei de casa SPEEDY, e na empresa onde tenho dois links SPEEDY e VIRTUA nos tres teste apareceu... Esta imagem foi para ilustrar o que o CAMPOS me perguntou, porque não faço OPEN/CLOSE/REFRESH na tabela, CASO, eu vá cadastrar um cliente onde não existe a cidade no banco de cidade, tendo que abrir outro FORM para cadastrar e ter que dar um REFRESH ou CLOSE/OPEN para atualizar a tabela como ambos os FORM´s usando o mesmo componente TTABLE, nao a necessidade de se dar um REFRESH pois cadastrou os dados estão lá claro, se o cadastro da cidade for feito por outro .EXEcutavél ou por outra maquina, ai na maquina/.EXEcutavél onde estou cadastrando o cliente teria OBRIGATORIAMENTE dar um REFRESH ou (melho) CLOSE/OPEN pois as vezes o REFRESH não REFRESca nada... ;-) Olha que a imagem é meio grande 1600x1200 - 341Kb umas pequenanissima descrição... http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Valfrid-Ly Silva Couto Tentando abrir a imagem: Fora do ar Esta página está fora do ar Provavelmente, o autor do site ainda não fez a publicação das páginas nos nossos servidores. Tente novamente outra hora. Luiz Escobar [EMAIL PROTECTED] escreveu: Uai... aqui pra ieu aparece Olha que a imagem é meio grande 1600x1200 - 341Kb http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor:
Res: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Eu tb não sei, mas no endereço que vc passou eu estou vendo a seguinte mensagem:
http://img99.imageshack.us/my.php?image=erroij1.jpg
Mas se quiser, sugiro que poste esta imagem lá no www.imageshack.com
- Mensagem original
De: Luiz Escobar [EMAIL PROTECTED]
Para: delphi-br@yahoogrupos.com.br
Enviadas: Quarta-feira, 6 de Dezembro de 2006 14:06:29
Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Bom gente não sei o que esta acontecendo, a pagina esta lá, testei de casa
SPEEDY, e na empresa onde tenho dois links SPEEDY e VIRTUA nos tres teste
apareceu...
Esta imagem foi para ilustrar o que o CAMPOS me perguntou, porque não faço
OPEN/CLOSE/REFRESH na tabela, CASO, eu vá cadastrar um cliente onde não
existe a cidade no banco de cidade, tendo que abrir outro FORM para
cadastrar e ter que dar um REFRESH ou CLOSE/OPEN para atualizar a tabela
como ambos os FORM´s usando o mesmo componente TTABLE, nao a necessidade de
se dar um REFRESH pois cadastrou os dados estão lá claro, se o cadastro
da cidade for feito por outro .EXEcutavél ou por outra maquina, ai na
maquina/.EXEcutavé l onde estou cadastrando o cliente teria OBRIGATORIAMENTE
dar um REFRESH ou (melho) CLOSE/OPEN.. .. pois as vezes o REFRESH não
REFRESca nada... ;-)
Olha que a imagem é meio grande 1600x1200 - 341Kb
umas pequenanissima descrição...
http://luizescobar. brlog.info
só a imagem...
http://paginas. terra.com. br/informatica/ radios/imagem. JPG
Luiz Escobar
Analista/Desenvolve dor:
Luiz Escobar
Analista/Desenvolve dor:
- Original Message -
From: Valfrid-Ly Silva Couto
Tentando abrir a imagem: Fora do ar
Esta página está fora do ar Provavelmente, o autor do site ainda não fez a
publicação das páginas nos nossos servidores.
Tente novamente outra hora.
Luiz Escobar [EMAIL PROTECTED] .com.br escreveu: Uai... aqui pra ieu
aparece
Olha que a imagem é meio grande 1600x1200 - 341Kb
http://luizescobar. brlog.info
só a imagem...
http://paginas. terra.com. br/informatica/ radios/imagem. JPG
Luiz Escobar
Analista/Desenvolve dor:
!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;
}
#ygrp-vital{
background-color:#e0ecee;
margin-bottom:20px;
padding:2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size:77%;
font-family:Verdana;
font-weight:bold;
color:#333;
text-transform:uppercase;
}
#ygrp-vital ul{
padding:0;
margin:2px 0;
}
#ygrp-vital ul li{
list-style-type:none;
clear:both;
border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;
color:#ff7900;
float:right;
width:2em;
text-align:right;
padding-right:.5em;
}
#ygrp-vital ul li .cat{
font-weight:bold;
}
#ygrp-vital a {
text-decoration:none;
}
#ygrp-vital a:hover{
text-decoration:underline;
}
#ygrp-sponsor #hd{
color:#999;
font-size:77%;
}
#ygrp-sponsor #ov{
padding:6px 13px;
background-color:#e0ecee;
margin-bottom:20px;
}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;
margin:0;
}
#ygrp-sponsor #ov li{
list-style-type:square;
padding:6px 0;
font-size:77%;
}
#ygrp-sponsor #ov li a{
text-decoration:none;
font-size:130%;
}
#ygrp-sponsor #nc {
background-color:#eee;
margin-bottom:20px;
padding:0 8px;
}
#ygrp-sponsor .ad{
padding:8px 0;
}
#ygrp-sponsor .ad #hd1{
font-family:Arial;
font-weight:bold;
color:#628c2a;
font-size:100%;
line-height:122%;
}
#ygrp-sponsor .ad a{
text-decoration:none;
}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;
}
#ygrp-sponsor .ad p{
margin:0;
}
o {font-size:0;}
.MsoNormal {
margin:0 0 0 0;
}
#ygrp-text tt{
font-size:120%;
}
blockquote{margin:0 0 0 4px;}
.replbq {margin:4;}
--
___
Você quer respostas para suas perguntas? Ou você sabe muito e quer compartilhar
seu conhecimento? Experimente o Yahoo! Respostas !
http://br.answers.yahoo.com/
[As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! OFF
Do RS. Funcionou...na segunda tentativa.. Cara...hein...muito show tua área de trabalho...poh... Atenc. Elazar -Mensagem original- De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Luiz Escobar Enviada em: quarta-feira, 6 de dezembro de 2006 14:06 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Bom gente não sei o que esta acontecendo, a pagina esta lá, testei de casa SPEEDY, e na empresa onde tenho dois links SPEEDY e VIRTUA nos tres teste apareceu... Esta imagem foi para ilustrar o que o CAMPOS me perguntou, porque não faço OPEN/CLOSE/REFRESH na tabela, CASO, eu vá cadastrar um cliente onde não existe a cidade no banco de cidade, tendo que abrir outro FORM para cadastrar e ter que dar um REFRESH ou CLOSE/OPEN para atualizar a tabela como ambos os FORM´s usando o mesmo componente TTABLE, nao a necessidade de se dar um REFRESH pois cadastrou os dados estão lá claro, se o cadastro da cidade for feito por outro .EXEcutavél ou por outra maquina, ai na maquina/.EXEcutavél onde estou cadastrando o cliente teria OBRIGATORIAMENTE dar um REFRESH ou (melho) CLOSE/OPEN pois as vezes o REFRESH não REFRESca nada... ;-) Olha que a imagem é meio grande 1600x1200 - 341Kb umas pequenanissima descrição... http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Valfrid-Ly Silva Couto Tentando abrir a imagem: Fora do ar Esta página está fora do ar Provavelmente, o autor do site ainda não fez a publicação das páginas nos nossos servidores. Tente novamente outra hora. Luiz Escobar [EMAIL PROTECTED] escreveu: Uai... aqui pra ieu aparece Olha que a imagem é meio grande 1600x1200 - 341Kb http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: ___ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
vou fazer isso, obrigado pela dica... esta porcaria do TERRA, deve estar
sobrecarregado e da essas desculpas...
Luiz Escobar
Analista/Desenvolvedor:
- Original Message -
From: Ricardo Cesar Cardoso
To: delphi-br@yahoogrupos.com.br
Sent: Wednesday, December 06, 2006 4:39 PM
Subject: Res: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Eu tb não sei, mas no endereço que vc passou eu estou vendo a seguinte
mensagem:
http://img99.imageshack.us/my.php?image=erroij1.jpg
Mas se quiser, sugiro que poste esta imagem lá no www.imageshack.com
- Mensagem original
De: Luiz Escobar [EMAIL PROTECTED]
Para: delphi-br@yahoogrupos.com.br
Enviadas: Quarta-feira, 6 de Dezembro de 2006 14:06:29
Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Bom gente não sei o que esta acontecendo, a pagina esta lá, testei de casa
SPEEDY, e na empresa onde tenho dois links SPEEDY e VIRTUA nos tres teste
apareceu...
Esta imagem foi para ilustrar o que o CAMPOS me perguntou, porque não faço
OPEN/CLOSE/REFRESH na tabela, CASO, eu vá cadastrar um cliente onde não
existe a cidade no banco de cidade, tendo que abrir outro FORM para
cadastrar e ter que dar um REFRESH ou CLOSE/OPEN para atualizar a tabela
como ambos os FORM´s usando o mesmo componente TTABLE, nao a necessidade de
se dar um REFRESH pois cadastrou os dados estão lá claro, se o cadastro
da cidade for feito por outro .EXEcutavél ou por outra maquina, ai na
maquina/.EXEcutavé l onde estou cadastrando o cliente teria OBRIGATORIAMENTE
dar um REFRESH ou (melho) CLOSE/OPEN.. .. pois as vezes o REFRESH não
REFRESca nada... ;-)
Olha que a imagem é meio grande 1600x1200 - 341Kb
umas pequenanissima descrição...
http://luizescobar. brlog.info
só a imagem...
http://paginas. terra.com. br/informatica/ radios/imagem. JPG
Luiz Escobar
Analista/Desenvolve dor:
Luiz Escobar
Analista/Desenvolve dor:
- Original Message -
From: Valfrid-Ly Silva Couto
Tentando abrir a imagem: Fora do ar
Esta página está fora do ar Provavelmente, o autor do site ainda não fez a
publicação das páginas nos nossos servidores.
Tente novamente outra hora.
Luiz Escobar [EMAIL PROTECTED] .com.br escreveu: Uai... aqui pra ieu
aparece
Olha que a imagem é meio grande 1600x1200 - 341Kb
http://luizescobar. brlog.info
só a imagem...
http://paginas. terra.com. br/informatica/ radios/imagem. JPG
Luiz Escobar
Analista/Desenvolve dor:
!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99%
arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;
}
#ygrp-vital{
background-color:#e0ecee;
margin-bottom:20px;
padding:2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size:77%;
font-family:Verdana;
font-weight:bold;
color:#333;
text-transform:uppercase;
}
#ygrp-vital ul{
padding:0;
margin:2px 0;
}
#ygrp-vital ul li{
list-style-type:none;
clear:both;
border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;
color:#ff7900;
float:right;
width:2em;
text-align:right;
padding-right:.5em;
}
#ygrp-vital ul li .cat{
font-weight:bold;
}
#ygrp-vital a {
text-decoration:none;
}
#ygrp-vital a:hover{
text-decoration:underline;
}
#ygrp-sponsor #hd{
color:#999;
font-size:77%;
}
#ygrp-sponsor #ov{
padding:6px 13px;
background-color:#e0ecee;
margin-bottom:20px;
}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;
margin:0;
}
#ygrp-sponsor #ov li{
list-style-type:square;
padding:6px 0;
font-size:77%;
}
#ygrp-sponsor #ov li a{
text-decoration:none;
font-size:130%;
}
#ygrp-sponsor #nc {
background-color:#eee;
margin-bottom:20px;
padding:0 8px;
}
#ygrp-sponsor .ad{
padding:8px 0;
}
#ygrp-sponsor .ad #hd1{
font-family:Arial;
font-weight:bold;
color:#628c2a;
font-size:100%;
line-height:122%;
}
#ygrp-sponsor .ad a{
text-decoration:none;
}
#ygrp-sponsor .ad a:hover{
text-decoration:underline;
}
#ygrp-sponsor .ad p{
margin:0
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! OFF
Bom pelo menos alguem conseguiu ver... heheheheh... Valeu pelo elogio... é troquei meu (samsgung syncmaster3 14) por um (Samsung 997MB 19) ia comprar um lcd 17 mas era bem mais caro, ai resolvi ver se o custo/beneficio ia valer apena em questão de gastos, já que falam por ia que o LCD gasta bem mesmo, coloquei na ponta do lapis para ver quanto tempo para o LCD se pagaria na diferença para o de 19 CRT, deu mais deu 12 anos comprei o CRT de 19 daqui 12 anos eu troco... hehehehe. muito bom, comprei na FNAC veio com alguns problemas, 1 pixel morto (achei que só LCD tinha isso), tela torta que não indireitava, liguei e pedi pra trocar, mandaram outro e levaram o meu embora... agora 100% só alegria... hhehehe Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Elazar Dornelles Ceza To: delphi-br@yahoogrupos.com.br Sent: Wednesday, December 06, 2006 4:45 PM Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! OFF Do RS. Funcionou...na segunda tentativa.. Cara...hein...muito show tua área de trabalho...poh... Atenc. Elazar -Mensagem original- De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Luiz Escobar Enviada em: quarta-feira, 6 de dezembro de 2006 14:06 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Bom gente não sei o que esta acontecendo, a pagina esta lá, testei de casa SPEEDY, e na empresa onde tenho dois links SPEEDY e VIRTUA nos tres teste apareceu... Esta imagem foi para ilustrar o que o CAMPOS me perguntou, porque não faço OPEN/CLOSE/REFRESH na tabela, CASO, eu vá cadastrar um cliente onde não existe a cidade no banco de cidade, tendo que abrir outro FORM para cadastrar e ter que dar um REFRESH ou CLOSE/OPEN para atualizar a tabela como ambos os FORM´s usando o mesmo componente TTABLE, nao a necessidade de se dar um REFRESH pois cadastrou os dados estão lá claro, se o cadastro da cidade for feito por outro .EXEcutavél ou por outra maquina, ai na maquina/.EXEcutavél onde estou cadastrando o cliente teria OBRIGATORIAMENTE dar um REFRESH ou (melho) CLOSE/OPEN pois as vezes o REFRESH não REFRESca nada... ;-) Olha que a imagem é meio grande 1600x1200 - 341Kb umas pequenanissima descrição... http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Valfrid-Ly Silva Couto Tentando abrir a imagem: Fora do ar Esta página está fora do ar Provavelmente, o autor do site ainda não fez a publicação das páginas nos nossos servidores. Tente novamente outra hora. Luiz Escobar [EMAIL PROTECTED] escreveu: Uai... aqui pra ieu aparece Olha que a imagem é meio grande 1600x1200 - 341Kb http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: ___ Novidade no Yahoo! Mail: receba alertas de novas mensagens no seu celular. Registre seu aparelho agora! http://br.mobile.yahoo.com/mailalertas/ [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Baixei, criei tudo bzl.. durante o cadastro seja pessoa ou compania da o
seguinte erro:
troque os 'X9s' pelos respectivos codigos dos object ehheehe...
Error storing object TPerson('x9x9x9'): Field 'Address' not found
Error storing object TCompany('x9x9'): Field 'Address' not found
Luiz Escobar
- Segue mensagem original! -
De: Joao Morais [EMAIL PROTECTED]
A caixa de diálogo do conector é apresentada sempre que existe um número
diferente de 1 (um) conector configurado. Para criar um novo conector,
click com botão direito, New, escolher o tipo de conector e depois
seguir a intuição. Esta informação é gravada em um xml na mesma pasta do
executável.
O InstantObjects constrói o banco sozinho, para isto basta escolher a
opção build após configurar o conector. MySQL, Interbase e Firebird
criam o banco de dados caso ele não seja encontrado. Para os demais
bancos é necessário criar um banco vazio para que o InstantObjects
construa o metadata.
--
João Morais
Re: RES: [delphi-br] Re: Usar ou não usar DBWares ? Eis a questão!
anderson wrote: Perdoem minha ignorancia no assunto, mas, existe possibilidade de se utilizar ASPECTOS no delphi ??? Sei que o Marcos ( do Infra ) estava procurando desenvolver o InfraAspects ou algo parecido, conhecem algo do genero ? Não é possível de forma nativa. O que o Marcos fez foi hackear a vmt mas isso deixa o código dificílimo de ser portado. Por sinal, acho que a implementação dele já está pronta. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
João, Mas vcs chegaram a discutir a complexidade de ter muitas interfaces ou cada um foi pra um lado mesmo? Tavez pudesse ter uma versão mais simples e outra mais completa e, portanto, mais complexa, por exemplo. Eu sou avesso a complexidade. Já baixei o source do Infra e do Jazz. Assim como vc, acho que há uma explosão de interfaces em ambos os projetos. Mesmo assim venho acompanhando os projetos desde então. Ainda não baixei o Press; dizem que ainda não ter versão estável, é verdade? Gostaria de receber o link mais atualizado do projeto, se possível. Vc está trabalhando neste projeto sozinho? mD Mensagem Original From: Joao Morais [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Seg, Dezembro 4, 2006 5:32 pm Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Marcos Douglas wrote: Tem uma coisa que eu não entendo. Tem o Press, Jazz e Infra (os que foram citados aqui na lista). Pq não juntar os 3 autores e colaboradores e criar um único projeto, cada um fazendo uma parte específica? No mundo OpenSource tem muito disso. O cara acha que o projeto XYZ não foi bem numa parte aí este faz o XYZ-Open-Beta-3, o outro faz o OpenXYZ, o outro ZYX, etc... Juntem as forças! Bem colocado. Conheci o Infra antes de dar o peteleco inicial no Press, mas pra minha humilde opinião o Infra usa interfaces demais. Tomei conhecimento do Jazz (que também tem uma pá de interface) depois de ter escrito um bocado de coisa. Vejo um projeto mais simples, aonde trabalha-se com classes com contagem de referência e algumas poucas interfaces internas, aonde se fizer necessário. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Bom dizem que uma imagem vale mais que mil palavras... então... veja ai... http://luizescobar.brlog.info/ Sei que a imagem ta meio grandinha, mas é a resolução do montor... depois vejo se dá pra colocar em 800x600 ou pelo menos 1024x768 Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Gerhard Roger Nack To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 3:48 PM Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Ta calma ai Luiz, deixa eu ver se entendi ... Voce cria toda a estrutura de classes de seu sistema, com descendencia, associacoes, etc. Alem disso voce tem um datamodule com todas as tabelas do sistema? Eh isso mesmo? E em algum lugar voce ainda faz o mapeamento das classes para as respectivas tabelas? [ ] s Gerhard Roger Nack [EMAIL PROTECTED] De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Luiz Escobar Enviada em: segunda-feira, 4 de dezembro de 2006 13:47 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Meus TTable´s ficam todos em DATAMODULES... Em Form´s não uso TTABLE Sim uso a mesma TTABLE... não fecho, nem abro, nem refresh, pra que isso ? se estou usando a mesma TTABLE, uma vez cadastrada ela já esta até na possição no cadastro do clienteos DBWare´s do FORM -CAD.CID.estão ligados ao DATASOURCE do DATAMODULE, assim como os componentes DBWARE´s que estiver usando para LOOKUP, já vai estar posicionado... ;-) Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br mailto:delphi-br%40yahoogrupos.com.br Sent: Monday, December 04, 2006 7:56 AM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se tu criase um descendente de TTable, já com o evento, não precisaria nem de colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso. Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre, refresh e tals ? - Original Message - From: Luiz Escobar [EMAIL PROTECTED] mailto:escobar%40megasistema.com.br . [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RE: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
A imagem não aparece :o) O ditado ainda não vale :o) [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
João, Poderia descrever um exemplo do caso que vc precisa fazer isso? mD Mensagem Original From: Joao Morais [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Ter, Dezembro 5, 2006 11:51 am Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Juliano Carvalho - Folhamatic wrote: Se a questão for somente propriedades fica mais fácil (ou menos dificil) resolver com interface. Ou estas propriedades são altamente complexas? Neste caso elas sequer possuem implementação, nem precisam de getter ou setter. São propriedades publicadas. Interface só vai deixar mais complicado, então preferi montar uma classe um por todos, sobrando propriedade em alguns casos. Não resolveu com elegância, mas resolveu. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz, a imagem não está abrindo para mim - Original Message - From: Luiz Escobar [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Tuesday, December 05, 2006 3:59 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Bom dizem que uma imagem vale mais que mil palavras... então... veja ai... http://luizescobar.brlog.info/ Sei que a imagem ta meio grandinha, mas é a resolução do montor... depois vejo se dá pra colocar em 800x600 ou pelo menos 1024x768 Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Gerhard Roger Nack To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 3:48 PM Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Ta calma ai Luiz, deixa eu ver se entendi ... Voce cria toda a estrutura de classes de seu sistema, com descendencia, associacoes, etc. Alem disso voce tem um datamodule com todas as tabelas do sistema? Eh isso mesmo? E em algum lugar voce ainda faz o mapeamento das classes para as respectivas tabelas? [ ] s Gerhard Roger Nack [EMAIL PROTECTED] De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Luiz Escobar Enviada em: segunda-feira, 4 de dezembro de 2006 13:47 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Meus TTable´s ficam todos em DATAMODULES... Em Form´s não uso TTABLE Sim uso a mesma TTABLE... não fecho, nem abro, nem refresh, pra que isso ? se estou usando a mesma TTABLE, uma vez cadastrada ela já esta até na possição no cadastro do clienteos DBWare´s do FORM -CAD.CID.estão ligados ao DATASOURCE do DATAMODULE, assim como os componentes DBWARE´s que estiver usando para LOOKUP, já vai estar posicionado... ;-) Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br mailto:delphi-br%40yahoogrupos.com.br Sent: Monday, December 04, 2006 7:56 AM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se tu criase um descendente de TTable, já com o evento, não precisaria nem de colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso. Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre, refresh e tals ? - Original Message - From: Luiz Escobar [EMAIL PROTECTED] mailto:escobar%40megasistema.com.br . [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.7/569 - Release Date: 05/12/2006 03:00
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Acho que você esqueceu de dar um Refresh na Tabela, para os outros usuários conseguirem ver as alterações que fez no registro. :o) Tente outra vez. []'s Ulisses -Mensagem Original- De: Andreano Lanusse Para: delphi-br@yahoogrupos.com.br Enviada em: terça-feira, 5 de dezembro de 2006 16:10 Assunto: RE: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! A imagem não aparece :o) O ditado ainda não vale :o) [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Uai... aqui pra ieu aparece Olha que a imagem é meio grande 1600x1200 - 341Kb http://luizescobar.brlog.info só a imagem... http://paginas.terra.com.br/informatica/radios/imagem.JPG Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Andreano Lanusse To: delphi-br@yahoogrupos.com.br Sent: Tuesday, December 05, 2006 4:10 PM Subject: RE: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! A imagem não aparece :o) O ditado ainda não vale :o) [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Marcos Douglas wrote: João, Poderia descrever um exemplo do caso que vc precisa fazer isso? Yep. TPressObject +-TPressQuery TPressAttribute +-TPressString +-TPressInteger +-TPressReference TPressObjectMetadata +-TPressQueryMetadata TPressAttributeMetadata +-TPressQueryAttributeMetadata Cada classe de metadata possui informações de runtime dos objetos de negócio. Um ObjectMetadata possui um ponteiro à classe, informações de persistência (pretendo tirar deste nível), etc. Um QueryMetadata possui ainda um ponteiro à classe que é comum a todos os objetos da Query. Até aqui tudo bem. Um AttributeMetadata possui informações como Size (string), Min e Max (Integer) ou ObjectClass (um ponteiro da classe base do Reference), além de informações comuns a todos como Calc. Para as informações específicas de cada atributo poderiam ser criadas novas classes de metadata, uma para cada tipo de atributo, mas o problema é o QueryAttributeMetadata: esta classe possui o campo Category que deve ser incluído em todos os tipos de atributo. Então o que fiz? Criei um único AttributeMetadata que, ao mesmo tempo que possui coisas como Size, Max, Min, possui ObjectClass que não tem nada a ver com atributos simples. Fiz isto para não criar várias vezes a mesma propriedade em classes diferentes. -- João Morais mD Mensagem Original From: Joao Morais [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Ter, Dezembro 5, 2006 11:51 am Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Juliano Carvalho - Folhamatic wrote: Se a questão for somente propriedades fica mais fácil (ou menos dificil) resolver com interface. Ou estas propriedades são altamente complexas? Neste caso elas sequer possuem implementação, nem precisam de getter ou setter. São propriedades publicadas. Interface só vai deixar mais complicado, então preferi montar uma classe um por todos, sobrando propriedade em alguns casos. Não resolveu com elegância, mas resolveu. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se
tu criase um descendente de TTable, já com o evento, não precisaria nem de
colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso.
Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um
cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no
momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre,
refresh e tals ?
- Original Message -
From: Luiz Escobar [EMAIL PROTECTED]
To: delphi-br@yahoogrupos.com.br
Sent: Friday, December 01, 2006 1:30 PM
Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Acho que vc esta redondamente equivocado nesta parte Campus
pra isso que existem os DATAMODULES / ( PROCEDURES / FUNCTIONS /
nEvent´s )-RECURSIVOS eu só faço a parte de pesquisa uma unica vez...
se ta loco fica colocando um TTABLE em cada FORM hehehehhe
Um exemplo RECURSIVO USANDO BeforePOST( bla bla ), em todas as minhas
tabelas (uso MySQL) tem o campo 'lastuser' que é o ultimo usuário que
cadastrou/modificou o registro.
Em todas as tabelas eu uso esse unico evento... crio ele uma unica vez e nos
BEFOREPOST eu seleciono o EVENTO que já esta criado (a data hora é um
campo TIMESTAMP no MySQL, assim nem me preocupo com ela)
procedure TMD_BeforePostALL( dataset : TDataSet ); // ALL porque é usado
para todos
Begin
DataSet.FieldByName('lastuser').AsString := (f_principal.l_user); //
pega o usuário do form.principal...
End;
Luiz Escobar
Analista/Desenvolvedor:
WEB - HTML/JavaScript/PHP/MySQL
WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase
DOS - Clipper/Assembler xBase
SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k
LINUX - LAZARUS/Kylix/MySQL;
http://www.megasistema.com.br
- Original Message -
From: Campus
To: delphi-br@yahoogrupos.com.br
Sent: Thursday, November 30, 2006 3:28 PM
Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz eu tb estou olhando mais de perto isso.
O bom é que tu pode criar uma classe TCliente, e chamando o retrieve, por
exemplo, carregar os dados do banco.
O ganho é que tu faz isso na classe, e só instancia o objeto.
Com TDataSet, se em cada form tu for colocar um TTable ou um TQuery para
buscar esses dados, tu vai ter que localizar o cliente corespondente, ou
com
Locate, ou com um GotoKey. Em resumo, e sempre tem que escrever muito
código.
Já no caso, usando um objeto cliente, tu escreve esse código uma vez só e
pronto.
- Original Message -
From: Luiz Escobar [EMAIL PROTECTED]
To: delphi-br@yahoogrupos.com.br
Sent: Thursday, November 30, 2006 2:01 PM
Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Andreano, não é achar que não deve ter, é ter certeza que não precisa
ter.
Opa, isso precisa ter muita base pra falar né futuro matuzalem
É sempre questão de preferência. Falo por mim, estou apenas expondo
vantagens de um modelo orientado a objetos perante o RAD (com exceção
de
usar TDataset como objeto de negócio - isso é roda quadrada).
HUmmm uma questao de preferencias. agora melhorou
TDataset é orientado a tabela, OPF é orientado a objetos do domínio do
problema.
==TDataset==
TabCliente.Open; // ou .Query := 'xx';
TabCliente.Locate(); // ou TabCliente.Open;
TabCliente.Edit
TabClienteNOME := 'Outro';
TabCliente.Post;
e se tiver Cached updates... transação...
ai vc coloca um APPLYUPDATE(-1) e ta tudo certo
==OPF==
Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc.
Cliente.Nome := 'Outro Nome';
Cliente.Save; -- cache, controle transacional, tudo aqui dentro.
E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra
TDataset.
Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho
um
SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias
alterações e mando salvar tudo de uma vez para que se der um problema eu
possa fazer um ROLLBACK ???
Este exemplo ta meio desproporcional...
Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo
mesmo porque os controles ficaram mais ainda longe das mãos dos
programadores não que eu não ache isso maravilhoso, muito pelo
contrario, quanto menos codigo melhor...
BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um
DBWARE ? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as
coisas,
vou ter que fazer um label1.caption := cliente.nome ?
Explique mais, ou mostre onde posso conseguir mais coisa to começando
a
gostar do bixim
==DBAware==
DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em
um componente (DB*) e a um datasource. Se você quer um componente
'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset
estiver em um DataModule e por desencargo do destino a ligação
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
João, Discordo qto a herança múltipla. Java, que foi concebido para implementar OO não tem herança múltipla, pq o pessoa da Sun sabe que herança múltipla complica mais do que gera resultados. MS .NET tb é outro exemplo. Para este problema, utilizamos interfaces. mD Mensagem Original From: Joao Morais [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Sex, Dezembro 1, 2006 7:39 pm Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Marcos Douglas wrote: Nada em informática é 100%, inclusive o ECO. Programar utilizando MVP, em Delphi, tb não quer dizer 100% OO, pois nem o Delphi é 100% OO... Não tomemos 100% como algo perfeito, mas tangível para a tecnologia atual. Neste caso MVP é 100% OO e Object Pascal / Delphi poderia estar melhor colocado se ao menos implementasse herança múltipla. -- João Morais --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso, quando se muda alguma coisa no código vc dificilmente faz todos os testes que já fez manualmente até hj, isso com testes automatizados nao aconteceria e vc teria a certeza (ou quase) que seu software nao está sendo entregue com novos bugs ou bugs que já havia sido corrigidos. Depois de toda esta discussão joão eu percebo que o pessoal só vai se interessar quando pudermos mostrar que será mais eficaz (RAD) do que a forma que é feita hj. E isso é uma pena, por que acho que a galera não deveria ficar esperando não, deveria investir um pouco nisso por que a tendência é geral. Veja o Java e .Net, estas linguagens já forçam os programadores a programar de forma OO, claro que os programadores podem misturar as camadas? sim podem, tem ameba pra tudo. Mas o Java e o .NET já nasceram focados em OO, enquanto a Borland para poder espalhar (vender) o Delphi, focou no desenvolvimento RAD estruturado, e se pegarmos os livros de delphi então, puts. A bíblia do Delphi por exemplo, Cantú sabe tanto e ainda nao mudou a abordagem daquele livro. A comunidade sabe pouco sobre OO, pouco sobre seus benefícios, etc... Estão todos esperando para ver no que vai dar. E quem espera sempre alcança né mesmo? Talvez, Só que estará absoleto e anos atrás de quem já começou a experimentar a OO. Eu hj programa datasnap estruturado, e depois que comecei o Infra eu olho para meu código e falo, poxa se fosse OO nao estaria fazendo isso. Mas, cada cabeça seu guia. Espero que o povo acorde. Para de ficar falando que é produtivo ou não e tente realmente entender o porque das coisas. Ah! já ia me esquecendo. Quanto a produtividade, que tal esta: O Infra pretende ser inteligente o suficiente para poder montar as telas sozinho com base em algorítimos de IA que vão aprendendo com os ajustes feitos pelo programador. A partir da segunda tela o bicho já vai começar a entender a estrutura que o programador utiliza e já propoe a nova tela. se o usuário nao gostar ele ajusta, e o infra guarda estas novas informações para a próxima tela, acredito que da 3 tela em diante vc nem precise mais ajudar nada! E nao precisou por nenhum componente no Form, ou colocar qualquer codigo em seus eventos. hehehe, quer produtividade? Engula isso. E isso só será possível com uma boa base OO, tente fazer isso com RAD estruturado pra ver É isso
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Vcs poderiam enviar algum exemplo de O.O. e DBWares delphi? Tipo um cadastro, algo que se pode ter uma noçao de como funciona? Ate +! Fabiano - Original Message - From: Bruno Lichot To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 1:54 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Salve galera! não quero entrar nos afins das questões aki..apenas deixar minha experiencia.. Delphi é RAD e é OO!!! e não e RAD pra espalhar não... faço qq coisa OO em delphi mais rapido e com a mesma qualidade do q e feito em Java ou .Net q seja. hj programo OO e uso plenamente dos recursos RAD sem ferir em nada os conceitos OO apenas dando um poder a mais ao meu desenvolvimento, mas pra isso vc não adinata conecer somente a metodologia ou os principios OO, tem q conhecer o Delphi em busca do estado da arte e usar os seus recursos para aumentar o Poder disso td.. como disse apenas uma experiencia e termino aki minha participação nesta thread Abração Bruno Lichot mrbar2000 escreveu: João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso, quando se muda alguma coisa no código vc dificilmente faz todos os testes que já fez manualmente até hj, isso com testes automatizados nao aconteceria e vc teria a certeza (ou quase) que seu software nao está sendo entregue com novos bugs ou bugs que já havia sido corrigidos. Depois de toda esta discussão joão eu percebo que o pessoal só vai se interessar quando pudermos mostrar que será mais eficaz (RAD) do que a forma que é feita hj. E isso é uma pena, por que acho que a galera não deveria ficar esperando não, deveria investir um pouco nisso por que a tendência é geral. Veja o Java e .Net, estas linguagens já forçam os programadores a programar de forma OO, claro que os programadores podem misturar as camadas? sim podem, tem ameba pra tudo. Mas o Java e o .NET já nasceram focados em OO, enquanto a Borland para poder espalhar (vender) o Delphi, focou no desenvolvimento RAD estruturado, e se pegarmos os livros de delphi então, puts. A bíblia do Delphi por exemplo, Cantú sabe tanto e ainda nao mudou a abordagem daquele livro. A comunidade sabe pouco sobre OO, pouco sobre seus benefícios, etc... Estão todos esperando para ver no que vai dar. E quem espera sempre alcança né mesmo? Talvez, Só que estará absoleto e anos atrás de quem já começou a experimentar a OO. Eu hj programa datasnap estruturado, e depois que comecei o Infra eu olho para meu código e falo, poxa se fosse OO nao estaria fazendo isso. Mas
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Meus TTable´s ficam todos em DATAMODULES... Em Form´s não uso TTABLE Sim uso a mesma TTABLE... não fecho, nem abro, nem refresh, pra que isso ? se estou usando a mesma TTABLE, uma vez cadastrada ela já esta até na possição no cadastro do clienteos DBWare´s do FORM -CAD.CID.estão ligados ao DATASOURCE do DATAMODULE, assim como os componentes DBWARE´s que estiver usando para LOOKUP, já vai estar posicionado... ;-) Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 7:56 AM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se tu criase um descendente de TTable, já com o evento, não precisaria nem de colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso. Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre, refresh e tals ? - Original Message - From: Luiz Escobar [EMAIL PROTECTED] . [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Concordo que interface, apesar de não ter nascido pra isso, resolve o problema. Discordo que isto seja motivo para remover o recurso. É um pouco mais complicado implementar herança múltipla com interface do que implementar diretamente através das classes. Mas como não sou engenheiro de nenhuma das duas empresas nem da Borland/CodeGear... Acho que os técnicos resolveram retirar a herança múltipla pq são poucos os casos que vc _realmente_ precisaria utilizar este recurso. mD Mensagem Original From: Joao Morais [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Sex, Dezembro 1, 2006 7:39 pm Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Marcos Douglas wrote: Nada em informática é 100%, inclusive o ECO. Programar utilizando MVP, em Delphi, tb não quer dizer 100% OO, pois nem o Delphi é 100% OO... Não tomemos 100% como algo perfeito, mas tangível para a tecnologia atual. Neste caso MVP é 100% OO e Object Pascal / Delphi poderia estar melhor colocado se ao menos implementasse herança múltipla. -- João Morais --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Mas então tu só trabalha com pequenas massas de dados, se tu for usar Um TTable num cadastro de produtos de auto-peças, que chega a 300 mil itens, o sistema não anda. Abrir e fechar, ou dar refresh é nescessário, caso outro usuário inclua novos dados. - Original Message - From: Luiz Escobar [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 1:46 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Meus TTable´s ficam todos em DATAMODULES... Em Form´s não uso TTABLE Sim uso a mesma TTABLE... não fecho, nem abro, nem refresh, pra que isso ? se estou usando a mesma TTABLE, uma vez cadastrada ela já esta até na possição no cadastro do clienteos DBWare´s do FORM -CAD.CID.estão ligados ao DATASOURCE do DATAMODULE, assim como os componentes DBWARE´s que estiver usando para LOOKUP, já vai estar posicionado... ;-) Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 7:56 AM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se tu criase um descendente de TTable, já com o evento, não precisaria nem de colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso. Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre, refresh e tals ? - Original Message - From: Luiz Escobar [EMAIL PROTECTED] . [As partes desta mensagem que não continham texto foram removidas] -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 04/12/2006 07:18
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Oi bruno concordo contigo. Dephi é RAD, ó OO, é Fantásticô!!! :) O problema nao é o delphi ou a borland, nao me entenda mal, o problema foi que apesar de poder trabalhar delphi OO dificilmente vemos literatura mostrando o uso puramente OO. Seria legal se vc pudesse montar um exemplozinho de como vc tá fazendo ai uma simples agendazinha (pessoa - agenda - compromisso), utilizando os recursos de OO e o RAD do delphi. Será que vc poderia postar este pequeno exemplo para poder a galera começar a ver isso de perto?
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
AH... tá, não... na realidade eu não uso TTABLE, usei ele apenas para exemplo Eu uso MyDAC (mysql) o que tenho em DBF já esta mais que aposentado.. todo desenvolvimento novo esta saindo para MySQL com MyDAC e os antigos em DBF estão sendo migrados...a gente ta migrando o cara!!!...(era do gelo) ;-) Agora PROCURAS, em TTABLE, só ficam lentos se vc não tiver INDICES para suas procuras... para filtros com o ONFILTER ai sim fica MUITO LENTO dependendo do tamanho do banco Quanto a CADASTROS, INSERÇÔES, MODIFICAÇÔES, REFRESH, são só lentros se vc usar FILTERED := true e dependendo do tamanho do banco; Agora TQUERY sim fica extremamete LENTO se vc não usar muito bem os filtros (WHERE´s) pois ele iria copiar todo seu banco na maquina local em um arquivo temporario... Caso a inclusão seja por outro usuario ai sim open/close/refresh são necessários... Mas vc tinha dito sobre eu não usar TTABLER em FORM´s, eu disse que não! E sobre cadastrar uma cidade para usar em um cliente que estou cadastrando... isso não deixaria lento... tenho isso no meu cadastro de ouvintes... uso o CEP como chave... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 4:03 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Mas então tu só trabalha com pequenas massas de dados, se tu for usar Um TTable num cadastro de produtos de auto-peças, que chega a 300 mil itens, o sistema não anda. Abrir e fechar, ou dar refresh é nescessário, caso outro usuário inclua novos dados. - Original Message - From: Luiz Escobar [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 1:46 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Meus TTable´s ficam todos em DATAMODULES... Em Form´s não uso TTABLE Sim uso a mesma TTABLE... não fecho, nem abro, nem refresh, pra que isso ? se estou usando a mesma TTABLE, uma vez cadastrada ela já esta até na possição no cadastro do clienteos DBWare´s do FORM -CAD.CID.estão ligados ao DATASOURCE do DATAMODULE, assim como os componentes DBWARE´s que estiver usando para LOOKUP, já vai estar posicionado... ;-) Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Campus To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 7:56 AM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tá mas teu exemplo de recursividade não tem relação com a questão, melhor se tu criase um descendente de TTable, já com o evento, não precisaria nem de colocar em todas as Tables. Eu prefiro usar um trigger para fazer isso. Tu disse que não usa uma TTable em cada form, mas se tu tá cadastrando um cliente, por exemplo, e não tem a cidade dele no cadastro de cidades, no momento de cadastrar a nova cidade, tu usa a mesma TTable ? Fecha, abre, refresh e tals ? - Original Message - From: Luiz Escobar [EMAIL PROTECTED] . [As partes desta mensagem que não continham texto foram removidas] -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 04/12/2006 07:18 [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Marcos, O problema não é terreno infértil, na minha opinião. Acontece que muitos profissionais são obrigados a utilizar a metologia da empresa na qual trabalham. A maioria é RAD, pois acham que a produtividade é maior (como vcs tanto falam aqui). O programador acaba gostando ou não tendo tempo para aprender os benefícios da programação Orientada à Objetos. Tb tem aqueles casos que o cara tem vários clientes que querem as coisas pra ontem. Então, pra muitos, linkar componentes ainda é mais rápido do que programar utilizando OO, mesmo que o sistema saia com varios bugs, mas pelo menos entregou o sistema. Tem uma coisa que eu não entendo. Tem o Press, Jazz e Infra (os que foram citados aqui na lista). Pq não juntar os 3 autores e colaboradores e criar um único projeto, cada um fazendo uma parte específica? No mundo OpenSource tem muito disso. O cara acha que o projeto XYZ não foi bem numa parte aí este faz o XYZ-Open-Beta-3, o outro faz o OpenXYZ, o outro ZYX, etc... Juntem as forças! mD Mensagem Original From: mrbar2000 [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Seg, Dezembro 4, 2006 1:29 pm Subject: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso, quando se muda alguma coisa no código vc dificilmente faz todos os testes que já fez manualmente até hj, isso com testes automatizados nao aconteceria e vc teria a certeza (ou quase) que seu software nao está sendo entregue com novos bugs ou bugs que já havia sido corrigidos. Depois de toda esta discussão joão eu percebo que o pessoal só vai se interessar quando pudermos mostrar que será mais eficaz (RAD) do que a forma que é feita hj. E isso é uma pena, por que acho que a galera não deveria ficar esperando não, deveria investir um pouco nisso por que a tendência é geral. Veja o Java e .Net, estas linguagens já forçam os programadores a programar de forma OO, claro que os programadores podem misturar as camadas? sim podem, tem ameba pra tudo. Mas o Java e o .NET já nasceram focados em OO, enquanto a Borland para poder espalhar (vender) o Delphi, focou no desenvolvimento RAD estruturado, e se pegarmos os livros de delphi então, puts. A bíblia do Delphi por exemplo, Cantú sabe tanto e ainda nao mudou a abordagem daquele livro. A comunidade sabe pouco sobre OO, pouco sobre seus benefícios, etc... Estão todos esperando para ver no que vai dar. E quem espera sempre alcança né mesmo? Talvez, Só que estará absoleto e anos atrás de quem já começou a experimentar a OO. Eu hj programa datasnap estruturado, e depois que comecei o Infra eu olho para meu código e falo, poxa se fosse OO nao estaria fazendo isso. Mas, cada cabeça seu guia. Espero que o
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Não sei se é bem por aí a coisa. O grande problema (e desafio) hoje da OOP, é convencer os programadores, de que a mesma é seja melhor que a programação estruturada. Na verdade é e não é. É porque permite uma curva reusabilidade e manutnibilidade do código muito maior do que a programação estruturada. Se você criar objetos genéricos, sua curva de produtividade pode até subir muito mais do que na PE. Não é porque a curva de produtividade dela não é igual a Programação estruturada. E, além do mais, o cara pra conseguir tais curvas satisfatórias ele tem que ter a mentalidade de OOP e saber programar OO. Do contrario ele mistura as duas sem ver, faz um balaio de gato com o código e o sistema dele acaba como o samba do criolo doido. Aí que tá o gargalo. Pra você aprender OOp, você precisa fazer algo como renunciar a todo o seu conhecimento de programação e recomeçar do zero trilhando por outro caminho PROIBIDO de olhar pra PE. Nos dias de hoje, com cronogramas apertados, sistemas complexos e pra ontem, quem anima a se meter numa dessas??? É uma coisa complicada pra você chegar aqui e afirmar isto. Não é que o terreno seja infértil, mas o problema é que o mercado não é um ambiente propício para tal. Se aqui na telemont, eu tivesse folga no cronograma, eu faria tudo OOP numa boa. Mas as vezes me aparecem cum troço aqui de manha pra entregar daqui a 2 dias []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, mrbar2000 [EMAIL PROTECTED] escreveu João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso, quando se muda alguma coisa no código vc dificilmente faz todos os testes que já fez manualmente até hj, isso com testes automatizados nao aconteceria e vc teria a certeza (ou quase) que seu software nao está sendo entregue com novos bugs ou bugs que já havia sido corrigidos. Depois de toda esta discussão joão eu percebo que o pessoal só vai se interessar quando pudermos mostrar que será mais eficaz (RAD) do que a forma que é feita hj. E isso é uma pena, por que acho que a galera não deveria ficar esperando não, deveria investir um pouco nisso por que a tendência é geral. Veja o Java e .Net, estas linguagens já forçam os programadores a programar de forma OO, claro que os programadores podem misturar as camadas? sim podem, tem ameba pra tudo. Mas o Java e o .NET já nasceram focados em OO, enquanto a Borland para poder espalhar (vender) o Delphi, focou no desenvolvimento RAD estruturado, e se pegarmos os livros de delphi então, puts. A bíblia do Delphi por exemplo, Cantú sabe tanto e ainda nao mudou a
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
E do verbo também... Eu vejo que tem muita gente que fica contente se o programa é entregue no prazo, mesmo que tenha bugs, ou que o resultado não esteja 100%. Muito acham que é melhor do que não ter entregue. - Original Message - From: Luiz Escobar [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 5:30 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Tb tem aquelescasos que o cara tem vários clientes que querem as coisas pra ontem. Então, pra muitos, linkar componentes ainda é mais rápido do que programar utilizando OO, mesmo que o sistema saia com varios bugs, mas pelo menos entregou o sistema. è verdade, sempre tem os de ontem e os de ante-ontem... Agora LINKAR componentes nçao significa que o sistema vai sair com varios bug´s ai como um outro amigo nosso disse problema esta no SUJEITO!!!... ;-) abraços... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Marcos Douglas To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 4:53 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Marcos, O problema não é terreno infértil, na minha opinião. Acontece que muitos profissionais são obrigados a utilizar a metologia da empresa na qual trabalham. A maioria é RAD, pois acham que a produtividade é maior (como vcs tanto falam aqui). O programador acaba gostando ou não tendo tempo para aprender os benefícios da programação Orientada à Objetos. Tb tem aqueles casos que o cara tem vários clientes que querem as coisas pra ontem. Então, pra muitos, linkar componentes ainda é mais rápido do que programar utilizando OO, mesmo que o sistema saia com varios bugs, mas pelo menos entregou o sistema. Tem uma coisa que eu não entendo. Tem o Press, Jazz e Infra (os que foram citados aqui na lista). Pq não juntar os 3 autores e colaboradores e criar um único projeto, cada um fazendo uma parte específica? No mundo OpenSource tem muito disso. O cara acha que o projeto XYZ não foi bem numa parte aí este faz o XYZ-Open-Beta-3, o outro faz o OpenXYZ, o outro ZYX, etc... Juntem as forças! mD Mensagem Original From: mrbar2000 [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Seg, Dezembro 4, 2006 1:29 pm Subject: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Tb tem aquelescasos que o cara tem vários clientes que querem as coisas pra ontem. Então, pra muitos, linkar componentes ainda é mais rápido do que programar utilizando OO, mesmo que o sistema saia com varios bugs, mas pelo menos entregou o sistema. è verdade, sempre tem os de ontem e os de ante-ontem... Agora LINKAR componentes nçao significa que o sistema vai sair com varios bug´s ai como um outro amigo nosso disse problema esta no SUJEITO!!!... ;-) abraços... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Marcos Douglas To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 4:53 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Marcos, O problema não é terreno infértil, na minha opinião. Acontece que muitos profissionais são obrigados a utilizar a metologia da empresa na qual trabalham. A maioria é RAD, pois acham que a produtividade é maior (como vcs tanto falam aqui). O programador acaba gostando ou não tendo tempo para aprender os benefícios da programação Orientada à Objetos. Tb tem aqueles casos que o cara tem vários clientes que querem as coisas pra ontem. Então, pra muitos, linkar componentes ainda é mais rápido do que programar utilizando OO, mesmo que o sistema saia com varios bugs, mas pelo menos entregou o sistema. Tem uma coisa que eu não entendo. Tem o Press, Jazz e Infra (os que foram citados aqui na lista). Pq não juntar os 3 autores e colaboradores e criar um único projeto, cada um fazendo uma parte específica? No mundo OpenSource tem muito disso. O cara acha que o projeto XYZ não foi bem numa parte aí este faz o XYZ-Open-Beta-3, o outro faz o OpenXYZ, o outro ZYX, etc... Juntem as forças! mD Mensagem Original From: mrbar2000 [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Seg, Dezembro 4, 2006 1:29 pm Subject: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! João, as vezes acho que estamos tentando plantar estas coisas em terreno infértil, o pessoal ainda nao acordou para reuso nem orientação a objetos, poucos faculdades e professores sabem realmente sobre o assunto e quando sabem, nao conseguem demostrar na prática como ficaria, nem quais os benefícios reais que OO pode trazer. 1) OO é solução para tudo? Não, mas ajuda e muito no desenvolvimento, virtualização do negócio do cliente com mais eficiência e acima de tudo na manutenção do sistema. Não que nao se consiga boa parte disso usando RAD com dataware (que eu particularmente acho produtivo tambem, mas infelizmente faz com que a maioria dos programadores acoplem as camadas, alem do problema de não ter controle sobre a sincronia dos dados) 2) Você utiliza OO? Ainda não, trabalho em um framework OO chamado Infra similar ao Press mas nao posso utilizar ainda pela falta da persistência (poderia usar o jazz, depo, tiopf, IO para isso, mas acho que nenhum deles segue o projeto que já tenho em mente para o Infra). Alem disso sei que usar agora seria aumentar o trabalho pela falta de uma ferramenta, expert ou wizard que facilite o desenvolvimento (acho que com estes recursos, desenvolver de forma OO vai dar um banho no desenvolvimento tradicional). Esta coisa de ser mais produtivo é bem relativo. Vc pode jogar os componentes no form, enfiar código em eventos ligar tudo visualmente e gastar um dia ou dois montando uma tela. Foi prodivo? sim foi. Se fosse fazer em OO com o que temos hj disponível poderia levar 3 dias. mas na próxima tela nao seria necessário mais 2 dias. E nao estou falando aqui de CTRL+C e CTRL+V como muito programador faz com suas telas hj em dia. Já tive muitos problemas em se fazer isso na minha empresa. Pessoal pega telas complexas cheias de código e simplesmente duplicava para montar um form similar, perdendo tempo demais procurando erros de ter componentes ou código fazendo ou apresentando coisas indevidas. Perdiamos muito mais tempo do que se tivessemos pegado o form do zero e montado. Alem disso tem a questão de testes. Automatizar testes é muito fácil em OO mas no desenvolvimento tradicional... hummm. uma desgraça. Segue-se o velho modelo: compila - testa - não funciona - compila - testa Alem disso, quando se muda alguma coisa no código vc dificilmente faz todos os testes que já fez manualmente até hj, isso com testes automatizados nao aconteceria e vc teria a certeza (ou quase) que seu software nao está sendo entregue com novos bugs ou bugs que já havia sido corrigidos. Depois de toda esta discussão joão eu percebo que o pessoal só vai se interessar quando pudermos mostrar que será mais
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Ok, valeu, vou tentar compilar, valeu... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 12:01 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Luiz Escobar wrote: - É o mesmo botãozinho em cada componente. E se for um TDBSpeedButtonLookupComboBox, tem que dizer qual é o formulário alvo em cada formulário criado. Se não quiser dizer qual é o form, tem que ser MVP. Mas João, como em MVP ele sabe que eu quero cadastrar e qual é o FORM, indiretamente eu estou informando não é ?? vejamos: procedure buttonclick(...) form1.showMODAL; procedure buttonclick(...) cliente := TCLIENTE.nãolembrootermo(ID); Você não precisa disso. O registro de Presenter faz isso por você. Então se você tem um combo e liga a um Nota.Cliente, ele sabe que isso aponta para TCliente, sabe que vai usar o form TClienteEditViewForm, ele sabe instanciar o form, destruir, gravar os dados do Cliente em TCliente e depois gravar o ID do cliente em TNota. Depois nesse combo você pode digitar um pedaço do nome do cliente e o Combo é aberto com os clientes que possuem aquele critério. Novamente, sem código algum. Tudo o que tens que fazer é criar as classes (Wizard, pois sem ele é bem phodha), registrar, e por fim ligar o Combo ao atributo da classe (uma linha de código que chama um método com três parâmetros). Tá certo, você precisa registrar algumas coisas, e no lugar certo. E se você quiser criar umas funcionalidades diferentes, tem que ser no lugar certo também, mas tudo isso resolve-se com Wizards, sem código nenhum -- exceto o seu próprio código, lógico, MVP não faz milagre. Você precisa pelo menos saber o que quer :-) E lógico, ainda falta implementar os raios dos Wizards. sempre penso em como fazer o software ser mais produtivo para o USUÁRIO também, se as telas começarem a demorar d+ para serem apresentadas, to fora... Depende da persistência. InstantObjects tem uns perrengues (lentidão) quando você tem objetos muito complexos. Mas como te disse - uma que a equipe está trabalhando nesse perrengue, outra que eu posso escrever um broker para tiOPF, DePO ou qualquer outro. Outra ainda é que eu tenho intenção de criar um framework de persistência próprio. Ainda assim, mesmo com InstantObjects, não é nada de arrancar os cabelos. Tenho um projeto com quatro níveis de mestre-detalhe, e as telas apesar de não serem apresentadas instantaneamente, levam uma pequena fração de segundos para aparecer quando o objeto ainda tá no banco. Se o objeto tá em cache, a apresentação é instantânea, independente do tamanho do form. Quanto ao produtivo para o usuário, aqui sim está a vantagem. Você cria novas funcionalidades em quaisquer componentes, como Combo, StringList, ou mesmo Edit, registra o Model no framework e a funcionalidade é replicada para todo o teu sistema. Se você quiser, agora, usar um ListView para apresentar dados (o framework *ainda* não o suporta), basta você registrar uma View que entenda ListView e pimba, tá lá o ListView mostrando os teus objetos de negócio. Você não precisa que o desenvolvedor do framework faça isso por você, nem mesmo se o código fosse fechado. Assim você usa uma ferramenta que não te prende a apenas um padrão, um banco, um componente, uma funcionalidade. Veja MVP.txt nos docs aonde eu falo mais ou menos isso com outras palavras. E que ASSEMBLY tem haver com isso... Quanto a arrastar componentes, bom se alguem trabalhar em DELPHI e não fizer isso, bom, deve ser um MASOQUISTA! O fato de eu, arrastar ou não componentes, e vc, ser o construtor de um MVP, não o torna melhor o pior programador que eu, acho que neste ponto vc deveria REVER OS SEUS CONCEITOS... Véi, foi forçado o comentário. Mas ainda assim tentei colocar dois exemplos extremos - Assembly é puro código e arrastar componente é puro click. Nenhum dos dois é bom porque por um lado lhe falta produtividade, por outro lhe falta recurso. MVP é mais orientado a código, especialmente _hoje_, _em Press_. Logo que a anta véia conseguir criar os Wizards tudo firacá mais divertido e clickável. Mesmo assim, desculpa a falta de jeito. Eu, pra mula, só tá faltando as penas. se compilou aquele PHONEBOOK ?? to loco pra testar a performance do bixim... Já vi que vc não quer me enviar o executavel pra eu testar... Leia os Readme. Já LI!... :-/ Vide ($Press)/Demos/Readme.txt. Você precisa remover a dependência com InstantObjects, ou instalá-lo em teu micro. Ainda assim vou empacotar um binário
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Assino embaixo - Original Message - From: mrbar2000 [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Monday, December 04, 2006 4:52 PM Subject: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Oi bruno concordo contigo. Dephi é RAD, ó OO, é Fantásticô!!! :) O problema nao é o delphi ou a borland, nao me entenda mal, o problema foi que apesar de poder trabalhar delphi OO dificilmente vemos literatura mostrando o uso puramente OO. Seria legal se vc pudesse montar um exemplozinho de como vc tá fazendo ai uma simples agendazinha (pessoa - agenda - compromisso), utilizando os recursos de OO e o RAD do delphi. Será que vc poderia postar este pequeno exemplo para poder a galera começar a ver isso de perto? -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.6/567 - Release Date: 04/12/2006 07:18
Re: RES: RES: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
anderson wrote: Adorei a ideia, To querendo algo assim mesmo ecomecar a de leve sair de win 32 e migrar tudo para .NET e nada melhor que aproveitar e mudar o modo de se trabalhar para algo o mais proveitoso ! Concordo. Agora duas coisas que julguei importante colocar: - OPF tem outra vantagem perante TDataset que eu esqueci de mencionar - mapeamento. Se você precisa mudar um nome de atributo, basta mudar esse nome no mapeamento. Se mudar o tipo ou remover um campo, basta mudar na classe e o seu projeto vai dar erro de compilação aonde você precisar alterar. 100% produtivo; - Especialmente quanto a Press (sei que você falou em .net, é só um gancho) não há compromisso em tornar compatível com a plataforma. Orientação a objetos o Press faz por si. Multiplataforma é feito com Free Pascal. E ainda gera código nativo--mais rápido. Se o porte para .net não trouxer dor de cabeça... beleza, um dia ela acaba saindo. -- João Morais _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Joao Morais Enviada em: sexta-feira, 1 de dezembro de 2006 15:58 Para: delphi-br@yahoogrupos.com.br Assunto: Re: RES: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! anderson wrote: Entendi, mas vamos supor entaum, eu posso suar ECO como OPF e usar uma camada MVP para desacoplar ao maximo possível DB / MODELO / APRESENTAÇÃO certo ? Desacoplar do banco você pode fazer com ClientDataSet ou DBExpress. Com OPF (ECO, por exemplo) além de desacoplar você tem objetos de negócio de verdade, e com hierarquia de classe, tipo: TContato-TPessoa-TCliente, caso seu projeto precise. Você tem também cache e controle transacional controlados pelo framework, evita repetição de código e de tratamentos de erro. O MVP faz com que você reaproveite código de apresentação e deixa os seus forms totalmente sem implementação. -- João Morais
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Bom vamos fazer o seguinte, eu não vo conseguir convencer vc que DBWares são uma boa coisa assim como vc não vai me converser que MVP são a solução dos problemas... CERTO!? Bem então já que vc esta desenvolvendo o SEU MVP que está em PRE-ALFA, faça o seguinte, porque creio que não só eu como varios aqui ficaram interessados no assunto, dá pra colocar no site um LINKzinho com um cadastro com nome e email para sempre que sair atualizações a gente receber no email pelo meno O MVP DO JOÃO FOI ATUALIZADO! ai a gente vai acompanhado e APRENDENDO MAIS E MAIS de como isso ai realmente funciona, porque pra VC é FACIL FALAR pois é VC que esta DESENVOLVENDO esta do jeito que esta na SUA CABEÇA e não na dos demais..., pra mim trabalhar com DBWARE´s é MUITO FACIL e nunca senti dificuldades com ele, o que pode ser muito CLARO pra vc pros outros vai parece um breu total... assim vc ajuda a comunidade a acompanhar o seu projeto, ou se não der pra fazer a parte de emails pois o provedor onde esta não aceita vc mandar MUITOS emails, posta aqui no GRUPO mesmo, OLHA GENTE ATUALIZEI MAIS UMAS COISA e coloca o LINK porque a gente acaba esquecendo... BLZ!? Sem recentimentos... Abraços... Até mais... Agora eu encerei a minha participação nesta THREAD... só v ou acompanhar e não mais participar... Então em sua resposta se puder apenas afirmar e não perguntar... ;-) E mais abaixo tem os meus comentários sobre os seus comentários Luiz Escobar - Segue mensagem original! - De: Joao Morais [EMAIL PROTECTED] - É o mesmo botãozinho em cada componente. E se for um TDBSpeedButtonLookupComboBox, tem que dizer qual é o formulário alvo em cada formulário criado. Se não quiser dizer qual é o form, tem que ser MVP. Mas João, como em MVP ele sabe que eu quero cadastrar e qual é o FORM, indiretamente eu estou informando não é ?? vejamos: procedure buttonclick(...) form1.showMODAL; procedure buttonclick(...) cliente := TCLIENTE.nãolembrootermo(ID); não vejo diferença assim... mas beleza... deixa queto... - Em herança de formulário você não tem como dizer que o ID_x aponta para a tabela x e que o formulário para fazer a alteração/inclusão é x. Se tivesse não seria herança de formulário, seria MVP. - DBNavigator não abre janela, e se abrir, você tem que dizer qual é a janela. E tem que destruir. E se duvidar, vai ser modal para que essa janela não bombeie o resto do sistema. E se nada disso der trabalho, não é DBNavigator, é MVP. - Herança, e não recursividade. O que manda mais que os dois acima é produtividade, tanto na parte de produção/construção do software quanto na parte de utilização dos mesmo... (tempo em todos os sentidos...). Porque EU como programador sempre penso em como fazer o software ser mais produtivo para o USUÁRIO também, se as telas começarem a demorar d+ para serem apresentadas, to fora... Do meu ponto de vista o DBWARE me parece mais produtivo, mas to tentando entender onde esta o ponto produtivo do MVP em DELPHI... tento QUE HOJE fazer mais códigos e/ou ficar separando isso aqui isso ali... - Pare de dar murro em ponta de faca, pergunte antes de falar bobagem. Se você tem certeza então não faça pergunta; se você tem dúvida, faça pergunta e não diga o que você acha. Para um programador Assembly você está me saindo um perfeito arrastador de componente. Se eu soubece tudo, não estaria DIALOGANDO(teimando) com vc e sim te encinando, ou ganhando muito mais dinheiro.. E que ASSEMBLY tem haver com isso.JESUS!!! Quanto a arrastar componentes, bom se alguem trabalhar em DELPHI e não fizer isso, bom, deve ser um MASOQUISTA! O fato de eu, arrastar ou não componentes, e vc, ser o construtor de um MVP, não o torna melhor o pior programador que eu, acho que neste ponto vc deveria REVER OS SEUS CONCEITOS... se compilou aquele PHONEBOOK ?? to loco pra testar a performance do bixim... Já vi que vc não quer me enviar o executavel pra eu testar... Leia os Readme. Já LI!... :-/
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
nao sei ha qntas anda essa thread, mas td q o mvp faz, da pra se fazer diferente usando DBAware vc sempre precisa de cadastros resolvido, faca um arquivo xml contendo o mapeamento dos campos (msm coisa, mas usando DBW) ah, preciso de uma tela de busca generica... eu sempre tive isso usando DB se quer abandonar DBAware nao tem problema, mas vai ter q escrever linhas q estao prontas, pq da pra se ter msm qualidade em qq forma de programacao desde q se tenha conhecimento no q esta fazendo... Julio Cesar [EMAIL PROTECTED] +353 (87) 2184139 +353 (091) 630317 Nao ha saber mais ou saber menos, ha saberes diferentes (Paulo Freire) - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Saturday, December 02, 2006 2:34 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Luiz Escobar wrote: Fazer botãozinho do lado do combo pra cadastrar da trabalho ? onde ? Fazer ginastica para digitar e achar o cliente ? VC não conhece o MyDAC né ? ele tem isso no DBGRID que o acompanha.. e muito mais Criar um novo cliente ? novamente DBNAVIGATOR. Novo FORM novo PROJETO ? mesma manobra ? e a parte RECURSIVA se é igual só copiar FORM de um pro outro e olhe lá... se vc já sabe que vai reusar é só inserir no novo projeto... e VUA-LA, ta lá... heeeheee Quanto a erros, bons se eu uso 1 FORM em dois projetos se arrumar em um já arrumei em outro... eita - É o mesmo botãozinho em cada componente. E se for um TDBSpeedButtonLookupComboBox, tem que dizer qual é o formulário alvo em cada formulário criado. Se não quiser dizer qual é o form, tem que ser MVP. - Em herança de formulário você não tem como dizer que o ID_x aponta para a tabela x e que o formulário para fazer a alteração/inclusão é x. Se tivesse não seria herança de formulário, seria MVP. - DBNavigator não abre janela, e se abrir, você tem que dizer qual é a janela. E tem que destruir. E se duvidar, vai ser modal para que essa janela não bombeie o resto do sistema. E se nada disso der trabalho, não é DBNavigator, é MVP. - Herança, e não recursividade. - Pare de dar murro em ponta de faca, pergunte antes de falar bobagem. Se você tem certeza então não faça pergunta; se você tem dúvida, faça pergunta e não diga o que você acha. Para um programador Assembly você está me saindo um perfeito arrastador de componente. se compilou aquele PHONEBOOK ?? to loco pra testar a performance do bixim Leia os Readme. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Com certeza. Não existem nenhuma relação entre MVP/MVC/OPF/OO e baixa produtividade ou DBAware relacional e falta de controle/projeto ruim. Afirmações assim são dogmas que as pessoas criam em suas mentes ou relatos de experiencias (muitas vezes em função do uso alienado de tecnologias pasteurizadas e pouca base computacional) ou do uso de IMPLEMENTAÇÕES RUINS, nada mais. - Original Message - From: anderson To: delphi-br@yahoogrupos.com.br Sent: Thursday, November 30, 2006 4:44 PM Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! É possivel então eu ter o OPF com ECO, continuando usando DBWares e utilizar MVP _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Joao Morais Enviada em: quinta-feira, 30 de novembro de 2006 15:11 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Anderson, Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Compete ao desenvolvedor saber aonde e como utilizá-los. O que acontece muitas vezes é que o camarada não conseguiu ser bem sucedido naquele recurso e adquire uma certa rejeição a ele ou então utilizou-os de forma errada, e aí a coisa saiu de controle. Resultado: Na ótica dele, isto tudo é ruim, não funciona, não presta. Mas não é. Por exemplo: Você pode plenamente usar DBWares para a confecção de cadastros visando a entrada de dados que irão interagir nas regras de negócios, já que cadastros são apenas inserção de dados nas tabelas e utilizar frameworks/OO na implementação das regras de negócio, até mesmo porque, se você trabalhar em uma grande corporação, verá que os processos internos compartilham alguma coisa em comum. Então, este compartilhar alguma coisa em comum podemos OOPzá-los, reaproveitando-se com isto, em novos projetos. E é aí que é fundamental você saber trabalhar com OOP. Aliás, você pode até desenvolver um sistema todinho todinho em OOP. Mas isto vai depender muito mais dos seus conhecimentos em programação OO e do cronograma do que da sua vontade mesmo. O que estamos discutindo aqui nesta thread, e eu até expus no meu ponto de vista, é que em um projeto, tem lugar pra todo mundo, basta saber AONDE IREMOS ALOCAR CADA TECNOLOGIA. O problema é quando vai alocar OOP aonde não precisa e vai usar DBWare aonde não deveria ser utilizado. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, anderson [EMAIL PROTECTED] escreveu É possivel então eu ter o OPF com ECO, continuando usando DBWares e utilizar MVP _ De: delphi-br@yahoogrupos.com.br [mailto:delphi- [EMAIL PROTECTED] Em nome de Joao Morais Enviada em: quinta-feira, 30 de novembro de 2006 15:11 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
O que me impede de reaproveitar código usando DBWare? Eu faço isso, ou seja, tenho algumas telas que são idênticsa e vários sistemas... mais uma vez eu digo, o erro não está no Objeto e sim no Sujeito. []s Em 01/12/06, Joao Morais [EMAIL PROTECTED] escreveu: Walter Chagas (Yahoo) wrote: Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Permita-me corrigi-lo: MVP faz exatamente o que DBWare faz, porém de forma orientada a objetos. Desta forma não tem cabimento colocá-los em um mesmo projeto. DBWare é bom pra quem não tem paciência pra oop. Se você quer reaproveitamento de código de interação com o usuário, você troca DBWare por MVP. -- João Morais -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Hehehehe, cê tá começando a ceder :) Já admite que alguém possa usá-lo por um motivo (falta de paciencia), mas eu corrijo, porque alguém possa usá-lo também por falta de tempo disponível no cronograma. Na verdade João, a sua proposta é tão interessante que muitos aqui (incluindo eu) resolvemos pesquisar pra ver o que acha a respeito. Foi valido a procura e a pesquisa sobre MVP e tudo mais, mas ainda continuo achando que o bom dessa aplicabilidade seria no tangente a regras de negócios, mas deixa pra lá. Apesar de eu não ser bom em OOP, vou pesquisar mais sobre o assunto e dar umas estudadas nos códigos. Quem sabe eu acabo também seguindo sua doutrina :) Mas lembrando que para mexer com estes Frameworks, o camarada tem que ter a manha de OOP, do contrario vai é acabar misturando OO com PE e começar a andar em circulos.. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Walter Chagas (Yahoo) wrote: Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Permita-me corrigi-lo: MVP faz exatamente o que DBWare faz, porém de forma orientada a objetos. Desta forma não tem cabimento colocá-los em um mesmo projeto. DBWare é bom pra quem não tem paciência pra oop. Se você quer reaproveitamento de código de interação com o usuário, você troca DBWare por MVP. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Acho que vc esta redondamente equivocado nesta parte Campus
pra isso que existem os DATAMODULES / ( PROCEDURES / FUNCTIONS / OnEvent´s
)-RECURSIVOS eu só faço a parte de pesquisa uma unica vez... se ta loco
fica colocando um TTABLE em cada FORM hehehehhe
Um exemplo RECURSIVO USANDO BeforePOST( bla bla ), em todas as minhas tabelas
(uso MySQL) tem o campo 'lastuser' que é o ultimo usuário que
cadastrou/modificou o registro.
Em todas as tabelas eu uso esse unico evento... crio ele uma unica vez e nos
BEFOREPOST eu seleciono o EVENTO que já esta criado (a data hora é um
campo TIMESTAMP no MySQL, assim nem me preocupo com ela)
procedure TMD_BeforePostALL( dataset : TDataSet ); // ALL porque é usado para
todos
Begin
DataSet.FieldByName('lastuser').AsString := (f_principal.l_user); // pega
o usuário do form.principal...
End;
Luiz Escobar
Analista/Desenvolvedor:
WEB - HTML/JavaScript/PHP/MySQL
WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase
DOS - Clipper/Assembler xBase
SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k
LINUX - LAZARUS/Kylix/MySQL;
http://www.megasistema.com.br
- Original Message -
From: Campus
To: delphi-br@yahoogrupos.com.br
Sent: Thursday, November 30, 2006 3:28 PM
Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz eu tb estou olhando mais de perto isso.
O bom é que tu pode criar uma classe TCliente, e chamando o retrieve, por
exemplo, carregar os dados do banco.
O ganho é que tu faz isso na classe, e só instancia o objeto.
Com TDataSet, se em cada form tu for colocar um TTable ou um TQuery para
buscar esses dados, tu vai ter que localizar o cliente corespondente, ou com
Locate, ou com um GotoKey. Em resumo, e sempre tem que escrever muito
código.
Já no caso, usando um objeto cliente, tu escreve esse código uma vez só e
pronto.
- Original Message -
From: Luiz Escobar [EMAIL PROTECTED]
To: delphi-br@yahoogrupos.com.br
Sent: Thursday, November 30, 2006 2:01 PM
Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Andreano, não é achar que não deve ter, é ter certeza que não precisa
ter.
Opa, isso precisa ter muita base pra falar né futuro matuzalem
É sempre questão de preferência. Falo por mim, estou apenas expondo
vantagens de um modelo orientado a objetos perante o RAD (com exceção de
usar TDataset como objeto de negócio - isso é roda quadrada).
HUmmm uma questao de preferencias. agora melhorou
TDataset é orientado a tabela, OPF é orientado a objetos do domínio do
problema.
==TDataset==
TabCliente.Open; // ou .Query := 'xx';
TabCliente.Locate(); // ou TabCliente.Open;
TabCliente.Edit
TabClienteNOME := 'Outro';
TabCliente.Post;
e se tiver Cached updates... transação...
ai vc coloca um APPLYUPDATE(-1) e ta tudo certo
==OPF==
Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc.
Cliente.Nome := 'Outro Nome';
Cliente.Save; -- cache, controle transacional, tudo aqui dentro.
E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra
TDataset.
Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho um
SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias
alterações e mando salvar tudo de uma vez para que se der um problema eu
possa fazer um ROLLBACK ???
Este exemplo ta meio desproporcional...
Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo
mesmo porque os controles ficaram mais ainda longe das mãos dos
programadores não que eu não ache isso maravilhoso, muito pelo
contrario, quanto menos codigo melhor...
BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um
DBWARE ? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as coisas,
vou ter que fazer um label1.caption := cliente.nome ?
Explique mais, ou mostre onde posso conseguir mais coisa to começando a
gostar do bixim
==DBAware==
DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em
um componente (DB*) e a um datasource. Se você quer um componente
'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset
estiver em um DataModule e por desencargo do destino a ligação quebrar
(nisso o Delphi melhorou um bocado), você tem que reabrir o form e
refazer a bendita.
é isso de quebrar realmente acontecia muito com D2 mas no D6 nunca
aconteceu comigo
==MVP==
MVP é totalmente desacoplado, é o framework que entende o componente, e
não o contrário. O formulário que usa o padrão MVP *não tem código*,
você pode mandar os .pas e os .dfm para uma empresa de design, entregar
uma licença de Delphi pra eles, eles usam qualquer componente que eles
quiserem, você tras os novos formulários para o seu projeto e recompila.
A única exigência é que os componentes continuem com o mesmo nome,
porque MVP pode ser
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Respondendo todas as suas perguntas abaixo não, faço isso uma vez Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Friday, December 01, 2006 10:14 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Fellipe Henrique wrote: O que me impede de reaproveitar código usando DBWare? Eu faço isso, ou seja, tenho algumas telas que são idênticsa e vários sistemas... mais uma vez eu digo, o erro não está no Objeto e sim no Sujeito. Você não tem que setar sempre o DataSource, DataField, KeyField, ListField, criar um botão pra criar novo cliente, criar atalhos pra incluir novo item no Grid e coisas afins? Eu conheço MVP e DBWare, estou falando por experiência, não estou jogando. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
RES: RES: [delphi-br] Re: Usar ou não usar DBWares ? Eis a questão!
Entendi, mas vamos supor entaum, eu posso suar ECO como OPF e usar uma camada MVP para desacoplar ao maximo possível DB / MODELO / APRESENTAÇÃO certo ? _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Joao Morais Enviada em: quinta-feira, 30 de novembro de 2006 16:27 Para: delphi-br@yahoogrupos.com.br Assunto: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! anderson wrote: É possivel então eu ter o OPF com ECO, continuando usando DBWares e utilizar MVP DBWare e MVP são inimigos mortais! Brincadeira. É o mesmo você dizer que quer sair de carro e moto ao mesmo tempo. MVP é um padrão para apresentação de dados, assim como DBWare. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
[Fatal Error] PressInstantObjectsBroker.pas(33): File not found: 'InstantConnectionManager.dcu' tentei compilar o trem do phonebook e nada isso no D6-PRO tem como vc mandar o executavel compilado, funcionando pra mim ? quero alimentar o banco e ver a performance do bixim na pratica... UAI, acho que vc falou, algo e eu entendi alga ou virce-versa... hehhehe Sempre que eu criar um novo FORM eu tenho que setar os DATASET´s, DATASOURCE´s, DATAFIELD´s..., mas isso uma vez, setou cabou ai é só fazer os EVENTos que eu precisar para testar CGC/CPF etc e tal... e pronto Eu queria o executavel disso ai, com o banco alimentado para ver a performance do carinha em XML, já vi que vai ser LENTO da dedel MAS QUERO TESTAR DBWARE com XML e o MVP com o XML Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Friday, December 01, 2006 3:30 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Luiz Escobar wrote: Respondendo todas as suas perguntas abaixo não, faço isso uma vez Eu já havia prometido largar essa thread, mas eu não resisto. Por favor, diga como você faz isso! -- João Morais Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Friday, December 01, 2006 10:14 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Fellipe Henrique wrote: O que me impede de reaproveitar código usando DBWare? Eu faço isso, ou seja, tenho algumas telas que são idênticsa e vários sistemas... mais uma vez eu digo, o erro não está no Objeto e sim no Sujeito. Você não tem que setar sempre o DataSource, DataField, KeyField, ListField, criar um botão pra criar novo cliente, criar atalhos pra incluir novo item no Grid e coisas afins? [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Pera ai, quem disse que com DBWARE não dá pra fazer reaproveitamento de código ? Talvez não no mesmo nivel, mas que dá, dá! Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Friday, December 01, 2006 9:39 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Permita-me corrigi-lo: MVP faz exatamente o que DBWare faz, porém de forma orientada a objetos. Desta forma não tem cabimento colocá-los em um mesmo projeto. DBWare é bom pra quem não tem paciência pra oop. Se você quer reaproveitamento de código de interação com o usuário, você troca DBWare por MVP. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
é isso ai Luiz Escobar Analista/Desenvolvedor: - Original Message - From: Fellipe Henrique To: delphi-br@yahoogrupos.com.br Sent: Friday, December 01, 2006 9:53 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! O que me impede de reaproveitar código usando DBWare? Eu faço isso, ou seja, tenho algumas telas que são idênticsa e vários sistemas... mais uma vez eu digo, o erro não está no Objeto e sim no Sujeito. []s Em 01/12/06, Joao Morais [EMAIL PROTECTED] escreveu: Walter Chagas (Yahoo) wrote: Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Permita-me corrigi-lo: MVP faz exatamente o que DBWare faz, porém de forma orientada a objetos. Desta forma não tem cabimento colocá-los em um mesmo projeto. DBWare é bom pra quem não tem paciência pra oop. Se você quer reaproveitamento de código de interação com o usuário, você troca DBWare por MVP. -- João Morais -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Nada em informática é 100%, inclusive o ECO. Programar utilizando MVP, em Delphi, tb não quer dizer 100% OO, pois nem o Delphi é 100% OO... MD --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Mas vc tem que configurar os campos, de uma mesma tabela, em vários forms diferentes, caso vc queira manipular os campos de uma tabela em mais de um form... A tecnologia RAD deixa mais fácil o que é fácil de fazer e mais difícil o que é difícil. mD --- Em delphi-br@yahoogrupos.com.br, Fellipe Henrique [EMAIL PROTECTED] escreveu O que me impede de reaproveitar código usando DBWare? Eu faço isso, ou seja, tenho algumas telas que são idênticsa e vários sistemas... mais uma vez eu digo, o erro não está no Objeto e sim no Sujeito. []s Em 01/12/06, Joao Morais [EMAIL PROTECTED] escreveu: Walter Chagas (Yahoo) wrote: Isto é plenamente possível sim. Não quer dizer que se voce for usar DBWares deverá renunciar ao outro ou vice versa. MVP/OO São recursos que podem conviver plenamente com os DB. Permita-me corrigi-lo: MVP faz exatamente o que DBWare faz, porém de forma orientada a objetos. Desta forma não tem cabimento colocá-los em um mesmo projeto. DBWare é bom pra quem não tem paciência pra oop. Se você quer reaproveitamento de código de interação com o usuário, você troca DBWare por MVP. -- João Morais -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
RES: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Deixar os forms sem implentação para deixar o código em outro lugar não acaba com o problema; pode até ficar mais complexo. Temos que pensar no _objetivo_ final, não na _forma_ como é feito. mD --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu anderson wrote: Entendi, mas vamos supor entaum, eu posso suar ECO como OPF e usar uma camada MVP para desacoplar ao maximo possível DB / MODELO / APRESENTAÇÃO certo ? Desacoplar do banco você pode fazer com ClientDataSet ou DBExpress. Com OPF (ECO, por exemplo) além de desacoplar você tem objetos de negócio de verdade, e com hierarquia de classe, tipo: TContato-TPessoa-TCliente, caso seu projeto precise. Você tem também cache e controle transacional controlados pelo framework, evita repetição de código e de tratamentos de erro. O MVP faz com que você reaproveite código de apresentação e deixa os seus forms totalmente sem implementação. -- João Morais
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
- Segue mensagem original! - De: Joao Morais [EMAIL PROTECTED] Ceder? Eu? è ta sim, já ta concordando com os TDATASET´s... heheheh Mas lembrando que para mexer com estes Frameworks, o camarada tem que ter a manha de OOP, do contrario vai é acabar misturando OO com PE e começar a andar em circulos.. Mas com certeza! Ta vendo já não é tão facil... Posso até adiantar uns conceitos pra você. Na boa! Meros pontos de vista de quem gosta de pegar um bom desafio: Desafio ? que nada gosto de ver a coisa fluindo e rodando o mais rapido possivel se não a produtividade vai pro [EMAIL PROTECTED] TDataset: É legal, você tem acesso direto à tabela, faz pesquisas e atualizações super-otimizadas. Ninguém bate TDataset em desempenho, apenas um louco faria um retrieve de trocentos objetos para fazer um reajuste de preço em 10%. TDataset mata a pau. Pronto chego no ponto TDataSet mata a PAU!!!... OPF: Agora, se você está escrevendo a lógica do sistema, esquece TDataset. Teus problemas são objetos, TDataset são tabelas e eles não combinam. Usar OPF pra cadastrinho já ajuda porque você não precisa daquela tranqueira de Locate/Edit/Post/Cancel, etc. Usar OPF pra hierarquia de classes, putz... pode escrever, é impossível você fazer um trabalho legal com TDataset porque o componente não entende de hierarquia de classes. Falo em coisa do tipo TContato-TPessoa-TCliente ... Usar OPF pra CADASTRINHO ? Pô João uma hora é pra coisa grande a longo prazo... etc.. e tal... agora pra cadastrinho ? e outra EDIT/POST/CANCEL ??? isso o DBNAGIGATOR faz e um locate não da tanto trabalho como vc ta falando... DBWare: Nada como ter tudo ao alcance de uns clicks. Dá pra fazer um cadastro funcional em minutos (5, 10), batendo papo e dando uns goles em uma xicrinha de café. O componente entende tudo de ler, gravar, buscar em outra tabela, etc. Mumu. Pronto adimitiu de vez... DBWare mada a PAU!!!... MVP: Mas o problema começa quando você percebe que perde tempo demais fazendo botãozinho do lado do combo pra cadastrar cliente, ou inventar uma ginástica diferente porque o cliente quer digitar um pedaço do nome e o componente retornar as opções dentro daquela pesquisa. Pior quando você quer, com um click, criar um novo cliente. Isso pode ser feito com DBWare mais um saco de paciência. E isso não é legal, pois cada novo projeto, cada novo form tem aquela mesma manobra. MVP soluciona isso. Tudo quanto é tranqueira desse tipo que você cria para o primeiro componente do primeiro form do primeiro projeto, é reaproveitado nos demais. Quando você acha um erro na implementação, o conserto de um é o conserto de todos os outros ao mesmo tempo. Aqui eu pergunto -- isto não é ganho de produtividade no médio prazo? Fazer botãozinho do lado do combo pra cadastrar da trabalho ? onde ? Fazer ginastica para digitar e achar o cliente ? VC não conhece o MyDAC né ? ele tem isso no DBGRID que o acompanha.. e muito mais Criar um novo cliente ? novamente DBNAVIGATOR. Novo FORM novo PROJETO ? mesma manobra ? e a parte RECURSIVA se é igual só copiar FORM de um pro outro e olhe lá... se vc já sabe que vai reusar é só inserir no novo projeto... e VUA-LA, ta lá... heeeheee Quanto a erros, bons se eu uso 1 FORM em dois projetos se arrumar em um já arrumei em outro... eita Nesse ponto eu volto a fazer a pergunta original dessa thread campeã: Usar ou não usar DBWare? E completo - por quê sim, por quê não? Justifique sua resposta com consciência. Acabei de fazer isso acima... Tudo isso que eu coloquei exige doses cavalares de OOP, e quem estiver preparado para esse tipo de desenvolvimento estará na frente -- construindo softares em cada vez menos tempo, com cada vez mais qualidade. doses cavalares de OOP não significa produtividade pra quem FAZ, talvez pra quem vá arrumar mais tarde e olhe lá... Sim, OPF, MVP, enfim tudo relacionado a 100% OOP vale muito a pena. Sei não... se compilou aquele PHONEBOOK ?? to loco pra testar a performance do bixim Luiz Escobar
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
É isso aí Andreano, DBWare são muito bem vindos, deste que o programador saiba usar. A grande maioria que fala mal dele, não o conhece muito... []s Em 30/11/06, Andreano Lanusse [EMAIL PROTECTED] escreveu: Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Abraços, Andreano Lanusse System Engineer CodeGear [As partes desta mensagem que não continham texto foram removidas] -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Você mesmo é um que deve se lembrar como eu metia o pau nos DBWares antes né? Lá pros remotos D1 e D2, ainda meio cru em conhecimento do Delphi e da VCL, me meti a embarcar nessa canoa e me dei muito mal. Tomei raiva do negócio e passei a usar a Suite Munhecaware. Recentemente, com grande ajuda dos colegas Eduardo Rocha da EduDelphipage, Mequi Pinho, Bruno Lichot e até de você Rubem, revi meus conceitos a respeito do supra-citado. Aprendi a usá-los da forma correta e hoje não volto atrás nem fudendo. O grande problema do DBWare é que ele aparenta facilitar a vida do desenvolvedor sem que ele tenha que escrever uma única linha de código sequer. Aí que tá a ilusão. Você ainda assim tem que escrever, mas não é TANTO quanto seria fazer na mão, mas tem. Aí o cara vê que a coisa não funciona, porque não soube usar ou usou de forma errada, o troço vai dar problema e como sabemos muito bem, o ser humano jamais assume seus erros e sua culpa. A culpa é sempre do vizinho, do Governo, do DBEdit, do Delphi, do Andreano, etc... Alias pessoal, sem querer fazer propaganda, mas o CD do Eduardo, que trata justamente disto, é uma senhora mão na roda viu. Convem o pessoal dar uma olhada. Ele tá sempre ministrando Minicursos de ClientDataset nos DDDs quem vem acontecendo aí anualmente. Quem já assitiu um viu que a coisa é de nível. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Fellipe Henrique [EMAIL PROTECTED] escreveu É isso aí Andreano, DBWare são muito bem vindos, deste que o programador saiba usar. A grande maioria que fala mal dele, não o conhece muito... []s Em 30/11/06, Andreano Lanusse [EMAIL PROTECTED] escreveu: Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Abraços, Andreano Lanusse System Engineer CodeGear [As partes desta mensagem que não continham texto foram removidas] -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
hehe, o que tenho visto muito aqui no trabalho, é o pessoal usando eventos OnChange de DbEdits por exemplo, mas acabam tendo efeitos colaterais, uma vez que o evento é disparado quando o estado do Dataset modifica quando se abre, fecha ou ainda em casos de pesquisa com SetKey-Gotokey/GotoNearest. Esse tipo de bug muitas vezes é dificil de achar, pricipalmente no caso de uso de datamodules, no caso de serem usados por diversos forms. Isso não é um problema do componente, ele faz exatamente o que tem que fazer, o programador é que desconhece o funcionamento do mesmo. - Original Message - From: Rubem Nascimento da Rocha [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 11:56 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! maniacapordelphi, eu lhe desafio vc a me dizer pq controles data-aware lhe causam resultados inesperados! Se vc me provar isso, eu abandono tudo o que eu sei hoje sobre o uso de controles data-aware. Sds. From: Joao Morais [EMAIL PROTECTED] Reply-To: delphi-br@yahoogrupos.com.br To: delphi-br@yahoogrupos.com.br Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Date: Wed, 29 Nov 2006 18:41:09 -0200 maniacapordelphi wrote: Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? Se existisse alguma culpa, seria do TDataset e não do DBAware. Mas geralmente OPFs são mais lentos do que o TDataset braçal (ponto pro RAD), DBAware faz meramente a apresentação dos dados. Nesse caso concordo com os colegas Felipe e Walter, isso tem dedo do programador. -- João Morais _ MSN Busca: fácil, rápido, direto ao ponto. http://search.msn.com.br -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.14.19/556 - Release Date: 28/11/2006 15:22
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Nunca tive problema algum com DBWARE´s Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Rubem Nascimento da Rocha To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 11:56 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! maniacapordelphi, eu lhe desafio vc a me dizer pq controles data-aware lhe causam resultados inesperados! Se vc me provar isso, eu abandono tudo o que eu sei hoje sobre o uso de controles data-aware. Sds. From: Joao Morais [EMAIL PROTECTED] Reply-To: delphi-br@yahoogrupos.com.br To: delphi-br@yahoogrupos.com.br Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Date: Wed, 29 Nov 2006 18:41:09 -0200 maniacapordelphi wrote: Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? Se existisse alguma culpa, seria do TDataset e não do DBAware. Mas geralmente OPFs são mais lentos do que o TDataset braçal (ponto pro RAD), DBAware faz meramente a apresentação dos dados. Nesse caso concordo com os colegas Felipe e Walter, isso tem dedo do programador. -- João Morais __ MSN Busca: fácil, rápido, direto ao ponto. http://search.msn.com.br [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
APOIADO... Luiz Escobar Analista/Desenvolvedor: Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Abraços, Andreano Lanusse System Engineer CodeGear [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Andreano, não é achar que não deve ter, é ter certeza que não precisa ter. Opa, isso precisa ter muita base pra falar né futuro matuzalem É sempre questão de preferência. Falo por mim, estou apenas expondo vantagens de um modelo orientado a objetos perante o RAD (com exceção de usar TDataset como objeto de negócio - isso é roda quadrada). HUmmm uma questao de preferencias. agora melhorou TDataset é orientado a tabela, OPF é orientado a objetos do domínio do problema. ==TDataset== TabCliente.Open; // ou .Query := 'xx'; TabCliente.Locate(); // ou TabCliente.Open; TabCliente.Edit TabClienteNOME := 'Outro'; TabCliente.Post; e se tiver Cached updates... transação... ai vc coloca um APPLYUPDATE(-1) e ta tudo certo ==OPF== Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc. Cliente.Nome := 'Outro Nome'; Cliente.Save; -- cache, controle transacional, tudo aqui dentro. E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra TDataset. Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho um SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias alterações e mando salvar tudo de uma vez para que se der um problema eu possa fazer um ROLLBACK ??? Este exemplo ta meio desproporcional... Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo mesmo porque os controles ficaram mais ainda longe das mãos dos programadores não que eu não ache isso maravilhoso, muito pelo contrario, quanto menos codigo melhor... BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um DBWARE ? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as coisas, vou ter que fazer um label1.caption := cliente.nome ? Explique mais, ou mostre onde posso conseguir mais coisa to começando a gostar do bixim ==DBAware== DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em um componente (DB*) e a um datasource. Se você quer um componente 'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset estiver em um DataModule e por desencargo do destino a ligação quebrar (nisso o Delphi melhorou um bocado), você tem que reabrir o form e refazer a bendita. é isso de quebrar realmente acontecia muito com D2 mas no D6 nunca aconteceu comigo ==MVP== MVP é totalmente desacoplado, é o framework que entende o componente, e não o contrário. O formulário que usa o padrão MVP *não tem código*, você pode mandar os .pas e os .dfm para uma empresa de design, entregar uma licença de Delphi pra eles, eles usam qualquer componente que eles quiserem, você tras os novos formulários para o seu projeto e recompila. A única exigência é que os componentes continuem com o mesmo nome, porque MVP pode ser bom, mas não é feiticeiro. HUmmm isso realmente parece bom... Teria mais um monte pra falar, mas encerro aqui minha participação nessa thread com esse mini-artigo (a menos que os colegas tenham dúvidas). Vixe... varias... mas vamos deixar para quando vc chegar no BETA ai eu vou ser um que vai querer testar isso ai... porque em PRÉ-ALFA, num vai dar Valeu e obrigado Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Olá galera Não acredito que o uso de TDataset seja ruim assim como citado, nem o uso de componentes DB-aware. Esse componentes são usados com muito sucesso aqui na empresa e ao mesmo tempo conseguimos manter a aplicação com as três camadas (persistência, regra de negócios e apresentação) muito bem separadas. Eu já tive alguns problemas com db-aware, mas quando eu necessitava de alguma funcionalidade um pouco diferente na interface, dai então carregava o componente com dados via código. Mas fora isso, o datasource nos dá um ganho de produtividade muito alto. Quanto ao uso de objetos de negócio ao invés de Tdataset, como citado anteriormente, não vejo vantagens na abordagem, já que necessita um duplo trabalho ao trazer os dados do banco em Datasets (ou existe outra forma de fazer) e depois popular objetos, tarefa essa realizada pelo OPF, e que poderia ser feita em um passo apenas. Além disso, existem funcionalidades de performance dos Datasets e Datasources como trazer os dados sobre demanda, sem contar o sistema de clientdataset e providers que estão prontos e que teriam que ser reimplementados pelo MVC. Usamos uma abordagem ao desenvolver a SpeedCASE onde o padrão Adapter faz com que as propriedades das classes de regras de negócio sejam mapedas para os campos das tablelas de forma transparente pelo nosso framework de regras de negócio, sem que se conheça qualquer detalhe da persistência, mas sem perder funções importantes de Tdatasets, como Edit, Post e Apply e com a possibilidade de usar db-aware, pois cada classe possui um dataset interno. Bom, espero não ter me alongado muito e mostrado a abordagem que utilizamos por aqui. Abraço a todos On 11/30/06, Joao Morais [EMAIL PROTECTED] wrote: Andreano Lanusse wrote: Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Andreano, não é achar que não deve ter, é ter certeza que não precisa ter. É sempre questão de preferência. Falo por mim, estou apenas expondo vantagens de um modelo orientado a objetos perante o RAD (com exceção de usar TDataset como objeto de negócio - isso é roda quadrada). Vou aproventar sua mensagem para citar uma vantagem de cada lado (de OPF e de MVP, lógico). TDataset é orientado a tabela, OPF é orientado a objetos do domínio do problema. ==TDataset== TabCliente.Open; // ou .Query := 'xx'; TabCliente.Locate(); // ou TabCliente.Open; TabCliente.Edit TabClienteNOME := 'Outro'; TabCliente.Post; e se tiver Cached updates... transação... ==OPF== Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc. Cliente.Nome := 'Outro Nome'; Cliente.Save; -- cache, controle transacional, tudo aqui dentro. E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra TDataset. ==DBAware== DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em um componente (DB*) e a um datasource. Se você quer um componente 'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset estiver em um DataModule e por desencargo do destino a ligação quebrar (nisso o Delphi melhorou um bocado), você tem que reabrir o form e refazer a bendita. ==MVP== MVP é totalmente desacoplado, é o framework que entende o componente, e não o contrário. O formulário que usa o padrão MVP *não tem código*, você pode mandar os .pas e os .dfm para uma empresa de design, entregar uma licença de Delphi pra eles, eles usam qualquer componente que eles quiserem, você tras os novos formulários para o seu projeto e recompila. A única exigência é que os componentes continuem com o mesmo nome, porque MVP pode ser bom, mas não é feiticeiro. Teria mais um monte pra falar, mas encerro aqui minha participação nessa thread com esse mini-artigo (a menos que os colegas tenham dúvidas). -- João Morais -- -- Flávio G. Maltempe Publisoft Informática Maringá - PR http://www.publisoft.com.br http://www.speedcase.com.br -- [As partes desta mensagem que não continham texto foram removidas]
RE: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO From: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] On Behalf Of Joao Morais Sent: Thursday, November 30, 2006 2:30 AM To: delphi-br@yahoogrupos.com.br Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Andreano Lanusse wrote: Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Andreano, não é achar que não deve ter, é ter certeza que não precisa ter. É sempre questão de preferência. Falo por mim, estou apenas expondo vantagens de um modelo orientado a objetos perante o RAD (com exceção de usar TDataset como objeto de negócio - isso é roda quadrada). Vou aproventar sua mensagem para citar uma vantagem de cada lado (de OPF e de MVP, lógico). TDataset é orientado a tabela, OPF é orientado a objetos do domínio do problema. ==TDataset== TabCliente.Open; // ou .Query := 'xx'; TabCliente.Locate(); // ou TabCliente.Open; TabCliente.Edit TabClienteNOME := 'Outro'; TabCliente.Post; e se tiver Cached updates... transação... ==OPF== Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc. Cliente.Nome := 'Outro Nome'; Cliente.Save; -- cache, controle transacional, tudo aqui dentro. E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra TDataset. ==DBAware== DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em um componente (DB*) e a um datasource. Se você quer um componente 'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset estiver em um DataModule e por desencargo do destino a ligação quebrar (nisso o Delphi melhorou um bocado), você tem que reabrir o form e refazer a bendita. ==MVP== MVP é totalmente desacoplado, é o framework que entende o componente, e não o contrário. O formulário que usa o padrão MVP *não tem código*, você pode mandar os .pas e os .dfm para uma empresa de design, entregar uma licença de Delphi pra eles, eles usam qualquer componente que eles quiserem, você tras os novos formulários para o seu projeto e recompila. A única exigência é que os componentes continuem com o mesmo nome, porque MVP pode ser bom, mas não é feiticeiro. Teria mais um monte pra falar, mas encerro aqui minha participação nessa thread com esse mini-artigo (a menos que os colegas tenham dúvidas). -- João Morais [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
É possivel então eu ter o OPF com ECO, continuando usando DBWares e utilizar MVP _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Joao Morais Enviada em: quinta-feira, 30 de novembro de 2006 15:11 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Andreano Lanusse wrote: O que você diz de OPF é o que o ECO faz. mas unindo os 2 mundos DataWare e 100% OO Apenas para fins de esclarecimento: - Eu não disse que a Borland não tem um framework OPF; - 100% OO é uma opinião, e não um fato. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Olá galera Não acredito que o uso de TDataset seja ruim assim como citado, nem o uso de componentes DB-aware. Esse componentes são usados com muito sucesso aqui na empresa e ao mesmo tempo conseguimos manter a aplicação com as três camadas (persistência, regra de negócios e apresentação) muito bem separadas. Eu já tive alguns problemas com db-aware, mas quando eu necessitava de alguma funcionalidade um pouco diferente na interface, dai então carregava o componente com dados via código. Mas fora isso, o datasource nos dá um ganho de produtividade muito alto. Quanto ao uso de objetos de negócio ao invés de Tdataset, como citado anteriormente, não vejo vantagens na abordagem, já que necessita um duplo trabalho ao trazer os dados do banco em Datasets (ou existe outra forma de fazer) e depois popular objetos, tarefa essa realizada pelo OPF, e que poderia ser feita em um passo apenas. Além disso, existem funcionalidades de performance dos Datasets e Datasources como trazer os dados sobre demanda, sem contar o sistema de clientdataset e providers que estão prontos e que teriam que ser reimplementados pelo MVC. Usamos uma abordagem ao desenvolver a SpeedCASE onde o padrão Adapter faz com que as propriedades das classes de regras de negócio sejam mapedas para os campos das tablelas de forma transparente pelo nosso framework de regras de negócio, sem que se conheça qualquer detalhe da persistência, mas sem perder funções importantes de Tdatasets, como Edit, Post e Apply e com a possibilidade de usar db-aware, pois cada classe possui um dataset interno. Bom, espero não ter me alongado muito e mostrado a abordagem que utilizamos por aqui. Abraço a todos -- Flávio G. Maltempe Publisoft Informática Maringá - PR http://www.publisoft.com.br http://www.speedcase.com.br -- [As partes desta mensagem que não continham texto foram removidas]
Res: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Nem terminei de ler o e-mail mas já sugiro que procure no Google por DePO ou
InstantObjects ou PressObjects e leia um pouco dos fóruns tanto do DePO
quanto do InstantObjects. Acho que vc vai se surpreender com o que vai achar.
- Mensagem original
De: Luiz Escobar [EMAIL PROTECTED]
Para: delphi-br@yahoogrupos.com.br
Enviadas: Quinta-feira, 30 de Novembro de 2006 14:01:21
Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Andreano, não é achar que não deve ter, é ter certeza que não
precisa ter.
Opa, isso precisa ter muita base pra falar né futuro matuzalem... .
É sempre questão de preferência. Falo por mim, estou apenas expondo
vantagens de um modelo orientado a objetos perante o RAD (com exceção de
usar TDataset como objeto de negócio - isso é roda quadrada).
HUmmm uma questao de preferencias. agora melhorou
TDataset é orientado a tabela, OPF é orientado a objetos do domínio do
problema.
==TDataset==
TabCliente.Open; // ou .Query := 'xx';
TabCliente.Locate( ); // ou TabCliente.Open;
TabCliente.Edit
TabClienteNOME := 'Outro';
TabCliente.Post;
e se tiver Cached updates... transação...
ai vc coloca um APPLYUPDATE( -1) e ta tudo certo
==OPF==
Cliente := TCliente.Retrieve( ID); -- monta query, pesquisa, etc.
Cliente.Nome := 'Outro Nome';
Cliente.Save; -- cache, controle transacional, tudo aqui dentro.
E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra
TDataset.
Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho um
SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias
alterações e mando salvar tudo de uma vez para que se der um problema eu possa
fazer um ROLLBACK ???
Este exemplo ta meio desproporcional. ..
Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo
mesmo porque os controles ficaram mais ainda longe das mãos dos programadores.
... não que eu não ache isso maravilhoso, muito pelo contrario, quanto menos
codigo melhor...
BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um DBWARE
? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as coisas, vou ter
que fazer um label1.caption := cliente.nome ?
Explique mais, ou mostre onde posso conseguir mais coisa to começando a
gostar do bixim
==DBAware==
DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em
um componente (DB*) e a um datasource. Se você quer um componente
'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset
estiver em um DataModule e por desencargo do destino a ligação quebrar
(nisso o Delphi melhorou um bocado), você tem que reabrir o form e
refazer a bendita.
é isso de quebrar realmente acontecia muito com D2 mas no D6 nunca
aconteceu comigo
==MVP==
MVP é totalmente desacoplado, é o framework que entende o componente, e
não o contrário. O formulário que usa o padrão MVP *não tem código*,
você pode mandar os .pas e os .dfm para uma empresa de design, entregar
uma licença de Delphi pra eles, eles usam qualquer componente que eles
quiserem, você tras os novos formulários para o seu projeto e recompila.
A única exigência é que os componentes continuem com o mesmo nome,
porque MVP pode ser bom, mas não é feiticeiro.
HUmmm isso realmente parece bom...
Teria mais um monte pra falar, mas encerro aqui minha participação nessa
thread com esse mini-artigo (a menos que os colegas tenham dúvidas).
Vixe... varias... mas vamos deixar para quando vc chegar no BETA ai eu vou ser
um que vai querer testar isso ai... porque em PRÉ-ALFA, num vai dar
Valeu e obrigado
Luiz Escobar
Analista/Desenvolve dor:
WEB - HTML/JavaScript/ PHP/MySQL
WINDOWS - Delphi/MyDAC/ ASSEMBLER/ MySQL/xBase
DOS - Clipper/Assembler xBase
SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k
LINUX - LAZARUS/Kylix/ MySQL;
http://www.megasist ema.com.br
[As partes desta mensagem que não continham texto foram removidas]
!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
==OPF== Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc. Cliente.Nome := 'Outro Nome'; Cliente.Save; -- cache, controle transacional, tudo aqui dentro. E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra TDataset. Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho um SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias alterações e mando salvar tudo de uma vez para que se der um problema eu possa fazer um ROLLBACK ??? Este exemplo ta meio desproporcional... Por favor, esclareça melhor a sua dúvida (ou as dúvidas). Onde eu implemento uma TRANSAÇÂO ? se der pau para fazer um ROLLBACK. TIPO usado seu exemplo... : try cliente.insert; Cliente.Nome := 'fulano'; contrato.insert; Contrato.data := 'hoje'; nota.insert; nota.id := '1'; itens.insert; itens.nota := 'item 001'; cliente.save; contrato.save; nota.save; itens.save; ALL.APPLYUPDATE ( -1 ); - e somente aqui salva tudo e se der um pau exception all.roolback(); -- volta tudo sem cadastrar nadinha nos bancos !!! end; Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo mesmo porque os controles ficaram mais ainda longe das mãos dos programadores não que eu não ache isso maravilhoso, muito pelo contrario, quanto menos codigo melhor... Que controles você precisa? EU !, De nenhum Quando menos tiver que me preocupar com controles disso-daquilo melhor, ganho em produtividade... eu disse PRA QUEM ACHA, afinal a discusão era DBWARE ou não... BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um DBWARE ? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as coisas, vou ter que fazer um label1.caption := cliente.nome ? Explique mais, ou mostre onde posso conseguir mais coisa to começando a gostar do bixim Cliente := TCliente.Retrieve(ID); TClienteEditPresenter.Run(Cliente); Em duas linhas você traz o cliente, mostra pro usuário, o usuário altera o que quer, clica OK, e o que o usuário alterou é enviado para o banco em uma única transação. TClienteEditPresenter.Run; Em uma linha você faz tudo o que eu falei acima, mas ao invés de alterar, você cria um novo cliente. Detalhe - nem precisa se preocupar em criar instância de coisa nenhuma. Nem destruir (use o FastMM se você não acredita). Acho que vou precisar experimentar para ver como é o trem ai... pra continuar a thread.. hehehhe Pois tem que ter uma ligação pra esse RUN ai uai... ele tem que estar ligado a um FORM que vc construiu... o o negocio é magico d+ Vejo um exemplo que pra LOGIN o cara faz uma aplicação completa agora vc vem com 2 linha que abre, localiza, edit, salva, create, destroiu e nem ligou ela ao banco ele adinhou tudo... ai ficou vago... heheheheh ==DBAware== DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em um componente (DB*) e a um datasource. Se você quer um componente 'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset estiver em um DataModule e por desencargo do destino a ligação quebrar (nisso o Delphi melhorou um bocado), você tem que reabrir o form e refazer a bendita. é isso de quebrar realmente acontecia muito com D2 mas no D6 nunca aconteceu comigo E eu te juro que na época eu achava uma coisa normal. ==MVP== MVP é totalmente desacoplado, é o framework que entende o componente, e não o contrário. O formulário que usa o padrão MVP *não tem código*, você pode mandar os .pas e os .dfm para uma empresa de design, entregar uma licença de Delphi pra eles, eles usam qualquer componente que eles quiserem, você tras os novos formulários para o seu projeto e recompila. A única exigência é que os componentes continuem com o mesmo nome, porque MVP pode ser bom, mas não é feiticeiro. HUmmm isso realmente parece bom... Isso é só o começo. Teria mais um monte pra falar, mas encerro aqui minha participação nessa thread com esse mini-artigo (a menos que os colegas tenham dúvidas). Vixe... varias... mas vamos deixar para quando vc chegar no BETA ai eu vou ser um que vai querer testar isso ai... porque em PRÉ-ALFA, num vai dar Pré alfa não significa cangalha. Significa que ainda tem mais código pra vir. Eu, no seu lugar, baixaria e fuçaria até virar do avesso. Pra quem gosta de Assembly isso é um prato cheio. O framework está estável, como eu já te disse, tenho ele em produção. BLZ vamos ver no que vai dar. Mas assim como troquei o CLIPPER por DELPHI vou acabar trocando o DELPHI por PHP um dia. ;-) [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz Escobar wrote: DBAware não é um desconhecido pra mim, e confesso que eu fiz injustiça. A roda quadrada é usar TDataset como objeto de negócio. Isso dá mais dor de cabeça do que Whisky paraguaio. O TDataset da dor de cabeça pra quem não sabe usar, é como Whisky paraguaio, pra quem não sabe comprar e tomar... Outro Matuzalém. Esse ano completei 21 de programação, 18 de Basic, 16 de Clipper e Pascal (Turbo 3). Parece que foi ontem. Meu DEUS, outro Jovem que acha que sabe tudo que diz Até parece que vc não vai ser um matuzalém... e pior vai ser um dos teimosos e sem educação Já está acontecendo. DBAware em .net publica propriedades de objetos, e o InstantObjects tem um esquema parecido para win32 e propriedades publicadas via RTTI. Pra quem gosta de DBAware é um prato cheio. Bom seguinte meu caro, a conversa arqui é DBWARE ou ÑDBWare certo, referindo-se a RESUMINDO, DBEDIT ou EDIT, DBLISTBOX ou LISTBOX, sendo assim DBWare é muito melhor Outra, até que me provem ao contrario à matematica sempre foi exata, então 1+1=2+3=5, certo então quanto mais código para ser interpretado/executado/compilado, maior a aplicação e mais pesada para rodar nas maquinas, então enquanto o parque tecnologico são de maquinas mais modestas, os DBWare´s ainda vão ser a melhor opção, imagine uma aplicação Delphi 6-DWARE contra uma BDS2006-FrameWork-MVC, a diferença deve ser em MEGAS. então, veja se me entende, por enquanto DBWare´s são melhores em performance e em produtividade contra os Edit´s da vida BASTA vc saber usar, porque se vc não sabe usar então meu caro, ai num tem jeito não... Não disse que FRAMEWORK-MVC seja pior que DBWare´s, quiz dizer que ele ainda esta crescendo/amadurecendo e futuramente com maquinas melhores que as de hoje, com certeza seja mais uma opção ou à opção realmente melhor que os DBWare´s Ponto Final... DEU PRA ENTERDER !!!... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Luiz eu tb estou olhando mais de perto isso. O bom é que tu pode criar uma classe TCliente, e chamando o retrieve, por exemplo, carregar os dados do banco. O ganho é que tu faz isso na classe, e só instancia o objeto. Com TDataSet, se em cada form tu for colocar um TTable ou um TQuery para buscar esses dados, tu vai ter que localizar o cliente corespondente, ou com Locate, ou com um GotoKey. Em resumo, e sempre tem que escrever muito código. Já no caso, usando um objeto cliente, tu escreve esse código uma vez só e pronto. - Original Message - From: Luiz Escobar [EMAIL PROTECTED] To: delphi-br@yahoogrupos.com.br Sent: Thursday, November 30, 2006 2:01 PM Subject: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Andreano, não é achar que não deve ter, é ter certeza que não precisa ter. Opa, isso precisa ter muita base pra falar né futuro matuzalem É sempre questão de preferência. Falo por mim, estou apenas expondo vantagens de um modelo orientado a objetos perante o RAD (com exceção de usar TDataset como objeto de negócio - isso é roda quadrada). HUmmm uma questao de preferencias. agora melhorou TDataset é orientado a tabela, OPF é orientado a objetos do domínio do problema. ==TDataset== TabCliente.Open; // ou .Query := 'xx'; TabCliente.Locate(); // ou TabCliente.Open; TabCliente.Edit TabClienteNOME := 'Outro'; TabCliente.Post; e se tiver Cached updates... transação... ai vc coloca um APPLYUPDATE(-1) e ta tudo certo ==OPF== Cliente := TCliente.Retrieve(ID); -- monta query, pesquisa, etc. Cliente.Nome := 'Outro Nome'; Cliente.Save; -- cache, controle transacional, tudo aqui dentro. E olha que eu escolhi um modelo de dados sem herança, pra ficar mumu pra TDataset. Ta tirei o EDIT, quer dizer só mando o valor, sem dar um EDIT, mas tenho um SAVE = POST, os cache/transaction no OPF não existem ? onde eu faço varias alterações e mando salvar tudo de uma vez para que se der um problema eu possa fazer um ROLLBACK ??? Este exemplo ta meio desproporcional... Pra quem acha que EDIT´s são melhores que DBEDIT´s, isso ai Fudeu com tudo mesmo porque os controles ficaram mais ainda longe das mãos dos programadores não que eu não ache isso maravilhoso, muito pelo contrario, quanto menos codigo melhor... BOM mas o que o OPF do RETRIEVE usou para se ligar ao BANCO ? não foi um DBWARE ? tipo um TTABLE ? TQUERY ? TDATABASE ? e para visualizar as coisas, vou ter que fazer um label1.caption := cliente.nome ? Explique mais, ou mostre onde posso conseguir mais coisa to começando a gostar do bixim ==DBAware== DBAware é orientado a TDataset (win32) e ainda assim fica pendurado em um componente (DB*) e a um datasource. Se você quer um componente 'Combo' mais envenenado, ele tem que entender DBAware. Se o seu Dataset estiver em um DataModule e por desencargo do destino a ligação quebrar (nisso o Delphi melhorou um bocado), você tem que reabrir o form e refazer a bendita. é isso de quebrar realmente acontecia muito com D2 mas no D6 nunca aconteceu comigo ==MVP== MVP é totalmente desacoplado, é o framework que entende o componente, e não o contrário. O formulário que usa o padrão MVP *não tem código*, você pode mandar os .pas e os .dfm para uma empresa de design, entregar uma licença de Delphi pra eles, eles usam qualquer componente que eles quiserem, você tras os novos formulários para o seu projeto e recompila. A única exigência é que os componentes continuem com o mesmo nome, porque MVP pode ser bom, mas não é feiticeiro. HUmmm isso realmente parece bom... Teria mais um monte pra falar, mas encerro aqui minha participação nessa thread com esse mini-artigo (a menos que os colegas tenham dúvidas). Vixe... varias... mas vamos deixar para quando vc chegar no BETA ai eu vou ser um que vai querer testar isso ai... porque em PRÉ-ALFA, num vai dar Valeu e obrigado Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br [As partes desta mensagem que não continham texto foram removidas] -- FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM Links do Yahoo! Grupos -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.430 / Virus Database: 268.15.2/559 - Release Date: 30/11/2006 05:07
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Não é bem assim, que para o programador tem que ter o controlel total sobre os dados deve fazer tudo na mão mesmo. Você não pode se esquecer, que você terá pela frente cronogramas com prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. DBWares são passiveis de todo tipo de consistência e tratamento de dados. Basta você saber usá- los adequadamente e não terás problemas. O problema é o cara que acha que apenas poe um DBEdit lá, conecta a query e pronto. É igual por uma roda num carro sem freios, sem ponteira de direção e sem pivô de suspensão.. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Moked - Humberto \(Brazil\) [EMAIL PROTECTED] escreveu Eu não sou a favor do uso de DBWares, pois creio que o programador tem q ter completo controle dos dados que estão sendo enviados ao banco ou trazidos dele. Com DBWares vc fica restrito, não me sinto seguro de deixar esse tipo de transação nas mãos dos DBWares. Mas cada um com a sua. \o/ De: delphi-br@yahoogrupos.com.br [mailto:delphi- [EMAIL PROTECTED] Em nome de Alisson Yahoo Enviada em: terça-feira, 28 de novembro de 2006 11:01 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
João, tá concordo que você tenha seus 10 anos de experiencia e comprovação de que sua metodologia seja tão eficiente como diz. Mas muitos aqui talvez não a conheçem e vamos mesmo de DBWares e Cia. E tão verdade isto é, que um aqui já postou uma pergunta do que vem a ser o Framework MVP que você tanto diz. Então que tal postar um exemplo funcional pra nós? Pode ser coisa básica mesmo. Assim poderemos ver se o mesmo é tão produtivo e eficiente como diz, pois nem eu conheço esta metodologia também. Confesso pra você. Numa boa :) []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Isso seria legal. To curioso pra ver. Eu quero começar um projeto pessoal com o Turbo Delphi. Tem como usar isso com ele? On 11/29/06, Walter Chagas (Yahoo) [EMAIL PROTECTED] wrote: João, tá concordo que você tenha seus 10 anos de experiencia e comprovação de que sua metodologia seja tão eficiente como diz. Mas muitos aqui talvez não a conheçem e vamos mesmo de DBWares e Cia. E tão verdade isto é, que um aqui já postou uma pergunta do que vem a ser o Framework MVP que você tanto diz. Então que tal postar um exemplo funcional pra nós? Pode ser coisa básica mesmo. Assim poderemos ver se o mesmo é tão produtivo e eficiente como diz, pois nem eu conheço esta metodologia também. Confesso pra você. Numa boa :) []s
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
E ai galera, to vendo que a discussão ta pegando fogo né ?!?!?!? Bom utilizei durante muito tempo Dbwares (e ainda continuo usando) e estou migrando meus projetos para trabalhar com padrões e em especial MVP e MGM. O legal disto tudo seria voltar as raízes, quem quiser se aventurar por este mundo de uma olhado em Design Patterns (GoF) que resolve um montão de problemas de maneira elegante. Agora naum esperem moleza não, vai ralar muito pois realmente programar com DBwares é muito mais rápido pois já está tudo lá ... pra quem mistura regras de negocio com GUI realmente ta lá. Segue exemplo de MVP explicadinho do inicio ao fim. Já dá pra ter uma idéia http://www.devmedia.com.br/articles/viewcomp.asp?comp=3043 Anderson Valério da Silva _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Leodinei Bielak Enviada em: quarta-feira, 29 de novembro de 2006 11:28 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Isso seria legal. To curioso pra ver. Eu quero começar um projeto pessoal com o Turbo Delphi. Tem como usar isso com ele? On 11/29/06, Walter Chagas (Yahoo) [EMAIL PROTECTED] mailto:wchagas%40telemont.com.br com.br wrote: João, tá concordo que você tenha seus 10 anos de experiencia e comprovação de que sua metodologia seja tão eficiente como diz. Mas muitos aqui talvez não a conheçem e vamos mesmo de DBWares e Cia. E tão verdade isto é, que um aqui já postou uma pergunta do que vem a ser o Framework MVP que você tanto diz. Então que tal postar um exemplo funcional pra nós? Pode ser coisa básica mesmo. Assim poderemos ver se o mesmo é tão produtivo e eficiente como diz, pois nem eu conheço esta metodologia também. Confesso pra você. Numa boa :) []s [As partes desta mensagem que não continham texto foram removidas]
Res: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Gostaria de dar a minha opinião sobre o assunto tb.
Com relação a DBWare ou não DBWare concordo com quem disse que não se deve
perder tempo e que para implementar vc tem que ter um conhecimento total da
aplicação (e regras do negócio) já que os DBWares não foram criados para nenhum
fim específico e sim para serem bastante abrangentes. Por isso podem haver
casos em que eles são totalmente descartáveis e outros em que são extremamente
aplicáveis.
Eu mesmo já tive projetos onde implementei 90% da aplicação usando DBWares
(DBEdits, DBGrids, DBLabels e etc) e funcionaram a contento como também já
desenvolvi projetos onde toda a parte de apresenção era feita com controles
não-DBWares (Edits, StringGrids, Labels e etc). E a única conclusão que pude
tirar é que ambas as alternativas são muito boas desde que vc saiba quanto de
tempo tem disponível para se dedicar à interface. Pela minha ótica, que pode
não ser a de outros colegas, se vc tem um cronograma menos apertado vc pode até
tentar abolir DBWares e focar na adaptação do Core do projeto (as regras de
negócio). Caso seu cronograma esteja mais apertado ou até mesmo enforcado, nem
tenho dúvidas, aplico DBWares e assim que possível vou eliminando aos poucos
conforme desafogo o cronograma.
Quanto ao MVP, pelo pouco (muito pouco mesmo) que vi trata-se de um passo
adiante em relação aos dilema proposto anteriormente, já que vc acaba usando os
componentes padrão da VCL mas de uma maneira orientada ao negócio.
Quanto aos Frameworks MVP, o único que cheguei mesmo a implementar foi o DePO
(Delphi Persistent Objects) e gostei do que vi. Apenas ressalto que existem
duas versões em paralelo correndo por ai, a oficial do projeto e outra que vem
sendo desenvolvida pelo pessoal do forum OODesign; ambas as versões já mostram
uma ótima alternativa para uso se vc quer dar um passo adiante e pensar mais
nas regras de negócio. Outro que eu baixei e quero testar com carinho é o
InstantObjects que parece ser um pouco mais velho (mais experiente) que o DePO
e também mostra um grande poder de fogo.
Esta é apenas a minha opinião, se alguém tiver mais informações, por favor,
compartilhe conosco.
Abraços,
Ricardo.
- Mensagem original
De: Leodinei Bielak [EMAIL PROTECTED]
Para: delphi-br@yahoogrupos.com.br
Enviadas: Quarta-feira, 29 de Novembro de 2006 12:27:33
Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Isso seria legal. To curioso pra ver. Eu quero começar um projeto
pessoal com
o Turbo Delphi. Tem como usar isso com ele?
On 11/29/06, Walter Chagas (Yahoo) [EMAIL PROTECTED] com.br wrote:
João, tá concordo que você tenha seus 10 anos de experiencia e
comprovação de que sua metodologia seja tão eficiente como diz. Mas
muitos aqui talvez não a conheçem e vamos mesmo de DBWares e Cia. E
tão verdade isto é, que um aqui já postou uma pergunta do que vem a
ser o Framework MVP que você tanto diz. Então que tal postar um
exemplo funcional pra nós? Pode ser coisa básica mesmo. Assim
poderemos ver se o mesmo é tão produtivo e eficiente como diz, pois
nem eu conheço esta metodologia também. Confesso pra você.
Numa boa :)
[]s
!--
#ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg table {font-size:inherit;font:100%;}
#ygrp-mlmsg select, input, textarea {font:99% arial,helvetica,clean,sans-serif;}
#ygrp-mlmsg pre, code {font:115% monospace;}
#ygrp-mlmsg * {line-height:1.22em;}
#ygrp-text{
font-family:Georgia;
}
#ygrp-text p{
margin:0 0 1em 0;
}
#ygrp-tpmsgs{
font-family:Arial;
clear:both;
}
#ygrp-vitnav{
padding-top:10px;
font-family:Verdana;
font-size:77%;
margin:0;
}
#ygrp-vitnav a{
padding:0 1px;
}
#ygrp-actbar{
clear:both;
margin:25px 0;
white-space:nowrap;
color:#666;
text-align:right;
}
#ygrp-actbar .left{
float:left;
white-space:nowrap;
}
.bld{font-weight:bold;}
#ygrp-grft{
font-family:Verdana;
font-size:77%;
padding:15px 0;
}
#ygrp-ft{
font-family:verdana;
font-size:77%;
border-top:1px solid #666;
padding:5px 0;
}
#ygrp-mlmsg #logo{
padding-bottom:10px;
}
#ygrp-vital{
background-color:#e0ecee;
margin-bottom:20px;
padding:2px 0 8px 8px;
}
#ygrp-vital #vithd{
font-size:77%;
font-family:Verdana;
font-weight:bold;
color:#333;
text-transform:uppercase;
}
#ygrp-vital ul{
padding:0;
margin:2px 0;
}
#ygrp-vital ul li{
list-style-type:none;
clear:both;
border:1px solid #e0ecee;
}
#ygrp-vital ul li .ct{
font-weight:bold;
color:#ff7900;
float:right;
width:2em;
text-align:right;
padding-right:.5em;
}
#ygrp-vital ul li .cat{
font-weight:bold;
}
#ygrp-vital a {
text-decoration:none;
}
#ygrp-vital a:hover{
text-decoration:underline;
}
#ygrp-sponsor #hd{
color:#999;
font-size:77%;
}
#ygrp-sponsor #ov{
padding:6px 13px;
background-color:#e0ecee;
margin-bottom:20px;
}
#ygrp-sponsor #ov ul{
padding:0 0 0 8px;
margin:0;
}
#ygrp-sponsor #ov li{
list-style-type:square;
padding:6px 0;
font-size:77%;
}
#ygrp
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Não acho que DBWares não são rodas quadradas não... E como vc mesmo disse, não é de bom to falar mal de uma implementação quando esta lhe é completamente desconhecida... Também tenho alguns anos, 16 anos de programação, 15-CLIPPER, 12-DELPHI. E posso garantir que DBWare´s são bem melhores que UNHALWare´s e olha que sou defençor do UNHAL.EXE... Agora se for pra partir para FrameWork´s MVP/Classes de negócios. ai ainda não tenho um opnião formada... Mas creio que mesmo assim dentro deles vamos ter DBWare´s funcionando, talvez de uma maneira mais inteligente e pratica, ainda não sei, o jeito é esperar pra ver no que vai dar... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Eu sigo a tese do Vitor. Também uso os dois. Simplesmente, se usa TDataSet quando ele permite o desenvolvedor fazer o q precisa e obter o resultado que espera, ou se usa o Edit tratando-o da forma que melhor se quer. Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? T+ Mani --- Em delphi-br@yahoogrupos.com.br, Vitor Luiz Redes [EMAIL PROTECTED] escreveu Trabalho com os dois. É besteira fazer sistemas pequenos com classes de negócio, é besteira fazer sistemas grandes com TDataSet. Vitor Luiz Redes Analista de Sistemas Redsystem Software / Bureau Software Messenger: [EMAIL PROTECTED] Phone: 3379-6939 Cel. Phone: 9677-8445 - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais --- --- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.0/524 - Release Date: 8/11/2006 [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Nobres e ilustres senhores de opinão formada e altamente consistente. To sabendo agora do suposto Framework MVP, afinal nunca disse aqui na lista que sou o SEITUDOSACOTUDODOMINOTUDOEUSOUOCARA, mas pelo papo aqui já deu pra montar uma ideia a respeito do produto. Mas já posso antecipar, TAMbém, que se a proposta em questão consiste em criar classes manualmente, codifica, implementa e tudo mais, já vai totalmente contraria a proposta do Delphi, que é praticidade e produtividade. DBEdits, você monta em dois tempos. Monta o Engine lá no DM (Query, DSP, CDS, DS), abre o fields editor, adiciona os campos, marca tudo e arrasta pro form. pronto! Seu cadastro tá pronto. Em média pra montar cadastros em sistemas, podemos gastar um dia implementando consistências e tudo mais via DBWare (Podemos pensar em 2 estourando estourando) e o restante do cronograma gastariamos em implementar regras de negócios, que é o que interessa no sistema. Sei lá, me corrijam se eu estiver falando asneiras, mas pra fazer cadastros, que é coisa básica e trivial em sistema, é proibitivo gastar muito tempo com esse tipo de coisa. Tanto que a proposta do ECO é fazer todo esse trabalho sujo e deixar o restante do cronograma pro camarada ficar exclusivamente focado apenas com as regras de negócio e os processos a serem codificados. Não vamos nos esquecer que no mundo dos negócios, sistemas são pra ontem! Agora, frameworks pra regras de negócios? Aí sim já pode ser uma coisa interessante pra nós. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Luiz Escobar [EMAIL PROTECTED] escreveu Não acho que DBWares não são rodas quadradas não... E como vc mesmo disse, não é de bom to falar mal de uma implementação quando esta lhe é completamente desconhecida... Também tenho alguns anos, 16 anos de programação, 15-CLIPPER, 12- DELPHI. E posso garantir que DBWare´s são bem melhores que UNHALWare´s e olha que sou defençor do UNHAL.EXE... Agora se for pra partir para FrameWork´s MVP/Classes de negócios. ai ainda não tenho um opnião formada... Mas creio que mesmo assim dentro deles vamos ter DBWare´s funcionando, talvez de uma maneira mais inteligente e pratica, ainda não sei, o jeito é esperar pra ver no que vai dar... Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
HAHAHHAHA, boa comparação hehehehehe Luiz Escobar Analista/Desenvolvedor: WEB - HTML/JavaScript/PHP/MySQL WINDOWS - Delphi/MyDAC/ASSEMBLER/MySQL/xBase DOS - Clipper/Assembler xBase SERVIDORES - NetWare4.11, LINUX-REDHAT9, WINDOWS-2k LINUX - LAZARUS/Kylix/MySQL; http://www.megasistema.com.br - Original Message - From: Walter Chagas (Yahoo) To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 8:51 AM Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Não é bem assim, que para o programador tem que ter o controlel total sobre os dados deve fazer tudo na mão mesmo. Você não pode se esquecer, que você terá pela frente cronogramas com prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. DBWares são passiveis de todo tipo de consistência e tratamento de dados. Basta você saber usá- los adequadamente e não terás problemas. O problema é o cara que acha que apenas poe um DBEdit lá, conecta a query e pronto. É igual por uma roda num carro sem freios, sem ponteira de direção e sem pivô de suspensão.. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Moked - Humberto \(Brazil\) [EMAIL PROTECTED] escreveu Eu não sou a favor do uso de DBWares, pois creio que o programador tem q ter completo controle dos dados que estão sendo enviados ao banco ou trazidos dele. Com DBWares vc fica restrito, não me sinto seguro de deixar esse tipo de transação nas mãos dos DBWares. Mas cada um com a sua. \o/ De: delphi-br@yahoogrupos.com.br [mailto:delphi- [EMAIL PROTECTED] Em nome de Alisson Yahoo Enviada em: terça-feira, 28 de novembro de 2006 11:01 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Olá maniacapordelphi Sua informacao que DBWares podem travar maquinas em rede está incorreta, pois eu tenho um sistema que roda em 45 lojas, cada qual com no minimo 5 máquinas, todas conectadas via internet usando BSS, tirando a matriz.. ou seja são quase 300 maquinas, e nada de dar pau... Se o sistema usa DBWares e é ruim, não é culpa dele, e sim do programador... me desculpem aos amigos.. mas essa é a verdade, 99% dos erros estão nos que nós mesmos causamos, e nao no componente. []s Em 29/11/06, maniacapordelphi [EMAIL PROTECTED] escreveu: Eu sigo a tese do Vitor. Também uso os dois. Simplesmente, se usa TDataSet quando ele permite o desenvolvedor fazer o q precisa e obter o resultado que espera, ou se usa o Edit tratando-o da forma que melhor se quer. Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? T+ Mani --- Em delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br, Vitor Luiz Redes [EMAIL PROTECTED] escreveu Trabalho com os dois. É besteira fazer sistemas pequenos com classes de negócio, é besteira fazer sistemas grandes com TDataSet. Vitor Luiz Redes Analista de Sistemas Redsystem Software / Bureau Software Messenger: [EMAIL PROTECTED] Phone: 3379-6939 Cel. Phone: 9677-8445 - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais -- --- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.0/524 - Release Date: 8/11/2006 [As partes desta mensagem que não continham texto foram removidas] -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Sem querer ser chato, mas aqui Trabalho com DBWare direto na elaboração de cadastros e tudo mais. Claro! Não existiu, não existe e jamais existirá sistemas 100% a base de DBWares, compete ao desenvolvedor saber aonde, quando e como usar. Travar rede, não trava e pesar a rede é relativo. Eu sempre uso DBEdits, dentre outros, mas tudo conectado ao banco via ClientDataset. Sentenças SQL bem montadas e trazendo apenas aquilo que interessa ao cadastro e ClientDatasets usando packetrecords na média, funcionam sem problemas. O RM é feito quase todo a base de DBWares, roda no terminal aqui tranquilo. E olha que a rede aqui não é daquelas maravilhosas beldades do universo da informatica não viu. Ela é apinhada de gargalos e deficiências. O problema, como eu já disse, é o cara que acha que apenas poe um DBEdit lá, conecta na query, dá um select todos form e pronto. Aí não há Swith, não há link e muito menos roteador que aguente mesmo. E DBWares podem ser tratados também, basta saber fazer e aonde fazer. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Fellipe Henrique [EMAIL PROTECTED] escreveu Olá maniacapordelphi Sua informacao que DBWares podem travar maquinas em rede está incorreta, pois eu tenho um sistema que roda em 45 lojas, cada qual com no minimo 5 máquinas, todas conectadas via internet usando BSS, tirando a matriz.. ou seja são quase 300 maquinas, e nada de dar pau... Se o sistema usa DBWares e é ruim, não é culpa dele, e sim do programador... me desculpem aos amigos.. mas essa é a verdade, 99% dos erros estão nos que nós mesmos causamos, e nao no componente. []s Em 29/11/06, maniacapordelphi [EMAIL PROTECTED] escreveu: Eu sigo a tese do Vitor. Também uso os dois. Simplesmente, se usa TDataSet quando ele permite o desenvolvedor fazer o q precisa e obter o resultado que espera, ou se usa o Edit tratando-o da forma que melhor se quer. Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? T+ Mani --- Em delphi-br@yahoogrupos.com.br delphi-br% 40yahoogrupos.com.br, Vitor Luiz Redes vredesredsystem@ escreveu Trabalho com os dois. É besteira fazer sistemas pequenos com classes de negócio, é besteira fazer sistemas grandes com TDataSet. Vitor Luiz Redes Analista de Sistemas Redsystem Software / Bureau Software Messenger: vitorluizredes@ Phone: 3379-6939 Cel. Phone: 9677-8445 - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br delphi-br% 40yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais -- --- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.0/524 - Release Date: 8/11/2006 [As partes desta mensagem que não continham texto foram removidas] -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Concordo plenamente com você Walter... O Cara sabendo trabalhar com os DBWare o sistema fica redondinho... []s Em 29/11/06, Walter Chagas (Yahoo) [EMAIL PROTECTED] escreveu: Sem querer ser chato, mas aqui Trabalho com DBWare direto na elaboração de cadastros e tudo mais. Claro! Não existiu, não existe e jamais existirá sistemas 100% a base de DBWares, compete ao desenvolvedor saber aonde, quando e como usar. Travar rede, não trava e pesar a rede é relativo. Eu sempre uso DBEdits, dentre outros, mas tudo conectado ao banco via ClientDataset. Sentenças SQL bem montadas e trazendo apenas aquilo que interessa ao cadastro e ClientDatasets usando packetrecords na média, funcionam sem problemas. O RM é feito quase todo a base de DBWares, roda no terminal aqui tranquilo. E olha que a rede aqui não é daquelas maravilhosas beldades do universo da informatica não viu. Ela é apinhada de gargalos e deficiências. O problema, como eu já disse, é o cara que acha que apenas poe um DBEdit lá, conecta na query, dá um select todos form e pronto. Aí não há Swith, não há link e muito menos roteador que aguente mesmo. E DBWares podem ser tratados também, basta saber fazer e aonde fazer. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] wchagasj%40yahoo.com.br http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] whitesockets%40hotmail.com --- Em delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.br, Fellipe Henrique [EMAIL PROTECTED] escreveu Olá maniacapordelphi Sua informacao que DBWares podem travar maquinas em rede está incorreta, pois eu tenho um sistema que roda em 45 lojas, cada qual com no minimo 5 máquinas, todas conectadas via internet usando BSS, tirando a matriz.. ou seja são quase 300 maquinas, e nada de dar pau... Se o sistema usa DBWares e é ruim, não é culpa dele, e sim do programador... me desculpem aos amigos.. mas essa é a verdade, 99% dos erros estão nos que nós mesmos causamos, e nao no componente. []s Em 29/11/06, maniacapordelphi [EMAIL PROTECTED] escreveu: Eu sigo a tese do Vitor. Também uso os dois. Simplesmente, se usa TDataSet quando ele permite o desenvolvedor fazer o q precisa e obter o resultado que espera, ou se usa o Edit tratando-o da forma que melhor se quer. Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? T+ Mani --- Em delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brdelphi-br% 40yahoogrupos.com.br, Vitor Luiz Redes vredesredsystem@ escreveu Trabalho com os dois. É besteira fazer sistemas pequenos com classes de negócio, é besteira fazer sistemas grandes com TDataSet. Vitor Luiz Redes Analista de Sistemas Redsystem Software / Bureau Software Messenger: vitorluizredes@ Phone: 3379-6939 Cel. Phone: 9677-8445 - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br delphi-br%40yahoogrupos.com.brdelphi-br% 40yahoogrupos.com.br Sent: Wednesday, November 29, 2006 10:04 AM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: snip prazos que não lhe darão margens pra criar coisas que já existem (o famoso reinventar a roda) ou então ficar fazendo na mão, aquilo que já tem pronto por mero capricho de desenvolvimento. Metendo o bedelho de novo. Ninguém está reinventando a roda ao usar um Edit para apresentar dados, muito pelo contrário, está ignorando uma roda quadrada idealizada há 10 anos pela Borland para implementar uma roda devidamente redonda, calibrada, com liga leve e orientada a objetos. Ainda acrescento que não é de bom tom falar mal de uma implementação quando esta lhe é completamente desconhecida. Eu estou falando com a experiência (e problemas) dos meus quase 10 anos de TDataset comparado com o que eu posso fazer com uma classe de negócio. Você não tem como sequer fazer idéia da diferença relacionada a ganho de produtividade no médio e longo prazos. -- João Morais -- --- Internal Virus Database is out-of-date. Checked by AVG Free Edition. Version: 7.1.409 / Virus Database: 268.14.0/524 - Release Date: 8/11/2006 [As partes desta mensagem que não continham texto foram removidas] -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
no inicio nao usava dbaware nos sistemas, qndo aprendi delphi aprendi assim corra do dbaware, eles fazem coisas q vc nao quer, mas ate qndo eu realmente comecei a usar e aprendi como controlar o q acontece eu desisti de fazer na mao... da menos trabalho, ainda mais qndo se tem uma estrutura bem montada. no br eu tenho nos meus arquivos um projeto chamado BASE, esse projeto tem a estrutura basica q eu preciso pra montar qq sistema, alguns exemplos: pra chamar uma msg de erro, eu posso chamar de qq lugar Erro(msg), assim como os outros dipos de tela, tem as telas basicas tb para cadastro onde ja estao tds os metodos de seguranca do sistema e tb as de tratamento de erros... a termos de producao, continuo com dbaware, sempre... Julio Cesar [EMAIL PROTECTED] +353 (87) 2184139 +353 (091) 630317 Nao ha saber mais ou saber menos, ha saberes diferentes (Paulo Freire) - Original Message - From: Joao Morais To: delphi-br@yahoogrupos.com.br Sent: Wednesday, November 29, 2006 3:00 PM Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Walter Chagas (Yahoo) wrote: Então que tal postar um exemplo funcional pra nós? Pode ser coisa básica mesmo. Assim poderemos ver se o mesmo é tão produtivo e eficiente como diz, pois nem eu conheço esta metodologia também. Você quer um exemplo bem básico pra saber se MVP é mais produtivo do que DBAware? Então nem perca seu tempo, pra exemplo bem básico DBAware chega a ser um pouco mais fácil de implementar. Estou falando em médio e longo prazo. Ainda assim você pode baixar o PressObjects, ler a pouca documentação (que por sinal cobre apenas uns 50% do que eu já consegui implementar) e estudar os fontes do aplicativo demonstração. Outra coisa que deve ser destacada é o jeito de programar de cada um. Tem quem prefira criar regras em classes, tem quem prefira criar regras em botão. Para cada um existe um framework que atenda suas preferências. Eu estou falando que criar regras em classe é melhor tendo utilizado as duas abordagens, você diz que usar Edit é coisa pra cientista maluco sem conhecer a ciência do negócio. MVP só vai ser melhor do que DBAware para quem tiver a cabeça aberta para programação orientada a objetos. -- João Morais [As partes desta mensagem que não continham texto foram removidas]
Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
maniacapordelphi, eu lhe desafio vc a me dizer pq controles data-aware lhe causam resultados inesperados! Se vc me provar isso, eu abandono tudo o que eu sei hoje sobre o uso de controles data-aware. Sds. From: Joao Morais [EMAIL PROTECTED] Reply-To: delphi-br@yahoogrupos.com.br To: delphi-br@yahoogrupos.com.br Subject: Re: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Date: Wed, 29 Nov 2006 18:41:09 -0200 maniacapordelphi wrote: Confesso que DBWares tem furos e às vezes nos dão um resultado inesperado sim. E nem sempre é rapido como se diz por aí. Pode travar a rede em caso de grande numero de usuarios e quando se usa o aplicativo através do Client Terminal, então? Se existisse alguma culpa, seria do TDataset e não do DBAware. Mas geralmente OPFs são mais lentos do que o TDataset braçal (ponto pro RAD), DBAware faz meramente a apresentação dos dados. Nesse caso concordo com os colegas Felipe e Walter, isso tem dedo do programador. -- João Morais _ MSN Busca: fácil, rápido, direto ao ponto. http://search.msn.com.br
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Que Heresia . Poxa antes de falar que não vai usarpq eh isso ou aquilo Da uma estudada na VCL..abre o fonte do componente...e veja como ele trabalha Abs, Rodrigo Mota. _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Moked - Humberto (Brazil) Enviada em: quarta-feira, 29 de novembro de 2006 13:53 Para: delphi-br@yahoogrupos.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! O único DBWare que eu uso é o DBGRID.. hehe pq eu uso ele somente para consultas.. então deixo ele somente leitura e é só festa hehehe... mas os DBEdits eu não gosto de usar. De: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br [mailto:[EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br] Em nome de Luiz Escobar Enviada em: quarta-feira, 29 de novembro de 2006 05:02 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Então vc não usa TTable, TQuery, DBExpress, IBTable, IBQuery, etc... etc... faz tudo na mão ??? Também sou da seita que o programador tem que ter completo controle dos dados, mas dai programar em ASSEMBLY PURO hehehehe to fora... Só não uso DBWares em casos EXTREMOS, e fico puto porque não encontrei um meio de fazer usando DBWARES. Eu já acho que o DBWare da muito mais produtividade, não te deixa restrito na maioria dos casos.. Acho um loucura construir um DBGRID sendo que ele esta pronto. Luiz Escobar - Segue mensagem original! - De: Moked - Humberto \(Brazil\) [EMAIL PROTECTED] mailto:humberto%40moked.com.br com.br mailto:humberto%40moked.com.br Data: Tue, 28 Nov 2006 11:04:43 -0200 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu não sou a favor do uso de DBWares, pois creio que o programador tem q ter completo controle dos dados que estão sendo enviados ao banco ou trazidos dele. Com DBWares vc fica restrito, não me sinto seguro de deixar esse tipo de transação nas mãos dos DBWares. Mas cada um com a sua. \o/ De: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br [mailto:[EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br ] Em nome de Alisson Yahoo Enviada em: terça-feira, 28 de novembro de 2006 11:01 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
RE: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Incrementando a VCL (este artigo vai lhe ajudar no que vc precisa!) http://www.clubedelphi.net/artigos/rubemrocha.asp Identificando Controles Data-Aware http://www.clubedelphi.net/artigos/U_Rubem01.asp Entendendo a camada WMI e seu uso com Delphi http://www.clubedelphi.net/artigos/Wmi_Delphi.asp http://www.devmedia.com.br/articles/viewcomp.asp?comp=651 Sds., Rubem Rocha Manaus, AM From: Rodrigo Mota [EMAIL PROTECTED] Reply-To: delphi-br@yahoogrupos.com.br To: delphi-br@yahoogrupos.com.br Subject: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Date: Wed, 29 Nov 2006 21:27:56 -0200 Que Heresia . Poxa antes de falar que não vai usarpq eh isso ou aquilo Da uma estudada na VCL..abre o fonte do componente...e veja como ele trabalha Abs, Rodrigo Mota. _ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Moked - Humberto (Brazil) Enviada em: quarta-feira, 29 de novembro de 2006 13:53 Para: delphi-br@yahoogrupos.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! O único DBWare que eu uso é o DBGRID.. hehe pq eu uso ele somente para consultas.. então deixo ele somente leitura e é só festa hehehe... mas os DBEdits eu não gosto de usar. De: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br [mailto:[EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br] Em nome de Luiz Escobar Enviada em: quarta-feira, 29 de novembro de 2006 05:02 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Então vc não usa TTable, TQuery, DBExpress, IBTable, IBQuery, etc... etc... faz tudo na mão ??? Também sou da seita que o programador tem que ter completo controle dos dados, mas dai programar em ASSEMBLY PURO hehehehe to fora... Só não uso DBWares em casos EXTREMOS, e fico puto porque não encontrei um meio de fazer usando DBWARES. Eu já acho que o DBWare da muito mais produtividade, não te deixa restrito na maioria dos casos.. Acho um loucura construir um DBGRID sendo que ele esta pronto. Luiz Escobar - Segue mensagem original! - De: Moked - Humberto \(Brazil\) [EMAIL PROTECTED] mailto:humberto%40moked.com.br com.br mailto:humberto%40moked.com.br Data: Tue, 28 Nov 2006 11:04:43 -0200 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu não sou a favor do uso de DBWares, pois creio que o programador tem q ter completo controle dos dados que estão sendo enviados ao banco ou trazidos dele. Com DBWares vc fica restrito, não me sinto seguro de deixar esse tipo de transação nas mãos dos DBWares. Mas cada um com a sua. \o/ De: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br [mailto:[EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br ] Em nome de Alisson Yahoo Enviada em: terça-feira, 28 de novembro de 2006 11:01 Para: [EMAIL PROTECTED] mailto:delphi-br%40yahoogrupos.com.br os.com.br mailto:delphi-br%40yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas] _ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br
RE: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Pessoal, após diversas opiniões... Qualquer desenvolvimento é mais produtivo com os componentes DBWare, mas para trabalhar com eles é bom que se entenda como funciona os eventos e os componentes DataSet e DataSource. Ao longo de todos os softwares que desenvolvi nunca tive problemas com os componentes, se algum comportamento dos componentes não estivesse de acordo com a minha necessidade, bastava herdar e alterar o comportamente do mesmo. Avaliem a necessidade, estude os componentes, agora ter uma aplicação sem nada de data ware por achar que não deve ter é uma decisão equivocada. Abraços, Andreano Lanusse System Engineer CodeGear [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas]
RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Então vc não usa TTable, TQuery, DBExpress, IBTable, IBQuery, etc... etc... faz tudo na mão ??? Também sou da seita que o programador tem que ter completo controle dos dados, mas dai programar em ASSEMBLY PURO hehehehe to fora... Só não uso DBWares em casos EXTREMOS, e fico puto porque não encontrei um meio de fazer usando DBWARES. Eu já acho que o DBWare da muito mais produtividade, não te deixa restrito na maioria dos casos.. Acho um loucura construir um DBGRID sendo que ele esta pronto. Luiz Escobar - Segue mensagem original! - De: Moked - Humberto \(Brazil\) [EMAIL PROTECTED] Data: Tue, 28 Nov 2006 11:04:43 -0200 Para: delphi-br@yahoogrupos.com.br Assunto: RES: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu não sou a favor do uso de DBWares, pois creio que o programador tem q ter completo controle dos dados que estão sendo enviados ao banco ou trazidos dele. Com DBWares vc fica restrito, não me sinto seguro de deixar esse tipo de transação nas mãos dos DBWares. Mas cada um com a sua. \o/ De: delphi-br@yahoogrupos.com.br [mailto:[EMAIL PROTECTED] Em nome de Alisson Yahoo Enviada em: terça-feira, 28 de novembro de 2006 11:01 Para: delphi-br@yahoogrupos.com.br Assunto: Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão! Eu também já fui defensor de desenvolvimento sem componentes DbWare. Mas, como diria Raulzito, Prefiro ser essa metamorfose ambulante Agora que estou começando a desenvolver usando ClientDataset estou mudando de opinião. O que eu acho chato são alguns erros que são um pouco mais difíceis de achar, como por exemplo, erros ocasionado pela chamada de certos eventos. [As partes desta mensagem que não continham texto foram removidas] [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Rubem, Já trabalhei muito com esta filosofia (tudo feito na mão), era até um defensor ferrenho disto aqui nos grupos. Depois que aprendi a trabalhar com ClientDataset e DBWare, CABOU! Não volto pra programação massante de jeito nenhum. Perde-se muito tempo pra fazer uma coisa que o Delphi já te dá 80% pronta. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Rubem Nascimento da Rocha [EMAIL PROTECTED] escreveu Faço minhas as palavras do Welson Avelar. Desde que comecei no Delphi 2, sempre usei componentes Data-Aware. Muita gente já comentou comigo dizendo: 'Data-Aware é uma droga! Acaba fazendo coisas que a gente não quer que aconteça, dispara eventos que a gente não quer que dispare, etc., etc., etc. Pois eu sempre usei, e não tem quem me faça não deixar de usar. O ganho de produtividade é inegável, indiscutível. Uma vez, fui dar manutenção em um sistema comercial (retaguarda) e fiquei p%$ da vida quando eu vi o que o programador tinha feito: todas as telas com grid de vendas e financeiro (contas a pagar/receber) com TStringGrid. Um absurdo de lento, além de requerer código a mais para efetar o refresh do componente. Tem gente que faz uso de um evento para uma coisa, quando na verdade deveria estar usando um outro evento. Uma excelente fonte de informação sobre os eventos dos datasets é o próprio help do Delphi. Só para citar, algumas coisas que eu sempre faço quando uso controles data-aware: . Sempre que for interagir muito com o seu dataset, faço uso dos métodos EnableControls(), DisableControls() e ControlsDisabled(); . Não uso AfterInsert pra alimentar dados iniciais a um registro, e sim OnNewRecord; . Durante a edição de um registro, pra validar/monitorar valores alterados em campos eu uso o evento OnSetText do TField do campo, e não no OnDataChange do DataSource ou no OnValidate; . Se quiser formatar um campo, ou mostrar ele de modo diferente em um TDBGrid, eu uso o evento OnGetText do TField do campo. Como eu sei disso tudo? Ora, tão simples quando elementar, lendo o help do Delphi. Data-aware é o canal, indiscutivelmente! Sds. From: Welson Avelar [EMAIL PROTECTED] Reply-To: delphi-br@yahoogrupos.com.br To: delphi-br@yahoogrupos.com.br Subject: Re: [delphi-br] Usar ou não usar DBWares? Eis a questão! Date: Fri, 24 Nov 2006 09:30:19 -0300 (ART) --- Joao Morais escreveu: Fellipe Henrique wrote: Olá amigos, Estive eu aqui pensando com meus botões, depois de ter lido uma informação em um livro de interface humano-computador. Qual é o melhor para se utilizar? Componentes DBWares (DBEdit, DBComboBox e etc...) ou componentes normais (Edit, ComboBox e etc..) para banco de dados? Pensando no lado do banco de dados, e nao da produção, pois é mais rápido usar um DBEdit, do que ter que fazer à mão... A menos que você utilize um framework para isso. Estou trabalhando em um framework MVP, aonde você cria formulários com simples TEdit, TComboBox, TStringGrid e sem uma única linha de código. Você diz ao framework o que é cada um dos componentes, e o framework popula os componentes para você. Dá uma conferida em www.pressobjects.org/ptbr -- João Morais [--x--] [Welson] Eu recomendo apenas que use o DBGrid pro caso de precisar informar uma quantidade da dados grande. Qual mudamos do D4 para o D7, mudamos também de ListBox pra DBGrid, entre outras diversas alterações. Então, meu velho, o ganho de tempo foi absurdo. Em formulários que mostram muita informação, até o cliente elogiou e adorou, é mole !? ^^ []s. = 'O que me preocupa não é o grito dos maus. É o silêncio dos bons.' Martin Luther King. = Welson de Avelar Soares Filho Analista/Programador Delphi Gemini Sistemas www.geminisistemas.com.br Juiz de Fora - Minas Gerais = ___ O Yahoo! está de cara nova. Venha conferir! http://br.yahoo.com _ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Walter, Fazer cadastros utilizando DBWares é mais rápido do que trabalhar com Edits pq existe um framework focado nisso. Se o foco fosse utilizar qq Edit para fazer o link com os campos das querys, fazer um cadastro com Edits seria super rápido. Em outras palavras, depende do framework utilizado. Marcos Douglas --- Em delphi-br@yahoogrupos.com.br, Walter Chagas (Yahoo) [EMAIL PROTECTED] escreveu Grande João, o homem das teorias dos grupos hehe Seguinte mermão, tudo isto aí que voce falou, é muito uma aplicação teórica. Mas na prática sabemos que fazer cadastros com DBEdits é muito mais rápido e produtivo. Quanto a mesma maratona para cada campo lookup ou para cada Grid, basta voce montar um form básico e tratá-lo como ancestral. Aqui eu faço assim. Tenho um form ancestral que já vem com os componentes comuns a todas as telas de cadastro que utilizarei. Em seguida basta ir criando os forms descendentes do dito- cujo. Jogo hiperrápido e sem stress... E também eu não disse aqui que se leva um dia pra popular um mísero Edit. Eu disse que pode-se levar ATÉ um dia para montar um cadastro todo na mão. Tudo bem. Falei em um dia e posso até ter exagerado, mas isto é altissimamente relativo ao que se pretente implementar nele. Fazer um cadastro básico apenas funcional, acredito que com uma ou no máximo duas horas de implementação se consegue, incluindo aí testes e tudo mais. Agora, dependendo do que se pretende implementar, podemos chegar a mais. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Joao Morais post@ escreveu Walter Chagas (Yahoo) wrote: Agora o uso de DBWares vai mesmo é facilitar a vida do desenvolvedor pois uma cadastro simples e básico, usando DBEdits e DBNavigator, gastaria mais ou menos na média pra ser feito e estar pronto para ser usado, uns 20 a 30 minutos chegando a 40 por aí. Este mesmo cadastro usando Edits, dependendo do tratamento que for feito e tudo mais (Já que todo o controle do dado é por conta do desenvolvedor), pode- se gastar até 1 dia de trabalho. O problema do DBAware está ligado à sua concepção, aonde você coloca em um nível muito alto quais registros do seu banco deve estar ligados à ele. Há um conserto intermediário a esse problema feito pelo InstantObjects, aonde você utiliza DBAware para acessar atributos de classes de negócio ao invés de registros do banco. Um outro problema que nem o próprio InstantObjects resolve é a reutilização de regras ligados à apresentação dos dados. Você ter que fazer a mesma maratona para cada campo lookup ou para cada Grid do seu form é um baita pé no saco. Aí só um framework MVP pra ajudar, e isso o PressObjects tem. Dizer que se leva um dia de trabalho para popular um Edit é o mesmo que dizer que se leva uns dois meses de trabalho para fazer uma agenda telefônica, pois seria necessário eu escrever toda a API do banco de dados que eu vou utilizar. -- Joao Morais
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Rubem, é discutível sim. Geralmente quem usa controles dataware misturam interface gráfica, com lógica de interface, com lógica de negócio, lógica de acesso a dados e vira um espaghetti só! Eu disse geralmente (isto é quase sempre! :) ) Hoje em dia o que é indiscutível é que a OO traz o mundo real para a aplicação enquanto o modelo relacional apresenta uma redução do mundo real. Com uso de bons frameworks vc ganha produtividade, facilidade de manutenção e testes automatizados (aqui então puts, podemos dar adeus a bugs recorrentes ou introdução de novos bugs em áreas que já estavam funcionando). Poucas pessoas tem essa visão, não sei se é por preguiça de pesquisa, comodismo ou sei lá o quê? Só sei que alguns brasileiros começam a enfrentar os desafios e estes estarão a frente no desenvolvimento de software. Minha idéia é que em algum tempo não precise mais escrever tanto código. Faremos diagramas UML e a aplicação sairá compilada seja em Delphi, Java, .Net ou qualquer porra que inventem! Usar um framework MVP, com Experts que auxiliem a ligação dos componentes de tela a presenters irá ser muito mais produtivo do que controle dataware. Isso sim é indiscutível, mas como a coisa está sendo montada agora, muita gente nao vai conseguir perceber o que é possível fazer e os benefícios de se usar tais tecnologias :) Mas prometo a vocês que o Infra, Jazz e Press estarão em destaque na comunidade delphi logo logo! e ai, ninguem mais vai discutir hehehehe! Isso sim será INDISCUTÍVEL
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Olá mrbar2000, Podia me dizer o que vem a ser Infra, Jazz e Press? São gratuitos, estão funcionais? []s Em 26/11/06, mrbar2000 [EMAIL PROTECTED] escreveu: Rubem, é discutível sim. Geralmente quem usa controles dataware misturam interface gráfica, com lógica de interface, com lógica de negócio, lógica de acesso a dados e vira um espaghetti só! Eu disse geralmente (isto é quase sempre! :) ) Hoje em dia o que é indiscutível é que a OO traz o mundo real para a aplicação enquanto o modelo relacional apresenta uma redução do mundo real. Com uso de bons frameworks vc ganha produtividade, facilidade de manutenção e testes automatizados (aqui então puts, podemos dar adeus a bugs recorrentes ou introdução de novos bugs em áreas que já estavam funcionando). Poucas pessoas tem essa visão, não sei se é por preguiça de pesquisa, comodismo ou sei lá o quê? Só sei que alguns brasileiros começam a enfrentar os desafios e estes estarão a frente no desenvolvimento de software. Minha idéia é que em algum tempo não precise mais escrever tanto código. Faremos diagramas UML e a aplicação sairá compilada seja em Delphi, Java, .Net ou qualquer porra que inventem! Usar um framework MVP, com Experts que auxiliem a ligação dos componentes de tela a presenters irá ser muito mais produtivo do que controle dataware. Isso sim é indiscutível, mas como a coisa está sendo montada agora, muita gente nao vai conseguir perceber o que é possível fazer e os benefícios de se usar tais tecnologias :) Mas prometo a vocês que o Infra, Jazz e Press estarão em destaque na comunidade delphi logo logo! e ai, ninguem mais vai discutir hehehehe! Isso sim será INDISCUTÍVEL -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
O Infra está sendo desenvolvido por mim, com alguma ajuda de alguns amigos. E pretende ser o melhor framework para desenvolvimento OO, o mais completo. Pelo menos é a minha pretensão: https://opensvn.csie.org/traccgi/infra/wiki http://www.oodesign.com.br/forum/index.php?showforum=51 O Jazz foi construido por cesar romero e o Press por joão morais, todos brasilerios e todos os 3 projetos são open source!
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Interface homem-maquina não tem nada haver com DBWares, DBEdits e coisa do tipo. Interface Homem-maquina tem haver com o padrão de interfaces (as telas e os comandos do usuário) que seu sistema irá apresentar ao operador. A premissa básica do estudo da interface HM, propôe que se faça telas limpas, práticas e com tudo facilmente ao alcance do usuário sem criar quaisquer dificuldade a ele. Na seção de arquivos da lista eu coloquei a muito tempo atrás uma apostila que trata exclusivamente do assunto. Vai lá na seção Apostilas e procura pela Interface_Homem _Máquina.zip. Tem uma outra também chamada OGuid.rar lá, ela trata do estudo feito pela Micro$oft sobre a IHM. Baixa elas e dá uma estudada. Vale a pena. Agora o uso de DBWares vai mesmo é facilitar a vida do desenvolvedor pois uma cadastro simples e básico, usando DBEdits e DBNavigator, gastaria mais ou menos na média pra ser feito e estar pronto para ser usado, uns 20 a 30 minutos chegando a 40 por aí. Este mesmo cadastro usando Edits, dependendo do tratamento que for feito e tudo mais (Já que todo o controle do dado é por conta do desenvolvedor), pode-se gastar até 1 dia de trabalho. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Fellipe Henrique [EMAIL PROTECTED] escreveu Olá amigos, Estive eu aqui pensando com meus botões, depois de ter lido uma informação em um livro de interface humano-computador. Qual é o melhor para se utilizar? Componentes DBWares (DBEdit, DBComboBox e etc...) ou componentes normais (Edit, ComboBox e etc..) para banco de dados? Pensando no lado do banco de dados, e nao da produção, pois é mais rápido usar um DBEdit, do que ter que fazer à mão... Desde já agradeço. []s -- _ Fellipe Henrique [EMAIL PROTECTED] Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
Re: [delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Coisas de faculdade Walter, eu temei com o professor, e ele teimou comigo... aí fiquei na dúvida... resolvi postar aqui.. rsrs.. Irei baixxar estes arquivo que voce indicou Walter. Muito obrigado, []s _ Fellipe Henrique [EMAIL PROTECTED] Borland Developer Studio 2006 Certified Venham até a borda, ele disse. Eles disseram: Nós temos medo. Venham até a borda, ele insistiu. Eles foram, Ele os empurrou... E eles voaram. (Guillaume Apollinaire) [As partes desta mensagem que não continham texto foram removidas]
[delphi-br] Re: Usar ou não usar DBWares? Eis a questão!
Grande João, o homem das teorias dos grupos hehe Seguinte mermão, tudo isto aí que voce falou, é muito uma aplicação teórica. Mas na prática sabemos que fazer cadastros com DBEdits é muito mais rápido e produtivo. Quanto a mesma maratona para cada campo lookup ou para cada Grid, basta voce montar um form básico e tratá-lo como ancestral. Aqui eu faço assim. Tenho um form ancestral que já vem com os componentes comuns a todas as telas de cadastro que utilizarei. Em seguida basta ir criando os forms descendentes do dito- cujo. Jogo hiperrápido e sem stress... E também eu não disse aqui que se leva um dia pra popular um mísero Edit. Eu disse que pode-se levar ATÉ um dia para montar um cadastro todo na mão. Tudo bem. Falei em um dia e posso até ter exagerado, mas isto é altissimamente relativo ao que se pretente implementar nele. Fazer um cadastro básico apenas funcional, acredito que com uma ou no máximo duas horas de implementação se consegue, incluindo aí testes e tudo mais. Agora, dependendo do que se pretende implementar, podemos chegar a mais. []s Walter Alves Chagas Junior Belo Horizonte - MG - Brazil [EMAIL PROTECTED] http://www.geocities.com/SiliconValley/Bay/1058 MSN: [EMAIL PROTECTED] --- Em delphi-br@yahoogrupos.com.br, Joao Morais [EMAIL PROTECTED] escreveu Walter Chagas (Yahoo) wrote: Agora o uso de DBWares vai mesmo é facilitar a vida do desenvolvedor pois uma cadastro simples e básico, usando DBEdits e DBNavigator, gastaria mais ou menos na média pra ser feito e estar pronto para ser usado, uns 20 a 30 minutos chegando a 40 por aí. Este mesmo cadastro usando Edits, dependendo do tratamento que for feito e tudo mais (Já que todo o controle do dado é por conta do desenvolvedor), pode- se gastar até 1 dia de trabalho. O problema do DBAware está ligado à sua concepção, aonde você coloca em um nível muito alto quais registros do seu banco deve estar ligados à ele. Há um conserto intermediário a esse problema feito pelo InstantObjects, aonde você utiliza DBAware para acessar atributos de classes de negócio ao invés de registros do banco. Um outro problema que nem o próprio InstantObjects resolve é a reutilização de regras ligados à apresentação dos dados. Você ter que fazer a mesma maratona para cada campo lookup ou para cada Grid do seu form é um baita pé no saco. Aí só um framework MVP pra ajudar, e isso o PressObjects tem. Dizer que se leva um dia de trabalho para popular um Edit é o mesmo que dizer que se leva uns dois meses de trabalho para fazer uma agenda telefônica, pois seria necessário eu escrever toda a API do banco de dados que eu vou utilizar. -- Joao Morais
