Hmm...
Minimal, jedenfalls im Vergleich zu einem Datenbankzugriff. Und ich bin immer noch Überzeugt dass sich ein Blick auf die
xml-klasse lohnt. Wenn da sich die
DB ändert muss man nicht die ganze Struktur der Übergabe ändern.
Wenn der Aufrufer davon Ausgeht, Äpfel zu erhalten, jedoch die Funktion (aufgrund der Datenbankänderung) nur Äpfel in die Struktur geben kann, wie kann das dann funktionieren?
Wenn der Aufrufer nicht sicher sein kann, was in welcher Struktur seitens der Funktion zurück geliefert wird, dann ist die Funktion meiner Meinung unbrauchbar..
Aus meiner Sicht ist der Aufruf der Funktion in UnitB aus UnitA einem
API-Aufruf unter MS gleich. Hier MUSS sicher sein, dass beide Seiten bei den übergebenen Daten (in beide Richtungen) vom gleichen Sprechen, sowohl Inhalt, wie auch Form.
Somit ist es ein Gangbarer Weg Records oder Objekte zu Verwenden, jedoch nur, wenn beide Units auch mit der gleichen Definition arbeiten (Stichwort
DLL-Funktionen).
Interfaces sind da eine Option, jedoch hängt das wohl eher von der Flexibilität/Komplexität der Funktion ab. Bei einfachen Aufrufen würde ich eher zu Records greifen.
Dynamische
XML-Strukturen sind schön, aber auch hier müssen die Tags fix definiert werden, sonst kann weder Aufrufer noch FUnktion damit etwas anfangen.
Wenn diese Tags fix sind, dann können natürlich einzelne weggelassen werden, jedoch müsste auch dann definiert werden, was ein Weglassen bedeutet. Wenn es sich z.B. um einen String-Wert handelt, kann das aus Sicht der
DB entweder um einen Leerstring ('') oder um einen NULL Wert handeln. Somit muss auch dies für den jeweiligen Wert definiert werden
Uff.. So viele Definitionen und alles nur um eine Funktion aufzurufen