Rolf B: PDO: Dynamische Read- und Write-Funktion schreiben

Beitrag lesen

Hallo borisbaer,

interessantes Bild - kann man so machen, muss man nicht.

Diese "Master Model" Klasse, die die CRUD Methoden implementieren soll, scheint mir eher sowas wie eine Toolbox mit den nötigen Methoden für den Model-Betrieb zu sein. Es gibt da diverse Ansätze, einer ist auch der, dass die Release- oder User-Klasse von einer AbstractModel Klasse erbt und Methoden wie dbRead oder dbCreate dort zu finden sind.

Man kann das beliebig over-engineeren.

Als mein Arbeitgeber in den 90er Jahren mit Smalltalk rumgemacht hat, war ein "Mapping Tool" Teil des Entwicklungssystems, das wir dafür eingekauft hatten. Da musste man mit einer GUI-Oberfläche das Objektmodell auf das Relationenmodell der DB abbilden. Daraufhin generierte das Mapping-Tool dann das SQL für die Zugriffe automatisch; es konnte sogar JOINs und Subselects aufbauen. Das kostete prompt einige Strafsekunden in der Performance.

Hinzu kam dann die Architekturanweisung, dass die Datenhaltung nicht in einer Server-DB zu erfolgen habe, sondern auf unserem guten alten IBM Großrechner. Auf den kann man natürlich NICHT mit generiertem SQL zugreifen - d.h. kann man schon, das wird aber aus Performance-Gründen verboten. Heißt also: für jedes potenziell generierte SQL musste man ein COBOL Modul auf dem Host bereitstellen, in dem das SQL dann tatsächlich stand. Und im Smalltalk eine Mapping-Tabelle führen, welches SQL Statement welches COBOL Modul aufzurufen hat. Nachdem wir uns zwei Jahre lang damit die Finger gebrochen haben, habe ich darauf gepfiffen, die Datenzugriffsmodule direkt aufgerufen und die Modellobjekte aus den Rückgabedaten von Hand generiert. Das fluppte wie Seife.

Hach ja. Die Nostalgie ist auch nicht mehr das, was sie mal war…

Rolf

--
sumpsi - posui - obstruxi