Ankündigung

Einklappen
Keine Ankündigung bisher.

Silex / ServiceProvider Konzept

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • #61
    @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:

    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.
    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.

    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;
        } 
    // $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:

    PHP-Code:
    $name1 "Peter";
    $name1 "Jack";
    $app->register(new HalloService, array('hello.name' => $name1));
    $app->register(new HelloService, array('hallo.name' => $name2)); 
    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:

    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.
    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
    -

    Kommentar


    • #62
      Wenn man seinen Parametern ordentliche Namen gibt, dann werden sie nicht überschrieben, ausser es war gewollt.

      Kommentar


      • #63
        Wenn man seinen Parametern ordentliche Namen gibt, dann werden sie nicht überschrieben, ausser es war gewollt.
        Die meisten Unfälle passieren ja nicht weil sie gewollt sind.

        https://github.com/kzykhys/doctrine-...ceProvider.php

        https://github.com/colindecarlo/sile...ceProvider.php

        https://github.com/palmasev/Doctrine...ceProvider.php

        https://github.com/umpirsky/Doctrine...ceProvider.php

        https://github.com/romainneutron/Mon...ceProvider.php

        Und das ist erst der Anfang - schätzte ich.

        Wahrscheinlich hast Du aber recht, bevor man sich die Mühe macht das alles zu prüfen (und damit meine ich nicht die Services selbst, sondern inwieweit sich diese möglicherweise gegenseitig beeinflussen), ist man wahrscheinlich schneller wenn man alles selber schreibt.

        vg
        jack
        -

        Kommentar


        • #64
          Also jetzt ist Silex schuld, weil diese Leute nicht ihren Namen noch vor "orm" schreiben können?

          Kommentar


          • #65
            Lauf Banane, lauf. Die Kirschen umrunden dich schon.
            [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

            Kommentar


            • #66
              oder statt irgendwelche Service provider zu setzen, benutzt du packagist und schaust dort dir die packages an die viele downloads haben

              https://packagist.org/search/?q=silex%20orm

              https://github.com/dflydev/dflydev-d...ceProvider.php

              hier zb
              apt-get install npm -> npm install -g bower -> bower install <package> YOLO [URL]https://www.paypal.me/BlackScorp[/URL] | Mein Youtube PHP Kanal: [url]https://www.youtube.com/c/VitalijMik[/url]

              Kommentar


              • #67
                Hmm.. so langsam dämmerts mir wieso das so schwierig ist für dich den Container zu verschließen.. Du nutzt Silex 1.2. Die aktuelle Version von Pimple kann container entities einfrieren und tut dies auch bei erster benutzung, was die dependency von Silex 1.2 nicht kann..

                Das aber nur so nebenbei.
                [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

                Kommentar

                Lädt...
                X