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]
