rxn
1.0.0
RXN (l'abréviation de «réaction») est un cadre conçu pour découper la complexité et l'encombrement des vues générées par PHP - déchargeant les vues sur tout frontend qui convient à votre fantaisie.
La philosophie derrière Rxn est simple: découplage strict backend / frontend .
Y compris les fonctionnalités planifiées pour la version bêta (sans contrôle):
RXN est libéré sous la licence MIT permissive et gratuite.
RXN utilise une structure d'espacement de noms qui correspond explicitement à la structure du répertoire des fichiers de classe. Bien qu'il soit également pratique, il est principalement utilisé pour implémenter des fonctionnalités de mise à jour assez cool.
Dites, par exemple, que vous avez créé une classe nommée OrganizationProductModelMyAwesomeModel . Il suffit de mettre le fichier dans une structure de répertoire qui suit la convention d'espace de noms (par exemple, {root}/organization/product/model/MyAwesomeModel.php ). Lorsque vous devez appeler la classe, appelez simplement la classe en l'appelant directement. Il n'est pas nécessaire de mettre un require nulle part.
Avant (n'utilisant pas la mise au point automatique):
<?php
require_once ( ' /organization/product/model/MyAwesomeModel.php ' );
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created!Après (en utilisant le mise au point automatique):
<?php
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created! Le même modèle existe pour les classes natives de RXN. Par exemple, la classe de réponse ( RxnFrameworkHttpResponse ) se trouve dans le répertoire {root}/rxn/api/controller . L'auto-ovrage est l'une des nombreuses façons dont le RXN réduit les frais généraux.
Les extensions de fichier suivantes sont prises en charge par la fonction de mise en état de mise en scène (vous pouvez également définir des extensions personnalisées dans RxnFrameworkConfig ):
Rxn vit, respire et mange des exceptions. Considérez l'extrait de code suivant:
try {
$ result = $ databse -> query ( $ sql , $ bindings );
} catch ( PDOException $ exception ) {
throw new Exception ( " Something went terribly wrong! " , 422 );
} Si vous lancez une Exception partout dans l'application, RXN s'auto-terminer, annulera toutes les transactions de base de données en cours, puis répondra gracieusement à l'aide de JSON:
{
"_rxn" : {
"success" : false ,
"code" : 422 ,
"result" : "Unprocessable Entity" ,
"message" : "Something went terribly wrong!" ,
//...
}
} Un exemple de point de terminaison de l'API pour votre backend avec RXN peut ressembler à ceci:
https://yourapp.tld/v2.1/order/doSomething
Où:
v2.1 est la version de point finalorder est le controllerdoSomething est l' action du contrôleur (une méthode publique) Maintenant, si vous vouliez ajouter une paire de valeurs de clé Get à la demande où id = 1234 , en php, vous le feriez normalement:
AVANT:
https://yourapp.tld/v2.1/order/someAction?id=1234
Dans RXN, vous pouvez simplifier cela en mettant la clé et la valeur dans l'URL en utilisant la barre oblique avant ( / ) comme séparateur, comme ainsi:
APRÈS:
https://yourapp.tld/v2.1/order/someAction/id/1234
Un nombre impair de paramètres après la version , controller et action entraîneraient une erreur.
En versant vos URL de point de terminaison (par exemple, v1.1 , v2.4 , etc.), vous pouvez vous reposer facilement en sachant que vous n'allez pas casser accidentellement votre frontend chaque fois que vous modifiez le comportement de point de terminaison. De plus, le versioning aide également à conserver votre documentation dans l'ordre; Les développeurs de frontend peuvent simplement construire dans la documentation et tout fonctionnera .
Donc, pour un point de terminaison avec la version v2.1 , le premier numéro ( 2 ) est la version contrôleur , et le deuxième numéro ( 1 ) est la version d'action . L'exemple ci-dessous est la façon dont nous déclarerions la version 2 du contrôleur avec Action version 1 :
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}Cela permet une documentation maintenable et vraie à la réalité que les développeurs frontend et backend peuvent prendre en retard.
Vous voulez expérimenter et explorer avec votre nouvelle architecture backend? Pas de problème, tant que vous avez un schéma de base de données, vous avez une suite d'API d'échafaudage avec qui jouer! Les points de terminaison d'échafaudage sont accessibles à l'aide d'URI similaires à ce qui suit (notez l' api au lieu du numéro de version):
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
Les API d'échafaudage sont des API sans version et sont conçues pour permettre aux développeurs de frontend un accès complet au backend sous la forme d'opérations et de recherches de création, de lecture, de mise à jour et de suppression (CRUD). Leur principal avantage est que vous n'avez pas à passer une tonne de temps à fabriquer manuellement les points de terminaison CRUD au cours des premières phases du développement des applications. (Comme ce sont ces premières phases de développement lorsque les exigences changent, et les choses sont constamment en évolution.)
AVERTISSEMENT: Parce que les API d'échafaudage sont sans version, elles inhérent tous les problèmes associés aux API sans version. Dès que le backend est modifié, ces API sont également modifiées; Cela peut potentiellement rompre une application de manière inattendue ou cachée. Pour cette raison, il est sage de transmettre des API sans version vers des API versées à mesure que le processus de développement se termine.
Alors que la plupart des gens pratiquent une forme d'injection de dépendance sans même y penser, le fait est que l'instanciation et l'injection manuels des classes avec beaucoup de dépendances peuvent être assez gros. Les exemples suivants devraient aider à démontrer l'avantage d'une injection de dépendance automatique via le conteneur du conteneur.
Avant (manuel 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 );
//...
}Après (en utilisant le conteneur de conteneur DI):
// call the action method
$ this -> doSomething_v1 ( $ app -> container );
public function doSomething_v1 ( Container $ container ) {
$ customer = $ container -> get (Customer::class);
//...
}J'espère que vous pourrez voir les avantages. Avec RXN, il n'est pas nécessaire d'instancier les conditions préalables à chaque fois! Utilisez le conteneur conteneur pour vous faciliter la vie.
Tapez simplement la classe dont vous avez besoin en tant que paramètre, et POOF , le conteneur du conteneur DI devinera toutes les dépendances pour vous et les chargera automatiquement et les injectera. Aucun désordre ne nécessite. Vous n'avez pas à injecter les dépendances manuellement!
Avant (instanciation manuelle):
// 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 ' );
//...
}Après (instanciation automatique et injection):
public function doSomething_v1 ( Request $ request ) {
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}Voir la différence?
