rxn
1.0.0
RXN (اختصار "رد الفعل") هو إطار مصمم لقطع تعقيد وتفكيك طرق العرض التي تم إنشاؤها من PHP-مما يؤدي إلى تفريغ المشاهدات إلى أي واجهة تناسب خيالك.
الفلسفة الكامنة وراء RXN بسيطة: خلفية صارمة / الواجهة الأمامية .
بما في ذلك الميزات المخططة للبيتا (غير مرصوف):
يتم إصدار RXN تحت رخصة معهد ماساتشوستس للتكنولوجيا المجاني.
يستخدم 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 الأصلية. على سبيل المثال ، تم العثور على فئة الاستجابة ( RxnFrameworkHttpResponse ) في دليل {root}/rxn/api/controller . التحميل التلقائي هو واحد من الطرق العديدة التي يقلل RXN من النفقات العامة.
يتم دعم ملحقات الملف التالية بواسطة ميزة التحميل التلقائي (يمكنك أيضًا تحديد ملحقات مخصصة في RxnFrameworkConfig ):
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!" ,
//...
}
} قد تبدو نقطة نهاية API الخاصة بك مع الواجهة الخلفية مع RXN مثل هذا:
https://yourapp.tld/v2.1/order/doSomething
أين:
v2.1 هو version نقطة النهايةorder هو controllerdoSomething هو action وحدة التحكم (طريقة عامة) الآن إذا كنت ترغب في إضافة زوج احصل على القيمة الرئيسية إلى الطلب حيث id = 1234 ، في PHP ، عادة ما تقوم بذلك:
قبل:
https://yourapp.tld/v2.1/order/someAction?id=1234
في RXN ، يمكنك تبسيط هذا عن طريق وضع المفتاح والقيمة في عنوان URL باستخدام SLASH ( / ) الأمامية كفاصل ، مثل ذلك:
بعد:
https://yourapp.tld/v2.1/order/someAction/id/1234
سيؤدي عدد فردي من المعلمات بعد version controller action إلى خطأ.
من خلال إصدار عنوان URL لنقطة النهاية الخاصة بك (على سبيل المثال ، v1.1 ، v2.4 ، إلخ) ، يمكنك أن ترتاح بسهولة معرفة أنك لن تكسر الواجهة الأمامية عن طريق الخطأ كلما قمت بتغيير سلوك نقطة النهاية الخلفية. بالإضافة إلى ذلك ، يساعد الإصدار أيضًا في الحفاظ على وثائقك بالترتيب ؛ يمكن لمطوري الواجهة الواجهة فقط البناء إلى الوثائق وسيعمل كل شيء فقط .
لذلك بالنسبة لنقطة النهاية مع الإصدار v2.1 ، فإن الرقم الأول ( 2 ) هو إصدار وحدة التحكم ، والرقم الثاني ( 1 ) هو إصدار الإجراء . المثال أدناه هو كيف سنعلن الإصدار 2 وحدة التحكم مع الإصدار 1 :
namespace Organization Product Controller v2 ;
class Order extends Rxn Framework Http Controller
{
public function doSomething_v1 () {
//...
}
}يسمح ذلك بوثائق واقعية يمكن الحفاظ عليها والتي يمكن أن يتخلفها كل من مطوري الواجهة الأمامية والخلفية.
هل تريد تجربة واستكشاف بنية الخلفية الجديدة؟ لا توجد مشكلة ، طالما أن لديك مخطط قاعدة بيانات ، لديك مجموعة من واجهات برمجة التطبيقات سقالة لتلعب مع! يتم الوصول إلى نقاط نهاية السقالات باستخدام URIs مماثلة لما يلي (لاحظ 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
واجهات برمجة تطبيقات Scaffolding هي واجهات برمجة تطبيقات أقل من الإصدار ، وهي مصممة للسماح لمطوري الواجهة الواجهة بالوصول الكامل إلى الواجهة الخلفية في شكل عمليات وعمليات إنشاء وعملية (CRUD). مصلحتهم الرئيسية هي أنك لست مضطرًا لقضاء الكثير من الوقت في صياغة نقاط نهاية التسلل يدويًا خلال المراحل المبكرة من تطوير التطبيقات. (كما هي هذه المراحل المبكرة من التطوير عندما تتغير المتطلبات ، والأمور تتدفق باستمرار.)
تحذير: لأن واجهات برمجة تطبيقات السقالات أقل من الإصدار ، فإنها ترث جميع المشكلات المرتبطة بآبار واجهات برمجة التطبيقات أقل من الإصدار. بمجرد تغيير الواجهة الخلفية ، يتم تغيير واجهات برمجة التطبيقات هذه أيضًا ؛ هذا يمكن أن يكسر التطبيق بطرق غير متوقعة أو خفية. لهذا السبب ، من الحكمة أن تنقل واجهات برمجة التطبيقات بدون إصدار إلى واجهات برمجة التطبيقات التي تم إصدارها مع اقتراب عملية التطوير.
في حين أن معظم الناس يمارسون بعض أشكال حقن التبعية دون حتى التفكير في الأمر ، فإن الحقيقة هي أن الطبقات في الطبقات والحقن مع الكثير من التبعيات يمكن أن تكون متاعب كبيرة يدويًا. يجب أن تساعد الأمثلة التالية في إظهار فائدة حقن التبعية التلقائية عبر حاوية الحاوية.
قبل (دليل 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 ، ليست هناك حاجة لإنشاء إنشاء المتطلبات الأساسية في كل مرة! استخدم حاوية الحاوية لجعل حياتك أسهل.
ما عليك سوى كتابة الفئة التي تحتاجها كمعلمة ، و 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 ' );
//...
}ترى الفرق؟
