Segue abaixo a resposta do Demian quando fiz essa pergunta à ele. "Em teoria, isolar a apresentação de dados em datasets e permitir sua edição em controles data-aware é possível. Em teoria.
Na prática, é improvável que a visão relacional e a visão OO dos modelos de dados sejam as mesmas. Para complicar, é comum que as interface de dados oferecidas aos clientes não representam exatamente os modelos de dados no SGBD subjacente, mas uma variação, uma visão particularizada desse modelo. Quando quebramos o paradigma de persistência em camadas, é comum acabarmos com objetos de dados, utilizados por objetos de negócios, passados para controladores de visão que, por sua vez, definem a interface visual a usar para editar os dados de negócios. Esses dados são retornados ao longo das camadas até dispararem alterações em um ou mais objetos de dados. Essa é a situação vista genericamente. Se o modelo de aplicativo é simples o suficiente para que as camadas de dados e negócios "se fundam", é possível utilizar uma só família de objetos para representar os dados (classe genérica de negócios). Se, esses objetos forem mapeados (ida-e-volta) aos dados de um TDataSet residente em memória (memory table), passa a ser possível editar os dados dos objetos usando controles data-aware. Importante, como eu mostro aqui, é que para ter isso OO você tem que resolver um problema relacionado com a lacuna semântica que existe entre o modelo relacional (registros, campos) e o modelo de objetos através de um mapeamento. Essa abordagem pode ser estendida para as situações onde os dados oferecidos nas interfaces com o usuário são obtidos da camada de negócios. Na ida, fica assim: SGBD - objetos DAO - objetos de negócios - mapeamento para TDataSet - UI com controles data-aware e na volta: TDataSet alterado - mapeamento para objetos de negócios - objetos DAO - SGBD Quando objetos DAO e de negócios se fundem numa só camada (padrão Active Record), o modelo fica mais simples. Como se vê, basta que sua camada de apresentação resolva o problema para você. Usar controles data-aware per se não é ruim. É até bacana. Desde que se saiba o que se está fazendo. Isto é, desde que seja apenas uma questão de APRESENTAÇÃO. Os mapeamentos entre o dataset e os objetos de negócios ou dados terão que existir, caso contrário, a abordagem será qualquer coisa, menos programação OO." Sds, Romario Marcos Antonio escreveu: > Caros Colegas, > estou tendo um trabalhao para substituir os comp. > data-aware em meu sistema. DBEdit -> Edit, mas estou > com grande dificuldade para incluir/mostrar registros > em DBGrids e agora talvez StringGrid, que sao detalhes > de outros registros. > Qual é o mais aconselhavel para este caso? > Abracos. > Marcos Antonio -- <<<<< FAVOR REMOVER ESTA PARTE AO RESPONDER ESTA MENSAGEM >>>>> Para ver as mensagens antigas, acesse: http://br.groups.yahoo.com/group/delphi-br/messages Para falar com o moderador, envie um e-mail para: [EMAIL PROTECTED] ou [EMAIL PROTECTED] Links do Yahoo! Grupos <*> Para visitar o site do seu grupo na web, acesse: http://br.groups.yahoo.com/group/delphi-br/ <*> Para sair deste grupo, envie um e-mail para: [EMAIL PROTECTED] <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
