Letzten Herbst saß ich bei einem Maschinenbauer im Münsterland. 180 Mitarbeitende, eine selbst entwickelte Auftragsmanagement-Software, gebaut vor acht Jahren von einem Freelancer, der heute in Neuseeland surft. Entity Framework 4, .NET Framework 4.6, SQL Server 2014. Der einzige interne Entwickler, Jonas, kam zu mir mit einem konkreten Problem: Bestimmte Reports dauerten drei bis vier Sekunden. Die Geschäftsführung wollte das unter eine Sekunde drücken, weil der Vertrieb das System jetzt auf dem iPad im Kundengespräch nutzt.
Jonas hatte bereits gegoogelt. Er hatte einen Artikel über Dapper gefunden und fragte mich: "Soll ich das einbauen?" Ich habe ihm eine Antwort gegeben — aber nicht die, die er erwartet hatte. Dazu komme ich gleich.
Was Nick Chapsas sagt
Nick Chapsas ist einer der kompetentesten .NET-Educators im deutschsprachigen und englischsprachigen Raum. Sein Artikel zu Dapper erklärt präzise, was das Micro-ORM ist: eine schlanke Extension-Library für IDbConnection, die dir erlaubt, eigenes SQL zu schreiben und Ergebnisse direkt auf C#-Objekte zu mappen — ohne den Overhead und die Magic von Entity Framework. Er zeigt CRUD-Operationen, Multiple Result Sets, Stored Procedures und Multi-Mapping. Die Performance-Argumentation ist korrekt: Dapper liegt in Benchmarks regelmäßig 30–50 % über Entity Framework Core bei read-heavy Workloads. Für Entwickler, die SQL können und die volle Kontrolle über ihre Queries wollen, ist Dapper schlicht die bessere Wahl gegenüber einem vollwertigen ORM.
Technisch: alles richtig. Kein Einwand.
Wie das im KMU wirklich landet
Hier beginnt der Teil, den Nick nicht schreibt — weil sein Publikum anders aussieht als meine Mandanten.
Das Skill-Problem. In einem KMU mit 30 bis 300 Mitarbeitenden gibt es typischerweise ein bis drei Entwickler. Manchmal einen. Dieser Entwickler hat meistens einen Mix aus Aufgaben: neue Features bauen, bestehende Systeme am Laufen halten, den IT-Helpdesk entlasten, wenn der Support überlastet ist. Wenn dieser Entwickler gut SQL kann, ist Dapper ein echter Gewinn. Wenn er vor allem mit EF Core groß geworden ist und SQL-Queries meidet wie frühere Generationen die Kommandozeile, dann kaufst du dir mit Dapper eine neue Kategorie von Fehlern: N+1-Queries, fehlende Parametrisierung, selbst gebastelte Injection-Lücken.
Ich habe in den letzten zwei Jahren in drei Unternehmen Code gesehen, der "handgeschriebenes SQL" als Pluspunkt im README stehen hatte. In zwei dieser drei Fälle waren SQL-Injection-Lücken drin. Nicht weil die Entwickler dumm waren. Sondern weil Dapper dir zwar @Parameter-Syntax gibt, aber dich nicht daran hindert, trotzdem "WHERE Name = '" + input + "'" zu schreiben, wenn du gestresst bist.
Das Wartungsproblem. Jonas beim Maschinenbauer war gut. Er konnte SQL. Aber: Was passiert, wenn Jonas kündigt? Sein Nachfolger muss dann nicht nur das Domänenwissen aufbauen, sondern auch 400 verstreute SQL-Strings im Code verstehen, ohne ein zentrales Schema-Modell zur Orientierung. EF Core hat da einen echten Vorteil: Das Modell ist explizit, versioniert, migrierbar. Mit Dapper baust du oft implizites Schema-Wissen in die Queries ein. Das ist für Performance toll. Für Onboarding eine Katastrophe.
Wann Dapper im KMU trotzdem die richtige Wahl ist.
Es gibt drei Szenarien, in denen ich Dapper auch im Mittelstand ohne Zögern empfehle:
-
Reporting und Lesezugriffe auf bestehende Datenbanken, die du nicht selbst besitzt. Wenn du Daten aus einem ERP oder einer Legacy-Datenbank liest, die ein anderes System schreibt, willst du kein EF-Modell darüber legen. Dapper mit sauber parametrisierten Queries ist hier sauber, schnell und ohne Nebenwirkungen.
-
Performance-kritische Hotspots in einer bestehenden EF-Anwendung. Du musst nicht alles umschreiben. Die pragmatische Lösung, die ich Jonas empfohlen habe: EF Core bleibt für 95 % des Codes. Die drei Report-Queries, die langsam waren, wurden mit Dapper neu geschrieben — direkt auf dem gleichen
DbConnection-Objekt, das EF Core intern nutzt. Ergebnis: Queries von 3,2 Sekunden auf 0,4 Sekunden. Kein Refactoring, keine neue Infrastruktur, kein Risiko für den Rest des Systems. -
Wenn du einen Entwickler hast, der SQL wirklich liebt und kann. Dann ist Dapper eine Befreiung. Aber das muss eine bewusste Entscheidung sein, keine Default-Antwort auf "EF ist zu langsam".
Was im Artikel fehlt, das KMUs brauchen.
Nick zeigt dir nicht, wie du Dapper mit einem Connection-Pool korrekt betreibst, wenn deine App unter Last steht und du fünf simultane Nutzer hast — nicht fünfhundert. Er erklärt nicht, wie du Dapper-Queries testest, wenn du kein dediziertes Test-Datenbanksetup hast. Und er sagt dir nicht, was du tust, wenn dein SQL Server auf einer VM läuft, die der IT-Dienstleister verwaltet, und du keinen direkten Zugriff auf Execution Plans hast, um zu verstehen, warum deine Query trotz Dapper noch langsam ist.
Das sind keine Kritiken an Nick — das ist schlicht außerhalb seines Scope. Sein Artikel ist ein technischer Einstieg. Mein Job ist es, dir zu sagen, was danach kommt.
Meine konkrete Empfehlung
Wenn du heute mit EF Core arbeitest und Performanceprobleme hast: Bevor du auf Dapper wechselst, mach drei Dinge:
- Schalte EF Core Query Logging ein und schau, welche Queries tatsächlich langsam sind. Oft ist es einer von zwanzig.
- Prüf, ob ein fehlender Index das Problem ist. Das kostet null Entwicklungsaufwand.
- Erst wenn Punkt 1 und 2 nicht helfen: Schreib den Hotspot mit Dapper um.
Wenn du ein Greenfield-Projekt startest und dein Team sicher SQL schreibt: Dapper als primäres Datenzugriffstool ist eine valide Wahl. Aber dokumentiere das Schema-Modell explizit an einer zentralen Stelle — zum Beispiel als annotierte SQL-Migrations-Skripte, die versioniert im Repository liegen.
Wenn du ein Team von einem Entwickler bist: Bleib bei EF Core als Fundament. Nutz Dapper gezielt. Misch beides — es funktioniert hervorragend.
Der vollständige Original-Beitrag von Nick Chapsas: Getting Started with Dapper in .NET
Wenn du gerade vor einer ähnlichen Entscheidung stehst — ORM-Wechsel, Performance-Probleme, Legacy-System unter Druck — und du willst das einmal in dreißig Minuten durchdenken ohne Vorverkauf: → 30 Min Klartext-Sparring
— Bernhard