Ankündigung

Einklappen
Keine Ankündigung bisher.

PSR Standard benutzen jedoch mit zusätzlichen öffentlichen Methoden.

Einklappen

Neue Werbung 2019

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

  • PSR Standard benutzen jedoch mit zusätzlichen öffentlichen Methoden.

    Hallo zusammen

    Ich möchte gerne den Psr Standard für mein Projekt benutzen. Jedoch scheint dies gar nicht so einfach zu sein, wenn ich z.B beim Response selber noch zusätzliche öffentliche Methoden definieren möchte. Denn wenn man ja nun die Implentation mit einer anderen Psr-7 tauglichen Library austauschen würde, hätte man ja da nicht die selbstdefinereten Methoden, somit wäre der Sinn von einem Interface eigentlich nicht gegeben, oder irre ich mich?

    Slim z.B definiert ja auch noch eigene Methoden wie $response->isRedirect() und implentiert das Psr-7 interface. Würde man jedoch eine andere PSR-7 Library nehmen, bekäme ja man auch Probleme. Somit wäre der Sinn vom Interface ja auch nicht gegeben.

    Oder schaut man Monolog an, dort wird ja auch noch eigene Methoden wie setHandlers() definiert und implementiert das Psr3 interface. Hier ist es natürlich nicht gravierend, da man ja zum Loggen nur die im Interface definierten Methoden verwendet und setHandlers() im booting macht.


    So wie kann man den Psr-7 benutzen, jedoch aber mit eigenen Methoden? Müsste man das Apdapter Pattern anwenden um die zusätzlichen Methoden zu integrieren.
    Wäre jedoch auch nicht optimal, man könnte dann nicht so einfach seine "Services" in einer anderen Library benutzen.

    Wie löst Ihr den sowas? Oder mache ich da einen Denkfehler? Besten dank im voraus für Eure Hilfestellung.

  • #2
    So wie kann man den Psr-7 benutzen, jedoch aber mit eigenen Methoden?
    Du erweiterst das PSR-7 Interface. Allerdings wird wohl kaum jemand (außer dir) eine Implementierung dazu schreiben wollen

    Kommentar


    • #3
      Hey Danke Dir Dormilich für die Antwort. Das mit dem erweitern wäre mir schon klar.

      Nehmen wir an ich habe ein Projekt mit SLIM gemacht und deren Response/Request z.B. in den Controllern verwendet. 2 Jahre später implemetiere ich aber ein anderes PSR-7 Library. Dann würde es ziemlich sicher Fehler geben, weil ja Slims Response/Request
      noch andere Methoden zur Verfügung stellt, die warscheinlich in der anderen Library nicht sind. Deshalb ist ja eigentlich der Sinn vom Interface nicht gegeben.

      Kommentar


      • #4
        Wenn du soweit bist, dass du bei Slim eine eigene Request/Response-Implementierung benutzt (nicht dass ich wüßte, ob das überhaupt geht), ist das alles nicht mehr relevant (weil du dann eh die Kontrolle über alles hast).

        Deshalb ist ja eigentlich der Sinn vom Interface nicht gegeben.
        Deswegen nimmt man ja auch das PSR-7 Interface, weil das alle kennen.

        Kommentar


        • #5
          Ok danke Dir vielmals für deine Zeit, das schätze ich sehr

          Kommentar


          • #6
            Zitat von strub Beitrag anzeigen
            Hey Danke Dir Dormilich für die Antwort. Das mit dem erweitern wäre mir schon klar.

            Nehmen wir an ich habe ein Projekt mit SLIM gemacht und deren Response/Request z.B. in den Controllern verwendet. 2 Jahre später implemetiere ich aber ein anderes PSR-7 Library. Dann würde es ziemlich sicher Fehler geben, weil ja Slims Response/Request
            noch andere Methoden zur Verfügung stellt, die warscheinlich in der anderen Library nicht sind. Deshalb ist ja eigentlich der Sinn vom Interface nicht gegeben.
            Eine eigene Request oder Response Implementierung hindert dich ja nicht daran innerhalb deiner Middlewares weiterhin gegen ServerRequestInterface und ResponseInterface zu entwickeln. Falls du - aus welchem Grund auch immer - auf Methoden dieser eigenen Implementierung innerhalb der Middlewares zugreifen willst / musst, spezialisieren sich deine Abhängigkeiten und du musst gegen eine konkrete Implementierung entwickeln. Ich würde daher versuchen innerhalb der Middlewares immer nur gegen die PSR-Interfaces zu entwickeln. Falls du dort Zugriff auf spezielle Funktionalitäten brauchst, kannst du diese aber auch über Constructor Injection reinschieben.

            Beispiel:

            PHP-Code:
            /** Request implementation */
            class MyFunkyRequest implements ServerRequestInterface{
              
            // [implement ServerRequestInterface]

              
            public function myCustomMethod(){
                
            // ..
              
            }
            }

            /** Middleware implementation */
            class SomeMiddleware implements MiddlewareInterface{
              public function 
            __construct(CacheInterface $cache){
                
            $this->cache $cache;
              }

              public function 
            handle(ServerRequestInterface $request, callable $next): ResponseInterface{
                
            // use $this->cache
                
            return $next($request);
              }
            }


            /** Usage */
            $request = new MyFunkyRequest(..);
            $request->myCustomMethod(..);
            $cache = new MyCacheImpl():

            $middlewareStack->add(new SomeMiddleware($cache));
            $response $middlewareStack->handle($request); 
            [SIZE="1"]Atwood's Law: any application that can be written in JavaScript, will eventually be written in JavaScript.[/SIZE]

            Kommentar

            Lädt...
            X