Up until now, we've been writing "plain" PHP. You've handled your own routing, managed your own database connections, and structured your folders however you liked. But in the professional world, you'll rarely start from a blank slate. You'll likely use a framework. In the PHP ecosystem, that almost always means choosing between Laravel and Symfony.

Before we dive into the differences, let me show you a mistake I see almost every single developer make when they first transition from vanilla PHP to a modern framework. They try to treat the framework like a library rather than an ecosystem.

The "Too Few Arguments" Crash

// A simplified Controller in a framework like Symfony or Laravel
class UserController {
    private $userRepository;

    public function __construct(UserRepository $userRepository) {
        $this->userRepository = $userRepository;
    }

    public function show($id) {
        return $this->userRepository->find($id);
    }
}

// The "Vanilla" mistake:
$controller = new UserController(); 
echo $controller->show(1);

If you run this, PHP will scream at you: Fatal error: Uncaught ArgumentCountError: Too few arguments to function UserController::__construct(), 0 passed.... When you're used to vanilla PHP, your instinct is to instantiate the class you need using new. But in Laravel and Symfony, you almost never manually instantiate a controller or a service.

Letting the Service Container Handle the Heavy Lifting

The fix isn't to manually create a UserRepository and pass it in. The fix is to stop using the new keyword for your core logic classes and let the framework's Service Container do it for you.

In both Laravel and Symfony, you define a route that points to a controller method. When a request hits that route, the framework looks at the constructor of your controller, sees that it needs a UserRepository, automatically creates that repository, and "injects" it into the controller for you. This is called Dependency Injection.

To fix the code above, you simply define the route in the framework's routing file (like web.php in Laravel or routes.yaml in Symfony) and let the framework call the method. You don't call the controller yourself. By delegating the object creation to the framework, you can swap out the UserRepository for a mock version during testing without ever changing a line of code in your controller.

Rapid Prototyping vs. Enterprise Modularism

So, which one should you actually use? It's the age-old PHP debate. I like to think of it as a choice between "magic" and "explicitly."

Laravel is designed for developer happiness. It's incredibly fast to get an app off the ground. It uses "Facades" and "Magic Methods" that allow you to do things like User::all() without having to explicitly instantiate a database manager. It feels seamless, and the ecosystem (Forge, Vapor, Nova) is top-tier. The downside? Sometimes the "magic" makes it harder to debug when something goes wrong deep in the framework's internals.

Symfony is the "grown-up" in the room. It's modular, strict, and incredibly stable. In Symfony, you'll find yourself writing more configuration and being more explicit about how your services are wired together. It's less "magic" and more "engineering." This makes it the gold standard for massive, enterprise-level applications where predictability is more important than development speed.

The Symfony Components Secret

Here is the secret that usually surprises people: Laravel isn't actually a competitor to Symfony in the way you think. Laravel is actually built on top of many Symfony components.

• Laravel's HTTP Foundation? That's Symfony.
• Laravel's Routing system? Heavily inspired by and utilizing Symfony components.
• Laravel's Console component? Also Symfony.

When you choose Laravel, you're getting a polished, opinionated layer of "sugar" wrapped around the rock-solid, modular components that Symfony provides. If you want a framework that tells you the "best" way to do things and lets you move fast, go Laravel. If you want to build a custom architecture where you pick and choose every single component, go Symfony.

📋 Practical Task

Exercise: Implementing Dependency Injection in a Mock Framework

You are tasked with simulating how a Service Container works. You have a DatabaseConnection class and a UserMapper class that depends on that connection. Instead of manually instantiating them, you must create a simple Container class that can "resolve" these dependencies.

Requirements:

• Create a DatabaseConnection class with a method connect() that returns "Connected to DB".
• Create a UserMapper class that requires DatabaseConnection in its constructor. It should have a method getUser() that returns "User data from [Connection Status]".
• Create a Container class with a method get($className). This method should use PHP's ReflectionClass to check if the class has a constructor, automatically instantiate any required dependencies, and return the final object.
• Test your container by calling $container->get(UserMapper::class) and verifying that the UserMapper was created with its dependency already injected.