1.3. Montando nosso framework PHP

Existem muitos caminhos diferentes para construir um framework. Alguns preferem frameworks muito complexos, outros preferem muito simples. Em nossos artigos, vamos rapidamente montar um framework simples de usar e fácil de entender.

Nossos artigos ajudarão você a desenvolver seu próprio framework, diferente do que precisamos para criar uma loja virtual, você poderá adicionar facilmente outras partes ao framework para criar algo maior. O principal objetivo da série de artigos é aprender a fazer seu próprio framework para qualquer CMS.

Padrões (Patterns)

 Para desenvolver um framework, são aplicados vários padrões de design de aplicativo chamados Padrões. Um padrão é a solução mais bem-sucedida e as práticas que resolvem problemas comuns relacionados ao desenvolvimento de programas. Entre os padrões, usaremos os seguintes:

• Modelo-Visão-Controlador (MVC, Model-View-Controller)
• Registro (Registry)
• Classe Singleton (Singleton)

Modelo-Visão-Controlador (MVC)

MVC é a base do nosso framework, fornecendo uma solução para separar a interface do usuário da lógica do aplicativo. A interface do usuário (View) interage com modelos de dados (Model), usando controladores (Controller), que por sua vez contêm a lógica de negócio necessária para gerenciar dados nos modelos.

Por exemplo, quando um usuário clica em "Adicionar ao carrinho" na Visão (view), o controlador processa esse pedido e interage com o modelo do carrinho e adiciona o produto ao carrinho. Normalmente, os dados do modelo do carrinho são retornados ao controlador quantos produtos estão no carrinho no momento e a nova página do carrinho é exibida com a nova quantidade de produtos.

Usaremos nosso próprio framework e poderemos expandir recursos baseados em MVC. Conforme descrito anteriormente, os dados são apresentados nos modelos, os dados em si estão no banco de dados. No entanto, modelos e tabelas de banco de dados estão no mesmo formato (campos nos modelos correspondem a campos nas tabelas). Portanto, podemos expandir nosso diagrama MVC. Também vemos o resultado final, que é processado na Visão e exibido no navegador, então vamos adicioná-lo ao diagrama também.

Registro (Registry)

O Registro fornece a capacidade de armazenar uma coleção de objetos do nosso framework. A necessidade de um Registro surge da abstração associada ao padrão MVC. Cada controlador e modelo (por exemplo, produto, carrinho, página) precisa executar tarefas comuns, incluindo:

• Consultas ao banco de dados
• Verificar se o usuário foi autorizado para obter as informações necessárias
• Enviar dados para a View (gerenciamento de templates)
• Enviar e-mails, por exemplo ao comprar um produto no site
• Interagir com o sistema de arquivos, por exemplo, fazer upload de fotos de produtos.

A maioria dos sistemas e frameworks executa essas funções em objetos e vamos criar tais objetos. O Registro permite armazenar esses objetos juntos. O Registro pode ser chamado de qualquer lugar do framework e fornece acesso às suas funções para isso. Aqui está um diagrama aproximado do nosso Registro.

O framework interage diretamente com o Registro quando precisa fornecer acesso aos objetos restantes. Dentro do Registro, objetos também podem interagir uns com os outros, por exemplo, um gerenciador de templates pode estar conectado a um gerenciador de arquivos, um remetente de e-mail conectado a templates de e-mail.

Classe Singleton

Em português é difícil encontrar uma designação para singleton, então teremos a Classe Singleton, mas principalmente na documentação escrevem singleton ou simplesmente em inglês singleton. É possível que seja melhor escrever em inglês (certamente, mas teremos a classe singleton).

Classe Singleton é um dos padrões mais simples de entender. O objetivo principal é garantir a existência de apenas uma instância da classe. A razão geralmente é a seguinte: apenas um objeto da classe original é necessário e você precisa que o objeto esteja disponível em qualquer lugar do aplicativo, ou seja, acesso global.

A classe Singleton é usada quando uma classe tem apenas um propósito. Por exemplo, configurar uma conexão com um banco de dados para que outros objetos possam interagir com o banco de dados.

Estrutura Geral

 O próximo passo no desenvolvimento do nosso framework é planejar a estrutura. Devemos criar uma estrutura para:

• Modelos
• Visões (Para que possamos integrar a capacidade de mudar os estilos do site em nosso framework, para que um estilo tenha uma pasta separada)
• Controladores (Para que possamos armazenar o controlador em uma pasta separada, se quisermos adicionar funcionalidade, precisamos apenas adicionar uma nova pasta com o controlador)
• Controlador de admin (não estamos criando apenas um framework, mas também um CMS, portanto precisamos garantir que informações no site possam ser inseridas por moderadores e administradores)
• Registro
• Objetos de registro
• Arquivos carregados
• Bibliotecas de terceiros
• Outro código

Considerando a estrutura do framework, as pastas do nosso framework devem ser assim (usaremos nomes de pastas em inglês, porque é assim que é feito em PHP):

• Models
• Views
  • View A
  • Templates
  • Images
  • JavaScript
• Controllers
  • Controller A
    • ControllerA
    • ControllerAAdmin
• Registry
  • Objects
  • Database objects
• Assets
• Uploads
  • To be expanded when we add products and images to our framework!
• Libraries
• Miscellaneous