Letzten Herbst war ich bei einem Maschinenbauer mit 180 Mitarbeitenden. Interne Warenwirtschaft, über Jahre gewachsen, .NET-Stack. Irgendwo in der Mitte dieser Applikation — zwischen Controller und Datenbank — steckte eine AutoMapper-Version aus dem Jahr 2021. Niemand wusste mehr, warum bestimmte Mappings so gebaut waren, wie sie gebaut waren. Die Fehler beim Deployment kamen immer samstags. Immer.
Ich sage nicht, dass AutoMapper schuld war. Ich sage: die Unsicherheit rund um diese Library — läuft das noch, wer wartet das, kommt da noch was — die war sehr real. Und sie hatte Entscheidungen verlangsamt, die eigentlich keine zwei Tage hätten kosten dürfen.
Was Jimmy Bogard ankündigt
Jimmy Bogard, der Erfinder von AutoMapper und MediatR, hat seine Roadmap veröffentlicht — mit einer wichtigen Vorgeschichte: Beide Bibliotheken waren über Jahre faktisch in Wartungsmodus, weil er kein Corporate Sponsoring mehr hatte. Jetzt hat er es zurück, und er kommuniziert konkret, wohin die Reise geht.
Kurz zusammengefasst: AutoMapper bekommt Source-Generator-Unterstützung — mit dem ausdrücklichen Ziel, Debuggability zu verbessern, nicht nur Performance. Das ist ehrlich, denn das war jahrelang der größte Kritikpunkt. MediatR soll unabhängiger vom Microsoft-DI-Container werden, was Features ermöglicht, die heute schlicht nicht gehen: policy-basierte Behaviors, Result-Pattern-Integration, Blazor-native Szenarien, Domain Events über EF Core. Bogard betont außerdem, dass netstandard2.0-Support zurückgekehrt ist — relevant für alle, die noch .NET Framework 4.8 in Teilen des Stacks haben.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper and MediatR Roadmaps
Wie das in einem KMU mit 30–300 Mitarbeitenden wirklich landet
Lass mich das in drei Schichten aufdröseln.
Schicht 1: Das netstandard2.0-Thema ist für Mittelständler nicht akademisch
Bogard erwähnt das relativ beiläufig. Im Enterprise-Kontext nickt man kurz und scrollt weiter. Im KMU-Kontext ist das teilweise der Unterschied zwischen "wir können migrieren" und "wir können nicht migrieren".
Ich habe in den letzten drei Jahren in mindestens fünf Projekten gesehen, wie ein alter .NET-Framework-Service in der Mitte des Stacks saß — oft ein Reporting-Dienst, ein Schnittstellen-Adapter zu einer Warenwirtschaft oder ein Legacy-Auth-Wrapper. Diese Dienste werden nicht in sechs Monaten auf .NET 9 gehoben. Das passiert in Trippelschritten über zwei bis vier Jahre, und genau in dieser Übergangsphase brauchst du Bibliotheken, die auf beiden Seiten des Grabens laufen. netstandard2.0-Support ist dafür keine Nice-to-have, sondern eine Voraussetzung.
Dass Bogard das zurückgebracht hat, ist ein konkreter Schritt, der Migrationsbudgets kleiner macht. Das ist das Einzige, was Mittelständler wirklich interessiert.
Schicht 2: Source Generators für AutoMapper — wann lohnt es sich, wann nicht
Bogards Fokus auf Debuggability ist die richtige Priorität. Ich bestätige das aus der Praxis: Das Problem mit AutoMapper war nie die Performance — die war in 90 % der Fälle irrelevant — sondern das Rätselraten bei Laufzeitfehlern. Wenn ein Mapping schweigend null zurückliefert oder eine Property nicht befüllt, weil irgendwo im Konfigurationsgraph eine Konvention greift, die niemand mehr kennt, dann verlierst du Zeit, die du nicht hast.
Source Generators können das lösen, wenn sie richtig gebaut sind. Bogard ist sich bewusst, dass er hier nicht einfach den Ansatz anderer Libraries kopieren will — er will AutoMapper-Features wie IQueryable-Projektionen und das Extensibility-Modell erhalten. Das ist ambitioniert, aber es ist der einzig vernünftige Weg. Eine vereinfachte Source-Generator-Version, die das Ökosystem kaputt macht, hätte keiner gebraucht.
Mein Vorbehalt für KMUs: Warte auf die erste stabile Minor-Version nach dem Feature-Release, bevor du umstellst. Source Generators haben in der Vergangenheit bei größeren .NET-Versionssprüngen Edge Cases produziert, die in Standardszenarien nie aufgefallen wären, aber genau dann zugeschlagen haben, wenn jemand einen ungewöhnlichen Mapping-Typ hatte. Und ungewöhnliche Mapping-Typen haben Mittelständler zuhauf — weil ihre Datenmodelle über zehn Jahre gewachsen sind, nicht nach einem sauberen DDD-Schema entworfen wurden.
Schicht 3: MediatR und Vertical Slice Architecture — realistische Einschätzung
Hier wird es interessant, und hier weiche ich etwas von Bogards Perspektive ab — nicht weil er falsch liegt, sondern weil sein Publikum und mein Publikum verschieden ist.
Bogard denkt in Richtung großer Applikationen, Teams mit klarer Feature-Struktur, Vertical Slice als bewusstes Architekturmuster. In diesem Kontext sind die MediatR-Erweiterungen — policy-basierte Behaviors, Result Patterns, Domain Events — wirklich wertvoll.
In einem KMU mit einem Entwickler oder einem kleinen Team von drei Leuten sieht die Situation anders aus. Ich beobachte regelmäßig, dass MediatR dort nicht als Architekturmuster eingesetzt wird, sondern als Cargo-Cult. Man hat es in einem Tutorial gesehen, es klang professionell, jetzt gibt es für jeden Button-Klick einen Command, einen Handler und ein Event — und niemand fragt mehr, warum eigentlich.
MediatR macht Sinn, wenn du klare Trennungsanforderungen hast, wenn mehrere Handler denselben Request verarbeiten sollen, wenn du Cross-Cutting-Concerns wie Logging und Validation über Behaviors abwickelst. Es macht weniger Sinn, wenn du eine CRUD-App baust, die drei Tabellen befüllt und einen Bericht ausgibt.
Die Erweiterungen, die Bogard ankündigt, sind sinnvoll für die Leute, die MediatR sinnvoll einsetzen. Sie machen die Bibliothek für die anderen nicht sinnvoller.
Meine Empfehlung
Wenn du heute eine .NET-Anwendung im Mittelstand wartest oder neu baust, empfehle ich folgendes:
AutoMapper: Bleibt eine valide Wahl für komplexe Mapping-Szenarien, besonders wenn du Projektionen auf IQueryable brauchst. Warte mit Source Generators auf eine stabile Version mit Track Record. Nutze AssertConfigurationIsValid() — jetzt, sofort, wenn du es noch nicht tust. Das eliminiert 80 % der stillen Mapping-Fehler.
MediatR: Frag dich erst, ob du es wirklich brauchst. Wenn dein Team unter fünf Entwickler hat und die App keine nennenswerten Cross-Cutting-Concerns managen muss, bau direkt. Wenn du es bereits im Stack hast: Aktualisiere auf eine aktuelle Version (die alten waren teils monatelang auf einem out-of-support .NET). Die angekündigten Features sind für dich relevant, sobald dein Team wächst oder dein Slice-Ansatz mehr Disziplin braucht.
Generell: Die Tatsache, dass Bogard wieder bezahlte Kapazität auf diese Libraries gibt, ist für alle Mittelständler gut, die sie im Stack haben. Abhängigkeiten ohne aktive Pflege sind technisches Risiko — das Risiko ist kleiner geworden.
Was ich mir von Bogard noch wünsche — und was im Artikel fehlt — ist eine klare Migrations-Guidance für Teams, die von alten Versionen auf moderne Versionen hochziehen. Nicht jeder Mittelständler hat die Zeit für Breaking-Change-Research. Ein gepflegtes Upgrade-Playbook wäre wertvoller als manche Architektur-Erweiterung.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper and MediatR Roadmaps
Wenn du nicht sicher bist, ob dein Team diese Bibliotheken sinnvoll einsetzt oder ob du dir damit gerade ein Wartungsproblem einhandelst, das in zwei Jahren teuer wird — dann lass uns das in 30 Minuten durchgehen.
— Bernhard