Olá Dirlei, Bom, primeiro vamos ver o que é framework: http://pt.wikipedia.org/wiki/Framework
Bom, sabendo que o framework é uma abstração que une códigos comuns, então estou dentro do conceito, pois abstraio qualquer componente a ser utilizado e trabalho somente com códigos seguindo o padrão OO. E sabendo que é um conjunto de classes que COLABORAM PARA REALIZAR UMA RESPONSABILIDADE, continuo dentro do conceito, pois todo o conjunto de classes do framework colaboram para realizar a responsabilidade de persistência de dados e gerência destes dados. Eu gostei das suas respostas, é isso ai. Eu também concordo que a maior vantagem do Delphi seja o RAD que é perfeito, o lance de você conectar objetos direto na tabela também facilita, a parte da VCL também é perfeita, mas eu sempre tive este problema com componentes de acesso a dados, em relação a qual usar, a poder trocar a camada de persistência sem ter que mecher no código do projeto e por ai vai. Notei também a lentidão no uso de componentes conectados direto, erros que eu não sabia de onde vinham, perdas e mais perdas, foi ai que pensei em seguir uma metodologia de desenvovlimento seguindo os padrões do mercado, já que dava certo para eles, daria certo para mim também, então desenvolvi este simples framework. Eu concordo com você em termos, pois o RAD do Delphi deve ser usada e muito, sem dúvida, mas não para uma camada sensível como a da persistência. Você pode desenvolver um software em 1 mês, mas quando for alterar para fazer algo mais específico ou complicado levará 2 meses para faer manutenção. Assim como aconteceu comigo, pois desenvolvi um software bacana para um cliente a uns anos atras, tudo conectado e tal, ai com o tempo começou os problemas de performance, perdas de dados, queda de conexão e vários problemas chatos. Após migrar para o framework, ficou muito mais fácil e rápido de entender o que o sistema faz, pois o código fica centralizado muitas das vezes no gerente, e acabou meus problemas de componentes ligados direto nos controles, pois agora gerencio a persistência e destruo tudo após o uso. Ganhei muita performance e todos viveram felizes para sempre. Isso não quer dizer que não consigo acessar o componente do gerente, eu até consigo mas não recomendo. Enfim, quero mostrar que seguir o padrão DAO é vantagem sim, e usar o RAD para fazer a camada de apresentação, até porque ninguém cria regra de negócios usando RAD. Usar um framework que controle via código a persistência é muito mais vantagem do que usar componentes visuais que muitas das vezes você nem sabe o que ele faz internamente e as vezes tem alocação de memória e acesso ao banco desnecessário. Enfim, está ai para quem quiser estudar. -- Atenciosamente, Paulo Coutinho. Blog: www.prsolucoes.com/blog Site: www.prsolucoes.com Msn: pa...@prsolucoes.com Skype: paulo.prsolucoes Consultor Certificado Bindows Em 2 de junho de 2010 11:15, Dirlei <dir...@gmail.com> escreveu: > > > Olá Paulo, > > Baixei olhei seu exemplo. Quero parabeniza-lo pela iniciativa de > desenvolver algo usando técnicas modernas e compartilhar livremente. > > Tenho alguns comentários para fazer e, poderemos discuti-los se você > desejar. Mas você perceberá que comentarei mais questões conceituais do > que de implementação. > > 1) A maior vantagem de desenvolver em Delphi - na minha opinião - é ter > os benefícios de uma ferramenta RAD. Isso, entre outras coisas, > significa que poderei arrastar componentes para fazer o básico (telas, > acesso a banco de dados etc) e me dedicar a codificar apenas aquilo que > uma ferramenta RAD não pode fazer por mim - regras de negócio, por > exemplo. Quando tento fazer no Delphi as coisas que são típicas de uma > tecnologia que não segue a filosofia RAD (Java, por exemplo), me vejo > perdendo as vantagens de usar Delphi. > > 2) Para que eu utilize um framework de acesso a dados no Delphi, ele > teria que tornar o meu trabalho mais simples e fácil do que já é usando > a VCL. Se eu tiver que escrever mais, isso significa que levarei mais > tempo para fazer o meu trabalho, além de precisar de mais tempo para > corrigir os bugs, que crescem na proporção da quantidade de código. E > como sabemos, tempo é dinheiro. > > 3) Percebo que você valoriza a utilização de padrões, inclusive notei o > uso de design patterns no seu código. Considero isso muito bom. > Igualmente bom é bom conhecer as aplicações mais apropriadas para os > padrões. Quando você diz "Esqueça esse lance de componente, foque na > orientao a objetos", tenho a impressão de que a praticidade das coisas é > menos importante do que seguir padrões. Pra mim, a orientação a objetos > não é boa para todos os casos. Se você tiver oportunidade de conversar > com "gurus" do desenvolvimento de software (ou ler seus artigos) - como > pessoas ligadas a criação de linguagens, software open source etc, verá > que eles também pensam assim. Pra mim, poder escrever tanto código > procedural como OO em Delphi é uma vantagem, não uma limitação. > > 4) O conceito de "framework" que conheço diz que o código que escrevemos > é executado pelo framework (inversão de controle). Quando nosso código é > quem chama alguém para fazer um trabalho, estamos utilizando uma > biblioteca - não um framework. Pode ser que exista mais de uma definição > de framework e eu ainda não sei. Mas sob o conceito que conheço, você > criou uma biblioteca, não um framework. > > Espero que essa troca de idéias tenha sido produtiva. Nenhum de nós é > dono da verdade, então posso estar equivocado em alguns conceitos, mas > atualmente, essas são minhas opiniões. > > Um abraço, > Dirlei Dionísio > > Novo artigo: Quando utilizar soluções de contorno > http://MaisQueBomCodigo.blogspot.com > > Em Qua, 2010-06-02 às 00:08 -0300, Paulo Coutinho escreveu: > > Ol, > > > > Eu entendi, mas o lance que em qualquer outra llinguagem/plataforma como > > java ou .net no se trabalha com componentes diretamente e sim com facade, > > DAO, pojo e por ai vai, ento no delphi usei a mesma lgica, ao invs de > > > acessar componentes vamos acessar os objetos e a forma como os objetos > > trabalham, pouco importa, pois o que acontece na maioria das vezes voc > > migrar de verso do delphi e ter que atualizar componentes e tudo mais, o > > que no precisa aqui , j que voc pode usar qualquer componente por tras > > das classes. > > > > Ento no escrever muito, um cdigo simples e bem pequeno para um > > framework que tem este propsito simples. Se voc for passar pro java ou > > .net ter mais trabalho ainda. > > > > Escrever muito no sinnimo de ser burocrtico, mas organizado e seguindo > > padres. > > > > muito mais fcil voc manter este cdigo, do que um sistema cheio de > > componentes conectados, alm de possuir um maior controle de memria e de > > > dados. > > > > Enfim, quem quiser ajudar ai, seja bem vindo, pode modificar livremente, > s > > peo que se for usar, me falar como foi a experiencia e o tipo de projeto, > > para eu ter idia. > > > > > Abs. > > > > > > > > > > Em 1 de junho de 2010 09:02, Marcos Douglas > > <m...@delfire.net<md%40delfire.net>> > escreveu: > > > > > > > > > > > 2010/6/1 Paulo Coutinho <pa...@prsolucoes.com > > > <paulo%40prsolucoes.com><paulo% > 40prsolucoes.com>>: > > > > > > > Ol, > > > > > > > > > Obrigado pelas criticas, com certeza ajudam muito. > > > > > > > > Mas vou explicar alguns detalhes. > > > > > > > > O framework utiliza o padro DAO ou MODELO/GERENTE, ento voc no usa > > > > diretamente componentes como ado ou dbx, voc cria os modelos e o > > > framework > > > > se encarrega de montar baseado nas configuraes do arquivo INI, embora > > > voc > > > > at possa acessar o dbx ou ado pelo gerente, mas no recomendo. > > > > > > > > A transparncia do framework permite deixar voc livre de qual > componente > > > > suar, j que estou colocando os 2 padres do delphi, mas nada impede de > > > voc > > > > > alterar o gerente para usar o UniDac por exemplo. > > > > > > > > Outra vantagem voc trabalhar com componentes desconectados e > liberando > > > da > > > > memria o desnecessrio, sempre criando e excluindo o objeto quando no > > > usar > > > > mais. > > > > > > > > Outra vantagem voc trabalhar com objetos , utilizando padres e > > > definindo > > > > uma metodologia de desenvolvimento para seus projetos, ao invs de > > > manipular > > > > componentes, voc vai manipular objetos, como : > > > > > > > > > - cliente.nome > > > > - mercadoria.valor > > > > - pessoa.data_nascimento > > > > - etc... > > > > > > > > Os cdigos no so confusos, apenas IFs para saber se o grid tem item > > > > > selecionado e depois vem: > > > > > > > > > > > > /////////////////////////// > > > > gMembro := TPRFWK_Membro.Create; > > > > > > > > gMembro.ID := 1; //substitui por um numero > > > > gMembro := gGR_Membro.obter(gMembro) as TPRFWK_Membro; > > > > > > > > //estou dizendo neste bloco que criei um objeto da minha classe de > > > dominio > > > > "Membro", defini o atributo padro "ID" para 1 e usei o gerente para > > > > obter > > > > este objeto pela chave "ID". > > > > > > > > //por padro todas os modelos do dominio possuem o atributo "ID" (pode > > > > ser > > > > alterado na classe pai dos modelos) > > > > /////////////////////////// > > > > > > > > //////////////////////////////////// > > > > > > > > if (gMembro <> nil) then > > > > begin > > > > gMembro.nome := edNome.Text; > > > > gGR_Membro.alterar(gMembro); > > > > gMembro.Free; > > > > end; > > > > > > > > carregarGrid(); > > > > > > > > > > > > //aqui estou verificando se o valor retornado para meu objeto no est > > > > nulo, > > > > ou seja, se realmente encontrou o Membro pelo ID dele. > > > > > > > > Em seguida defino o nome do membro como o texto do edit e uso o > gerente > > > para > > > > alter-lo e libero o modelo recebido da memria. > > > > > > > > //////////////////////////////////// > > > > > > > > No vi complicao. E em nenhum momento me preocupei com componentes. > > > Essa > > > > a regra. Esquea esse lance de componente, foque na orientao a > objetos. > > > > > > > > > > > > Mais uma classe til, usada aqui: > > > > > > > > > /////////////////////////// > > > > lTemp := > > > > > > > > MD_PRFWK_Utilidades.TPRFWK_Utilidades.obterInstancia().obterConfiguracao('APLICACAO','titulo', > > > > ''); > > > > self.Caption := lTemp; > > > > > > > > //aqui eu estou usando uma classe do framework para obter do arquivo > de > > > > configurao o TITULO da aplicao, mas em aplicaes que tenho aqui, > > > possuo > > > > trocentas configuraes pelo INI, ento ajuda bastante. > > > > > > > > /////////////////////////// > > > > > > > > > > > > Mais alguma dvida? > > > > > > Falei que o cdigo confuso, no que eu tinha dvidas sobre como ele > > > trabalha. confuso porque escreve-se demais para obter coisas > > > simples; burocrtico, na minha opinio, claro. > > > Em todo caso, pode ser bem til para vrias pessoas. Parabns pela > > > divulgao. > > > > > > Marcos Douglas > > > > > > > > > > > > > > > -- > > Atenciosamente, > > Paulo Coutinho. > > Blog: www.prsolucoes.com/blog > > Site: www.prsolucoes.com > > Msn: pa...@prsolucoes.com <paulo%40prsolucoes.com> > > Skype: paulo.prsolucoes > > Consultor Certificado Bindows > > > > > > [As partes desta mensagem que no continham texto foram removidas] > > > > > > > > ------------------------------------ > > > > > [As partes desta mensagem que não continham texto foram removidas] ------------------------------------ -- <<<<< 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: delphi-br-ow...@yahoogrupos.com.br 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: delphi-br-unsubscr...@yahoogrupos.com.br <*> O uso que você faz do Yahoo! Grupos está sujeito aos: http://br.yahoo.com/info/utos.html
