Schließen einer Datenbankverbindung

[dedlfix]

Tach!

Er sprach von zwei Methoden und davon abgesehen ist nichts dagegen einzuwenden, wenn eine Methode ihren eigenen Kram auch selbst aufräumt, ganz im Gegenteil.

Diese zwei Methoden, so habe ich seine Ausführungen interpretiert, fragen beide Daten ab. Die eine fängt an, delegiert eine Teilaufgabe zu einer anderen und will dann weitermachen. Dummerweise hat die andere Methode die Verbindung geschlossen. Die Verbindungsverwaltung soll nicht ihre Aufgabe sein, weil sie - wie in dem Fall sehr schön sichtbar wurde - gar nicht weiß, was mit der Verbindung noch geschehen soll. Deshalb soll die Verbindungsverwaltung aus den Methoden raus und in einem übergeordneten Kontext abgehandelt werden. Und das ist dann auch ganz unabhängig von der Frage, ob ein PHP-Script an seinem Lebensende von selbst aufräumt oder nicht.

Die Verbindungsverwaltung ist also in deisem Fall nicht "ihr eigener Kram". Wohl aber wäre das ein Preäared Statement (wenn es da was aufzuräumen gäbe) oder eine Transaction, die sie vollständig selbst erledigen soll.Ist sie nur Teil oder kann aus anderen Gründen nicht wissen, dass sie Teil eienr Transaction is, dann ist es nicht ihre Aufgabe, die Transaction nach getaner Arbeit zu schließen.

Nur, wenn dieser Kram auch woanders benötigt wird, wie in diesem Fall nach der Erweiterung wohl vorliegend, sollte die Verwaltung aus der Methode ausgelagert werden - und das hat er anscheinend gemacht, wie in seiner Eingangsfrage beschrieben.

Wenn die Aufgabe klein und überschaubar ist, und vor allem unter allen Umständen atomar, dann spricht aus meine Augen auch nichts dageben, dass sie sämtlichen Kram allein macht und man nicht noch eine aufgeblähte Klasse drumherum schreibt. Doch irgendwann ist mit dieser Einfachheit Schluss und dann braucht man für komplexe Probleme eine ordentliche Aufgabenteilung. An dem Punkt ist der OP anscheinend grad angekommen und muss sich nun überlegen, wie er die Aufgaben zielführend teilt - und am Ende auch noch die Übersicht behält. Nicht umsonst haben sich anderenorts Muster à la Datenbankkontext, Repository, Service, Unit of Work, MVC und so weiter und so fort entwickelt. Nicht immer braucht man das volle Ballett, aber solche Aufgabentrennungen wurden ja auch nicht aus Langeweile erfunden.

dedlfix.