eigene MySQLi-Klasse verschiedene Verbindungen

[Günni]

Die abstrakte Klasse ist hier nichts weiter als ein Interface. Warum also nicht gleich ein richtiges Interface verwenden?

Wie würde das aussehen? Also mit einer abstrakten Klasse scheint das ja wohl zu gehen.

[hellbringer]

Wie würde das aussehen? Also mit einer abstrakten Klasse scheint das ja wohl zu gehen.

Die abstrakte Klasse trägt aber auch nichts dazu bei. Die ist hier nur Zierwerk. Lässt man sie weg, geht der Code 1:1 genauso.

[jspit]

Das ganze Thema löst sich halt in Luft auf wenn man bspw. PHP-DI mit Autowiring einsetzt. Ich konfiguriere an zentraler Stelle welche Implementierungen & Instanzen injiziert werden sollen. Dabei spielt es auch überhaupt keine Rolle wie tief die Abhängigkeiten verschachteln sind. Auf statische Aufrufe verzichte ich vollständig. Typischer Aufbau (simplifiziert):

// demo controller
class Controller{
public function __construct(UserRepositoryInterface $users){ .. }

public function selectById(int $id): User{
return $this->users->selectById($id);
}
}

// demo repository interface
interface UserRepositoryInterface{
function selectById(int $id): User;
}

// demo repository implementation
class PdoUserRepository implements UserRepositoryInterface{
public function __construct(PDO $pdo){ .. }

public function selectById(int $id): User{
return $this->pdo->query(..);
}
}

// di config
$config = [
UserRepositoryInterface::class => PdoUserRepository::class,
PDO::class => \DI\object()->constructor($dsn, $user, $pass, $opts),
];

// di usage
$controller = $container->get(Controller::class);
$result = $container->call([$controller, 'selectById'], ['id' => 123]); 

Verstehe nur Bahnhof was di usage betrifft.
Liefert $container->get(Controller::class); eine Instanz der class Controller ?
Sehe auch nicht den Zusammenhang wie der Container zu der Controller-Klasse kommen soll.
Und wo kommt $container her?

Dies hier hat nicht mehr viel mit den Fragen im Startbeitrag zu tun. Ich glaube es ist besser, wenn ich einen neuen Thread aufmache !?

[rkr]

Verstehe nur Bahnhof was di usage betrifft.
Liefert $container->get(Controller::class); eine Instanz der class Controller ?

Ja. Wichtig um das Konzept eines DICs zu verstehen, ist, dass du so einen Aufruf pro Scriptaufruf normal höchstens 1mal brauchst - im Bootstrap (index.php oder so).

Alle Abhängigkeiten, die "Controller" in seinem Constructor führt, werden automatisch aufgelöst. Und die Abhängigkeiten der Abhängigkeiten genau so. In den meisten Fällen ohne weitere Konfiguration (autowiring nennt sich das dann). Wenn der DIC den Kandidaten nicht erraten kann, muss er in einer Konfiguration beschrieben werden. Beispielsweise dann, wenn ein Interface oder eine Abstrakte Klasse als Typehint aufgeführt sind (Interface => KonkreteKlasse).

[jspit]

Ich hab das DIC Konzept schon im groben verstanden. Es ist jedoch bei mir mehr die Ausnahme das mir im Bootstrap schon bekannt ist welche Klassen ich brauche geschweige das ich deren Abhängigkeiten kenne.
Was wann gemacht werden soll und womit legt der Nutzer mit einen Konfigurationsskript fest dessen Resultat letztlich in der DB landet. Welche Klassen benötigt werden und mit welchen Abhängigkeiten ist nicht allein von der Konfiguration abhängig, sondern das ergibt sich teilweise erst bei Abarbeitung des Jobs selbst in einer tieferen Ebene.

[rkr]

Ohne genauere Kenntnis von deiner Umgebung zu haben würde ich glatt behaupten, dass das geht.

Ich habe hier zum Teil auch ein dynamisches Setup. Du kannst einen DIC druchaus auch in Factories und Plugin-Dispatchern verwenden. Mache ich auch so.

In einem Projekt verwende ich Slim für das Routing. Da habe ich dann eine kleine Hilfsfunktion, die de DIC ins Spiel bringt:

$app->get('/login', dic([LoginCtrl::class, 'login']));
$app->get('/login/{username}', dic([LoginCtrl::class, 'login']));
$app->post('/login', dic([LoginCtrl::class, 'login'])); 

Bei Plugins funktioniert das bei mir ähnlich. Irgendwo registriere ich, welche Plugins es für welche Art von Call geben kann:

$plugins->register('index/before-start', [Security::class, 'check']) 

Die Plugins haben einen Constructor, mit dem sie ihre Abhängigkeiten frei definieren können und Methoden, deren Parameter automatisch mit gleichnamigen Parametern aus dem ursprünglichen fire-Call befüllt werden:

$plugins->fire('index/before-start', ['requestUri' => $requestUri]) 

class Security {
    /* ... */

    public function __construct(Database $db) {
        $this->db = $db;
    }

    public function check(string $requestUri) {
        /* ... */
    }
} 

Die Konfiguration des DIC ist das eigentliche Thema. PHP-DI hat sogenannte Factories. Da kannst du beliebigen PHP-Code für die Erzeugung der Kandidaten verwenden und auch wieder auf andere, durch den DIC-Erzeugte Instanzen zugreifen.

Und du kannst in eigenen Factories den DIC nutzen, um ständig neue Instanzen einer Entität zu erzeugen, wenn eine Klasse nicht als Singleton im Kontext eines DICs verwendet werden soll.

class MyFactory {
    /** @var Container */
    private $dic;

    /**
     * @param Container $dic
     */
    public function __construct(Container $dic) {
        $this->dic = $dic;
    }

    /**
     * @param array $data
     * @return MyInterface
     */
    public function create(array $data) {
        return $this->dic->make(MyInterface::class, $data);
    }
} 

Dadurch kann die resultierende Instanz von MyInterface eigene Abhängigkeiten haben, von denen die Factory nichts weiß. Die Factory kann diese Parameter aber noch mal wieder erweitern.

[jspit]

rkr : Muss ich mir mal in Ruhe reinzehen. Danke schon mal.

Ohne genauere Kenntnis von deiner Umgebung zu haben würde ich glatt behaupten, dass das geht.

Knackpunkt ist das ich PHP-DI auf meine Zielplattform nicht verfügbar habe.
Die Zielplattform ist ein Embedded System grob vergleichbar mit dem bekannten Raspberry Pi.
Da versuche ich erst gar nicht PHP-DI zu installieren.

Dummerweise läuft mein Thema jetzt zweigleisig, werde deshalb hier
https://www.php.de/forum/webentwickl...bankverbindung
darauf antworten.

[rkr]

Naja, wenn du keine externen Komponenten einbinden kannst, dann ist das eben so.

Theoretisch macht PHP-DI nichts anderes, als den Constructor via Reflection zu analysieren und zu schauen, ob es die Klassen automatisch oder auf Basis seiner Konfiguration erzeugen kann - sonst Exception.