RXN (singkatan untuk 'reaksi') adalah kerangka kerja yang dirancang untuk memotong kompleksitas dan kekacauan pandangan yang dihasilkan PHP-melepas pemandangan ke frontend apa pun yang sesuai dengan kesukaan Anda.
Filosofi di balik RXN sederhana: decoupling backend / frontend yang ketat .
Termasuk fitur yang direncanakan untuk beta (tidak dicentang):
RXN dirilis di bawah lisensi MIT permisif dan gratis.
RXN menggunakan struktur namespacing yang secara eksplisit cocok dengan struktur direktori file kelas. Meskipun juga nyaman, ini terutama digunakan untuk menerapkan beberapa fitur autoloading yang cukup keren.
Katakanlah, misalnya, bahwa Anda membuat kelas bernama OrganizationProductModelMyAwesomeModel . Cukup letakkan file dalam struktur direktori yang mengikuti konvensi namespace (misalnya, {root}/organization/product/model/MyAwesomeModel.php ). Ketika Anda perlu menelepon kelas, cukup panggil kelas dengan memanggilnya secara langsung. Tidak perlu menempatkan require di mana pun.
Sebelum (tidak menggunakan autoloading):
<?php
require_once ( ' /organization/product/model/MyAwesomeModel.php ' );
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created!Setelah (menggunakan autoloading):
<?php
use Organization Product Model MyAwesomeModel ;
$ object = new MyAwesomeModel()
// object gets created! Pola yang sama ada untuk kelas asli RXN. Sebagai contoh, kelas respons ( RxnFrameworkHttpResponse ) ditemukan di direktori {root}/rxn/api/controller . Autoloading adalah salah satu dari banyak cara di mana RXN mengurangi overhead.
Ekstensi file berikut didukung oleh fitur autoloading (Anda juga dapat mendefinisikan ekstensi khusus di RxnFrameworkConfig ):
RXN hidup, bernafas, dan makan pengecualian. Pertimbangkan cuplikan kode berikut:
try {
$ result = $ databse -> query ( $ sql , $ bindings );
} catch ( PDOException $ exception ) {
throw new Exception ( " Something went terribly wrong! " , 422 );
} Jika Anda melempar Exception di mana saja dalam aplikasi, RXN akan diakhiri sendiri, mengembalikan transaksi basis data dalam proses, dan kemudian dengan anggun merespons menggunakan JSON:
{
"_rxn" : {
"success" : false ,
"code" : 422 ,
"result" : "Unprocessable Entity" ,
"message" : "Something went terribly wrong!" ,
//...
}
} Contoh titik akhir API untuk backend Anda dengan RXN mungkin terlihat seperti ini:
https://yourapp.tld/v2.1/order/doSomething
Di mana:
v2.1 adalah version titik akhirorder adalah controllerdoSomething adalah action pengontrol (metode publik) Sekarang jika Anda ingin menambahkan pasangan mendapatkan nilai kunci ke permintaan di mana id = 1234 , dalam php Anda biasanya melakukan ini:
SEBELUM:
https://yourapp.tld/v2.1/order/someAction?id=1234
Di RXN, Anda dapat menyederhanakan ini dengan meletakkan kunci dan nilai di URL menggunakan slash maju ( / ) sebagai pemisah, seperti itu:
SETELAH:
https://yourapp.tld/v2.1/order/someAction/id/1234
Sejumlah parameter ganjil setelah version , controller , dan action akan menghasilkan kesalahan.
Dengan versi URL titik akhir Anda (misalnya, v1.1 , v2.4 , dll), Anda dapat tenang mengetahui bahwa Anda tidak akan secara tidak sengaja memecahkan frontend Anda setiap kali Anda mengubah perilaku titik akhir backend. Selain itu, versi juga membantu menjaga dokumentasi Anda; Pengembang Frontend dapat membangun dokumentasi dan semuanya hanya akan berhasil .
Jadi untuk titik akhir dengan versi v2.1 , angka pertama ( 2 ) adalah versi pengontrol , dan angka kedua ( 1 ) adalah versi aksi . Contoh di bawah ini adalah bagaimana kami akan mendeklarasikan Controller Version 2 dengan Action Version 1 :
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}Hal ini memungkinkan dokumentasi yang dapat dipertahankan, benar-benar-benar yang dapat didapat oleh pengembang Frontend dan Backend.
Ingin bereksperimen dan menjelajahi dengan arsitektur backend yang baru dimakamkan? Tidak masalah, selama Anda memiliki skema basis data, Anda memiliki serangkaian perancah API untuk bermain -main! Titik akhir perancah diakses menggunakan URI yang mirip dengan yang berikut (perhatikan api alih -alih nomor versi):
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 perancah adalah API tanpa versi, dan dirancang untuk memungkinkan pengembang frontend akses penuh ke backend dalam bentuk operasi dan pencarian Buat, Membaca, Perbarui, dan Hapus (CRUD) (CRUD). Manfaat utama mereka adalah Anda tidak perlu menghabiskan banyak waktu secara manual membuat titik akhir yang kasar selama fase awal pengembangan aplikasi. (Karena fase awal pengembangan ini ketika persyaratan berubah, dan segalanya terus berubah.)
PERINGATAN: Karena API perancah tidak ada versi, mereka melekat semua masalah yang terkait dengan API tanpa versi. Segera setelah backend diubah, API ini diubah juga; Ini berpotensi merusak aplikasi dengan cara yang tidak terduga atau tersembunyi. Untuk alasan ini, adalah bijaksana untuk transisi API tanpa versi ke API versi saat proses pengembangan hampir selesai.
Sementara kebanyakan orang mempraktikkan beberapa bentuk suntikan ketergantungan tanpa memikirkannya, faktanya adalah, secara manual instantiating dan menyuntikkan kelas dengan banyak ketergantungan dapat menjadi kerumitan yang cukup besar. Contoh -contoh berikut harus membantu menunjukkan manfaat injeksi ketergantungan otomatis melalui wadah kontainer.
Sebelum (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 );
//...
}Setelah (menggunakan wadah wadah DI):
// call the action method
$ this -> doSomething_v1 ( $ app -> container );
public function doSomething_v1 ( Container $ container ) {
$ customer = $ container -> get (Customer::class);
//...
}Semoga Anda bisa melihat manfaatnya. Dengan RXN, tidak perlu membuat instantiasi prasyarat setiap saat! Gunakan wadah wadah untuk membuat hidup Anda lebih mudah.
Cukup dengan jenis kelas yang Anda butuhkan sebagai parameter, dan poof , wadah wadah DI akan menebak semua dependensi untuk Anda dan secara otomatis memuat dan menyuntikkannya. Tidak ada yang berantakan membutuhkan. Anda tidak perlu menyuntikkan dependensi secara manual!
Sebelum (Instantiasi 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 ' );
//...
}Setelah (instantiasi otomatis dan injeksi):
public function doSomething_v1 ( Request $ request ) {
// grab the id from the request
$ id = $ request -> collectFromGet ( ' id ' );
//...
}Lihat bedanya?