Arquitetura Magento 2 (Back-end)

Com certeza, para quem vem do desenvolvimento do Magento 1, uma das grandes mudanças que irá notar quando iniciar o desenvolvimento em Magento 2 será em sua arquitetura, desde a organização das pastas em que se instalavam módulos no Magento 1, até ao fato de ser necessário compilar seu código. Neste artigo abordaremos a parte de estrutura Back-end Magento 2.

Ao contrário do Magento 1, que seguia a estrutura MVC, os desenvolvedores do Magento 2 não utilizam essa estrutura e também não intitulam uma outra estrutura, embora se pareça muito com Model, View, View e Model (MVVM).

É seguido o padrão PSR-4 no desenvolvimento do Magento 2 e a mesma deve ser seguida quando se desenvolve um módulo, sendo uma boa prática recomendada pela própria Magento e que também o seu código melhor.

O Magento 2 usa o ObjectManager para gerar e injetar as classes declaradas em seu construtor. No artigo ObjectManager e compilação em Magento 2 falamos um pouco mais sobre o que é o ObjectManager…

Estrutura de pastas principais

  • <sua instalação Magento>/app : Esse é o local recomendado para o desenvolvimento de componentes.
    – para módulos use a pasta app/code ;
    – para os temas de front-end, use a pasta app/design/frontend ;
    – para os temas de admin, use a pasta app/design/adminhtml ;
    – para os pacotes de linguagem, use a pasta app/i18n .
  • <sua instalação Magento>/vendor : Todos os componentes de terceiros (e o próprio Magento) são baixados e armazenados no diretório vendor. Esta pasta é padrão pelo Composer e toda alteração que for necessário para um código desta pasta, deve ser feita na pasta app/code , nunca na vendor .
  • <sua instalação Magento>/pub : Os arquivos de front (javascript, phtml, css…) estarão compilados nesta pasta. É esta pasta que seu servidor web irá ler.
  • <sua instalação Magento>/var : Já conhecida de muitos, aqui estão arquivos que seu Magento irá salvar temporariamente, como cache, logs, reports… No Magento 2, um outro diretório que será criado dentro da pasta var é a pasta generation em que será criado todos os Factories das suas classes, geradas pelo ObjectManager.

Adeus pastas community, local!

Não há mais distinção na pasta app/code entre módulo community e local, agora todos os módulos ficam dentro dessa pasta e também ganham uma outra novidade: os arquivos de front também ficam dentro da pasta de cada módulo (css, javascript, phtml …). Abaixo um exemplo da pasta app/code com alguns módulos instalados.

Estrutura da pasta code no Magento 2

Registrando Model, Block, Helper…

No Magento 1 era comum a estrutura abaixo para se declarar as models, blocks, helpers… O que era bem trabalhoso e que podia trazer muita dor de cabeça para depurar.

Declaração de Model, Block e Helper no Magento 1

Mas como o Magento 2 utiliza o conceito de Dependency Injection e namespaces 🙏, isso não é mais necessário. Todo o conteúdo que estiver dentro da pasta do seu módulo será compilado via compilador do Magento e este será o responsável por injetar essas classes.

Estrutura de um módulo

Uma estrutura típica de um módulo em Magento 2 segue este padrão:

  • Block : Contém os blocos de seu módulo;
  • Controller : Contém os controllers (MVC) do seu módulo;
  • Model : Contém os models (MVC) do seu módulo;
  • Setup : Contém classes para estrutura de banco de dados de módulos e configuração de dados que são invocados ao instalar ou atualizar.
  • etc : Contém arquivos de configuração, sendo a única pasta obrigatório para um módulo;
  • i18n : Contém os arquivos de tradução do seu módulo;
  • view : Contém arquivos de exibição, incluindo arquivos estáticos (css, js), templates, modelos de e-mail e arquivos de layout.

Como podemos ver, algumas partes sofreram atualizações (no caso da pasta etc) ou receberam novas estruturas como por exemplo a pasta Plugin que é uma novidade e será comentada em outra publicação.

Vale notar que um arquivo obrigatório de todo módulo é o registration.php, nele você declara o seu módulo para o Magento 2. Este arquivo possui a seguinte estrutura:

Exemplo de um arquivo registration.php

E outro arquivo que todo módulo possui é o arquivo composer.json (não confundir com o arquivo da raiz do projeto) em que você declara quais dependências esse módulo possui entre outras configurações.

Dentro de etc também temos um arquivo obrigatório para todo módulo, que especifica a versão de seu módulo, o arquivo module.xml , como exemplo abaixo:

Exemplo do arquivo module.xml

A pasta etc também pode ser dividida em outras partes, como no exemplo em que há arquivos para a pasta etc/adminhtml, em que estas configurações se aplicarão apenas ao painel administrativo do Magento e etc/frontend em que tais configurações se aplicam ao front do Magento.

Habilitando/Desabilitando um módulo

No Magento 1 cada módulo possuía seu respectivo arquivo xml, dentro da pasta app/etc/modules, para registro em que você declarava a qual codepool pertencia e etc… No Magento 2 todos os módulos são habilitados ou desabilitados no arquivo app/etc/config.php dentro de um array. Abaixo temos um exemplo desse arquivo:

Exemplo do arquivo config.php

Também podemos habilitar ou desabilitar um módulo através da linha de comando, com os comandos:

bin/magento module:enable --clear-static-content Vendor_Name
bin/magento module:disable --clear-static-content Vendor_Name

Para não estender muito, criei um outro artigo sobre a Estrutura básica de um módulo em Magento 2 para quem tiver curiosidade.

E, para saber mais sobre a estrutura de um módulo em Magento, sugiro a leitura da documentação oficial do Magento 2 (en-US) neste link e neste link

Local.xml

Outro ponto estrutural com mudanças é a configuração no banco de dados e outras configurações, que deixou de ser um arquivo xml (o famoso arquivo app/etc/local.xml no Magento 1) para um arquivo php e toda a configurações fica dentro de um array no arquivo app/etc/env.php.

Comments

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *