Irre ich mich, wenn ich denke, dass die Notwendigkeit von AutoMapper ein Zeichen für schlechtes Design ist?

Automapper ist ein "Objekt-Objekt-Mapper" für .NET. Dies bedeutet, dass Objekte aus einer Klasse in eine andere Klasse kopiert werden, die dasselbe darstellt.

Warum ist das jemals nützlich? Ist das Duplizieren von Klassen jemals nützlich / gutes Design?

Eine schnelle Google-Suche ergab folgendes Beispiel:

http://www.codeproject.com/Articles/61629/AutoMapper

zeigt eine perfekt gültige Verwendung von AutoMapper, die definitiv kein Beispiel für ein schlechtes Design ist. In einer Anwendung mit mehreren Ebenen befinden sich möglicherweise Objekte in Ihren Daten oder in Ihrer Business-Ebene. Manchmal benötigen Sie nur eine Teilmenge der Attribute dieser Datenobjekte oder eine Art Sicht auf diese in Ihrer UI-Ebene. Sie erstellen also ein Ansichtsmodell, das Objekte mit genau den Attributen enthält, die Sie in Ihrer Benutzeroberfläche benötigen, und verwenden AutoMapper, um den Inhalt dieser Objekte mit weniger Boilerplate-Code zu versehen.

In einer solchen Situation sind Ihre "Ansichtsobjekte" kein Duplikat der ursprünglichen Klasse. Sie haben verschiedene Methoden und vielleicht ein paar doppelte Attribute. Dies ist jedoch in Ordnung, solange Sie diese Ansichtsobjekte nur für die Anzeige auf der Benutzeroberfläche verwenden und sie nicht für Datenmanipulationen oder Geschäftsvorgänge missbrauchen.

Ein weiteres Thema, das Sie möglicherweise lesen, um dies besser zu verstehen , ist im Gegensatz zu CRUD das Trennungsmuster "Fowlers Command Query Responsibility" . Es zeigt Situationen, in denen unterschiedliche Objektmodelle zum Abfragen und Aktualisieren von Daten in einer Datenbank sinnvoll sind. Hier kann die Zuordnung von einem Objektmodell zu einem anderen auch mit einem Tool wie AutoMapper erfolgen.

Ist das Duplizieren von Klassen jemals nützlich / gutes Design?

Es hat sich bewährt, eine separate Ansichtsmodellklasse für die Verwendung in der Benutzeroberflächenebene zu verwenden, anstatt dieselbe Klasse zu verwenden, die in der Datenebene verwendet wird. Ihre Benutzeroberfläche / Webseite muss möglicherweise andere Informationen anzeigen, die sich nicht ausschließlich auf die Datenentität beziehen. Indem Sie diese zusätzliche Klasse erstellen, geben Sie sich die Freiheit, die Benutzeroberfläche einfach zu optimieren, wenn sich die Anforderungen im Laufe der Zeit ändern.

Ich persönlich vermeide die Verwendung von AutoMapper aus drei Gründen:

Stille Ausfälle häufiger

Da AutoMapper automatisch zwischen Eigenschaften abbildet, wird die Eigenschaftszuordnung übersprungen, wenn ein Eigenschaftsname für eine Klasse und nicht für die andere Klasse geändert wird. Der Compiler wird es nicht wissen. Automapper ist das egal.

Fehlende statische Analyse

Sie haben also eine große Codebasis erhalten, mit der Sie sich befassen müssen. Es gibt eine Million Klassen mit einer Million Eigenschaften. Es sieht so aus, als ob sie nicht verwendet werden oder Duplikate sind. Mit dem Tool "Alle Verweise suchen" in Visual Studio können Sie feststellen, wo Eigenschaften verwendet werden, und in Ihrem Kopf eine Übersicht darüber erstellen, wie die gesamte Anwendung zusammen hängt. Warten Sie, es gibt keine expliziten Verweise auf die Hälfte der Eigenschaften, da Automapper verwendet wird. Mein Job ist jetzt um einiges schwieriger.

Späte Anforderungen, die die Komplexität erhöhen

Automapper funktioniert einwandfrei, wenn Sie nur die Werte aus EINER Klasse in eine andere Klasse kopieren möchten (wie dies häufig zu Beginn der Entwicklung der Fall ist). Erinnern Sie sich jedoch an die Anforderungen, die sich mit der Zeit ändern? Was ist, wenn Sie jetzt Werte von anderen Teilen Ihrer Anwendung abrufen müssen, möglicherweise spezifisch für den angemeldeten Benutzer oder einen anderen Kontextstatus?

Das AutoMapper-Muster zum Erstellen der Eins-zu-Eins-Klassenzuordnungen beim Anwendungsstart eignet sich nicht gut für diese Art von kontextspezifischen Änderungen. Ja, es gibt wahrscheinlich Möglichkeiten, es zum Laufen zu bringen, aber ich finde es normalerweise sauberer, einfacher und ausdrucksvoller, die Logik selbst zu schreiben.

Kurz gesagt, bevor Sie sich an Automapper wenden, um 30 Sekunden Zeit für die manuelle Zuordnung einer Klasse zu einer anderen zu sparen, sollten Sie darüber nachdenken.

Programmieren ist die Kunst, einem anderen Menschen zu sagen, was der Computer tun soll. - Donald Knuth

Fragen Sie sich vor diesem Hintergrund: "Ist AutoMapper heute hilfreich und wird es morgen sein?"

Nach meiner Erfahrung hat sich jemand über "zu viel Heizplatte" beschwert und möchte AutoMapper verwenden.

1. Sie finden es irritierend, immer wieder denselben Code zu schreiben.
2. Sie sind faul und möchten keinen Code schreiben, der Ax = Bx ausführt
3. Sie stehen unter zu großem Zeitdruck, um tatsächlich darüber nachzudenken, ob es eine gute Idee ist, Ax = Bx immer wieder zu schreiben, und schreiben Sie dann einen guten Code für die Aufgabe.

Jedoch:

1. Wenn es wirklich darum geht, Wiederholungen zu vermeiden, können Sie ein Objekt oder eine Methode erstellen, um es zu abstrahieren. Sie brauchen keinen AutoMapper.
2. Wenn Sie faul sind, werden Sie faul sein und nicht lernen, wie AutoMapper funktioniert. Stattdessen übernehmen Sie das Muster "Programmieren durch Zufall" und schreiben schrecklichen Code, in dem Sie Geschäftslogik in ein AutoMapper-Profil schreiben. In diesem Fall sollten Sie Ihre Einstellung zum Programmieren ändern oder sich eine andere berufliche Tätigkeit suchen. Sie brauchen keinen AutoMapper.
3. Wenn Sie unter zu viel Zeitdruck stehen, hat Ihr Problem nichts mit der Programmierung selbst zu tun. Sie brauchen keinen AutoMapper.

Wenn Sie eine statisch typisierte Sprache ausgewählt haben, können Sie die Sprache nutzen. Wenn Sie versuchen, die Steuerelemente in der Sprache zu umgehen, die dazu beitragen, Fehler aufgrund übermäßiger Verwendung von Reflection- und Magic-APIs wie AutoMapper zu vermeiden, bedeutet dies lediglich, dass Sie eine für Ihre Anforderungen unbefriedigende Sprache ausgewählt haben.

Nur weil Microsoft Funktionen zu C # hinzugefügt hat, bedeutet dies nicht, dass sie in jeder Situation fair sind oder bewährte Methoden unterstützen. Reflection und das Schlüsselwort 'dynamic' sollten beispielsweise in Fällen verwendet werden, in denen Sie einfach nicht das erreichen können, was Sie ohne sie benötigen. AutoMapper ist keine Lösung für jeden Anwendungsfall, der ohne AutoMapper noch nicht gelöst werden kann.

Ist also die Duplizierung von Klassen ein schlechtes Design? Nicht unbedingt.

Ist AutoMapper eine schlechte Idee? Ja absolut.

Die Verwendung von AutoMapper weist auf systembedingte Mängel im Projekt hin. Wenn Sie es brauchen, denken Sie über Ihr Design nach. Sie werden immer ein besseres, lesbareres, wartbareres und fehlerfreieres Design finden.

Es gibt ein tieferes Problem hier: die Tatsache , dass C # und Java bestehen die meisten / alle Arten von Namen zu unterscheiden sein müssen , anstatt Struktur: zB class MyPoint2Dund class YourPoint2Dsind getrennte Arten , auch wenn sie genau die gleichen Definitionen haben. Wenn der von Ihnen gewünschte Typ "eine anonyme Sache mit einem xFeld und einem yFeld" (dh ein Datensatz ) ist, haben Sie kein Glück. Wenn Sie also eine YourPoint2Din eine verwandeln möchten MyPoint2D, haben Sie drei Möglichkeiten:

1. Schreiben Sie ein langweiliges, sich wiederholendes, alltägliches Boilerplate nach dem Vorbild von this.x = that.x; this.y = that.y
2. Generiere den Code irgendwie.
3. Verwenden Sie Reflexion.

Wahl 1 ist in kleinen Dosen einfach genug, wird jedoch schnell zur Pflicht, wenn die Anzahl der zuzuordnenden Typen groß ist.

Wahl 2 ist weniger wünschenswert, da Sie jetzt Ihrem Erstellungsprozess einen zusätzlichen Schritt hinzufügen müssen, um den Code zu generieren, und sicherstellen müssen, dass das gesamte Team das Memo erhält. Im schlimmsten Fall müssen Sie auch Ihren eigenen Codegenerator oder Ihr eigenes Vorlagensystem rollen.

Das lässt dich nachdenken. Sie können es selbst tun oder AutoMapper verwenden.

Automapper ist eine jener Bibliotheken / Tools, in denen der Kaiser buchstäblich stumpf nackt herumläuft. Wenn Sie an dem glitzernden Logo vorbeikommen, stellen Sie fest, dass es nichts tut, was Sie nicht manuell tun können, mit viel besseren Ergebnissen.

Obwohl ich nicht ganz sicher bin, wie es auf Auto-Mapping-Mitglieder hindeutet, handelt es sich höchstwahrscheinlich um zusätzliche Laufzeitlogik und mögliche Überlegungen. Dies kann eine erhebliche Leistungseinbuße im Austausch für eine Zeitersparnis sein. Beim manuellen Mapping wird der Hinweis jedoch lange vor dem Kompilieren ausgeführt.

In Fällen, in denen AutoMapper keine Ahnung hat, müssen Sie die Zuordnung mit Code konfigurieren und Flags setzen. Wenn Sie die gesamte Setup- und Code-Arbeit erledigen möchten, müssen Sie sich fragen, wie viel Sie durch manuelles Mapping sparen.