Ich muss an einer Anwendung arbeiten, die aus zwei Hauptteilen besteht:
- Der Geschäftslogikteil mit spezifischen Geschäftsklassen (z.B. Buch, Bibliothek, Autor, ...)
- Ein generischer Teil, der Bücher, Bibliotheken, ... in Datenrastern anzeigen kann, sie einer Datenbank zuordnet, ...).
Der generische Teil verwendet Reflection, um die Daten aus den Geschäftsklassen zu erhalten, ohne dass spezielle Datengitter- oder Datenbanklogik in die Geschäftsklassen geschrieben werden muss. Dies funktioniert gut und ermöglicht es uns, neue Geschäftsklassen (z. B. LibraryMember) hinzuzufügen, ohne das Datengitter und die Datenbanklogik anpassen zu müssen.
Im Laufe der Jahre wurde jedoch Code zu den Business-Klassen hinzugefügt, der ebenfalls Reflection nutzt, um Dinge in den Business-Klassen zu erledigen. Wenn z. B. der Autor eines Buches geändert wird, werden Beobachter aufgerufen, um dem Autor selbst mitzuteilen, dass er dieses Buch zu seiner Sammlung der von ihm geschriebenen Bücher (Author.Books) hinzufügen soll. In diesen Beobachtern werden nicht nur die Instanzen übergeben, sondern auch Informationen, die direkt von der Reflexion abgeleitet sind (FieldInfo wird dem Beobachteraufruf hinzugefügt, damit der Aufrufer weiß, dass das Feld "Author" des Buches geändert wurde).
Ich sehe durchaus Vorteile in der Verwendung von Reflection in diesen generischen Modulen (wie dem Datengitter oder der Datenbankschnittstelle), aber es scheint mir, dass die Verwendung von Reflection in den Geschäftsklassen eine schlechte Idee ist. Sollte die Anwendung nicht so weit wie möglich ohne Reflection funktionieren? Oder ist die Verwendung von Reflection die "normale Arbeitsweise" im 21. Jahrhundert?
Ist es eine gute Praxis, Reflexion in Ihrer Geschäftslogik zu verwenden?
EDIT : Eine Klarstellung zu der Bemerkung von Kirk:
- Stellen Sie sich vor, dass Author einen Beobachter auf Book implementiert.
- Book ruft alle seine Beobachter auf, wenn sich ein Feld von Book ändert (wie Titel, Jahr, #Seiten, Autor, ...). Die 'FieldInfo' des geänderten Feldes wird an den Beobachter übergeben.
- Der Author-observer entscheidet dann anhand dieser FieldInfo, ob er an dieser Änderung interessiert ist. In diesem Fall, wenn FieldInfo für das Feld Author of Book ist, wird der Author-Observer seinen eigenen Vektor von Books aktualisieren.