rxn
1.0.0
RXN (la abreviatura de 'reacción') es un marco diseñado para eliminar la complejidad y el desorden de las vistas generadas por PHP, descargando vistas a cualquier interfaz que se adapte a su fantasía.
La filosofía detrás de RXN es simple: estricto backend / desacoplamiento de frontend .
Incluyendo características planificadas para beta (sin control):
RXN se publica bajo la licencia MIT permisiva y gratuita.
RXN utiliza una estructura de composición de nombres que coincide explícitamente con la estructura del directorio de los archivos de clase. Si bien también es conveniente, se utiliza principalmente para implementar algunas características de autoinforme bastante geniales.
Digamos, por ejemplo, que creó una clase llamada OrganizationProductModelMyAwesomeModel . Simplemente coloque el archivo en una estructura de directorio que sigue la convención del espacio de nombres (por ejemplo, {root}/organization/product/model/MyAwesomeModel.php ). Cuando necesite llamar a la clase, simplemente invoque la clase llamándola directamente. No hay necesidad de poner una require en ningún lado.
Antes (no usar auto -mayor):
<?php
require_once ( ' /organization/product/model/MyAwesomeModel.php ' );
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created!Después de (usando auto -cola):
<?php
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created! El mismo patrón existe para las clases nativas de RXN. Por ejemplo, la clase de respuesta ( RxnFrameworkHttpResponse ) se encuentra en el directorio {root}/rxn/api/controller . La autolaading es una de las muchas formas en que RXN reduce la sobrecarga.
Las siguientes extensiones de archivos son compatibles con la función de autoinforme (también puede definir extensiones personalizadas en RxnFrameworkConfig ):
RXN vive, respira y come excepciones. Considere el siguiente fragmento de código:
try {
$ result = $ databse -> query ( $ sql , $ bindings );
} catch ( PDOException $ exception ) {
throw new Exception ( " Something went terribly wrong! " , 422 );
} Si lanza una Exception en cualquier lugar de la aplicación, RXN se auto terminará, retrocede cualquier transacción de base de datos en proceso y luego responda con gracia usando JSON:
{
"_rxn" : {
"success" : false ,
"code" : 422 ,
"result" : "Unprocessable Entity" ,
"message" : "Something went terribly wrong!" ,
//...
}
} Un punto final API de ejemplo para su backend con RXN podría verse así:
https://yourapp.tld/v2.1/order/doSomething
Dónde:
v2.1 es la version de punto finalorder es el controllerdoSomething es la action del controlador (un método público) Ahora, si quisiera agregar un par de valores de clave GET a la solicitud donde id = 1234 , en PHP normalmente haría esto:
ANTES:
https://yourapp.tld/v2.1/order/someAction?id=1234
En RXN, puede simplificar esto colocando la clave y el valor en la URL utilizando la barra de avance ( / ) como el separador, como así:
DESPUÉS:
https://yourapp.tld/v2.1/order/someAction/id/1234
Un número impar de parámetros después de la version , controller y action daría como resultado un error.
Al versificar sus URL de punto final (por ejemplo, v1.1 , v2.4 , etc.), puede descansar tranquilo sabiendo que no va a romper accidentalmente su interfaz cada vez que altere el comportamiento de punto final de backend. Además, los versiones también ayuda a mantener su documentación en orden; Los desarrolladores frontend pueden simplemente construir la documentación y todo funcionará .
Entonces, para un punto final con la versión v2.1 , el primer número ( 2 ) es la versión del controlador , y el segundo número ( 1 ) es la versión de acción . El ejemplo a continuación es cómo declararíamos el controlador versión 2 con Action versión 1 :
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}Esto permite la documentación mantenible y realizada que tanto frontend y los desarrolladores de backend pueden respaldar.
¿Quieres experimentar y explorar con tu arquitectura de backend novedoso? No hay problema, siempre que tenga un esquema de base de datos, ¡tiene un conjunto de API de andamios para jugar! Se accede a los puntos finales de andamios utilizando URI que son similares a los siguientes (tenga en cuenta la api en lugar del número de versión):
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
Las API de andamio son API sin versión, y están diseñadas para permitir a los desarrolladores frontends el acceso completo al backend en forma de operaciones y búsquedas de creación, lectura, actualización y eliminación (CRUD). Su principal beneficio es que no tiene que pasar un montón de tiempo elaborando los puntos finales de Crud durante las primeras fases del desarrollo de aplicaciones. (Como son estas primeras fases del desarrollo cuando los requisitos están cambiando, y las cosas están constantemente en flujo).
ADVERTENCIA: Debido a que las API de andamio no tienen versión, heredan todos los problemas asociados con las API sin versión. Tan pronto como se altera el backend, estas API también se alteran; Esto puede romper una aplicación de manera inesperada o oculta. Por esta razón, es aconsejable transición API sin versión a API versionadas a medida que el proceso de desarrollo se acerca a la finalización.
Si bien la mayoría de las personas practican alguna forma de inyección de dependencia sin siquiera pensar en ello, el hecho es que instanciando e inyectar clases manualmente con muchas dependencias puede ser una molestia bastante grande. Los siguientes ejemplos deben ayudar a demostrar el beneficio de la inyección de dependencia automática a través del contenedor.
Antes (manual 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 );
//...
}Después de (usando el contenedor DI):
// call the action method
$ this -> doSomething_v1 ( $ app -> container );
public function doSomething_v1 ( Container $ container ) {
$ customer = $ container -> get (Customer::class);
//...
}Ojalá pueda ver los beneficios. ¡Con RXN, no hay necesidad de instanciar los requisitos previos cada vez! Use el contenedor de contenedor para facilitar su vida.
Simplemente escriba la clase que necesita como parámetro y POOF , el contenedor DI contenedor adivinará todas las dependencias para usted y las cargará automáticamente y las inyectará. Ningún desordenado requiere. ¡No tienes que inyectar las dependencias manualmente!
Antes (instanciación manual):
// 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 ' );
//...
}Después (instanciación e inyección automática):
public function doSomething_v1 ( Request $ request ) {
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}¿Ves la diferencia?
