nom meu caso uso os dois.. eu criei meus propios datasets derivando do tclientdataset e melhorei ele a minha maneira.. Ja os controles dbedit´s, dbmemo´s eu tambem criei novos com rotinas de validação, se é obrigatorio, etc, mudar ao receber focu, etc. fiz tudo isso usando controles nativos do delphi sem usar de terceiros. tambem recriei uma dbgrid com zebrado, exibição de fotos, etc. entao quando é apenas um cadastro utilizo eles. tambem fiz outro framework onde eu desenvolvi um sisteminha de uma unica tela so pra gerar componentes das minhas tabelas do banco de dados. onde eu digo qual o banco ai ele me lista as tabelas ai eu informo uma tabela e ele me gera um objeto com o insert, delete, update, listar dados (retornando um dataset), carregar (carregar dados de um registro nesse componente pela chave), etc, e todos os seus campos sao criados como propiedades. entao ja tenho uma stringdbgrid que eu melhorei ai quando eu quero por exemplo fazer algo mais complexo utilizo esses objetos que eu criei nesse meu sisteminha. ainda mais tirando esses objetos que eu crio do banco de dados e meus frameworku de acesso a dados tenho todo um framewokr de heranca visual dos forms onde todos herdam de um TformPai. entao quando eu crie um componente pra validacao de usuario e permissoes coloquei no form pai e eu digo se ele é um TVFormnormal, TVformrelatorio, TVformcadastro ou um TVformprincipal e ele verifica a seguranca pelo nivel de acesso dele aos botoes e etc. ate os botoes de cadastro eu criei um TrafaelbotaoCadastro onde eu digo o tipo (insert, delete, refresh, etc) e ele realiza rotinas como setar foco, autoincremento, varrer o form e ver se na hora do cadastro vc nao deixou nenhum item que é obrigatorio nao setado e etc.
levei 6 messes desenvolvento todo o meu framework que tem mais de 150 componentes que vao des de melhorias nos edits, herança de formularios, geradores de classe e tudo o mais. mas hoje eu crio uma tela de cadastro com validacao de campos se ja tem no banco ou nao, campos obrigatoris, auto incremento, e uma porrada de coisa sem digitar uma linha de codigo e idependente do banco. e quando e algo mais complexo que precisa de rapidez e agilidade uso os meus obijetos criados pelo banco de dados por exemplo uma tela de pedidos. onde fica tudo na memoria e depois e salvo no banco eu alimento os campos da forma "self.venda.cliente := self.combcliente.valor", onde no exemplo ao lado no meu objeto criado da tabela de vendas vai pegar o "valor" num combobox que eu fiz que lista os dados de uma tabela e pode resgatar um campo ao selecionar um dados desses exemplo : ele lista todos os nomes dos clientes e quando le seleciona um ele retorna o codigo no campo valor, sim e se tiver mais de um cliente? ele tem um evento onmaisdeumresultado onde ele mostra uma tela pra pessoa esolher qual ele realmente quer. ja fazia isso a um tempao pois precisava de produtividade, agilidade e dominio total no sistema e tinha que ser algo reaproveitavel dai fiz esse framework. entao minha opiniao é que voce deve correr atraz da forma que lhe cai bem no momento sem gambiarras, eu me quebrei muito pois trabalhava sozinho e quando dava um pau no sistema me lascava na manutencao. hoje em dia com meu framework o meu propio sistema gerencia os erros me envia eu corrigo de uma forma rapida e simples e envio pra net e ele mesmo se atualiza sozinho. ou seja ganhaei produtividade, rapidez e nem preciso ir no cliente pra ajeitar pequenas coisas. escolha um framework que lhe atenda ou entao desenvolva o seu propio como eu fiz. vc vai ver que copiar e colar nao ajuda de nada na hora da manutencao e fazer tudo procedural e de forma estrutorada tambem nao. use OOP pra facilitar sua vida e se vc precisa de algo que o delphi nao atende.. crie. afinal de contas o propio delphi e feito nele. uma das politicas que a gente tem aqui e que nunca pegamos componentes de terceiros sem fontes e nao usamos frameworks gigantes como a rxlib ou jed se precisamos de algo a gente mesmo faz. tirando o gerenciador de realtorio visual (o pra matricial a gente fez), que ate hoje a gente usa o quickrep mas ta tentando migrar pro fortes que a gente tem os fontes e ta estudando eles. entao é isso.. eu usao no minimo 4 frameworks que sao integrados de uma forma que parecem ser apenas um. tudo foi uma questao de ganho de tempo e produtividade. entao escolhe o que vc precisa usar e usa todos os que voce precisar. t+ 2009/6/5 Ricardo César Cardoso <ricardo_engs...@yahoo.com.br> > > > Longe de mim dizer que um é melhor que o outro. Ambas as vertentes são > muito boas quando em mãos hábeis. Digo pela minha experiência que me sinto > mais a vontade com non-DBWare, mas não dispenso o uso de um DBGrid. > > O fazer tudo na unha, na minha experiência foi relativo. Fiz uma vez e com > o tempo fui aprimorando. Mas única e exclusivamente porque não me adapto > tão bem aos componentes DBWare. Como já disse, muita comodidade e facilidade > ME prejudica. Não tenho a mesma flexibilidade de muitos amigos aqui, > reconheço... > > Se for requisito de projeto usar DBWare, não vejo problemas nem vou > espernear. Mas se puder escolher, prefiro um modelo misto, mas minimizando o > uso de DBWares a um TDataSource e TDBGrid, por exemplo. > > > []'s > Ricardo. > > 1) Evite escrever suas mensagens usando somente LETRAS MAIÚSCULAS. > > 2) Revise o texto de sua mensagem. Uma mensagem bem escrita é melhor > compreendida. > > 3) Vamos ajudar o Grupo e o Yahoo! Apague o conteúdo irrelevante! > > --- Em sex, 5/6/09, Marcos Douglas <m...@delfire.net <md%40delfire.net>> > escreveu: > > De: Marcos Douglas <m...@delfire.net <md%40delfire.net>> > Assunto: Re: RES: [delphi-br] Re: framework > Para: delphi-br@yahoogrupos.com.br <delphi-br%40yahoogrupos.com.br> > Data: Sexta-feira, 5 de Junho de 2009, 19:51 > > > Por que me sinto mais confortável? No meu caso é porque já me acostumei a > criar as rotinas de alimentação dos componentes. .. Com dbWare é fácil? Sim, > mas comigo foi nocivo. Me senti emburrecendo quando fiquei usando por muito > tempo e precisei fazer algo mais "na unha". Acabei pegando um vício, que me > deu um trabalhão pra perder. > > Se você entrar numa "briga" dizendo que "non-DBware" é melhor do > > DBware porque "fazer na unha" é melhor, então a briga será perdida. > > Tem muita gente aqui (não estou me referindo a você, Ricardo) que só > > vê 2 mundos: utilizar DBware ou fazer "tudo na unha". Se eu tiver que > > escolher entre as duas opcões, não penso duas vezes, é DBware. > > Temos que comparar 2 tecnologias/ frameworks. Não dá pra comparar > > "fazer tudo na unha" com um framework razoavelmente bem feitoque é o > > DBware. > > Marcos Douglas > > > > > > > > > > > > Veja quais são os assuntos do momento no Yahoo! +Buscados > http://br.maisbuscados.yahoo.com > > [As partes desta mensagem que não continham texto foram removidas] > > > -- _________________________ Rafael jorge alves Desenvolvedor/analista Ativa Soluções em TI. Recife - PE [As partes desta mensagem que não continham texto foram removidas]
