Letzte Woche sitze ich mit dem Entwicklungsleiter eines Maschinenbauers aus dem Schwarzwald zusammen. Fünfzig Mitarbeitende, davon drei in der IT. Die zeigen mir ihren selbst gebauten ERP-Connector — 6.000 Zeilen C#, gewachsen seit 2017. Ich frage, ob sie AutoMapper nutzen. Stille. Dann: „Das ist doch dieses NuGet-Ding, das wir mal drin hatten und dann rausgeschmissen haben, weil's bei uns nie richtig funktioniert hat, oder?"
Genau das ist die Realität im Mittelstand. Draußen feiert die .NET-Community eine Milliarde Downloads. Drinnen weiß man nicht mal, ob man die Bibliothek noch im Projekt hat.
Was Jimmy Bogard ankündigt
Jimmy Bogard hat AutoMapper 16.1 und MediatR 14.1 veröffentlicht — beides im Rahmen eines jetzt regelmäßigen Quartals-Release-Rhythmus, was allein schon ein Zeichen von Reife ist. Bei AutoMapper gibt es ein echtes Feature-Update: Factories und Conditions können jetzt Dependencies injizieren, also den vollen DI-Container nutzen, nicht mehr nur simple Func-Callbacks. Das war ein echter Schmerzpunkt in komplexen Mapping-Szenarien. Bei MediatR wurden Generic-Hierarchien verbessert — relevant für Teams, die das Framework in abstrakteren Architektur-Patterns einsetzen — und ein paar Bugs gefixt. Obendrauf kommt der Meilenstein: eine Milliarde NuGet-Downloads für AutoMapper. Das ist keine Kleinigkeit; das ist de-facto-Standard-Status im .NET-Ökosystem.
Bogard schreibt knapp und sachlich, wie immer. Er erklärt, was neu ist, verlinkt die Release Notes, fertig. Keine Marketing-Prosa, kein Overselling. Dafür respektiere ich ihn.
Wie das im KMU wirklich landet
Lass mich direkt sein: Für die meisten meiner Kunden im Bereich 30 bis 300 Mitarbeitende ist dieses Release irrelevant — nicht weil die Bibliotheken schlecht sind, sondern weil das Abstraktionslevel, für das sie gebaut sind, in diesem Umfeld oft nicht existiert.
AutoMapper wurde für Teams gemacht, die systematisch zwischen Domänen-Objekten und DTOs trennen. Das setzt voraus, dass jemand im Team überhaupt verstanden hat, warum diese Trennung existiert. In der Praxis sehe ich häufiger das Gegenteil: eine einzige Customer-Klasse, die direkt in die View geht, direkt in die Datenbank, direkt in den API-Response. Das ist nicht schön, aber es funktioniert. AutoMapper in so ein Projekt reinzubringen ohne die darunter liegende Architektur zu ändern — das schafft nur eine weitere Abstraktionsschicht über einem Chaos, das keine Abstraktionsschicht braucht, sondern Aufräumen.
Das neue Feature — Dependencies in Factories und Conditions — ist technisch sauber gedacht. Du kannst jetzt beim Mapping auf echte Services zugreifen, ohne Workarounds. In einem gut geschnittenen System mit klaren Bounded Contexts ist das hilfreich. Aber mal ehrlich: Wer in einem 50-Mann-Betrieb ein System mit klaren Bounded Contexts hat, braucht von mir keine Beratung mehr.
MediatR ist ein anderes Tier, und hier wird's interessanter. Das CQRS-Pattern, das MediatR umsetzt, bringt echten Wert — auch im Mittelstand. Ich habe Kunden, bei denen ich MediatR eingeführt habe, und die damit messbar besser fahren: Weniger versteckte Seiteneffekte, bessere Testbarkeit, klarere Befehlskette. Das ist kein Architekten-Selbstzweck, das zahlt sich aus.
Die Verbesserungen in 14.1 bei Generic-Hierarchien sind aber technisch fortgeschritten. Das betrifft Teams, die MediatR bereits konsequent nutzen und an die Grenzen des Typsystems stoßen. In meinen Projekten ist das selten das Problem. Das Problem ist meistens: Der Handler hat 300 Zeilen und vier Abhängigkeiten, weil niemand die Logik weiter aufgeteilt hat. Da hilft kein Generic-Hierarchy-Fix.
Was wirklich wichtig ist, wenn du das heute liest
Drei konkrete Einschätzungen:
Wenn du AutoMapper noch nicht nutzt: Fang damit an, wenn du eine klare DTO-Schicht hast oder aufbaust — nicht vorher. Die Onboarding-Kosten sind real: neue Entwickler stolpern über Mapping-Profile, Fehler sind schwer zu debuggen, weil der Stack nicht mehr linear ist. Der Break-Even kommt bei Projekten, wo du mehr als zehn Objekt-Typen systematisch transformierst. Darunter ist record ToDto() => new(...) { ... } in 90% der Fälle die bessere Wahl.
Wenn du AutoMapper schon nutzt und noch auf einer alten Version feststeckst: Das Quarterly-Release-Modell ist ein gutes Signal. Bogard bringt das in Ordnung. Ein Update auf 16.1 lohnt sich, wenn du dabei die Release Notes liest und schaust, ob die neuen DI-fähigen Factories dir einen Workaround ersetzen können, den du irgendwo im Code hast. Oft gibt es solche Workarounds — ich sehe sie regelmäßig.
MediatR im KMU: Ja, aber mit Augenmaß. Ich empfehle es für Projekte ab mittlerer Komplexität — grob: wenn du mehr als drei verschiedene fachliche Domänen in einer Anwendung hast und das Team größer als zwei Personen ist. Unter diesen Schwellenwerten ist MediatR eine Komplexitätspumpe, keine Vereinfachung. Das ist keine Kritik am Framework; das ist die falsche Anwendung des richtigen Werkzeugs.
Eine Zahl aus der Praxis: Ich habe in den letzten zwei Jahren vier Projekte gesehen, die MediatR eingebaut hatten, ohne dass das Team verstanden hat, was ein Command von einer Query unterscheidet. In zwei davon war MediatR der einzige Grund, warum ich einen bestimmten Bug eine Stunde länger gesucht habe als nötig. Der Abstand zwischen „wir nutzen MediatR" und „wir nutzen MediatR richtig" ist größer, als die Einstiegsdokumentation vermuten lässt.
Was in Bogards Artikel fehlt — und das ist keine Kritik
Bogard schreibt für ein Publikum, das diese Bibliotheken bereits versteht und einsetzt. Das ist richtig so. Er muss nicht erklären, warum jemand AutoMapper überhaupt braucht. Für meine Zielgruppe — Betriebe, die gerade entscheiden, ob sie sowas einführen sollen — fehlt genau das: der ehrliche Fitcheck. Passt das zu uns? Oder holen wir uns damit Komplexität ins Haus, die wir nicht brauchen?
Die Antwort ist fast nie binär. AutoMapper und MediatR sind ausgereifte, gut gewartete Bibliotheken. Bogards Quartals-Rhythmus ist ein Zeichen von Professionalität, nicht von Volatilität. Das eine Milliarde-Download-Meilenstein ist kein Marketing-Blödsinn, das ist ein echtes Signal für Stabilität.
Aber „stabil und weit verbreitet" ist kein Freifahrtschein für unkritische Übernahme. Im Mittelstand entscheiden oft ein oder zwei Entwickler über den Technologie-Stack, und die müssen diese Entscheidung fünf Jahre lang leben. Das ist ein anderer Kontext als ein zehnköpfiges Architektur-Team in einem Enterprise-Umfeld.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper 16.1 and MediatR 14.1 Released
Wenn du gerade vor der Entscheidung stehst, ob AutoMapper oder MediatR in euer Projekt passt — oder wenn du es schon drin habt und dir nicht sicher bist, ob ihr es richtig nutzt — dann lass uns das in dreißig Minuten durchsprechen. Kein Pitch, kein Drumherum.
— Bernhard