rxn
1.0.0
O RXN (a abreviação de 'reação') é uma estrutura projetada para cortar a complexidade e a desordem das vistas geradas pelo PHP-descarregando vistas para qualquer front-end que combina com sua fantasia.
A filosofia por trás do RXN é simples: rigorosa desacoplamento back -end / front -end .
Incluindo recursos planejados para beta (desmarcada):
O RXN é liberado sob a licença permissiva e gratuita do MIT.
O RXN usa uma estrutura de espaço para nome que corresponda explicitamente à estrutura do diretório dos arquivos de classe. Embora também seja conveniente, é usado principalmente para implementar alguns recursos de carga automática bem legais.
Digamos, por exemplo, que você criou uma classe chamada OrganizationProductModelMyAwesomeModel . Basta colocar o arquivo em uma estrutura de diretório que segue a convenção de namespace (por exemplo, {root}/organization/product/model/MyAwesomeModel.php ). Quando você precisar ligar para a classe, basta invocar a classe chamando -a diretamente. Não há necessidade de colocar uma require em qualquer lugar.
Antes (não usando o automobilismo):
<?php
require_once ( ' /organization/product/model/MyAwesomeModel.php ' );
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created!Depois (usando o automobilismo):
<?php
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created! O mesmo padrão existe para as classes nativas da RXN. Por exemplo, a classe Response ( RxnFrameworkHttpResponse ) é encontrada no diretório {root}/rxn/api/controller . O automobilismo é uma das muitas maneiras pelas quais o RXN reduz a sobrecarga.
As seguintes extensões de arquivo são suportadas pelo recurso de carga automática (você também pode definir extensões personalizadas em RxnFrameworkConfig ):
O RXN vive, respira e come exceções. Considere o seguinte snippet de código:
try {
$ result = $ databse -> query ( $ sql , $ bindings );
} catch ( PDOException $ exception ) {
throw new Exception ( " Something went terribly wrong! " , 422 );
} Se você lançar uma Exception em qualquer lugar do aplicativo, o RXN terá se terminado, reverte quaisquer transações de banco de dados em processo e responda graciosamente usando o JSON:
{
"_rxn" : {
"success" : false ,
"code" : 422 ,
"result" : "Unprocessable Entity" ,
"message" : "Something went terribly wrong!" ,
//...
}
} Um exemplo de endpoint da API para o seu back -end com o RXN pode ser assim:
https://yourapp.tld/v2.1/order/doSomething
Onde:
v2.1 é a version terminalorder é o controllerdoSomething é a action do controlador (um método público) Agora, se você quisesse adicionar um par de valores-chave à solicitação onde id = 1234 , no PHP, você normalmente faria isso:
ANTES:
https://yourapp.tld/v2.1/order/someAction?id=1234
No RXN, você pode simplificar isso colocando a chave e o valor no URL usando a barra para a frente ( / ) como o separador, assim:
DEPOIS:
https://yourapp.tld/v2.1/order/someAction/id/1234
Um número ímpar de parâmetros após a version , controller e action resultaria em um erro.
Ao fazer uma versão dos URLs do ponto de extremidade (por exemplo, v1.1 , v2.4 , etc), você pode ficar tranquilo sabendo que não vai quebrar acidentalmente seu front -end sempre que alterar o comportamento do terminal de back -end. Além disso, o versão também ajuda a manter sua documentação em ordem; Os desenvolvedores de front -end podem apenas construir para a documentação e tudo funcionará .
Portanto, para um endpoint com a versão v2.1 , o primeiro número ( 2 ) é a versão do controlador e o segundo número ( 1 ) é a versão de ação . O exemplo abaixo é como declararíamos o controlador versão 2 com a ação da ação 1 :
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}Isso permite uma documentação sustentável e realidade que os desenvolvedores de front-end e back-end podem ficar para trás.
Deseja experimentar e explorar com sua arquitetura de back -end recém -realizada? Não tem problema, desde que você tenha um esquema de banco de dados, você terá um conjunto de APIs de andaimes para brincar! Os pontos de extremidade de andaimes são acessados usando URIs semelhantes aos seguintes (observe a api em vez do número da versão):
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
As APIs de andaimes são APIs sem versão e são projetadas para permitir que os desenvolvedores de front-end acessem o acesso total ao back-end na forma de operações e pesquisas de criação, leitura, atualização e exclusão (CRUD). O principal benefício deles é que você não precisa gastar uma tonelada de tempo criando manualmente pontos de extremidade do CRUD durante as fases iniciais do desenvolvimento de aplicativos. (Como são essas fases iniciais de desenvolvimento quando os requisitos estão mudando e as coisas estão constantemente em fluxo.)
AVISO: Como as APIs de andaimes são sem versão, elas ineriçam a todos os problemas associados às APIs sem versão. Assim que o back -end é alterado, essas APIs também são alteradas; Isso pode potencialmente quebrar um aplicativo de maneiras inesperadas ou ocultas. Por esse motivo, é aconselhável fazer a transição de APIs sem versão para as APIs versionadas à medida que o processo de desenvolvimento próximo da conclusão.
Enquanto a maioria das pessoas pratica alguma forma de injeção de dependência sem sequer pensar nisso, o fato é que, instantando e injetando manualmente as aulas com muitas dependências podem ser um aborrecimento bastante grande. Os exemplos a seguir devem ajudar a demonstrar o benefício da injeção automática de dependência através do contêiner de contêiner.
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 );
//...
}Depois (usando o contêiner DI):
// call the action method
$ this -> doSomething_v1 ( $ app -> container );
public function doSomething_v1 ( Container $ container ) {
$ customer = $ container -> get (Customer::class);
//...
}Espero que você possa ver os benefícios. Com o RXN, não há necessidade de instanciar os pré -requisitos sempre! Use o contêiner para facilitar sua vida.
Basta digitar a classe que você precisa como um parâmetro e o POOF , o contêiner DI adivinhará todas as dependências para você e carregará e injetará automaticamente. Nenhuma bagunça exige. Você não precisa injetar as dependências manualmente!
Antes (instanciação 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 ' );
//...
}Depois (instanciação e injeção automáticas):
public function doSomething_v1 ( Request $ request ) {
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}Veja a diferença?
