Closed TiagoGouvea closed 6 years ago
Vendo o código superficialmente deu para notar que é possível melhorar muito o reaproveitamento criando classes para cada área, tanto para SQL quanto para outras tarefas.
Uma coisa que pode ajudar tanto na organização quanto na eficiência é o uso de uma Framework como laravel que agilizaria problemas como rotas e acesso ao banco. Assim que possível irei analizar com mais detalhes
Verdade @maxjf1! Uso o laravel em alguns projetos e acho bem bacana.
Um ponto importante porém, é que este repositório aqui deve ser "fácil" de qualquer pessoa programar... muitas pessoas fazem o Desafio do Código, começam a programar e querem contribuir.
Muitos jovens que estão começando sua vida na programação também gostariam de vir aqui, pegar umas issues, fazer uns commits para poder ganhar experiência. E neste contexto acho o laravel um "dificultor"... entende? O quanto mais "código" apenas, melhor.
Isso certamente me faz preferir usar códigos puros. Organizados, mas puros.. sem um grande framework por trás.
É uma ideia.. o que acham?
Se essa é a proposta então acho uma boa manter no nativo.
A melhor alternativa é então o uso de OO e boa organização, já que hoje em PHP é o maior diferencial.
Sobre o framework, acredito que seja bom utilizar para facilitar na organização do projeto e deixei meus 2¢ aqui: #17
Já sobre ORM, o único que eu tenho experiência de uso e gosto de utilizar é o Doctrine, porém como um dos objetivos do projeto é manter as coisas o mais simples possível, acredito que um ORM possa ser um complicador. Na maioria dos ORM, existem muitos métodos mágicos que facilitam a vida porém criam problemas gigantescos de performance, tornando necessário um estudo/entendimento maior sobre o funcionamento do ORM para saber a melhor forma de utiliza-lo(Como por exemplo no Doctrine, existe o DQL, uma linguagem para query bem parecida com SQL mas que deixa claro o que o ORM irá fazer, sem muita mágica)
Então acredito que utilizar um padrão DAO com PHP puro seja mais simples.
Legal @mathmarques ! O Doctrine é muito bom, concordo. Já usei e é prático.
Acho que o caminho é esse mesmo @maxjf1 , @mathmarques , seguir o DAO com classes simples, bem organizadas em pastas e tal, pra que 100% do código esteja disponível no projeto.
Neste post o autor apresenta um padrão simples, com PDO, que acho que podemos seguir. O que acham?
Amigos, criei um DAO aqui juntando uns pedaços de madeira que eu tinha em casa, cola, e umas caixas de papelão que encontrei aqui na rua.
Se puderem dar uma olhada, está em /app/src/Model/.
Criei um controller de teste (enquanto não temos testes unitários), onde dá pra ver o uso do model.
Ainda preciso concluir mas me digam o que acham.
Fala @TiagoGouvea ! Eu gostei bem de como ficou!
Eu só moveria o DAO.php
e UserDAO.php
para a pasta Persistence/
e removeria o singleton(getInstance()
) de dentro do UserDAO.php
e adicionaria no Container(em dependencies.php) algo como:
$container['UserDAO'] = function ($container) {
$userDao = new UserDAO($container['db']);
return $userDao;
}
Achei daora o DAO mas no caso singleton n seria uma boa pedida? ou tem casos de multiplas conexões que podem ser úteis?
Show @mathmarques , vou ajustar desta forma. Sim @maxjf1 é um singleton já, mas, também ajustando como o @mathmarques sugeriu, continuará sendo. Ao pedi ao slim o "UserDAO" ele sempre retornará a mesma instância. Ali ele só executa uma vez.
Grato amigos
O acesso aos dados deve ser prático, claro, seguro e eficiente. Proponho aqui uma discussão sobre qual modelo seguir, que seja simples para todos utilizarem e seguirem em frente.
O que deseja criar
Resultado esperado
Todas as queries, ficarem apenas nos arquivos dentro do modelo, ao invés de espalhadas pelo código.
Como isso é hoje?
Hoje existem queries em vários arquivos, sem padrão, sem segurança, sem reaproveitamento de código.
Detalhe o que deve ser feito o máximo que puder
Gostaria de sua sugestão de como pode ser feito. Usar PHP puro? Usar alguma biblioteca? Quais as vantagens de fazer da forma como você propõe? Diga ai!