rxn下载 - rxn源代码下载

rxn

其他类别

1.0.0

下载

PHP的快速，简单且功能强大的API框架。与JSON响应API请求，确保您的后端与前端完全分开

请注意：RXN目前正在积极开发中，仍被视为早期的Alpha

RXN（“反应”的缩写）是一个框架，旨在减少PHP生成的视图的复杂性和混乱 - 将视图转移到适合您的幻想的任何前端。

RXN背后的哲学很简单：严格的后端 /前端脱钩。

仅应通过API访问后端
后端只能作为JSON做出回应
前端应负责解释JSON回应
前端应负责生成用户视图
通过严格的后端 /前端脱钩，可能会发生惊人的事情

后端和前端都可以使用版本的API合约作为参考来分开开发
后端和前端都具有较不纠缠的复杂性，提供简单干净的工作流程
可以用完全不同的解决方案将后端或前端完全换成，从而使您更加灵活性
并行前端开发变得非常简化（例如，使用相同的后端利用内部应用程序，外部应用程序，电话应用等）。

Alpha的功能

包括Beta的计划功能（未检查）：

执照

RXN根据允许和免费的MIT许可发布。

分层命名和自动加载

RXN使用的命名区结构明确匹配类文件的目录结构。尽管也方便，但它主要用于实现一些非常酷的自动加载功能。

例如，例如，您创建了一个名为OrganizationProductModelMyAwesomeModel类。只需将文件放入遵循命名空间约定的目录结构中（例如{root}/organization/product/model/MyAwesomeModel.php ）。当您需要打电话时，只需直接调用课程即可调用。无需在任何地方提出require 。

之前（不使用自动加载）：

 <?php

require_once ( ' /organization/product/model/MyAwesomeModel.php ' );

use  Organization  Product  Model  MyAwesomeModel ;

$ object = new MyAwesomeModel()
// object gets created!

之后（使用自动加载）：

 <?php

use  Organization  Product  Model  MyAwesomeModel ;

$ object = new MyAwesomeModel()
// object gets created!

RXN的本地类也存在相同的模式。例如，在{root}/rxn/api/controller目录中找到响应类（ RxnFrameworkHttpResponse ）。自动加载是RXN降低开销的众多方式之一。

以下文件扩展名由自动加载功能支持（您还可以在RxnFrameworkConfig中定义自定义扩展）：

.php
.class.php
.interface.php
.model.php
.controller.php

错误处理

RXN生活，呼吸和吃例外。考虑以下代码段：

 try {
    $ result = $ databse -> query ( $ sql , $ bindings );
} catch (  PDOException $ exception ) {
    throw new  Exception ( " Something went terribly wrong! " , 422 );
}

如果您在应用程序中的任何地方都抛出Exception ，则RXN会自我终止，回滚任何程序中的数据库交易，然后使用JSON优雅地响应：

 {
    "_rxn" : {
        "success" : false ,
        "code" : 422 ,
        "result" : "Unprocessable Entity" ,
        "message" : "Something went terribly wrong!" ,
        //...
    }
}

路由请求参数

您使用RXN的后端的API端点示例可能是这样的：

 https://yourapp.tld/v2.1/order/doSomething

在哪里：

v2.1是端点version
order是controller
doSomething是控制器的action （一种公共方法）

现在，如果您想将get键值对添加到id = 1234的请求中，则通常会这样做：

前：

 https://yourapp.tld/v2.1/order/someAction?id=1234

在RXN中，您可以使用前向斜杠（ / ）将键和值放在URL中来简化这一点，就像这样：

后：

 https://yourapp.tld/v2.1/order/someAction/id/1234

version ， controller和action之后的奇数参数将导致错误。

版本的控制器和动作

通过对端点URL（例如， v1.1 ， v2.4等）进行版本处理，您可以轻松地知道，只要您改变后端端点行为，就不会意外地破坏前端。此外，版本控制还有助于使您的文档保持秩序；前端开发人员只能为文档构建，一切都会起作用。

因此，对于具有v2.1版本的端点，第一个数字（ 2 ）是控制器版本，第二个数字（ 1 ）是动作版本。下面的示例是我们将如何使用Action 1 2

 namespace Organization  Product  Controller  v2 ;

class Order extends  Rxn  Framework  Http Controller
{
    public function doSomething_v1 () {
        //...
    }
}

这允许前端和后端开发人员都可以落后于前端和后端开发人员。

脚手架

是否想通过您的新型后端体系结构进行实验和探索？没问题，只要您有一个数据库模式，您就有一套脚手架的API！使用类似于以下的URI访问脚手架端点（请注意api而不是版本号）：

 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

脚手架API是无版本的API，旨在以创建，读取，更新和删除（CRUD）操作和搜索的形式使前端开发人员完全访问后端。他们的主要好处是，您不必花费大量时间在应用程序开发的早期阶段手动制作CRUD终点。（因为在需求发生变化时，正是这些发展的早期阶段，而且事情不断变化。）

警告：由于脚手架的API是无版本的API，因此它们继承了与无版本的API相关的所有问题。后端发生变化后，这些API也会改变。这可能会以意外或隐藏的方式破坏应用程序。因此，随着开发过程接近完成，将无版本的API转换为版本的API是明智的。

依赖注入（DI）容器容器

虽然大多数人甚至在不考虑它的情况下进行某种形式的依赖注入，但事实是，手动实例化和注射课程的依赖性很多可能会很麻烦。以下示例应有助于证明通过容器容器自动依赖注入的好处。

之前（手册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 );
    //...
}

之后（使用DI容器容器）：

 // call the action method
$ this -> doSomething_v1 ( $ app -> container );

public function doSomething_v1 ( Container $ container ) {
    $ customer = $ container -> get (Customer::class);
    //...
}

希望您能看到好处。使用RXN，无需每次实例化先决条件！使用容器容器使您的生活更轻松。

控制器方法注入

只需将所需的类Typehint作为一个参数，而POOF ，DI容器容器就会猜测所有依赖关系，并自动加载并注入它们。没有混乱的需要。您不必手动注入依赖项！

之前（手动实例化）：

 // 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 ' );
    //...
}

之后（自动实例化和注射）：

 public function doSomething_v1 ( Request $ request ) {
    // grab the id from the request
    $ id = $ request -> collectFromGet ( ' id ' );
    //...
}