👵🏽 ⬛️ 😼 الوسيطة وميزات خطوط الأنابيب في Laravel 🎥 👉🏻 🧓🏽

Laravel هو نظام كبير ومعقد حقًا يحاول حل معظم المهام اليومية لمطور الويب بالطريقة الأكثر أناقة وجمع أكبر عدد ممكن من الأدوات ، والأهم من ذلك ، مع أكبر قدر ممكن من الواجهة البشرية.

واليوم سنركز على إحدى هذه الأدوات ، أو بالأحرى على استخدامها وتطبيقها من قبل المبرمج. دفعني نقص التوثيق الكامل ، وكذلك عدم وجود مقالات باللغة الروسية وعدد قليل جدًا من المقالات الأجنبية ، إلى اتخاذ قرار بالكشف عن حجاب معين من السرية حول هذه الميزة المثيرة للإطار واختيار هذا الموضوع كمقالتي الأولى عن حبري.

الوسيطة

تفترض هذه المقالة أن القارئ على دراية بالاستخدام الأساسي لهذه الوظيفة في إطار العمل ، لذلك لن أتطرق إلى هذه النقطة لفترة طويلة.

من خارج الصندوق ، توفر لنا Laravel وظيفة قوية إلى حد ما لتصفية طلبات HTTP الواردة إلى تطبيقنا. نتحدث عن البرامج الوسيطة المحبوبة لدى الجميع (أو لا) - يواجه المطور هذه الفئات بسرعة كبيرة في طريقه لإتقان Laravel ، أثناء قراءة قسم "الأساسيات" من الوثائق الرسمية ، وهذا ليس مفاجئًا - الوسيطة هي واحدة من أهم وأهم الطوب على أساسه يتم بناء النظام بأكمله.

أمثلة لحالات المستخدم القياسية لهذا المكون في Laravel هي: EncryptCookies / RedirectIfAuthenticated / VerifyCsrfToken ، وكمثال على تنفيذ مخصص ، يمكنك الاستشهاد بتوطين تطبيق الوسيطة (تعيين الترجمة المطلوبة بناءً على بيانات طلب معينة) قبل نقل الطلب بشكل أكبر.

أعمق في الهاوية

تخلوا عن الأمل يأتون الجميع هنا

حسنًا ، الآن بعد أن انتهت النقاط الرئيسية - يمكننا الخوض في مكان رهيب للكثيرين - في ألفا وأوميغا ، البداية والنهاية - في مصادر Laravel . أولئك الذين تواصلوا لإغلاق المقال على الفور - خذوا وقتكم. في الواقع ، في التعليمات البرمجية المصدر لهذا الإطار ، لا يوجد شيء معقد تقريبًا من الجانب المفاهيمي - يحاول منشئو المحتوى بشكل واضح ليس فقط إنشاء واجهة واضحة ومريحة للعمل مع أطفالهم ، ولكنهم يحاولون أيضًا القيام بنفس الشيء مباشرة على مستوى التعليمات البرمجية المصدر ، والتي لا يمكن لا ترضي.

سأحاول شرح مفهوم البرامج الوسيطة وخط الأنابيب على مستوى الكود والمنطق بأبسط وأسهل ما يمكن الوصول إليه ، وسأحاول عدم الخوض في المكان الذي لا تحتاج فيه إلى المقالة. لذا ، إذا كان في التعليقات أشخاص يعرفون جميع أسطر شفرة المصدر عن ظهر قلب - أطلب منك الامتناع عن انتقاد روايتي السطحية. ولكن أي توصيات وتصحيحات لعدم الدقة هي موضع ترحيب فقط.

الوسيطة - عبر الحواجز

أعتقد أن تعلم أي شيء يكون دائمًا أسهل عندما يتم تقديم أمثلة جيدة. لذلك ، أدعوكم وأنا لدراسة هذا الوحش الغامض تحت اسم خط الأنابيب . إذا كان مثل هؤلاء الرجال الشجعان موجودين حقًا ، فقبل إجراء مزيد من القراءة ، سنحتاج إلى تثبيت إصدار مشروع Laravel فارغ 5.7 - يرجع الإصدار فقط إلى حقيقة أنه الأخير في وقت الكتابة ، يجب أن يكون كل ما سبق مطابقًا على الأقل للإصدار 5.4. أولئك الذين يريدون فقط معرفة جوهر واستنتاجات المقالة يمكنهم تخطي هذا الجزء بأمان.

ما الذي يمكن أن يكون أفضل من دراسة سلوك المكون ، باستثناء دراسة السلوك المدمج بالفعل في النظام؟ ربما يمكن لشيء ما أن يفعل ، ولكننا سنستغني عن التعقيدات غير الضرورية ونبدأ تحليلنا باستخدام الوسيطة القياسية - أي ، مع أبسط وأكثرها فهمًا من المجموعة بأكملها - RedirectIfAuthenticated :

RedirectIfAuthenticated.php

class RedirectIfAuthenticated { /**      * Handle an incoming request. * * @param \Illuminate\Http\Request $request * @param \Closure $next * @param string|null $guard * @return mixed */ public function handle($request, Closure $next, $guard = null) { if (Auth::guard($guard)->check()) { return redirect('/'); } return $next($request); } }

في أي فئة من البرامج الوسيطة الكلاسيكية ، هناك طريقة رئيسية يجب أن تقوم بمعالجة الطلب مباشرة وتمرير المعالجة إلى المرحلة التالية في السلسلة - في حالتنا ، هذه هي طريقة المقبض . في هذه الفئة بالذات ، تكون معالجة الطلب بسيطة للغاية - "إذا كان المستخدم مخولًا ، فقم بإعادة توجيهه إلى الصفحة الرئيسية ، وبالتالي إنهاء السلسلة."

إذا نظرنا إلى تسجيل هذه الوسيطة في app / Http / Kernel.php ، فسوف نرى أنها مسجلة في "مسار الوسيطة". من أجل معرفة كيفية عمل النظام مع هذه الوسيطة ، دعنا نذهب إلى الفصل الذي يرث منه تطبيقنا / Http / Kernel - ويرث من فئة Illuminate \ Foundation \ Http \ Kernel . في هذه المرحلة ، سنفتح البوابات مباشرةً لشفرة شفرة المصدر لإطار عملنا ، أو بالأحرى ، لأهمها وأهمها - إلى جوهر العمل مع HTTP. بالمناسبة ، من يهتم - يعتمد Laravel على العديد من مكونات Symfony ، على وجه التحديد في هذا الجزء - على HttpFoundation و HttpKernel .

تعريف وتنفيذ الوسيطة الخاصة بنا في مُنشئ النواة كما يلي:

إضاءه \ مؤسسة \ Http \ Kernel (تطبيق $ التطبيق ، جهاز التوجيه $ جهاز التوجيه)

  /**    HTTP Kernel . * Create a new HTTP kernel instance. * * @param \Illuminate\Contracts\Foundation\Application $app * @param \Illuminate\Routing\Router $router * @return void */ public function __construct(Application $app, Router $router) { $this->app = $app; $this->router = $router; $router->middlewarePriority = $this->middlewarePriority; foreach ($this->middlewareGroups as $key => $middleware) { $router->middlewareGroup($key, $middleware); } foreach ($this->routeMiddleware as $key => $middleware) { $router->aliasMiddleware($key, $middleware); } }

الكود بسيط للغاية ومباشر - لكل برنامج وسيط في المصفوفة ، نسجله باستخدام اسم مستعار / فهرس في جهاز التوجيه الخاص بنا. تضيف طريقتا aliasMiddleware و middlewareGroups من فئة المسار لدينا برامج وسيطة إلى أحد صفائف كائن جهاز التوجيه. لكن هذا لا يتم تضمينه في سياق المقالة ، لذلك سوف نتخطى هذه اللحظة وننتقل.

ما يهمنا حقًا هو طريقة sendRequestThroughRoute ، التي تترجم حرفيا كيفية إرسال طلب عبر المسار :

تضيء \ مؤسسة \ Http \ Kernel :: sendRequestThroughRouter ($ request)

  /**     middleware / router. * Send the given request through the middleware / router. * * @param \Illuminate\Http\Request $request * @return \Illuminate\Http\Response */ protected function sendRequestThroughRouter($request) { // *    * return (new Pipeline($this->app)) ->send($request) ->through($this->app->shouldSkipMiddleware() ? [] : $this->middleware) ->then($this->dispatchToRouter()); }

كمعلمة ، تتلقى هذه الطريقة طلبًا. عند هذه النقطة ، يجب أن ننظر مرة أخرى إلى رمز RedirectIfAuthenticated الخاص بنا. نحصل أيضًا على طلب في طريقة التعامل مع الوسيطة الخاصة بنا ، سنحتاج إلى هذه الملاحظة بعد ذلك بقليل.

يحتوي الكود أعلاه على واجهة واضحة للغاية وقابلة للقراءة - "Pipeline" ، والتي ترسل طلبًا من خلال كل برنامج وسيط مسجل ، ثم "تنقله" إلى جهاز التوجيه . ساحرة ورائعة. أعتقد في هذه المرحلة أننا لن نحاول تحليل هذا القسم من التعليمات البرمجية أكثر من ذلك ، سأصف فقط باختصار دور هذا القسم في النظام بأكمله:

قبل أن يصل الطلب إلى وحدة التحكم الخاصة بك ، يتم تنفيذ الكثير من الإجراءات ، من التحليل البسيط لعنوان URL نفسه إلى تهيئة فئة الطلب . تشارك الوسيطة أيضًا في سلسلة العمل هذه. تطبق الطبقات الوسيطة نفسها نمط (تقريبًا) لتصميم سلسلة المسؤولية ، أو سلسلة المسؤولية ، لذا فإن كل فئة برامج وسيطة معينة ليست سوى رابط في السلسلة.

أعلاه ، لم نعد إلى فئة RedirectIfAuthenticated التي تم اعتبارها في الأصل. الطلب "متداول" على طول السلسلة ، بما في ذلك السلسلة التي تمر بكل ما هو مطلوب لمسار الوسيطة. ستساعدنا هذه اللحظة في العمل مع روابطنا الخاصة في سلسلتنا ، المزيد عن ذلك لاحقًا.

خط الأنابيب - الصرف الصحي لتطبيقنا

أحد الأمثلة على تنفيذ خط الأنابيب الذي رأيناه أعلاه. لكن الغرض من المقالة لم يكن فقط لشرح تشغيل هذا المكون على مستوى التكامل مع Laravel ، ولكن أيضًا لشرح المبدأ الأساسي للعمل مع هذه الفئة في التعليمات البرمجية الخاصة بنا.

يمكن العثور على الفئة نفسها من خلال تعريفها الكامل مع مساحة الاسم:

تضيء \ خط الأنابيب \ خط الأنابيب

يمكن أن يكون هناك الكثير من التطبيقات لهذا المكون ، اعتمادًا على المهمة المحددة التي تحتاج إلى حلها ، ولكن أحد الدوافع الأكثر وضوحًا هو متطلبات إنشاء سلسلة معالجات الطلبات الخاصة بك ، والتي لا تتداخل مع عمليات النظام بأكمله ويتم تحديدها حصريًا على مستوى منطق عملك. أيضًا ، تحتوي واجهة الفصل على مستوى كاف من التجريد ولها وظائف كافية لتنفيذ أنواع مختلفة من قوائم الانتظار.

تنفيذ العينة في Laravel

ننفذ أبسط سلسلة وبعيدة عن سلسلة استعلام الواقع. سنستخدم السلسلة "HELLO WORLD" كبيانات ، وبمساعدة معالجين سنقوم بتشكيل السلسلة "Hello User". تم تبسيط الرمز عمدا.

قبل التنفيذ الفوري لـ "الأنابيب" الخاصة بنا ، نحتاج إلى تحديد عناصر هذا الأنبوب. العناصر مكتوبة عن طريق القياس مع الوسيطة:

تحديد معالجات

StrToLowerAction.php:

 use Closure; class StrToLowerAction { /** * Handle an incoming request. * * @param string $content * @param Closure $next * @return mixed */ public function handle(string $content, Closure $next) { $content = strtolower($content); return $next($content); } }

SetUserAction.php:

 use Closure; class SetUserAction { /** * Handle an incoming request. * * @param string $content * @param Closure $next * @return mixed */ public function handle(string $content, Closure $next) { $content = ucwords(str_replace('world', 'user', $content)); return $next($content); } }

ثم نقوم بإنشاء "خط أنابيب" ، ونحدد نوع البيانات التي نريد إرسالها فوقها ، ونحدد من خلال مجموعة المعالجات التي نريد إرسال هذه البيانات ، ونحدد أيضًا رد الاتصال ، الذي يتلقى كحجة تمرير بياناتنا عبر السلسلة بأكملها. في حالة بقاء البيانات في جميع أنحاء السلسلة دون تغيير ، يمكن حذف الجزء الذي يحتوي على رد الاتصال:

 $pipes = [ StrToLowerAction::class, SetUserNameAction::class ]; $data = 'Hello world'; $finalData = app(Pipeline::class) ->send($data) // ,       ->through($pipes) //   ->then(function ($changedData) { return $changedData; //  ,    }); var_dump($finalData); //      $finalData

أيضًا ، إذا كانت لديك رغبة أو تحتاج إلى تحديد طريقتك الخاصة في المعالجات ، فإن واجهة Pipeline توفر طريقة خاصة عبر ('method_name') ، ثم يمكن كتابة معالجة السلسلة بهذه الطريقة:

 $finalData = app(Pipeline::class) ->send($data) ->through($pipes) ->via('handle') //      ,         ->then(function ($changedData) { return $changedData; });

مباشرة ، البيانات التي نمررها عبر المعالجات يمكن أن تكون أي شيء على الإطلاق ، بالإضافة إلى التفاعل معها. ستساعد كتابة تلميحات وتعيين نوع الكائن الذي تم إرجاعه في السلسلة على تجنب أخطاء تكامل البيانات.

الخلاصة

توفر Laravel عددًا كبيرًا من الفصول الدراسية المدمجة ، وتتيح لنا مرونة العديد منها تطوير شيء معقد وبساطة كافية. درست هذه المقالة إمكانية إنشاء قوائم انتظار بسيطة للطلبات بناءً على فئة Pipeline المضمنة في Laravel. يمكن أن تكون تطبيقات هذه الفئة في الرمز النهائي مختلفة تمامًا ، وتسمح لك مرونة هذه الأداة بالتخلص من العديد من الإجراءات غير الضرورية عند بناء خوارزميات معينة.

تعتمد كيفية استخدام هذه الميزة في إطار العمل على وجه التحديد على المهام المسندة إليك.

الوسيطة وميزات خطوط الأنابيب في Laravel