Nullable VS Nullable

[WiPhi]

Hallo liebe DPler,

ich stehe zur Zeit vor einem Problem welches Nullables aus zwei Frameworks betrifft: Spring4D Nullables vs Aurelius Nullables.

Zur Zeit verwende ich die Aurelis (ORM) Bibliothek und dessen Nullables zur Definition von den Datenstrukturen.
Jetzt habe ich mich in die Spring4D eingearbeitet und dort auch die Nullables entdeckt. Natürlich sind diese anders deklariert als die aus Aurelius.

Meine erste Idee war, ich verwende strikt nur einen Nullable-Typen und zwar den aus Spring. Mit diesem kommt Aurelius jedoch nicht klar, da dieser zwar erkennt das es sich um einen Nullable handelt, ihm jedoch die Informationen aus Aurelius fehlen (war auch zu erwarten).

Wiederrum könnte ich den Aurelius-Nullable überall verwenden. Jedoch wird das ganze problematisch sobald ich die Unit Spring einbinde, in welcher u.A. auch der Nullable für Spring deklariert ist. Das Typen-Chaos will ich unbedingt vermeiden!

Vielleicht hat der ein oder andere eine Idee wie ich beide Typen (oder besser gesagt beide Frameworks mit gleichnamigen Typen) miteinander verwenden kann?

[Schokohase]

Wenn du SoC berücksichtigst, dann ist es kein Problem.

Du hast ein Domain-Model und für die Speicherung mit dem Aurelius-ORM entsprechende Entity-Models. Zum Speichern erzeugst du dir aus dem Domain-Model das Entity-Model bzw. zum Lesen erzeugst du dir aus dem Entity-Model das Domain-Model.

[hoika]

Hallo,

Zitat:

Jedoch wird das ganze problematisch sobald ich die Unit Spring einbinde, in welcher u.A. auch der Nullable für Spring deklariert ist. Das Typen-Chaos will ich unbedingt vermeiden!

Binde die Aurelius-Nullable-Unit immer als letzte Unit ein.
Oder definier dir einen eigenen Nullable-Type, der vom Aurelis-Typ abgeleitet ist:
type TMyNullable = Aurelius.Nullable.

[WiPhi]

Ich danke euch für die Anregungen.
Derzeit habe ich es so gelöst wie hoika es vorgeschlagen hat: Die Aurelis Unit als letztes einbinden. Ich prüfe demnächst noch, ob ich es sich lohnt den Aurelis-Typen durch meinen eigenen zu ersetzen.

Das Problem besteht wirklich darin, dass in der Spring-Unit alle Basis-Typen von Spring4D deklariert sind.

Z.B.: Ich benutze den Nullable-Spring nicht, möchte aber dennoch den TValue-Helper verwenden. (Konkret die Fähigkeit des Helpers um Werte zu konvertieren.)

Delphi-Quellcode:

uses
  Spring;
// <snip>
procedure Foo;
var
  x: String
  Value: TValue
begin
  Value := 20;
  x := Value.ToType<String>;
end;

Möchte ich jetzt aber eine Nullable-Konvertierung durchführen, registriere ich zuerst Aurelis-Nullable Konverter:

Delphi-Quellcode:

uses
  Spring.ValueConverters,
  Aurelius.Nullable;

// <snip>
TValueConverterFactory.RegisterConverter([SaemtlicheTypen], TypeInfo(Aurelius.Nullable<EntsprechenderTyp>), TTypeToNullableConverter);  // und natürlich die Gegenrichtung

Besonders schön ist das die Klasse TTypeToNullableConverter nicht von mir, sondern auch aus Spring stammt und augenscheinlich mit dem Aurelius-Nullable klar kommt.

Anschließend kann ich Aurelius.Nullable-Konvertierungen durchführen:

Delphi-Quellcode:

uses
  Spring,
  Aurelius.Nullable;
// <snip>
procedure Foo;
var
  x: Nullable<String>
  Value: TValue;
begin
  Value := 20;
  x := Value.ToType<Nullable<String>>;
end;

Vielleicht hat jemand noch eine andere Idee, anonsten kann ich (und auch zukünftige Entwickler des Projekts) denk ich damit umgehen.

[freimatz]

Zitat von WiPhi:

Das Problem besteht wirklich darin, dass in der Spring-Unit alle Basis-Typen von Spring4D deklariert sind.
...
Vielleicht hat jemand noch eine andere Idee, anonsten kann ich (und auch zukünftige Entwickler des Projekts) denk ich damit umgehen.

Bei Spring4D vorstellig werden, sie mögen doch bitte eine eigene unit für die Nullable machen?

[mkinzler]

Spring4D beinhaltet auch ein ORM (MarshMallow)

[WiPhi]

Entschuldige freimatz, deine Antwort hatte ich vorhin übersehen.

Zitat von freimatz:

Bei Spring4D vorstellig werden, sie mögen doch bitte eine eigene unit für die Nullable machen?

Darüber habe ich auch schon nachgedacht, wollte aber erstmal sehen, ob es vielleicht eine einfache Lösung gibt, ohne in das Framework einzugreifen.

Zitat von Schokohase:

Ich möchte nochmals darauf hinweisen, dass gerade hier bei der Einhaltung von SoC dieses Problem nicht wirklich existiert, bzw. an nur einer überschaubaren Stelle auftritt.

Die Entity-Klassen für Aurelius (oder jedes andere ORM-Framework) spiegeln 1:1 die SQL-Tabellen wieder und nur in den eher zufällig seltenen Fällen auch Anwendungs-Klassen.

Anwendungs- und Datenhaltungsklassen sind strikt getrennt.

Ich denke bei meinem Fall geht es gerade um diese "überschaubare" Stelle: eine Import-Klasse, welche aus einer Datei in die Datenbank (sprich ORM) einliest. Diese Klasse muss zwangsläufig das Datenobjekt und somit auch den Aurelius-Nullable kennen. Weiterhin muss der Import bei Bedarf Werte konvertieren können (u.a. in Aurelius-Nullables). Ich möchte gar nicht den Spring Nullable verwenden, jedoch aber den TValue-Helper, welcher sich in der Spring-Unit befindet. Dummerweise befindet sich in dieser Unit auch der Spring Nullable.

Somit hat freimatz natürlich Recht: Wenn der Spring Nullable-Typ in einer separaten Unit liegen würde, hätte ich das Problem nicht.

Zitat von TiGü:

Hm, so richtig will das nicht mit den generischen Operator für record helper.
Höchstens so ein "stumpfer" Ansatz mit Konvertierungsfunktionen scheint zu kompilieren:

Ja sowas hatte ich auch schon mal vor mir, war aber nicht besonders begeistert und habe es wieder verworfen. Wenn sollte das schon Implicit funktionieren.

Wie gesagt, derzeit funktioniert die Variante mit Aurelius Nullable als letzte Unit einbinden gut. Mittelfristig werde ich bei Gelegenheit mal bei Spring4D anfragen, ob der Nullable-Type in eine eigene Unit (so wie bei Aurelius ) wandern könnte.
OT: Da steht doch bald ein neues Release an? Wenn dort einige Major Änderungen gemacht welchen, wäre das ja eine Idee.

[Stevie]

Zitat von WiPhi:

Besonders schön ist das die Klasse TTypeToNullableConverter nicht von mir, sondern auch aus Spring stammt und augenscheinlich mit dem Aurelius-Nullable klar kommt.

Die braucht man nicht - die von und nach Nullable<T> Konvertierung ist im TValueHelper direkt implementiert.
Diese benutzt aber die Implementierung, wie Spring4D sie hat und scheint nur mit Aurelius zu funktionieren, wird aber im Endeffekt Speicher korrumpieren. Bei Spring ist das interne FHasValue Feld ein String, damit auch lokale Variablen vom Typ Nullable<T> immer so initialisieren, dass sie signalisieren, null zu sein. Bei Aurelius ist es einfach ein Boolean. Hat auch Vorteile (kein expliziter Code für Init und Finalize für solche Variablen notwendig. Dafür sind sie erstmal in einem nicht definierten Zustand wie alle nicht gemanagten Wertetypen.

Wenn du ToType<Nullable<T>> für Aurelius Nullable<T> benutzt, wirst du dir Speicherlöcher schaffen und Speicher überschreiben, weil das intern auf das FHasValue Feld schreibt, was es für ein string Feld hält.

Aurelius ist im übrigen nicht die einzige Drittanbieter Komponente, die den Nullable Typen für sich entdeckt hat - da aber leider die Bereitschaft der meisten für Zusammenarbeit mit OpenSource Bibliotheken zusammen zu arbeiten gleich null ist, ist mir das dann auch egal, wenn der Klump nicht kompatibel ist. Ich wäre gern gewillt, bestimmte Teile so zu restrukturieren, dass sie gemeinsam mit anderen genutzt werden können, ohne dass jeder das Rad ein bisschen anders neu erfinden muss.

P.S. Ich werd mal zumindest schauen, dass er auch Aurelius Nullable korrekt konvertiert, ohne, dass es den Speicher zerfräst. Das sollte sich einfach genug machen lassen.