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 >