Re: [delphi-br] Componentes data-aware, usar ou nao usar?
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
Re: [delphi-br] Componentes data-aware, usar ou nao usar?
Romario, O Demian respondeu bem acertado, mas dentro do contexto de um modelo OO. A pergunta não foi bem essa: foi a de usar ou não componentes data-aware. Esta resposta do Demian é muito válida, mas fora do contexto da discussão. Componentes DBAware podem poupar imenso trabalho, e existem milhares de casos que uma aproximação OO é matar mosquito com canhão. Os próprios componentes DB-aware não são todos iguais, e é dificil de os generalizar. A pergunta é válida. Mas, na minha modesta opinião, é como perguntar qual a melhor linguagem de programação. Dentro de um contexto, - como o demian respondeu muito bem - é possível a tentativa de uma análise. Genericamente, é casa sem pão: todos ralham e ninguém tem razão. Faz lembrar porque é que existe uma versão Classic e uma SuperServer do Firebird: se uma das opções fosse claramente superior à outra, você acha que se perdia tempo a desenvolver as duas ? :-))) Artur Romario (Delphi) wrote: 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
Re: [delphi-br] Componentes data-aware, usar ou nao usar?
Artur, O Demian não respondeu à essa pergunta feita pelo colega. Eu apenas utilizei uma resposta que ele deu para uma outra pergunta que fiz à ele. Como achei que tinha uma boa explicação falando da possibilidade, mesmo que remota, na utilização de camadas com componentes data-aware, eu postei a mensagem dele. Acho que a mensagem que enviei ficaria melhor apresentada no tópico Edit ou DBEdit discutida antes desse tópico. Ela sim tinha tomado um rumo que levaria à essa resposta. Sds, Romario Artur Anjos escreveu: Romario, O Demian respondeu bem acertado, mas dentro do contexto de um modelo OO. A pergunta não foi bem essa: foi a de usar ou não componentes data-aware. Esta resposta do Demian é muito válida, mas fora do contexto da discussão. Componentes DBAware podem poupar imenso trabalho, e existem milhares de casos que uma aproximação OO é matar mosquito com canhão. Os próprios componentes DB-aware não são todos iguais, e é dificil de os generalizar. A pergunta é válida. Mas, na minha modesta opinião, é como perguntar qual a melhor linguagem de programação. Dentro de um contexto, - como o demian respondeu muito bem - é possível a tentativa de uma análise. Genericamente, é casa sem pão: todos ralham e ninguém tem razão. Faz lembrar porque é que existe uma versão Classic e uma SuperServer do Firebird: se uma das opções fosse claramente superior à outra, você acha que se perdia tempo a desenvolver as duas ? :-))) Artur -- 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
