Como decidi escrever ORM em php do zero em um site de trabalho e o que resultou disso

Eu, como muitos programadores, tenho uma atitude bastante negativa em relação à criação de bicicletas e à invenção de rodas, e isso é mais do que justificado pelo menos pelo custo de desenvolvimento para o negócio. Mas, como minha experiência mostra, às vezes você tem que se desviar dessa regra e, até mesmo, se beneficiar dela. Quero dizer não apenas interesse e prazer no desenvolvimento, mas também guloseimas para o projeto como um todo. Você pode ler algumas palavras sobre uma de minhas experiências semelhantes sob o corte.







Introdução



A forma como criamos aplicativos da web agora é muito diferente do código que vinha até nós em busca de suporte desde os tempos antigos, quando a Star Factory foi exibida na TV, estava na moda andar com uma concha e o PHP estava apenas começando a adquirir sinais de uma linguagem orientada a objetos. Programar na década de 2000 me parece uma excelente ilustração das ideias de Darwin: naquela época, quase qualquer desenvolvedor criava suas próprias soluções, algumas delas capturavam a mente de mais de uma pessoa e, após passar pela seleção natural acelerada, frameworks e CMS se tornaram os exemplos dos melhores e mais populares métodos de desenvolvimento ... Em alguns casos, no entanto, apenas populares, sem a palavra "bom" ou ainda mais "o melhor".





Mas, ao contrário dos dinossauros e mamutes, nem todas as soluções alternativas caíram no esquecimento, especialmente no backend, e eu sei disso em primeira mão. Eu tive a chance de trabalhar, não direi com uma grande, mas bastante sólida quantidade de legado em php. Algumas delas eram simplesmente horríveis e alguns dos sites e até mesmo o CMS eram bem interessantes. Às vezes, gosto de mergulhar no que nasceu na mente dos pioneiros. Não existia essa padronização naquela época e, embora na maioria das vezes seja um excelente material para aprender antipadrões, esse código me diverte, torna o trabalho semelhante à arqueologia de TI.



Legado amado



Pessoalmente, gosto de trabalhar com sites de trabalho em legado - fazer uma edição, remover algumas muletas selvagens, reduzir o nível de caos e ao mesmo tempo não quebrar todo o sistema. Nesses momentos me sinto como uma pessoa que fez esse mundo um pouco melhor, e isso é legal.



print " <button onClick='domultimove();' class=controlbutton><img src=syspix/ico32_move.gif border=0><br></button>";
print "<b>" . $ITEM->Description . "</b>:<br>";
$browsebgcolor = "#D9D9D9";
$sql = "select i.ID, m.Name, i.perm, i.descr from item4 i inner join main m on i.ID=m.ElementID";
echo "<script language='JavaScript'> document.location='" . $_SERVER['PHP_SELF']";


Uma característica comum do legado é uma confusão de código escrito em diferentes linguagens, embora no desenvolvimento moderno, é claro, possamos adicionar, por exemplo, código em SQL a classes de PHP. Mas estou falando de outra coisa, no legado, muitas vezes há um fluxo de pensamento universal do desenvolvedor - o que e em que linguagem ele pensou, ele escreveu em um fluxo. Quero falar sobre uma situação semelhante com uma solução de CMS megadaterna com a qual venho trabalhando há algum tempo. Tudo lá era tão "maravilhoso" que estou muito feliz por ter conseguido consertar algo e fazer o site funcionar de maneira muito mais correta e rápida.



Então, eu consegui um site para uma grande empresa, escrito na primeira metade dos anos 2000. Nesse projeto tudo era baseado em classes com um método, em que tudo acontecia: trabalhar com lógica, exibir a interface (view) e acessar o banco de dados, aliás, o sql estava ali entre os comandos
print "<table>";
... Fazer edições em um site rodando com esse código, aliás, com bom tráfego e um componente comercial, não foi o mais agradável, mas o evento muito divertido.





Não é difícil imaginar que facilitei muito a vida dos desenvolvedores de back-end, primeiro trazendo a saída do layout para os modelos. Para isso, usei o mecanismo de modelo de galho já pronto e bastante popular. Foi fácil e rápido, então nem gastei muito tempo refatorando-o. O próximo passo, na minha opinião, foi fazer algo com consultas ao banco de dados, afinal, MVC não é em vão tão popular em nossa web.





Depois de examinar o Symphony e o Laravel, decidi que a abordagem ORM se encaixaria perfeitamente aqui também. Vai ajudar a realizar o trabalho com o Banco de Dados e deixar por enquanto os não-para-controladores só trabalharem com os dados já recebidos. É lógico e totalmente correto usar as soluções existentes. Portanto, em primeiro lugar, corri para o packagist para ver quais alternativas eu tenho além da Doutrina, mas depois de pensar cuidadosamente, cheguei à conclusão decepcionante de que não é tão importante. A questão é que este projeto tinha uma estrutura de dados bastante incomum. Não vi tal coisa em nenhum outro lugar, embora tenha trabalhado com MODx :) Enfrentei um problema: usar ORMs de código aberto populares do jeito que eu quero não vai funcionar, bem, pelo menos será outra aventura. Então decidi criar uma bicicleta.



Um pouco sobre o que eu fiz





Sim, decidi que escreveria um ORM em PHP do zero (não, bem, tive ideias e conceitos emprestados do mesmo Docktrine) especificamente para este projeto, para que funcionasse com a estrutura de dados. Afinal, este é um site de trabalho, e ninguém estava pronto para alocar recursos dos programadores para a tarefa de “reescrever tudo do zero com uma estrutura de banco de dados normal”. Os antepassados ​​que fundaram este CMS criaram 2 tipos de objetos, e um deles também foi dividido em "tipos de dados" internos: recursos que possuem datas, links, diferentes tipos de texto, imagens e vários outros tipos foram armazenados em 2 tabelas, mas também havia objetos armazenados em uma tabela, acho que podem ser chamados de dados do sistema.





Eu não queria ter que pensar em junções ao aplicar chamadas a modelos, ou pelo menos tentar reduzir esses momentos ao mínimo. Portanto, decidi que os modelos deveriam ser de dois tipos: para objetos de mesa única e para objetos básicos de duas mesas. Uma vez que essas classes de modelo têm muitos métodos comuns, o mesmo ORDER BY ou LIMIT, portanto, cada classe base, com base na qual os modelos concretos serão criados, eu herdei da classe Abstract geral.



ORM



Como você pode ver na árvore, também adicionei suporte para diferentes tipos de bancos de dados, o que é redundante neste caso. Mas naquele momento entrei no "stream" e criei :). Além disso, o passo muito correto neste caso foi que eu fiz isso com base no PDO, porque o php-mysql usado no código não permitia traduzir o site para a sétima versão da linguagem, e eu queria consertar isso na raiz, como dizem.



$element = (new Model())->getOne($id);


Pelo fato de ter um bom entendimento da lógica da estrutura do Banco de Dados, consegui buscar e recuperar um recurso apenas pelo seu ID, mesmo sem saber que tipo de dado interno o recurso possui, o que era necessário com a abordagem antiga. Objetos reais trabalham com dados, e esquecemos o sql no código.





Parágrafos finais ...



Este trabalho trouxe 2 voltas inesperadas para mim. Primeiro, tentei escrever tudo de uma vez na forma de código e nada funcionou. Tive que pegar uma caneta, um caderno, sair na natureza e, ao chilrear dos pardais e ao zumbido das abelhas, primeiro desenhar o que quero obter, como será conectado, de que classes preciso e como será chamado no código "controladores". A propósito, então a implementação diferia dos esboços originais apenas ligeiramente. Portanto, se um programador não codifica nada, não significa que ele não esteja fazendo nada útil.



Em segundo lugar, fiz isso muito rapidamente, muitas empresas não gostam quando os programadores gastam tempo em todos os tipos de refatorações incompreensíveis. Implementei todo o projeto em cerca de uma semana, enquanto fazia simultaneamente as tarefas de implementação de novas funcionalidades.



Vou observar as vantagens que afirmei no início do artigo: a sequência e a gradualidade da substituição do código existente em um projeto de trabalho, o que significa que não há necessidade de alocar mais tempo para a transição, refatorando o código dentro da estrutura das tarefas recebidas. Por isso me despeço, obrigado por ler.



All Articles