Era isso que eu ia dizer! Andreano Lanusse <[EMAIL PROTECTED]> escreveu: 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] -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Links do Yahoo! Grupos Valfrid-Ly Silva Couto [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ICQ 15114646 --------------------------------- Yahoo! Search Música para ver e ouvir: You're Beautiful, do James Blunt [As partes desta mensagem que não continham texto foram removidas]
