aplicacao orientada a objeto sem DBEdit

Jair,          Existem várias formas de vc fazer isso, abaixo listei as mais usadas. Como apresentado na vídeo anterior, vc pode criar uma Classe e definir um método Update base identificando qual será a operação a ser efetuada com a tabela em questão. Pode ser insert ou update. (nesse caso) Sendo assim, no formulário vc colocar Edit ao invés de Dbedit, vai mudar na hora de gravar os dados, e na hora de apresentá-        Vamos entender bem isso. ·         Se vc utilizar DBEdit, sabemos que eles possuem as seguintes propriedades que o vinculam aos dados de uma tabela o    A propriedade DataSource:  onde indicamos o DataSource que esta ligado ao componente Table; o    A propriedade DataField: que identifica qual campo(field) da tabela que esse BDEdit irá exibir ou atualizar. §  Isso é transparente, sempre que chamarmos o método Open, abrimos a tabela e os registros são apresentados nos DBsEdits. Ao navegarmos na tabela com Prior, Next etc. Os registros são atualizados nos DBsEdits, tranqüilo, não precisamos nos preocupar com nada. Se chamarmos o método Insert, a tabela entra em modo de inserção e todos os DBsEdits são limpados e ficam prontos para receber novos dados. Por fim ao chamarmos o método Post(gravar) os registros são persistidos na base de dados. ·         Ao contrário se vc trabalhar com Edit, não teremos as propriedades DataSource e DataField, sempre que precisarmos exibir os registros de uma tabela, precisamos preencher os campos manualmente, colocando o valor gravado na tabela na propriedade Text do EDIT, Exemplo: o    EditNomeCliente.Text := NomeCompTableFieldNomeCliente.AsString; §  Sempre que chamarmos os métodos de navegação Prior, Next etc. Teremos que repetir a linha acima para atualizar o valor em todos os Edit’s, já sabemos então que essa opção deve ser uma função dentro de uma classe, pode ser na classe UpdateBase criado no vídeo anterior. Sendo assim, podemos chama-la de MostraRegistros. E na implementação da mesma trabalharmos com o componente query. Ex: ·         Query1.Close; ·         Query1.ParamByName(‘CodCliente’).asInteger := ValorASerLocalizado. ·         Query1.Open; // Nesse momento tenho o registro de apenas um cliente carregado em memória. O que é ótimo. Outro detalhe que muda, é no momento de gravarmos os dados, (post) podemos fazer da seguinte forma: //Abrir a tabela TblCliente.Open; TblCliente.Insert; TblClienteCodigoCliente.AsInteger := StrToInt(EditCodigoCliente.text); TblClienteNomeCliente.AsString := EditNomeCliente.text; ………….. todos os campos… da tabela devem receber os valores TblCliente.Post; -------------------------Outra forma e a mais utilizada é trabalhando com StoredProcedures ------------- (storedProcedures são procedures que ficam armazenadas no banco de dados)   // Nessa opção não preciso abrir a tabela ela fica isolada e trabalho 100% desconectado da base de dados. O que é ótimo! StoredProcedureInseriCliente.ParamByName(CodigoCliente).asInteger:= StrToInt(EditCodCliente.Text); .......................... faço isso com todos os campos. StoredProcedureInseriCliente.ExecProc;   Vamos as considerações das duas alternativas, trabalhar com DBEdits ou com Edits Trabalhando com DBEdits: Vantagens: Facilidade na manutenção (apenas chamo o método que precisar Post por exemplo); Escreve-se muito menos código, praticamente nada Não precisamos nos preocupar com qual operação esta sendo executada, se é Insert, ou Update ou Delete, apenas chamamos o método correspondente do componente Table e esta feito. Desvantagens: Sempre que precisarmos navegar nos registros da tabela, ou inserir um novo, ou alterar um existente, ou mesmo deletar algum registro, obrigatóriamente preciso ABRIR a tabela, o que significa carregar todos os registros existente na tabela de cliente por exemplo para a memória, (pense nisso), imagine 1 milhão de registros na memória, ou pior ainda trafegando por uma rede para serem exibidos em uma estação. Mantemos a conexão com a base de dados 100% ativa. Trabalhando com Edit’s Vantagens Trabalhamos 100% desconectados, não precisamos em momento algum abrir tabelas, para mostrar os dados, utilizamos uma query, que pode retornar apenas um registro se for o caso, para altera-los so precisamos saber o código que será alterado, para inserir so precisamos preencher os dados nos edits e chamar a StoredProcedures. Claro que se utilizarmos a opção de trabalhar com tabelas e abri-la, morre aqui a vantagem, mas eu diria que 99% das pessoas que trabalha com Edit, o usam para ser 100% desconectado, utilizando sempre StoredProcedures no banco. Performance muito melhor, em momento algum trafegamos registros de tabelas pela rede, os Insert’s, Updates etc. são executados direto no servidor, no banco de dados. Desvantagens So vejo uma, da um pouco mais de trabalhos pois codificamos muito mais do que com DbEdit, mas temos a aplicação na mão e controlamos o que esta sendo inserido de forma muito mais otimizada   Eu sinceramente aconselho sempre que possível (considerando a questão tempo e também o tamanho do projeto) , o uso de Edit e StoredProcedures, assim melhoramos a performance e garantimos o que esta sendo inserido. Mas é necessário uma análise de cada projeto, não fará sentido trabalhar desconectado em um sistema que é usado apenas em 1 máquina e que terá poucos registros na base. Aí so teremos trabalho. A questão da orientação a objetos nesse caso, DBEdit’s e Edit’s, viabiliza a criarmos classes com funções pré-definidas, uma será responsável por mostrar os registros da base, outra pela atualização dos registros qdo houver navegação, outra pela inserção etc. Depois de estrutura a classe podemos começar a generalizar algumas coisas. Espero que tenha sido claro.   Qualquer coisa estamos a diposição.    abs  

Ola Guinter,        Agora que estou começando entender OO estou convencido de que pelo exemplo da sua vídeo aula, usar DBEdits pela facilidade e quantidade de código a ser escrito, esse perigo de se trazer milhões de registro do BD ao abrir um ClientDataset, creio que não esquecendo de parametrizar os mesmos seja resolvido. Por favor estou encerrando este chamado, mas se falei alguma besteira por favor, me ajudem, minhas aplicações só tenho usado TEDits.   []s. Jair de Souza Cruz.

Jair,     Referente a sua colocação sobre os DBEdit’s, é isso mesmo, sempre que o utilizarmos, temos que ter consciência de que corremos o risco de sobrecarregar a memória e nos depararmos com problemas na hora de inserir, registros, ou alterá-los.   Considere também a situação de que se vc tem um sistema em rede, pense que um usuário pode estar alterando o cliente código 1 e outro cliente pode tentar apagá-lo, com certeza teremos problemas. Por outro lado, imagine um sistema com uma chave primária, CodigoCliente por exemplo, sabemos que a chave primária deve ser única, com DbEdit pode acontecer de 2 ou mais usuários estarem cadastrando Clientes e pegarem o mesmo código, lembre-se so na hora de gravar é que a chave é persistida na tabela, teremos mais um stress aqui.   Em todos os sistemas que eu desenvolvi, sempre que envolver vários usuários utilizando-os eu uso StoredProcedures, e Edit’s, assim evito esse problema.   O segredo do bom funcionamento de qualquer software é a Lógica, e as Regras de Negócio, que vc cria com as classes.   Fica esse aprendizado então, DBEdit’s para sistemas pequenos e ou com apenas um usuário acessando a mesma tela (exemplo a tela de Cliente). Edit’s, StoredProcedures etc. para sistemas robustos.   Precisando estamos a disposição,   Consideramos então esse chamado encerrado,   abs