Teste de Framework
06/07/2014
0
link: https://github.com/wllfl/framework
Quero deixar bem claro que a minha ideia não é reinventar a roda e nem ganhar dinheiro com isso, uma vez que já existem diversos frameworks para PHP no mercado, comecei a escreve-lo porque não me adaptei com Cake, CodeIgniter e Zend.
Minha ideia é fornecer algo simples e rápido de se utilizado no dia a dia, ele possui apenas 4 classes e não vai sair disso:
- Conexao.class.php -> Classe de conexão com banco de dados via PDO
- Crud.class.php -> Classe genérica para CRUD
- Helper.class.php -> Classe com métodos estáticos para auxílio na formatação de valores
- Controller.class.php -> Classe que faz o meio campo entre as páginas (View) o banco de dados (Model)
Não estou seguindo a arquitetura MVC, e nem os padrões de projeto uma vez que a GoF prega como boa prática o desenvolvimento orientado a objetos para interfaces.
Mas o bacana é que utilizo ele no dia a dia na empresa com SQL Server, MySQL e já foi testado com PostgreSQL, gostaria de pedir aos nobres colegas que baixem e utilizem para ver até onde ele pode ser útil, rápido e versátil. Quem puder e tiver disponibilidade poderia testa-lo no Oracle, mas ressalto que para utilizar o PDO com Oracle é necessário instalar a DLL correta.
No link existem scripts de exemplo para uso, as classes também estão bem comentadas.
Aceito receber criticas e sugestões !!!
William
Post mais votado
06/07/2014
1) como se daria a regra de negócio? Uma regra pra cada página? Tudo no controller? E as regras que se aplicam na camada de modelo, onde seriam tratadas? Validação de campos???
2) realmente O.O é uma boa prática, mas ignorar MVC e outros design patterns é algo um pouco absurdo.
3) uma classe de crud e uma de controller?? Ambíguo, não? Como vc mesmo definiu, a classe controller faz o meio campo de regras e banco. O crud está diretamente ligado a este conceito. Por qual motivo optou por tratar classes diferentes para tal?
4) como seu frame trata persistência no banco? Como ficam as tabelas com relacionamento n pra n (hasAndBelongsToMany)?
5) como se aplica os conceitos de segurança como geração de hash, controle de sessão, acl etc?
Considerações finais: deve-se planejar muito antes de disseminar uma nova ferramenta, principalmente o planejamento e implementação de boas práticas em prática no mercado. No meu front-end tenho algumas práticas que simplificam a criação do meu layout, levando em consideração opiniões e aplicações de outros especialistas. Mas aquilo que facilita pra mim pode dificultar pra você. Pensando nisso, invista na documentação da sua ideia inicialmente. Repense o fato de não utilizar design patterns e outros. No mais, parabéns pela iniciativa.
Raphael Souza
Mais Posts
06/07/2014
Marcio Araujo
06/07/2014
William
Nos exemplos você pode observar como é fácil de usar, pode configurar campos que podem ser nulos na inserção e edição, verificar duplicidade de registros antes de inserir e etc ...
Claro que ainda faltam melhorias, mas compartilhando com a comunidade espero ter um feedback para correções!!!
06/07/2014
William
06/07/2014
Fabio Santos
07/07/2014
William
Cometi um erro grave na escolha do título do post "Teste Framework", acaba passando a impressão de algo grande para competir com os renomados frameworks do mercado que possuem diversas funcionalidades, esse meu erro acabou gerando um certo rigor na sua análise. Mas na verdade o que escrevi é um conjunto de classes que ordenadas auxiliam no desenvolvimento do dia a dia, citei acima que não pretendo colocar mais classes aumentando a complexidade, pois não é esse o objetivo e muito menos ganhar dinheiro com isso.
Bom vamos as considerações:
Regras de negócio continuam sendo aplicadas no script client que recebe as submissões e como sabemos podem existir diversos tipos para cada página. O controller possue apenas regras comuns a todas as operações de cadastro, como verificação de campos nulos e duplicidade de registros antes da inserção. Validação de campos específicos como email, senha e etc. podem ser acrescentadas na classe Helper, pois a classe controller possui somente métodos genéricos.
Já faz algum tempo que li o livro "Aprendendo Padrões de Projeto em PHP" do autor William Sanders, não utilizo design patterns no que diz respeito as interfaces e padrões comportamentais mas, se você analisar as classes pode notar que a classe de conexão utiliza o padrão singleton para instância do PDO, outro ponto interessante é que o relacionamento entre as classes pode ser considerado de associação também.
Talvez o nome "controller" não retrate a real função dessa classe, ela funciona como uma camada antes da persistência onde já existe validações genéricas e pretendo colocar mais. A classe Crud seguindo o conceito de alta coesão, possui somente a responsabilidade de operações INSERT, UPDATE, DELETE e SELECT não se preocupando com validações ou duplicidade de registros. Um fator interessante dessa classe é que essa camada pode ser retirada, onde o usuário instanciaria somente a classe Crud, trabalhando diretamente com as operações no banco de dados.
Como citei no início da respota, o título do post acabou gerando esse rigor, simplesmente utilizo instruções SQL parametrizadas o que já é uma boa prática, mas não me preocupo com relacionamentos entre entidades, esse não é o foco das classes.
Hash de segurança, ACL ainda necessita ser escrito pelo próprio usuário, até cheguei a elaborar e testar algo com sessions, mas aumentou a complexidade então deixei de fora.
Talvez nesse ponto eu acabe discordando um pouco de você, todo e qualquer framework do mercado e até paradigmas de desenvolvimento é baseado em experiências de um grupo de profissionais inicialmente, posteriormente com a evolução ocorrem as melhorias com a chegada de sugestões. Então vamos pensar que de alguma maneira somos influenciados por práticas hoje vencedoras mas que no início eram apenas uma ideia maluca de um grupo de programadores.
Enfim Raphael, agradeço mais uma vez seus comentários, meu objetivo é facilitar alguns pontos do desenvolvimento diário onde consigo trabalhar com 3 SGBDs (até o momento) apenas alterando os dados de conexão, sem a preocupação com o resto das instruções.
Acredito que essas classes possam ter utilidade para aplicações pequenas, mas não para grandes projetos.
Ainda tem algumas melhorias que pretendo implementar baseadas em opiniões de leitores do meu blog http://devwilliam.blogspot.com.br/, aliás foi através de sugestões de alguns que foram escritas essas classes.
07/07/2014
Raphael Souza
Com base nas suas considerações, posso afirmar que a metodologia abordada seria para facilitar pequenos e talvez médios projetos? Pergunto isso baseado no critério de aplicar métodos simples para situações complexas e levando em consideração a parte de segurança que ainda deve ser implementada "na unha". Pensa em uma documentação futura?
Gostei bastante das considerações e agradeço por compartilhar seu conhecimento.
07/07/2014
William
Sua análise foi perfeita Raphael, reproduziu muito bem em poucas linhas o meu objetivo!
Agradeço pelo retorno.
07/07/2014
Ronaldo Lanhellas
Mesmo que seu framework seja simples, ele deve ser genérico o bastante para possibilitar a utilização de outros frameworks em conjunto.
07/07/2014
William
Não entendi muito bem essa colocação, o pouco que conheço do framework Doctrine sei que ele suporta a maioria dos drivers para PDO.
Infelizmente fico devendo essa funcionalidade meu amigo, ainda preso pela simplicidade.
Abs.
07/07/2014
Ronaldo Lanhellas
Clique aqui para fazer login e interagir na Comunidade :)