rxn
1.0.0
RXN (die Abkürzung für 'Reaktion') ist ein Gerüst, das die Komplexität und den Unruhen von PHP-generierten Ansichten ausgibt-Ansichten zu jedem Frontend, der zu Ihrer Phantasie geeignet ist.
Die Philosophie hinter RXN ist einfach: Strenge Backend / Frontend -Entkopplung .
Einschließlich geplanter Funktionen für Beta (ungeprüft):
RXN wird im Rahmen der zulässigen und kostenlosen MIT -Lizenz veröffentlicht.
RXN verwendet eine Namespacing -Struktur, die explizit mit der Verzeichnisstruktur der Klassendateien übereinstimmt. Obwohl es auch bequem ist, wird es hauptsächlich verwendet, um einige ziemlich coole Autoloadfunktionen zu implementieren.
Sagen Sie beispielsweise, dass Sie eine Klasse namens OrganizationProductModelMyAwesomeModel erstellt haben. Fügen Sie einfach die Datei in eine Verzeichnisstruktur ein, die der Namespace Convention folgt (z. B. {root}/organization/product/model/MyAwesomeModel.php ). Wenn Sie die Klasse anrufen müssen, rufen Sie einfach die Klasse auf, indem Sie sie direkt anrufen. Es ist nicht nötig, eine require irgendwo zu fordern.
Vor (Autolading nicht verwenden):
<?php
require_once ( ' /organization/product/model/MyAwesomeModel.php ' );
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created!Nach (mit autoloading):
<?php
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created! Das gleiche Muster existiert für die nativen Klassen von RXN. Beispielsweise wird die Antwortklasse ( RxnFrameworkHttpResponse ) im Verzeichnis {root}/rxn/api/controller gefunden. Autolading ist eine der vielen Möglichkeiten, wie RXN den Overhead reduziert.
Die folgenden Dateiverlängerungen werden durch die Autoloading -Funktion unterstützt (Sie können auch benutzerdefinierte Erweiterungen in RxnFrameworkConfig definieren):
RXN lebt, atmet und isst Ausnahmen. Betrachten Sie den folgenden Code -Snippet:
try {
$ result = $ databse -> query ( $ sql , $ bindings );
} catch ( PDOException $ exception ) {
throw new Exception ( " Something went terribly wrong! " , 422 );
} Wenn Sie eine Exception irgendwo in die Anwendung werfen, endet RXN selbst, rollen Sie in den Datenbank-Transaktionen zurück und reagieren Sie dann mit JSON anmutig:
{
"_rxn" : {
"success" : false ,
"code" : 422 ,
"result" : "Unprocessable Entity" ,
"message" : "Something went terribly wrong!" ,
//...
}
} Ein Beispiel -API -Endpunkt für Ihr Backend mit RXN könnte so aussehen:
https://yourapp.tld/v2.1/order/doSomething
Wo:
v2.1 ist die versionorder ist der controllerdoSomething ist die action des Controllers (eine öffentliche Methode) Wenn Sie nun der Anfrage ein GET-Schlüsselwertpaar hinzufügen möchten, wobei id = 1234 , würden Sie dies normalerweise in PHP tun:
VOR:
https://yourapp.tld/v2.1/order/someAction?id=1234
In RXN können Sie dies vereinfachen, indem Sie den Schlüssel und den Wert in die URL mit dem Vorwärts -Schrägstrich ( / ) als Trennzeichen wie SO einstellen:
NACH:
https://yourapp.tld/v2.1/order/someAction/id/1234
Eine ungerade Anzahl von Parametern nach der version , controller und action würde zu einem Fehler führen.
Wenn Sie Ihre Endpunkt -URLs (z. B. v1.1 , v2.4 usw.) versionieren, können Sie sich leicht ausruhen, wenn Sie wissen, dass Sie Ihr Frontend nicht versehentlich brechen, wenn Sie das Backend -Endpunktverhalten ändern. Darüber hinaus hilft die Versionierung auch dabei, Ihre Dokumentation in Ordnung zu halten. Frontend -Entwickler können sich nur für die Dokumentation aufbauen und alles funktioniert einfach .
Für einen Endpunkt mit Version v2.1 ist die erste Nummer ( 2 ) die Controller -Version , und die zweite Nummer ( 1 ) ist die Aktionsversion . Das folgende Beispiel ist, wie wir Controller Version 2 mit Action Version 1 deklarieren würden:
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}Dies ermöglicht eine Dokumentation für die Wartbarkeit, die wahre zu Realität, die sowohl Frontend- als auch Backend-Entwickler hinter sich lassen können.
Möchten Sie mit Ihrer neu gestatteten Backend -Architektur experimentieren und erkunden? Kein Problem, solange Sie ein Datenbankschema haben, haben Sie eine Reihe von Gerüst -APIs zum Spielzeug! Gerüstendpunkte werden mit URIs zugegriffen, die dem folgenden ähnlich sind (beachten Sie die api anstelle der Versionsnummer):
https://yourapp.tld/api/order/create
https://yourapp.tld/api/order/read/id/{id}
https://yourapp.tld/api/order/update/id/{id}
https://yourapp.tld/api/order/delete/id/{id}
https://yourapp.tld/api/order/search
Gerüst-APIs sind version ohne APIs und sind so konzipiert, dass Frontend-Entwickler den vollen Zugriff auf das Backend in Form von Operationen und Suchungen für Erstellen, Lesen, Update und Löschen (CRUD) ermöglichen. Ihr Hauptvorteil besteht darin, dass Sie in den frühen Phasen der Anwendungsentwicklung nicht viel Zeit damit verbringen müssen, CRUD -Endpunkte manuell zu erstellen. (Wie es diese frühen Entwicklungsphasen sind, wenn sich die Anforderungen ändern, und die Dinge ständig im Fluss sind.)
WARNUNG: Da Gerüst-APIs versionsfrei sind, ernen sie alle Probleme, die mit Versionen ohne Versionen verbunden sind. Sobald das Backend geändert wird, werden auch diese APIs verändert. Dies kann möglicherweise eine Anwendung auf unerwartete oder verborgene Weise brechen. Aus diesem Grund ist es ratsam, die Versionslosen -APIs zu versionierten APIs zu wechseln, da sich der Entwicklungsprozess kurz vor dem Abschluss nähert.
Während die meisten Menschen irgendeine Form der Abhängigkeitsinjektion praktizieren, ohne darüber nachzudenken, kann es ein ziemlich großer Aufwand sein, manuell zu instanziieren und zu injizieren, wie Klassen mit vielen Abhängigkeiten injiziert werden. Die folgenden Beispiele sollten dazu beitragen, den Nutzen einer automatischen Abhängigkeitsinjektion über den Behälterbehälter zu demonstrieren.
Vor (Handbuch DI):
// instantiate the dependencies
$ config = new Config ();
$ database = new Database ( $ config );
$ registry = new Registry ( $ config , $ database );
$ filecache = new Filecache ( $ config );
$ map = new Map ( $ registry , $ database , $ filecache );
// call the action method
$ this -> doSomething_v1 ( $ registry , $ database , $ map );
public function doSomething_v1 ( Registry $ registry , Database $ database , Map $ map ) {
$ customer = new Customer ( $ registry , $ database , $ map );
//...
}Nach (unter Verwendung des DI -Behälterbehälters):
// call the action method
$ this -> doSomething_v1 ( $ app -> container );
public function doSomething_v1 ( Container $ container ) {
$ customer = $ container -> get (Customer::class);
//...
}Hoffentlich können Sie die Vorteile sehen. Bei RXN müssen die Voraussetzungen nicht jedes Mal instanziiert werden! Verwenden Sie den Containerbehälter, um Ihr Leben zu erleichtern.
TypeHint die Klasse, die Sie als Parameter benötigen, und der DI -Container -Container erraten alle Abhängigkeiten für Sie und laden automatisch und injizieren sie. Kein unordentliches erfordert. Sie müssen die Abhängigkeiten nicht manuell injizieren!
Vor (manuelle Instanziierung):
// require the dependencies
require_once ( ' /path/to/Config.php ' );
require_once ( ' /path/to/Collector.php ' );
require_once ( ' /path/to/Request.php ' );
public function doSomething_v1 () {
// instantiate the dependencies
$ config = new Config ();
$ collector = new Collector ( $ config );
$ request = new Request ( $ collector , $ config );
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}Nach (automatische Instanziierung und Injektion):
public function doSomething_v1 ( Request $ request ) {
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}Den Unterschied sehen?
