Een productiewaardige maatwerk-Magento-2-module bouwen

Een productiewaardige Magento 2-module vereist juiste registratie, declarative schema voor elke databasewijziging, dependency injection in plaats van ObjectManager, service contracts voor publieke API's, plugins in plaats van class-rewrites en geautomatiseerde tests. De twee fouten die modules bij een upgrade breken zijn het overslaan van declarative schema en het lekken van ObjectManager.

Belangrijkste punten

• Gebruik declarative schema (db_schema.xml), geen InstallSchema-scripts — het overleeft upgrades netjes.
• Injecteer afhankelijkheden via de constructor; roep in bedrijfscode nooit direct ObjectManager aan.
• Stel functionaliteit beschikbaar via service contracts (Api/-interfaces) zodat andere modules afhangen van stabiele API's.
• Verkies plugins (interceptors) boven class-rewrites om upgrade-veilig te blijven.
• Lever unit- + integratietests; Magento's testframework vangt DI- en schema-regressies vroeg.

1. Registratie en declaratie

Elke module begint met registration.php en etc/module.xml. Declareer module-afhankelijkheden in module.xml zodat de afhankelijkheidsgraaf en laadvolgorde expliciet zijn.

2. Databasewijzigingen: alleen declarative schema

Definieer tabellen en kolommen in etc/db_schema.xml en genereer db_schema_whitelist.json. Declarative schema is omkeerbaar en idempotent over upgrades — de grootste reden dat oude modules breken zijn verouderde InstallSchema/UpgradeSchema-scripts.

3. Dependency injection in plaats van ObjectManager

Type-hint afhankelijkheden in je constructor en laat de DI-container ze leveren. Directe ObjectManager::getInstance()-aanroepen verbergen afhankelijkheden, breken testbaarheid en worden gemarkeerd door Magento's codingstandaarden.

4. Service contracts voor alles wat publiek is

Als andere modules (of je eigen frontend/API) je logica gebruiken, stel die dan beschikbaar via interfaces onder Api/ en Api/Data/, gebonden in di.xml. Service contracts geven een stabiel oppervlak en maken REST/GraphQL triviaal.

5. Gedrag uitbreiden met plugins, niet met rewrites

Gebruik before/after/around-plugins. Class-preferences (rewrites) botsen met andere modules en verliezen wijzigingen stil bij een upgrade. Gebruik around spaarzaam — het heeft de hoogste prestatiekosten.

6. Testen

Voeg unit-tests toe voor pure logica en integratietests voor DI-bedrading en schema. Een module zonder tests breekt stil bij de volgende platform-upgrade.

Laten uitvoeren op een overdraagbare standaard? Zie Magento-/Hyvä-engineering of vraag een offerte aan.

Veelgestelde vragen

Wat is het verschil tussen declarative schema en setup-scripts in Magento 2?

Declarative schema (db_schema.xml) beschrijft de gewenste databasetoestand en Magento berekent de wijzigingen, waardoor het idempotent en upgrade-veilig is. Oude InstallSchema/UpgradeSchema-scripts draaien imperatief en falen vaak in latere versies, wat modules breekt.

Moet ik plugins of rewrites gebruiken in Magento 2?

Gebruik vrijwel altijd plugins (interceptors). Class-rewrites (preferences) botsen wanneer twee modules dezelfde class targeten en kunnen wijzigingen stil verliezen bij een upgrade. Gebruik around-plugins alleen wanneer echt nodig vanwege de hoogste prestatie-overhead.

Waarom wordt direct gebruik van ObjectManager afgeraden in Magento 2?

Directe ObjectManager-aanroepen verbergen de echte afhankelijkheden van een class, bemoeilijken unit-testen en schenden Magento's codingstandaarden. Injecteer afhankelijkheden in plaats daarvan via de constructor en laat de DI-container ze oplossen.

Hebben Magento 2-modules tests nodig?

Ja, voor alles wat productie is. Unit-tests dekken bedrijfslogica, integratietests verifiëren dependency injection en schema. Tests zijn de goedkoopste manier om regressies te vangen voordat een platform-upgrade de module in productie breekt.