@mYkon
Ich gebe Dir in allem Recht was Du sagt, das ist alles richtig. Aber das ist nicht ganz das was ich mit diesen Aussage gemeint habe:
Natürlich wird es Exception geben wenn ein Service gelöscht wird oder ein Interface nicht erfüllt wird. Selbst ohne Typehints wird ein Aufruf wie $logger->getXYZ() wahrscheinlich zu einer Exception führen.
Ein ServiceProvider ist nichts anderes als ein Konfigurationsobjekt für einen bestimmten Service. Bei Silex konfiguriert der ServiceProvider allerdings nicht nur sich selbst sondern auch noch die gesamte Applikation mit dazu.
// $this ist die Applikation!
Ein ServiceProvider legt seine Konfigurationsparameter – die nur für ihn selbst bestimmt sind - im Namensraum der Applikation ab, also in einem anderen Objekt ab und bestimmt sogar selbst unter welchem Namen er sich als Service in der Applikation einträgt. Es ist ein bisschen so, als ob man jedem Lieferanten immer den Generalschlüssel geben würde.
Ob bereits vorhandene Parameter/Services dabei geändert oder überschrieben werden wird nicht geprüft.
Fehler wie diese:
Können sehr schwer zu finden sein, weil Sie sich im schlimmsten Falle eben nicht durch eine Execption bemerkbar machen. Das habe ich bereits auch schon geschrieben:
Damit sind Fehler gemeint, die eben nicht sofort auffallen – die einen so richtig ärgern können.
Man braucht einen ServiceProvider nur zu registrieren – noch nicht mal zu benutzen - um die ganze Anwendung schlimmstenfalls in einen inkonsistenten Zustand zu bringen.
Das ist meiner Ansicht nach kein gutes Konzept für eine robuste Softwarearchitektur.
vg
jack
Ich gebe Dir in allem Recht was Du sagt, das ist alles richtig. Aber das ist nicht ganz das was ich mit diesen Aussage gemeint habe:
Alles an Parametern wird einfach in den globalen Namensraum des Applikations-Containers rein geklatscht.
Es ist von überall und jederzeit problemlos möglich nicht nur die Services zu ändern oder komplett zu überschreiben, sondern auch jeden internen ServiceParameter zu manipulieren.
Ein ServiceProvider ist nichts anderes als ein Konfigurationsobjekt für einen bestimmten Service. Bei Silex konfiguriert der ServiceProvider allerdings nicht nur sich selbst sondern auch noch die gesamte Applikation mit dazu.
PHP-Code:
public function register(ServiceProviderInterface $provider, array $values = array())
{
$this->providers[] = $provider;
$provider->register($this);
foreach ($values as $key => $value) {
$this[$key] = $value;
}
return $this;
}
Ein ServiceProvider legt seine Konfigurationsparameter – die nur für ihn selbst bestimmt sind - im Namensraum der Applikation ab, also in einem anderen Objekt ab und bestimmt sogar selbst unter welchem Namen er sich als Service in der Applikation einträgt. Es ist ein bisschen so, als ob man jedem Lieferanten immer den Generalschlüssel geben würde.
Ob bereits vorhandene Parameter/Services dabei geändert oder überschrieben werden wird nicht geprüft.
Fehler wie diese:
PHP-Code:
$name1 = "Peter";
$name1 = "Jack";
$app->register(new HalloService, array('hello.name' => $name1));
$app->register(new HelloService, array('hallo.name' => $name2));
Einfache Vertippter innerhalb der ServiceProviders können ebenfalls leicht zu schwer lokalisierbaren Fehlern führen
Im schlimmsten Falle überschreibt er „nur“ (versehentlich oder auch nicht) irgendeinen Parameter von irgendeinem anderen Service.
Man braucht einen ServiceProvider nur zu registrieren – noch nicht mal zu benutzen - um die ganze Anwendung schlimmstenfalls in einen inkonsistenten Zustand zu bringen.
Das ist meiner Ansicht nach kein gutes Konzept für eine robuste Softwarearchitektur.
vg
jack
Kommentar