[php] [FYI] Vortrag in Hamburg: DAO, Resultsets und Spreadsheets

[Ulf Wendel]

Marc Ende wrote:

> Hi Ulf,
> 
> On Sun, Dec 14, 2003 at 01:35:14PM +0100, Ulf Wendel wrote:
> 
>>[...], aber wie 
>>groß ist der Zeitgewinn wirklich? Ich bemerke bei etwas größeren 
>>Projekten etwa folgende Verteilung der Programmierzeit: 60% 
>>Geschäftsklassen, 30% Presentation-Tier, 10% Framework inkl. DAOs. Das 
>>gibt mir wenig Anreiz, um darüber nachzudenken wie ich DAOs und 
>>Formulare automatisch koppel oder Formulare aus DAOs ableite. Ist die 
>>Verteilung der Arbeitszeit bei Dir wesentlich anders?
> 
> 
> ich denke nicht, daß die Aufteilung tatsächlich so ist. Wenn ich mir zum
> Beispiel die DB_DataObjects genauer anschaue, fällt bei der
> Programmierung die DAOs nicht ins Framework sondern durchaus mit in die
> Geschäftsklassen und nicht ins Framework (es sei denn du läßt einfach
> createTables.php einfach laufen und nutzt sie so wie sie sind).

Die PEAR DB_DataObjects verleiten dich dazu in diesen Objekten 
Businessfunktionalitäten abzulegen. Ich bin mir nicht sicher, ob diese 
enge Koppelung sinnvoll ist.

Der DAO-Gedanke führt ein "Integration-Tier" ein, welches 
Geschäftsklassen und Persistenzmedium trennen soll. Dieser neue Layer 
sorgt dafür, daß die Geschäftsklassen ohne Änderungen übernommen werden 
können, wenn das Persistenzmedium wechselt. Bei konsequenter Anwendung 
ist es egal, ob eine Geschäftsklasse gerade mit DB_DataObject oder 
SOAP_DataObject arbeitet. Werden Business-Tier und Integration-Tier 
vermischt droht eine Situation, die der eines Datenbankwechsels ähnelt.

Ich muß zugeben, daß ich mich mit dem PEAR DB_DataObjects nicht 
besonders gut auskenne und meine Einschätzung möglicherweise falsch ist 
aber ich würde nicht so weit gehen das ganze mit dem Begriff DAO zu 
belegen. Es fehlt mir, die klar erkennbare Motivation Geschäftsklassen 
und Persistenzmedium konsequent entkoppeln zu wollen.

In der Artikelserie gehe ich nicht auf das problematische Mapping von 
Objekten auf relationale Datenbanken ein. Das Mapping ist ein 
Dauerthema, da sich Entitäten aus der Geschäftswelt nur selten direkt in 
Datenbank Entitäten übersetzen lassen. Die PEAR DB_DataObjects versuchen 
automatisch verwandte Objekte zu erkennen. Ich mache das nicht, 
vielleicht ist das ein Fehler.

Bei größeren Projekten (> 50kloc, >50 DB-Tabellen) verbringe ich nur 
einen kleinen Teil meiner Arbeitszeit damit, mich um die Erstellung von 
Code zu Persistierung zu kümmern. Seit ein paar Tagen bastel ich daran 
Bestellungen in einem Handelsnetz, die ich aus einem Warenkorb mit 
Remote-Items ableite, in einer Art State-Maschine zu verklausulieren, 
damit ein Cron-Job alle notwendigen RPC-Calls im Netzwerk vornehmen 
kann. Für die zwei Datenobjekte habe ich vielleicht 30 Minuten 
aufgewendet (DAO, Framework). Die übrige Zeit (Geschäftslogik) habe ich 
mit der Vorrausberechnung der RPC-Calls und der Erstellung der 
State-Maschine verbracht.

Ok, ok, es gibt auch Gegenbeispiele ala CRUD ;-). Es hängt sehr von der 
Anwendung ab, ob es wirklich lohnenswert ist über automatische 
Codegenerierung nachzudenken. Ich brauchte es bislang nicht aber ich 
werde einen Teufel tun, es anderen Leuten auszureden. Vielleicht 
profitiere ich ja von den Entwicklungen und ändere meine Meinung: Was 
der Bauer nicht kennt, frißt er nicht.

Grüße,
Ulf

-- 
Suche neuen Job. Erfahrung: NetUSE AG Kiel (PHPLib)
WWE Hamburg, http://www.ulf-wendel.de