Forem: Ahmed EBEN HASSINE 脳の流れ

Doctrine ORM: How I Escaped the Cartesian Product Trap

Ahmed EBEN HASSINE 脳の流れ — Tue, 24 Feb 2026 14:41:45 +0000

Snippet from a client project; property names anonymized for confidentiality.

I opened the Symfony profiler on my catalog page and saw it: 201 SQL queries. For just 50 products. Development load time? 3 seconds. In production, that’s a ticking time bomb, waiting for the first traffic spike to explode.

If you use Doctrine, you’ve probably run into the N+1 monster. But in the rush to defeat it, many developers stumble into an even more vicious "final boss": the Cartesian Product.

Here’s how I optimized hydration without killing performance.

1. Diagnosing N+1 in the Wild

My Product entity is standard but data-heavy, with four main relationships:

categories (ManyToMany)
tags (ManyToMany)
images (OneToMany)
reviews (OneToMany)

The code looks innocent enough:

$products = $productRepository->findBy(['active' => true]);

But in the Twig template, it’s a bloodbath. Every time the template accesses product.categories or product.tags, Doctrine hits the database again.

Quick math: 1 initial query (products) + (50 products × 4 relations) = 201 queries.

2. The Pitfalls of EAGER Fetching with Collections

My first instinct? Set the relations to fetch: 'EAGER'. Result? The same number of queries—just triggered earlier, in the controller instead of the template.

Lesson learned: EAGER fetching works well for ToOne relationships (ManyToOne, OneToOne) but behaves differently with collections (OneToMany, ManyToMany). For collections, Doctrine typically runs extra queries per association—essentially "N+1 in disguise."

Note: LAZY vs EAGER controls when data is loaded, not always how. For collections, EAGER rarely solves N+1; it just moves the timing around.

3. The Hidden Cost of Cartesian Products

"Fine," I thought, "I’ll just leftJoin and addSelect everything in a single Query Builder call."

$this->createQueryBuilder('p')
    ->leftJoin('p.categories', 'c')->addSelect('c')
    ->leftJoin('p.tags', 't')->addSelect('t')
    ->leftJoin('p.images', 'i')->addSelect('i')
    ->leftJoin('p.reviews', 'r')->addSelect('r');

Profiler shows "1 query." Victory? Not really. The page was slower. The culprit: the Cartesian Product.

Imagine a product with 3 categories and 4 images. SQL can’t return nested arrays in a column, so it flattens everything:

3 categories × 4 images = 12 rows for one product
Add 5 tags and 10 reviews: 3 × 4 × 5 × 10 = 600 rows for a single product

For 50 products, that’s over 30,000 rows. Doctrine chokes trying to deduplicate this data to hydrate your objects. Multiplicative explosion occurs whenever multiple collections are joined.

4. The Solution: Multi-Step Hydration

This is where Doctrine’s Identity Map shines. Instead of one massive join, break the loading into logical steps:

public function findActiveWithRelations(): array
{
    // Step 1: Load products + categories
    $products = $this->createQueryBuilder('p')
        ->addSelect('c')
        ->leftJoin('p.categories', 'c')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    if (empty($products)) return [];

    // Step 2: Prime tags into the Identity Map
    $this->createQueryBuilder('p')
        ->addSelect('t')
        ->leftJoin('p.tags', 't')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    // Step 3: Prime images
    $this->createQueryBuilder('p')
        ->addSelect('i')
        ->leftJoin('p.images', 'i')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    // Step 4: Prime reviews
    $this->createQueryBuilder('p')
        ->addSelect('r')
        ->leftJoin('p.reviews', 'r')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    return $products;
}

Why This Works

Query 1: Loads 50 products + categories.
Subsequent queries: Load related entities. Doctrine tracks product IDs in memory via the Identity Map. Even if you don’t assign the result, Doctrine hydrates the entities and attaches relations to the existing objects.

Result: 4 lightweight, predictable queries, no data duplication.
Pro Tip: Make sure each step uses the exact same WHERE filters. For complex cases (e.g., pagination), it’s safer to extract IDs from the first query and use WHERE p.id IN (:ids) for subsequent queries.

5. Automate to Prevent Regressions

Tracking queries manually is tedious. I now use doctrine-doctor to stay ahead.

It integrates with the Symfony Web Profiler and alerts you to:

Obvious N+1 patterns
Excessive hydration (Cartesian products)
Missing indexes on join columns

composer require --dev ahmed-bhs/doctrine-doctor

Final Lesson: In ORM optimization, "less" isn’t always "better." Reducing 201 queries to 1 can crash your server via a Cartesian product. Reducing 201 to 4 can save it.

References:

GitHub Issue doctrine/orm#4762

Doctrine ORM: How I Escaped the Cartesian Product Trap

Ahmed EBEN HASSINE 脳の流れ — Tue, 24 Feb 2026 08:09:34 +0000

Snippet from a client project; property names changed for confidentiality.
I started by opening the Symfony profiler on my catalog page and there it was: 201 SQL queries. For just 50 products. Development load time? 3 seconds. In production, that’s a ticking time bomb, waiting for the first traffic spike to explode.

If you use Doctrine, you’ve probably run into the N+1 monster. But in the rush to defeat it, many developers stumble into an even more vicious "final boss": the Cartesian Product.

Here’s how I optimized hydration without killing performance.

1. Diagnosing N+1 in the Wild

My Product entity is standard but data-heavy, with four main relationships:

categories (ManyToMany)
tags (ManyToMany)
images (OneToMany)
reviews (OneToMany)

The code looks innocent enough:

$products = $productRepository->findBy(['active' => true]);

But in the Twig template, it’s a bloodbath. Every time the template accesses product.categories or product.tags, Doctrine hits the database again.

Quick math: 1 initial query (products) + (50 products × 4 relations) = 201 queries.

2. The Pitfalls of EAGER Fetching with Collections

My first instinct? Set the relations to fetch: 'EAGER'. Result? The same number of queries—just triggered earlier, in the controller instead of the template.

Note: LAZY vs EAGER controls when data is loaded, not always how. For collections, EAGER rarely solves N+1; it just moves the timing around.

3. The Hidden Cost of Cartesian Products

"Fine," I thought, "I’ll just leftJoin and addSelect everything in a single Query Builder call."

$this->createQueryBuilder('p')
    ->leftJoin('p.categories', 'c')->addSelect('c')
    ->leftJoin('p.tags', 't')->addSelect('t')
    ->leftJoin('p.images', 'i')->addSelect('i')
    ->leftJoin('p.reviews', 'r')->addSelect('r');

Profiler shows "1 query." Victory? Not really. The page was slower. The culprit: the Cartesian Product.

Imagine a product with 3 categories and 4 images. SQL can’t return nested arrays in a column, so it flattens everything:

3 categories × 4 images = 12 rows for one product
Add 5 tags and 10 reviews: 3 × 4 × 5 × 10 = 600 rows for a single product

For 50 products, that’s over 30,000 rows. Doctrine chokes trying to deduplicate this data to hydrate your objects. Multiplicative explosion occurs whenever multiple collections are joined.

4. The Solution: Multi-Step Hydration

This is where Doctrine’s Identity Map shines. Instead of one massive join, break the loading into logical steps:

public function findActiveWithRelations(): array
{
    // Step 1: Load products + categories
    $products = $this->createQueryBuilder('p')
        ->addSelect('c')
        ->leftJoin('p.categories', 'c')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    if (empty($products)) return [];

    // Step 2: Prime tags into the Identity Map
    $this->createQueryBuilder('p')
        ->addSelect('t')
        ->leftJoin('p.tags', 't')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    // Step 3: Prime images
    $this->createQueryBuilder('p')
        ->addSelect('i')
        ->leftJoin('p.images', 'i')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    // Step 4: Prime reviews
    $this->createQueryBuilder('p')
        ->addSelect('r')
        ->leftJoin('p.reviews', 'r')
        ->where('p.active = true')
        ->getQuery()
        ->getResult();

    return $products;
}

Why This Works

Query 1: Loads 50 products + categories.
Subsequent queries: Load related entities. Doctrine tracks product IDs in memory via the Identity Map. Even if you don’t assign the result, Doctrine hydrates the entities and attaches relations to the existing objects.

Result: 4 lightweight, predictable queries, no data duplication.
Pro Tip: Make sure each step uses the exact same WHERE filters. For complex cases (e.g., pagination), it’s safer to extract IDs from the first query and use WHERE p.id IN (:ids) for subsequent queries.

5. Automate to Prevent Regressions

Tracking queries manually is tedious. I now use doctrine-doctor to stay ahead.

It integrates with the Symfony Web Profiler and alerts you to:

Obvious N+1 patterns
Excessive hydration (Cartesian products)
Missing indexes on join columns

composer require --dev ahmed-bhs/doctrine-doctor

Final Lesson: In ORM optimization, "less" isn’t always "better." Reducing 201 queries to 1 can crash your server via a Cartesian product. Reducing 201 to 4 can save it.

References:

GitHub Issue doctrine/orm#4762

How Traditional Controllers Violate SRP

Ahmed EBEN HASSINE 脳の流れ — Tue, 16 Sep 2025 07:02:02 +0000

How Traditional Controllers Violate SRP

Every Symfony developer has been there: you open a controller file expecting a quick fix, only to find a 500-line monster with 15 methods and 10 injected dependencies. What went wrong? As someone who audits projects for external companies, I see this pattern pop up constantly in growing Symfony applications.

What starts as a simple ProductController can quickly morph into a monolithic God Object — a class that knows too much, does too much, and becomes a nightmare to maintain, test, and scale.

Even though Symfony gives us some nice tools like autowiring and dependency injection through the argument resolver, that alone isn’t enough. You still need solid design patterns to really guide developers and help them build controllers that are clean, lightweight, and easy to maintain. A controller with 15 actions might end up injecting 10 different services, even though each method only uses a few of them. That’s a classic symptom of low cohesion and high coupling: the class isn’t a unified whole, it’s a convenient but messy collection of methods.

While Symfony’s lazy loading mitigates the performance impact of injecting many services, the true cost is human. A constructor with ten dependencies signals a violation of SRP and imposes a heavy cognitive load on any developer trying to understand or modify the class. It becomes impossible to know which dependencies are needed for which action without reading the entire file.

The solution is both elegant and powerful: the Single Action Controller.

In fact, this isn’t just a community trend, it’s a pattern officially recommended in Symfony’s own best practices, especially for a common use case: having a single controller action that both renders a form and processes its submission.

The Single Responsibility Principle (SRP), Applied Correctly to Controllers

The Single Responsibility Principle (SRP), a precise rule that helps enforce a clear Separation of Concerns (SoC), is one of the most frequently misunderstood ideas in software design. Drawing from Robert C. Martin’s clarification, the principle isn’t about a class “doing only one thing.” Instead, it states:

“_A module should have a single reason to change and be the responsibility of exactly one actor.”_

An actor is a group of people, a stakeholder, or a department that requires changes in the software. The SRP is about structuring our code to align with the structure of your organization. For controllers, this means a single controller class should serve the needs of exactly one of these actors.

Why the “Fat Controller” Violates SRP

A “Fat Controller” is a classic SRP violation because it becomes a magnet for requests from multiple, unrelated business departments. It serves many actors, giving it many reasons to change.

Let’s look at a typical OrderController:

class OrderController extends AbstractController
{
    // Constructor with many dependencies for different actors...
    public function __construct(
        private OrderRepository $orderRepository, // Used by Marketing/UX
        private PromotionManager $promotionManager, // Used by Marketing
        private PaymentGateway $paymentGateway, // Used by Finance
        private ShippingCalculator $shippingCalculator, // Used by Logistics
        private MailerInterface $mailer, // Used by Finance & Logistics
        private LoggerInterface $logger
    ) {}
    // Method for Actor 1: Marketing/UX Team
    public function showCart(Request $request): Response { /* ... */ }
    // Method for Actor 2: Finance Department
    public function processPayment(Request $request): Response { /* ... */ }
    // Method for Actor 3: Logistics Department
    public function calculateShipping(Request $request): Response { /* ... */ }
}

This single class is forced to change for reasons driven by completely different parts of the business. It is responsible to three distinct actors:

Actor: The Marketing & UX Team

Their Goal: Optimize the user’s shopping experience to drive sales.
Reason to Change: They might request a new feature in the cart display, like adding promo codes or changing the layout. A change to the showCart method is required.

2. Actor: The Finance Department

Their Goal: Ensure payments are processed securely and accurately.
Reason to Change: They might decide to switch payment providers or add new fraud-detection logic. A change to the processPayment method is needed.

3. Actor: The Logistics Department

Their Goal: Fulfill and ship orders efficiently.
Reason to Change: They could partner with a new shipping carrier or need to adjust the shipping cost calculation rules. This requires modifying the calculateShipping method.

The problem is that these unrelated reasons for change are tangled together in one class. A developer from the finance team modifying payment logic could accidentally introduce a bug that breaks the shipping calculator, affecting the logistics team. This creates high coupling between organizational departments within the codebase, leading to merge conflicts, increased cognitive load, and a higher risk of regressions.

How Single-Action Controllers Enforce SRP

By adopting Single-Action Controllers, you align your code structure with your organizational structure. Each controller is responsible to exactly one actor and handles the orchestration of a single use case.

1. Serving the Marketing & UX Team

This controller’s sole reason to exist is to fulfill requests from the Marketing/UX team regarding the cart’s presentation.

#[Route('/cart', methods: ['GET'])]
final class ShowCartController extends AbstractController
{
    public function __construct(
        private CartService $cartService,
        private PromotionService $promotionService
    ) {}
    public function __invoke(Request $request): Response
    {
        // Single responsibility: orchestrate cart display for the user
        $cartData = $this->cartService->getCartForDisplay($this->getUser());
        return $this->render('cart/show.html.twig', $cartData);
    }
}

Single Actor & Reason to Change: The Marketing Team needs to alter the cart’s appearance or data. Changes are isolated here, with zero risk of affecting payments or shipping.

2. Serving the Finance Department

This controller is exclusively owned by the needs of the Finance department.

#[Route('/payment/process', methods: ['POST'])]
final class ProcessPaymentController extends AbstractController
{
    public function __construct(private PaymentService $paymentService) {}
    public function __invoke(Request $request): Response
    {
        // Single responsibility: orchestrate payment processing
        $result = $this->paymentService->processPayment($request->request->all());
        return $this->json(['status' => 'success', 'id' => $result->getId()]);
    }
}

Single Actor & Reason to Change: The Finance Department needs to modify the payment workflow. This class can be changed independently of all other application features.

3. Serving the Logistics Department

This controller’s responsibility is to the Logistics team and no one else.

#[Route('/shipping/calculate', methods: ['POST'])]
final class CalculateShippingController extends AbstractController
{
    public function __construct(private ShippingService $shippingService) {}
    public function __invoke(Request $request): Response
    {
        // Single responsibility: orchestrate shipping cost calculation
        $cost = $this->shippingService->calculateShipping($request->request->all());
        return $this->json(['cost' => $cost]);
    }
}

Single Actor & Reason to Change: The Logistics Department needs to update how shipping is calculated.

By breaking up the “fat controller,” we’ve created small, focused classes. The dependencies of each controller are now a clear signal of which actor it serves. This design minimizes coupling, reduces the risk of unintended side effects, and makes the codebase dramatically easier to navigate and maintain. Your code’s structure now reflects and respects your organization’s structure.

Radically Simplified Testing (This is a Game-Changer)

This is where the pattern truly shines. Let’s compare the testing experience.

The “Fat Controller” Testing Nightmare:

// Testing the processPayment method requires mocking ALL dependencies
public function testProcessPayment()
{
    // Need to mock services that have nothing to do with payment processing
    $orderRepository = $this->createMock(OrderRepository::class);
    $shippingCalculator = $this->createMock(ShippingCalculator::class); // Not needed!
    $promotionManager = $this->createMock(PromotionManager::class); // Not needed!
    $paymentGateway = $this->createMock(PaymentGateway::class);
    $mailer = $this->createMock(MailerInterface::class);
    $logger = $this->createMock(LoggerInterface::class); // Not needed!
    $controller = new OrderController(
            $orderRepository,
            $paymentGateway,
            $shippingCalculator,
            $promotionManager,
            $mailer,
            $logger
        );
        // Complex setup just to test one method...
    }

The problems: Noisy setup, fragility (change the constructor, break all tests), and high cognitive load.

The Single Action Controller Testing Dream:

public function testProcessPayment()
{
    // We mock the service, not its dependencies
    $paymentService = $this->createMock(PaymentService::class);
    // We can configure the mock if needed
    // $paymentService->expects($this->once())->method('processPayment')->willReturn(...);

    $controller = new ProcessPaymentController($paymentService);

    $response = $controller($this->createPaymentRequest());

    $this->assertSame(200, $response->getStatusCode());
}

The benefits: Readability, robustness, and maintainability. You test behavior, not configuration.

Addressing Common Concerns

“But doesn’t this create too many files?”

Yes, you’ll have more files, but organization beats convenience every time. Would you rather have:

One 500-line file that’s impossible to navigate, or
Fifty 10-line files that are immediately understandable?

Modern IDEs make file navigation trivial, and the mental overhead of understanding a focused class is dramatically lower.

“What about code duplication?”

Shared logic doesn’t belong in controllers anyway — it belongs in services, Command Handlers. Single Action Controllers actually encourage better architecture by making this obvious:

// Shared logic moves to services where it belongs
class OrderService
{
    public function validateOrderData(array $data): void
    {
        // Validation logic used by multiple controllers
    }
}

“Won’t this hurt performance?”

Symfony’s lazy loading means classes are only instantiated when needed. The performance impact is negligible, and the maintainability gains far outweigh any theoretical overhead.

The Bottom Line: An Architectural Win-Win

Adopting Single Action Controllers isn’t just a syntactic preference; it’s a strategic architectural decision that prioritizes maintainability, robustness, and cleaner code.

The “Fat Controller” is technical debt in disguise. Easy to write at first, but its hidden costs in testing time, debugging, and fragility compound quickly.

The Single Action Controller requires a slight shift in mindset but pays immediate and lasting dividends. You get a codebase that’s easier for new developers to onboard, safer to refactor, and built to last.

For a deeper dive into this architectural pattern, I highly recommend watching “ Cruddy by Design” by Adam Wathan from Laracon US 2017.