Slim Framework — Criando Microservices 03 — Camada de Persistência com Doctrine e Entity Manager

Matheus Fidelis
5 min readApr 27, 2017

--

Fala pessoal! Aqui vai o terceiro post sobre o Microframework Slim. Se você não viu os últimos dois, te recomendo muito dar uma lida antes pra ver o que fizemos até aqui.

Nesse post iremos abordar o inicio da nossa camada de persistência, onde vamos utilizar o Framework Doctrine como um Entity Manager para manipular nossas entidades e representações dos nossos dados.

Doctrine Frameworkhttp://www.doctrine-project.org/

Doctrine Entity Manager http://www.doctrine-project.org/api/orm/2.5/class-Doctrine.ORM.EntityManager.html

Arquivo de Bootstrap

Para melhor entendimento, vamos separar toda nossa responsabilidade de configurações em um arquivo separado chamado bootstrap.php. Nele vamos concentrar inicialmente todo o nosso autoload e configuração de dependências da nossa API.

touch bootstrap.php

Inicialmente vamos remover o require do autoload e a instância do Slim\App() do nosso index.php e colocá-las no nosso Bootstrap. Agora pode parecer simples, mas nos próximos posts, esse arquivo tende a crescer bastante.

index.php

bootstrap.php

Estrutura de Pastas e Instalação do Doctrine

Agora vamos ser obrigados tornar nossa estrutura de pastas um pouco mais robusta. Ainda não está nem perto do ideal, mas é o nosso preview de como vai ficar. Primeiro vamos criar nossa pasta base do projeto chamada src/, e depois dela mais dois níveis de pasta, uma Model, e outra Entity dentro da mesma, no fim vai dar algo parecido com src/Models/Entity.

Até o fim dessa série vamos abordar mais alguns patterns de manipulação de dados, não apenas Entity Managers e Data Mapping, então já vou deixar a estrutura pronta para criarmos classes de Models e etc.

Vamos criar a pasta base do projeto. Dessa forma vamos criar todas elas de uma única vez de forma recursiva.

$ mkdir -p src/Models/Entity

Depois desse passo, nossa estrutura de pastas vai ficar parecida com essa:

tree .                                                                      
.
├── bootstrap.php
├── composer.json
├── composer.lock
├── index.php
└── src
└── Models
└── Entity
3 directories, 4 files

Agora, vamos configurar nosso composer.json para encontrar mapear nossas pastas e classes que criaremos futuramente dentro da pasta src dentro de um namespace chamado App

composer.json

Agora vamos carregar as configurações do nosso autoload para gerar o novo mapeamento.

Após criarmos nossa primeira estrutura de namespace, vamos instalar pelo composer a biblioteca ORM do Doctrine. Eu gosto muito desse framework por ser simples de configurar e pode ser utilizado de várias formas, pouco nos prendemos a utilização dele. Nos próximos posts vamos aprender a utilizar o Entity Manager dele de uma forma mais completa, mas também vamos ter alguns posts extras retratando o Query Builder.

$ composer require doctrine/orm

No final das contas nosso composer.json vai ficar parecido com esse, já contendo nosso namespace padrão e com o Slim e Doctrine como dependências

composer.json

Configurando o Doctrine

Após a instalação ser bem sucedida, vamos adicionar alguns parâmetros ao nosso arquivo de Bootstrap. Nele vamos concentrar todas as nossas configurações de todas as dependências da nossa API.

No nosso arquivo bootstrap.php, dar o use no Setup e EntityManager do conjunto de bibliotecas do Doctrine.

A partir de agora, temos que estar afiados com o conceito de Dependency Injection. Nosso $app, é um um Singleton, ou seja, ele é instanciado apenas uma vez, e nos garante um gerenciamento de toda nossa aplicação através de um ponto de acesso global. E dentro dele, vamos carregar nossa injeção de dependências dentro de um container.

O Slim já possui um objeto padrão de container e Dependency Injection, criado a partir da classe Slim\Container. Nele vamos injetar todos os nossos objetos, funções e configurações que vamos consumir durante o projeto.

bootstrap.php

Para começar, vamos iniciar o projeto utilizando um banco SQlite. Mais tarde quando formos tratar de assuntos de escalabilidade, vamos trocar pra um banco mais poderoso. Agora, para fins de teste manteremos esse mesmo :).

Em seguida, vamos mapear nosso diretório de Annotations do Doctrine. Vamos gerar nossas entidades no banco de dados a partir das annotations das classes que se encontram nesse diretório. Criamos ele no primeiro passo, o diretório src/Models/Entity.

Registrando nossa primeira Entidade

Vamos criar agora nossa primeira entidade, a entidade Book. Ela vai ser criado no diretório que acabamos de comentar. Ela vai ser uma classe anêmica que não vai ter comportamento nenhum, somente vai ser nosso saco de dados que vamos manipular através de Getters e Setters. Sem segredo por enquanto.

src/Models/Entity/Book.php

O Doctrine trabalha nativamente por meio de Annotations nos DocBlocks que criamos em nossas classes de entidade. No comentário da nossa classe, vamos dizer pra ele qual vai ser o nome da nossa tabela responsável pelas entidades criadas a partir daquela classe, no caso @Entity @Table(name=”books”)

Os Fields do nosso banco devem ser correspondentes aos atributos da nossa entidade. E elas dependem de Annotations Específicas para descrição dos tipos de dados que cada uma deve respeitar.

Para uma referência mais completa sobre as Annotations do Doctrine, veja:

Client do Doctrine CLI e gerando nosso Schema.

Vamos precisar criar um arquivo de configuração para o CLI do Doctrine. Esse arquivo, obrigatoriamente deve se chamar cli-config.php. Nele vamos apenas dar um require no nosso Bootstrap e passar nossa instância do Entity Manager para o Console Runner do Doctrine.

Após a configuração do nosso CLI, vamos rodar o cli do Doctrine dentro da pasta de bins dentro da nossa pasta vendor.

vendor/bin/doctrine orm:schema-tool:update --force

Um arquivo chamado db.sqlite será criado. Ele vai ser nosso banco de dados. Todas as alterações efetuadas na entidade Book.php, ou novas entidades criadas vão ser automaticamente configuradas no nosso schema de dados quando rodarmos esse comando de update do Doctrine. É só abrir o banco com qualquer gerenciador de bancos de dados que comporte SQLite. Eu gosto muito do Valentina Studio por conter uma quantidade muito grande de Drivers.

No próximo post vamos abordar todas as nossas operações de CRUD da API de livros utilizando nosso Entity Manager. Fiquem ligados!

Exemplos de código até aqui: https://github.com/msfidelis/slim-microservices/tree/v3

:)

--

--