Array
(
    [0] => stdClass Object
        (
            [Votos_Balanceados] => 1
            [id] => 484738
            [titulo] => Teste de Framework
            [dataCadastro] => DateTime Object
                (
                    [date] => 2014-07-06 22:43:17
                    [timezone_type] => 3
                    [timezone] => America/Sao_Paulo
                )

            [isFirstPost] => -1
            [idUsuario] => 358006
            [status] => A
            [isExample] => 
            [NomeUsuario] => Raphael Neves de Souza
            [Apelido] => Raphael Neves
            [Foto] => 358006_20140212083232.jpg
            [Conteudo] => Boa noite. Primeiramente parabéns pela iniciativa. Bom, seguem alguns comentários:

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. ) )

Teste de Framework

PHP
William (devwilliam)
   - 06 jul 2014

Olá pessoal, estou disponibilizando um link no Git Hub onde coloquei um mini "framework" que estou desenvolvendo em PHP.
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 !!!

Post mais votado

Raphael Neves
   - 06 jul 2014

Boa noite. Primeiramente parabéns pela iniciativa. Bom, seguem alguns comentários:

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.

Marcio Araujo
   - 06 jul 2014

não conheço bem a utilização de frameworks, mas logo te parabenizo pela iniciativa de fazer algo mais simples.

William (devwilliam)
   - 06 jul 2014

Olá Marcio, é bem simples de usar e não pretendo colocar mais complexidade senão cai na mesma história ...

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!!!

Marcio Araujo
   - 06 jul 2014

nos exemplo tem algo como um CRUD?

William (devwilliam)
   - 06 jul 2014

Sim tem INSERT, UPDATE, DELETE e consultas no título de cada arquivo tem o propósito (exemplo-insert.php) ...

Marcio Araujo
   - 06 jul 2014

ta certo William, assim que der posso testar. abraço.

Fabio Santos
   - 06 jul 2014

parabens pela iniciativa, mas sou bem iniciante mesmo no assunto, se puder me repassar algum material basico de framework, eu poderia tentar utilizar.

William (devwilliam)
   - 07 jul 2014

Olá Raphael, primeiro gostaria de agradecer a todas as considerações que você fez, como moderador da sala PHP acompanhei alguns tópicos que você participou e notei que o seu conhecimento no framework CakePHP é vasto, isso acaba dando maior credibilidade nas suas considerações.

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:

Citação:
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???

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.

Citação:
2) realmente O.O é uma boa prática, mas ignorar MVC e outros design patterns é algo um pouco absurdo.

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.

Citação:
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?

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.

Citação:
4) como seu frame trata persistência no banco? Como ficam as tabelas com relacionamento n pra n (hasAndBelongsToMany)?

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.

Citação:
5) como se aplica os conceitos de segurança como geração de hash, controle de sessão, acl etc?

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.

Citação:
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ê.

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.

Raphael Neves
   - 07 jul 2014

Bom dia, William. Compreendi o objetivo real do projeto. Antes de prosseguir, relendo a citação que você colocou "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ê." percebo que fui um pouco infeliz nessa minha colocação, uma vez que tudo aquilo que é novo gera obstáculos iniciais. Você foi muito feliz no seu comentário.

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.

William (devwilliam)
   - 07 jul 2014


Citação:
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"


Sua análise foi perfeita Raphael, reproduziu muito bem em poucas linhas o meu objetivo!

Agradeço pelo retorno.

Ronaldo Lanhellas
   - 07 jul 2014

Muito boa sua iniciativa mas senti falta de algo, se eu quiser acoplar um outro framework ao seu, por exemplo o Doctrine (muito utilizado) como faria se você está usando PDO ?

Mesmo que seu framework seja simples, ele deve ser genérico o bastante para possibilitar a utilização de outros frameworks em conjunto.

William (devwilliam)
   - 07 jul 2014

Olá Ronaldo, agradeço seu comentário e acho extremamente pertinente sua colocação.

Citação:
Doctrine (muito utilizado) como faria se você está usando PDO ?

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.

Citação:
Mesmo que seu framework seja simples, ele deve ser genérico o bastante para possibilitar a utilização de outros frameworks em conjunto.

Infelizmente fico devendo essa funcionalidade meu amigo, ainda preso pela simplicidade.

Abs.

Ronaldo Lanhellas
   - 07 jul 2014

Na verdade a segunda citação é complemento da primeira. Enfim, obrigado pela resposta.