docs(articles): English translation of From Magento to Symfony
en/articles/magento-to-symfony/basics/mindset.md
new file +27
−0
1
+
# A change of mindset
2
+
3
+
Magento is a finished product that you extend without touching the core. That is why it has so many ways to intervene: plugins on any public method, preferences, layout XML, EAV, admin config with scopes.
4
+
5
+
Symfony is a set of components from which you assemble your own application. There is no core as a product: the code in `src/` is the application, you own it and simply change it. So there are far fewer ways to intervene, and behavior is more explicit: what you see in the constructor and the configuration is what runs.
6
+
7
+
:::info subtitle="The key idea"
8
+
Most Magento-style "how do I intercept X" questions turn into "just change your code" in Symfony. Interception is only needed for code in vendor/, and there are three tools for it: an event, a decorator, a service override.
9
+
:::
10
+
11
+
## Carries over almost unchanged
12
+
13
+
- Constructor dependency injection, programming to interfaces. Magento taught you this, Symfony rewards it.
14
+
- Composer, PSR-4, `Psr\Log\LoggerInterface` and Monolog are the same.
15
+
- `bin/magento` is built on Symfony Console. A command class looks almost the same.
16
+
- Thinking in events and observers.
17
+
- Message queues, retries, separate workers.
18
+
- PHPUnit, PHPStan, PHP-CS-Fixer.
19
+
20
+
## You need to unlearn
21
+
22
+
- ObjectManager and generated code: `Factory`, `Proxy`, `Interceptor` in `generated/`.
23
+
- `getData()`/`setData()`, `DataObject` and magic getters.
24
+
- Plugins on any method of any class.
25
+
- XML for everything. In Symfony most configuration is PHP attributes next to the code, the rest is YAML.
26
+
- An interface in `Api/Data` for every entity. Service contracts are optional here.
27
+
- EAV, store/website scopes, admin settings, indexers, modes. They don't exist, and you shouldn't build them without a real need.