Symfony Admin: EasyAdmin 4 vs. Sonata Admin — Wann was?

1. Kontext: Was Symfony-Admin-Bundles leisten sollen

Ein Admin-Bundle für Symfony nimmt eine Doctrine-Entity und generiert daraus eine vollständige CRUD-Oberfläche: Listenansicht mit Filtern und Sortierung, Formular für Erstellung und Bearbeitung, Detailansicht und Lösch-Bestätigung. Das klingt einfach, aber die Anforderungen dahinter variieren enorm: Ein kleines Team mit wenigen Entities braucht etwas anderes als eine Enterprise-Anwendung mit dutzenden Entities, komplexen Relations und unterschiedlichen Zugriffsrollen. EasyAdmin 4 und Sonata Admin repräsentieren die beiden Enden dieses Spektrums.

Die zentrale Frage ist nicht "Welches Bundle ist besser?", sondern "Welches Bundle passt zu unserem Projekt?". EasyAdmin 4 ist so konzipiert, dass man in 15 Minuten eine funktionierende Admin-Oberfläche hat und schrittweise erweitert. Sonata Admin ist so konzipiert, dass man von Beginn an alle Aspekte des Backends konfigurieren und kontrollieren kann. Beide Ansätze haben ihre Berechtigung — die Herausforderung liegt im richtigen Match zwischen Projektgröße, Team-Erfahrung und langfristiger Wartbarkeit.

2. EasyAdmin 4: Philosophie und Stärken

EasyAdmin 4 folgt dem Prinzip "Convention over Configuration" konsequenter als jedes andere Symfony-Admin-Bundle. Für einfache Entities braucht man nichts weiter als eine CrudController-Klasse, die von AbstractCrudController erbt und die Entity-Klasse zurückgibt. EasyAdmin 4 leitet daraus automatisch Listenspalten, Formularfelder, Filteroptionen und Sortierung ab. Das Ergebnis ist in Minuten einsatzbereit — kein YAML, keine XML-Konfiguration, keine Service-Deklarationen.

Die Stärken von EasyAdmin 4 liegen in der PHP-first-Konfiguration: Alle Anpassungen erfolgen durch Überschreiben von Methoden im CrudController. Die Methoden configureFields(), configureFilters(), configureActions() und configureCrud() steuern jeden Aspekt der CRUD-Ansichten. Diese Methoden erhalten den Kontext (List, Detail, Form) und geben typisierte Konfigurationsobjekte zurück. IDE-Autovervollständigung funktioniert sofort, keine String-basierten Konfigurationsschlüssel. Das Twig-Templating von EasyAdmin 4 erlaubt partielles Überschreiben einzelner Blöcke — ohne das gesamte Template zu ersetzen.

<?php

declare(strict_types=1);

namespace App\Controller\Admin;

use App\Entity\Product;
use EasyCorp\Bundle\EasyAdminBundle\Controller\AbstractCrudController;
use EasyCorp\Bundle\EasyAdminBundle\Field\AssociationField;
use EasyCorp\Bundle\EasyAdminBundle\Field\BooleanField;
use EasyCorp\Bundle\EasyAdminBundle\Field\DateTimeField;
use EasyCorp\Bundle\EasyAdminBundle\Field\IdField;
use EasyCorp\Bundle\EasyAdminBundle\Field\MoneyField;
use EasyCorp\Bundle\EasyAdminBundle\Field\TextField;
use EasyCorp\Bundle\EasyAdminBundle\Config\Filters;
use EasyCorp\Bundle\EasyAdminBundle\Filter\BooleanFilter;
use EasyCorp\Bundle\EasyAdminBundle\Filter\EntityFilter;

/**
 * EasyAdmin 4 CrudController — minimal config, maximum auto-generation.
 */
final class ProductCrudController extends AbstractCrudController
{
    public static function getEntityFqcn(): string
    {
        return Product::class;
    }

    /**
     * Configure fields for list, detail and form views.
     * Context-aware: show different fields per page type.
     */
    public function configureFields(string $pageName): iterable
    {
        yield IdField::new('id')->onlyOnIndex();

        yield TextField::new('name')
            ->setRequired(true)
            ->setMaxLength(255);

        // Money field handles currency and cent conversion automatically
        yield MoneyField::new('price')
            ->setCurrency('EUR')
            ->onlyOnForms();

        yield AssociationField::new('category')
            ->setRequired(true);

        yield BooleanField::new('active')
            ->renderAsSwitch(true);

        yield DateTimeField::new('createdAt')
            ->onlyOnIndex()
            ->setFormat('dd.MM.Y HH:mm');
    }

    /**
     * Configure list filters — appear in the filter sidebar.
     */
    public function configureFilters(Filters $filters): Filters
    {
        return $filters
            ->add(BooleanFilter::new('active'))
            ->add(EntityFilter::new('category'));
    }
}

3. Sonata Admin: Philosophie und Stärken

Sonata Admin ist das ältere und schwergewichtigere der beiden Bundles — mit einem deutlich umfangreicheren Feature-Set auf Kosten einer steileren Lernkurve. Die Konfiguration erfolgt über Admin-Klassen, die von AbstractAdmin erben und in drei Pflicht-Methoden unterteilt ist: configureListFields() für die Listenansicht, configureFormFields() für Erstellungs- und Bearbeitungsformulare und configureDatagridFilters() für Filteroptionen. Diese Dreiteilung ist expliziter als EasyAdmin 4s Kontext-Parameter und macht die Konfiguration leichter lesbar — aber auch umfangreicher.

Die Stärken von Sonata Admin liegen in Enterprise-Features, die EasyAdmin 4 nicht out of the box bietet: komplexe Batch-Aktionen über mehrere Entities, verschachtelte Admin-Klassen für Relations, die direkt im Parent-Formular editiert werden können, ein ausgereiftes ACL-System mit Objekt-Level-Permissions und tiefer Integration mit dem SonataUserBundle für Benutzer- und Rollenverwaltung. Das SonataAdminBundle hat außerdem ein ausgefeilteres System für Admin-Groups und Dashboard-Widgets, das für komplexe Backend-Strukturen mit vielen Entities und Benutzerrollen geeignet ist.

4. Konfigurationsaufwand im direkten Vergleich

Der erste messbare Unterschied zwischen EasyAdmin 4 und Sonata Admin ist der Konfigurationsaufwand für eine neue Entity. Mit EasyAdmin 4 reicht der Befehl php bin/console make:admin:crud — der Generator erstellt einen vollständigen CrudController, der sofort funktioniert. Die Mindest-Konfiguration besteht aus getEntityFqcn()-Methode und einem Eintrag im DashboardController. Für einfache Entities ist das die gesamte Konfiguration.

Sonata Admin erfordert mehr Handarbeit: Die Admin-Klasse muss drei Pflicht-Methoden implementieren, als Service registriert und mit dem sonata.admin-Tag versehen werden. Jedes Feld muss in configureFormFields() und configureListFields() separat deklariert werden — automatische Ableitung aus der Entity gibt es nicht. Das ist mehr Arbeit für die erste Entity, aber auch mehr Kontrolle. In Projekten mit vielen ähnlich aufgebauten Entities zahlt sich der Template-Ansatz von Sonata aus: Eine sorgfältig konfigurierte Base-Admin-Klasse vererbt Standardkonfigurationen an alle Child-Admins.

5. Customizing: Wie weit kann man gehen?

Wenn die Standard-CRUD-Ansichten nicht ausreichen, trennen sich die Wege der beiden Bundles. In EasyAdmin 4 überschreibt man Twig-Blöcke oder fügt Custom-Fields als eigene Field-Klassen hinzu. Für vollständig eigene Aktionen mit eigenem Twig-Template schreibt man einen Custom-Action-Controller, der als normaler Symfony-Controller funktioniert und von EasyAdmin 4 in das Admin-Layout integriert wird. Diese Integration ist nahtlos — der Custom-Controller erbt das Layout, das Menü und die Breadcrumbs, ohne dass man das Layout selbst verwalten muss.

Sonata Admin bietet für Customizing mehr Einstiegspunkte: Admin-Extensions ermöglichen das Hinzufügen von Feldern, Filtern und Aktionen zu bestehenden Admin-Klassen ohne Vererbung. Das ist mächtiger als EasyAdmin 4s Methoden-Überschreibung, wenn man fremde Bundle-Admin-Klassen erweitern muss. Allerdings führt das extensive Customizing von Sonata häufig zu tief verschachtelten Admin-Klassen, die schwer zu testen und zu warten sind. Der Overhead von Sonata Admin ist in kleinen bis mittleren Projekten selten gerechtfertigt — der Mehrwert zeigt sich erst bei sehr komplexen Backend-Anforderungen mit vielen Rollen und tiefen Objekt-Hierarchien.

<?php

declare(strict_types=1);

namespace App\Controller\Admin;

use App\Entity\Product;
use App\Service\ProductPublisher;
use EasyCorp\Bundle\EasyAdminBundle\Config\Action;
use EasyCorp\Bundle\EasyAdminBundle\Config\Actions;
use EasyCorp\Bundle\EasyAdminBundle\Config\Crud;
use EasyCorp\Bundle\EasyAdminBundle\Context\AdminContext;
use EasyCorp\Bundle\EasyAdminBundle\Controller\AbstractCrudController;
use EasyCorp\Bundle\EasyAdminBundle\Router\AdminUrlGenerator;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Response;

/**
 * EasyAdmin 4 — custom action integrated into admin layout.
 */
final class ProductCrudController extends AbstractCrudController
{
    public function __construct(
        private readonly ProductPublisher $publisher,
        private readonly AdminUrlGenerator $adminUrlGenerator,
    ) {}

    public static function getEntityFqcn(): string
    {
        return Product::class;
    }

    /**
     * Add a custom "Publish" action to the list and detail views.
     */
    public function configureActions(Actions $actions): Actions
    {
        $publishAction = Action::new('publish', 'Veröffentlichen', 'fa fa-globe')
            ->linkToCrudAction('publishProduct')
            ->displayIf(fn (Product $p) => !$p->isPublished());

        return $actions
            ->add(Crud::PAGE_INDEX, $publishAction)
            ->add(Crud::PAGE_DETAIL, $publishAction);
    }

    /**
     * Handle the publish action — called when user clicks "Veröffentlichen".
     */
    public function publishProduct(AdminContext $context): RedirectResponse
    {
        /** @var Product $product */
        $product = $context->getEntity()->getInstance();
        $this->publisher->publish($product);

        $this->addFlash('success', "Produkt '{$product->getName()}' wurde veröffentlicht.");

        // Redirect back to the product list
        $url = $this->adminUrlGenerator
            ->setController(self::class)
            ->setAction(Action::INDEX)
            ->generateUrl();

        return $this->redirect($url);
    }
}

6. Doctrine-Integration und Relations

Beide Bundles sind tief in Doctrine integriert, gehen aber mit Relations unterschiedlich um. EasyAdmin 4 stellt für ManyToOne- und OneToMany-Relations das AssociationField bereit. Es rendert ManyToOne-Relationen als Select-Dropdown mit Live-Suche für große Collections und OneToMany-Relations als eingebettete Listen mit Add/Remove-Funktion. Die Konfiguration bleibt minimal — der Feldtyp wird aus dem Doctrine-Mapping abgeleitet.

Sonata Admin bietet für Relations die Konzepte "Inline" und "Choice": Inline-Relations rendert man direkt im Parent-Formular als eingebettete Collection von Formularzeilen. Das ist mächtiger als EasyAdmin 4s AssociationField für Szenarien, bei denen die Child-Entities komplex sind und viele Felder haben. Die Konfiguration einer Inline-Relation in Sonata ist aufwendiger, gibt aber vollständige Kontrolle über das Child-Formular, inkl. eigener Admin-Klasse für das Child-Entity. In EasyAdmin 4 ist dieses Szenario über Custom-Fields lösbar, aber der Weg ist weniger direkt dokumentiert als in Sonata.

7. Performance und Skalierung

Im Bereich Performance hat EasyAdmin 4 einen klaren Vorteil gegenüber Sonata Admin. EasyAdmin 4 generiert weniger Service-Definitionen beim Container-Build und hat eine schlankere Request-Verarbeitungskette. Bei Listenansichten mit vielen Entities und komplexen Query-Builder-Konfigurationen ist EasyAdmin 4 spürbar schneller — vor allem, weil Sonata Admins eine umfangreichere Middleware-Kette durchläuft, die für jede Anfrage den Admin-Graphen aufbaut und validiert.

Für Listenansichten mit zehntausenden Entities ist keines der beiden Bundles ohne Anpassung geeignet. Standard-Listen laden alle Daten für die aktuelle Seite über eine einfache Doctrine-Query — ohne Lazy Loading oder Cursor-Pagination. Für große Datensätze muss man bei EasyAdmin 4 den createIndexQueryBuilder() überschreiben und eigene Optimierungen einbauen, bei Sonata den createQuery()-Override. Der Aufwand ist bei beiden ähnlich — die Grundproblematik der Admin-generierten Queries trifft beide Lösungen gleichermaßen.

8. Entscheidungskriterien: Wann was wählen?

Die Entscheidung für oder gegen EasyAdmin 4 bzw. Sonata Admin lässt sich auf drei Kernfragen reduzieren: Wie viele Entities muss das Backend verwalten? Wie komplex sind die Relations und Zugriffsrechte? Wie viel Zeit hat das Team für die Backend-Entwicklung? EasyAdmin 4 ist die richtige Wahl, wenn das Team schnell ein funktionierendes Backend braucht und die meisten Entities einfache CRUD-Operationen ohne tief verschachtelte Relations haben. Der Zeitvorteil am Anfang ist real — in vielen Projekten reicht EasyAdmin 4 vollständig aus.

Sonata Admin ist die richtige Wahl, wenn das Projekt von Anfang an umfangreiche ACL-Anforderungen hat, wenn verschiedene Benutzerrollen unterschiedliche Sichten auf dieselben Entities haben sollen, oder wenn das Backend ein zentraler Teil des Produkts ist und nicht nur ein Verwaltungswerkzeug. Wer EasyAdmin 4 startet und nach sechs Monaten merkt, dass die Anforderungen darüber hinausgehen, hat oft eine unangenehme Wahl: Entweder den EasyAdmin 4-Code mit immer komplexeren Overrides aufblähen, oder zu Sonata migrieren. Dieses Szenario spricht dafür, die Komplexitätsanforderungen vor der Toolwahl klar zu analysieren.

9. EasyAdmin 4 vs. Sonata Admin: Feature-Matrix

Der direkte Vergleich zeigt, wo die Stärken und Schwächen der beiden Bundles liegen. Die richtige Wahl hängt immer vom konkreten Projektkontext ab — diese Matrix zeigt die typischen Ausschläge.

In der Praxis sehen wir bei Symfony-Projekten in kleinen bis mittleren Unternehmen häufig EasyAdmin 4 — mit dem Ergebnis, dass 80 % der Backend-Anforderungen ohne besonderen Aufwand erfüllt werden. Die verbleibenden 20 % komplexerer Anforderungen werden mit Custom-Fields und Custom-Actions gelöst, was gut funktioniert. Enterprise-Projekte mit komplexen Rollen, Multi-Tenancy und tiefer Benutzerrechteverwaltung greifen eher zu Sonata Admin oder entwickeln ein eigenes Backend auf Basis von Symfony-Controllern und Twig — was bei sehr spezifischen Anforderungen die wartbarste Lösung bleibt.

10. Zusammenfassung

EasyAdmin 4 und Sonata Admin adressieren zwei unterschiedliche Projekttypen. EasyAdmin 4 ist die richtige Wahl für Teams, die schnell ein funktionierendes, wartbares Backend brauchen und bereit sind, komplexere Anforderungen mit Custom-Code im Rahmen des Bundles zu lösen. Sonata Admin ist die richtige Wahl für Enterprise-Projekte mit komplexen ACL-Anforderungen, vielen Benutzerrollen und tiefen Objekt-Hierarchien. Beide Bundles sind für Symfony 6.x und 7.x unterstützt — mit EasyAdmin 4 als aktiverer weiterentwickelter Option in den letzten Releases.

Die häufigste Entscheidungsempfehlung aus der Praxis: Mit EasyAdmin 4 starten, die Backend-Anforderungen über die ersten Wochen des Projekts beobachten, und nur dann zu Sonata oder einem Custom-Backend wechseln, wenn EasyAdmin 4s Grenzen tatsächlich erreicht werden. In den meisten Symfony-Projekten mittlerer Komplexität werden sie es nicht.

11. FAQ: EasyAdmin 4 vs. Sonata Admin in Symfony