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.

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.

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:

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:

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:

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

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.