Vor ein paar Monaten saß ich bei einem Maschinenbauer, 180 Mitarbeitende, IT-Team von acht Leuten. Die hatten eine interne Warenwirtschaft, .NET Framework 4.6.2, gewachsen seit 2014. Solide, produktiv, niemand will sie anfassen. Und mitten in diesem System: AutoMapper überall. Nicht als bewusste Architekturentscheidung – sondern weil ein Entwickler damals gesagt hat: "Das macht die DTOs einfacher." Jetzt, zwölf Jahre später, hat niemand mehr einen Überblick, was in welchem Mapping-Profil wirklich passiert. Businesslogik versteckt sich in AfterMap-Callbacks. Die neue Entwicklerin, die seit sechs Monaten dabei ist, sagt mir: "Ich traue mich nicht, irgendetwas anzufassen, weil ich nie weiß, was da noch mitläuft."
Das ist kein Einzelfall. Das ist ein Pattern, das ich in zwei von drei .NET-Projekten im Mittelstand antreffe, wenn sie älter als fünf Jahre sind.
Was Jimmy Bogard veröffentlicht hat
Jimmy Bogard hat AutoMapper 15.1.0 und MediatR 13.1.0 released. Wichtigste Neuerung: Beide Libraries haben jetzt echten First-Class-Support für .NET Framework 4.6.2 – nicht nur als netstandard2.0-Kompatibilitäts-Shim, sondern mit eigenem Build-Target und Tests auf Windows und Linux. Bogard erklärt direkt, warum: netstandard2.0 allein war keine ausreichende Garantie dafür, dass alles gegen volles .NET Framework wirklich funktioniert. Dazu gibt es die üblichen Bug-Fixes und kleinere Features, die in den jeweiligen Release Notes aufgelistet sind. Außerdem kündigt er quartalsweise Releases als neue Policy an – also verlässlicherer Rhythmus statt Ad-hoc-Drops.
Kurz gesagt: Jimmy pflegt seine Libraries weiterhin aktiv, denkt an die Leute, die noch auf Legacy-Stacks hängen, und macht die Wartbarkeit berechenbarer. Das ist respektabel.
Wie das im KMU wirklich landet
Das net462-Update: endlich ehrlich
Der Teil mit dem net462-Support ist für den Mittelstand keine Nebensache. Ich habe in den letzten drei Jahren in mindestens einem Dutzend KMUs reingeguckt, die noch auf .NET Framework laufen – meistens 4.6.x oder 4.7.2. Warum? Weil Migration teuer ist, weil das ERP oder der OPC-UA-Adapter oder das hauseigene Reportingtool nicht migriert werden kann, weil niemand Zeit hatte, und weil "es läuft ja". Das sind keine faulen Entscheidungen. Das sind Ressourcenentscheidungen.
Wenn du also noch auf net462 bist und AutoMapper oder MediatR nutzt: Dieses Release ist eine direkte Aussage, dass die Libraries jetzt ernsthaft gegen deinen Stack getestet werden – nicht nur theoretisch kompatibel sind. Das ist konkret gut. Es reduziert das Risiko, dass du ein Update spielst und dann beim nächsten Hotfix merkst, dass irgendein Edge Case auf Windows anders feuert als der Entwickler auf seinem Mac erwartet hat.
AutoMapper: das Mapping ist nicht das Problem
Hier muss ich aber kurz aus dem Bogard-Fan-Modus raus und ehrlich sein.
AutoMapper löst ein echtes Problem: Du willst nicht hundert mal entity.Name = dto.Name schreiben. Das verstehe ich. Aber im KMU-Kontext sehe ich regelmäßig, wie aus diesem Werkzeug eine Verantwortungsdiffusion wird. Das Mapping "gehört" irgendwie niemandem. Es liegt nicht in der Service-Schicht, nicht im Controller – es ist magisch konfiguriert, und wenn es falsch mappt, dann sucht man zwanzig Minuten, bevor man überhaupt weiß, wo man suchen soll.
Konkrete Zahl aus einem Mandat: Wir haben in einem Audit 34 AutoMapper-Profile gefunden, von denen 11 nie aufgerufen wurden. Niemand wusste das. Niemand hatte es entfernt, weil niemand sicher war. Das ist kein AutoMapper-Problem – das ist ein Team-Ownership-Problem, das durch AutoMapper unsichtbar gemacht wird.
Meine Faustregel für KMUs: Wenn dein Team kleiner als sechs Entwickler ist und ihr keine strikte Schichttrennung lebt – also kein echtes Domain-Model, das von den DTOs wirklich getrennt ist – dann kauft ihr mit AutoMapper mehr Komplexität als ihr spart. Dann sind drei Zeilen new UserDto { Name = user.Name, Email = user.Email } ehrlicher Code.
MediatR: CQRS light oder Overhead-Generator?
MediatR ist ähnlich ambivalent. Das Mediator-Pattern ist nicht falsch – es entkoppelt Handler von Aufrufer, macht Unit-Tests einfacher, und CQRS als Denkmodell (Commands ändern Zustand, Queries lesen ihn) ist auch im Mittelstand sinnvoll. Das sage ich ohne Ironie.
Aber ich sehe in KMUs immer wieder denselben Fehler: MediatR wird eingeführt, weil jemand ein Clean-Architecture-Tutorial geschaut hat, und jetzt hat man für jeden Datenbankaufruf eine eigene Handler-Klasse, ein eigenes Request-Objekt, ein eigenes Response-Objekt – und fünf Entwickler, die jeden Morgen dreimal so viele Dateien öffnen müssen wie vorher, um eine Änderung zu machen. Der Overhead ist real. In einem 15-Personen-Unternehmen mit zwei Backend-Entwicklern ist das oft einfach zu viel Infrastruktur für den tatsächlichen Problemumfang.
MediatR lohnt sich im KMU dann, wenn ihr wirklich voneinander unabhängige Module habt, die denselben Bus nutzen sollen – also wenn Entkopplung ein echter Bedarf ist, nicht nur ein architektonisches Ideal.
Meine konkrete Empfehlung
Erstens: Wenn du noch auf .NET Framework 4.6.2 läufst und AutoMapper oder MediatR schon im Stack hast – jetzt updaten. Das net462-Build-Target in diesen Releases ist genau das, was du brauchst, um auf festem Grund zu stehen.
Zweitens: Wenn du neu anfängst oder ein Greenfield-Projekt planst, überleg dir vor der Entscheidung für AutoMapper oder MediatR zwei Minuten, ob du wirklich das Problem hast, das sie lösen. Nicht ob das Pattern cool ist – ob dein Team, mit eurer Codebasis, mit eurem Testcover von dieser Abstraktion profitiert oder ob sie euch drei Jahre später in die Falle läuft wie bei meinem Maschinenbauer.
Drittens: Quartalsweise Releases als Policy ist ein starkes Signal. Bogard zeigt damit, dass diese Libraries nicht in den Ruhestand gehen. Wenn du also langfristig damit planst, ist das eine verlässlichere Grundlage als noch vor zwei Jahren.
Der vollständige Original-Beitrag von Jimmy Bogard: AutoMapper 15.1 and MediatR 13.1 Released
Wenn du gerade vor einer ähnlichen Entscheidung stehst – Legacy-Stack mit AutoMapper/MediatR, Migration geplant, oder ihr zieht einen neuen .NET-Stack auf und fragt euch, wo die Fallen liegen – dann reden wir kurz.
— Bernhard