Attribute Properties werden zu DProperties
Refactoring, Refactoring, Refactoring. AttributeProperties werden zu DProperties. Unsere DataObjects basieren auf der Basisklasse DataObject, die Funktionen bereitstellt, um Delegates für Strings, Int, Float und alle anderen unterstützten Typen zu erzeugen. Die Delegates basieren auf unserer Klasse AttributeProperty. Im Framework greifen wir aber auch häufig auf die Type-Properties der Reflection-Klassen zu, die ebenfalls Properties heißen. Unsere AttributeProperties haben wir an vielen Stellen einer Variablen „property“ zugewiesen. Um diesem Mischmasch und der Unlesbarkeit Einhalt zu gebieten heißen alle AttributeProperties nun DProperties (für Delegate Properties) und die Type-Properties sind KProperties (da sie auf der Klasse KMutableProperty basieren).
Dummyobjekte statt Dummyobjekte 😛
Für Abfragen wie Tree.find{ id = 24 } haben wir bisher konkrete Instanzen von Datenobjekte erzeugt, um einen typesafen Zugriff auf die Attribute in unserer Selector-Funktion { id = 24 } zu ermöglichen. Auch wenn wir dazu nur ein DummyObjekt verwenden, das nur einmal erzeugt und immer wieder verwendet wird, wird eine konkrete Instanz des DataObjects erzeugt. Es ist unschön und kann früher oder später zu Problemen führen.
Um das Problem zu lösen, werden nun richtige Dummyobjekte in Form von Mocks erzeugt. Das Mock sieht aus wie das DataObject, aber es ist eine Instanz einer komplett anderen Klasse. Dafür nutzen wir Objenesis. Ein kleines Framework, das auch von mockk eingesetzt wird.
Reload works
Unser Reload funktioniert nun. Der Reload eines einzelnen DataObjects funktionierte bereits. Nur beim Massenreload hatten wir Probleme, da die Reihenfolge der zu reloadenden Objekte nicht mit dem Ergebnis der Datenbank übereinstimmte. Wurden nun die Properties der DataObjects geupdated, hat das DataObject 1 möglicherweise die Attribute vom DataObject 5 bekommen.
Um das Problem zu lösen, sortieren wir die zu reloadenden DataObjects, bevor wir die Daten des Reloads von der Datenbank auslesen.
Core Library
Jetzt geht es nochmal ans Deployment. Wir würden gerne eine Core-Library anlegen, die wir in alle Projekte einbinden, um gewisse Funktionalitäten wie z.B. zentrale Extensions auf Strings, Booleans etc. oder den ServiceProvider und zukünftige Dependencies, die zentral verfügbar sein sollen, anzubieten. Dazu muss das Deployment angepasst werden, weil wir bis jetzt keine transitiven Dependencies in dem Projekt, welches die Dependency einbindet, zur Verfügung stellen können. Hier bedarf es wieder etwas mehr Forschungsarbeit.