Laravel مقابل Symfony: الاختيار بينهما وما يكلّفه

تُقدَّم هذه المقارنة عادةً كاختبار شخصية - Laravel عملي وSymfony صارم، فاختر ما يشبهك. وذلك لا ينفع حين تكون هناك ميزانية معلَّقة به.

والفرق الفعلي هو: Symfony يفترض أنك ستقرر، وLaravel قد قرّر. وكل ما عداه يتبع من ذلك، في الاتجاهين.

ماذا يشتري "مقرَّرًا نيابةً عنك" وماذا يكلّف

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

وفي Symfony أغلب ذلك خيارات - Doctrine معتاد لا إلزامي، والإطار مرتاح لأن تجمّع شيئًا آخر. والكلفة قرار لكل مشروع. والفائدة أنه حين تكون متطلباتك غير معتادة فعلًا، لا يقف شيء في وجهك.

ونمطا الفشل متناظران وكلاهما حقيقي. تطبيق Laravel لم تطابق افتراضاتُ الإطار مجالَه قط ينتهي كمًّا كبيرًا من الشيفرة تلتف حول Eloquent. وتطبيق Symfony لم يفرض أحد فيه أعرافًا ينتهي بثلاثة فرق حلّوا المشكلة نفسها بثلاث طرق.

الـ ORM هو أكبر فرق منفرد

هنا يعيش أغلب التباين اليومي.

Eloquent سجل نشط: النموذج هو الصف، وهو يعرف كيف يحفظ نفسه. سريع الكتابة وجيد القراءة - العبارة $order->customer->name بديهية لأي أحد. والكلفة أن الاستمرارية تنتشر في كائنات مجالك، وأن الراحة تجعل استعلامات N+1 سهلة الكتابة دون ملاحظة.

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

إن كان تطبيقك في أغلبه CRUD على مخطط علائقي، فالسجل النشط شيفرة أقل للنتيجة نفسها. وإن كان لمجالك ثوابت يجب ألا تعتمد على كيفية تخزين الصفوف، فالمخطِّط يكسب عبأه. تلك هي القسمة الصادقة، وهي تنطبق على اختيار الإطار أكثر من أي شيء آخر.

أين يكون كل منهما جوابًا واضحًا

Laravel، بوضوح: فريق منتج يسلّم ميزات باستمرار؛ وتطبيق SaaS؛ وكل ما تُراد فيه الطوابير والمجدول والبريد والبث ولا تريد أن تدمج أربع مكتبات؛ وفريق سينمو بالتوظيف، لأن مجتمع المرشحين أكبر والإدماج أقصر.

Symfony، بوضوح: نظام طويل العمر في مجال بتعقيد حقيقي - التأمين، واللوجستيات، والمال المنظَّم - حيث تهم النمذجة أكثر من سرعة التسليم؛ ومؤسسة تشغّل Symfony بالفعل؛ ومشروع يجب أن يجلس فيه الإطار على حافة معمارية قائمة لا أن يعرّفها.

أيّهما، بصدق: أغلب كل ما عدا ذلك. الفريق المتمرس يكتب تطبيقًا قابلًا للصيانة بكليهما، وسيكون الفرق في النتيجة أصغر من الفرق الذي يصنعه هل كتب أحد اختبارات.

ما يقرره عمليًا

ليس المعمارية. الناس.

مجتمع المرشحين لـ Laravel أكبر بكثير، ومجتمع Symfony يميل إلى الأقدم خبرةً - وهو إما ما تريده وإما ما لا تقدر عليه. والفريق الذي يعرف أحدهما بالفعل سيسلّم فيه أسرع من الملاءمة الأفضل نظريًا، والفجوة أكبر من أي ميزة معمارية لأيّهما.

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

ما لا يقرره

الأداء. كلاهما يقضي وقته في قاعدة بياناتك. وإن كان تطبيقك بطيئًا فهو بطيء لأسباب ستنجو من تغيير الإطار سالمة.

"الجاهزية المؤسسية". كلاهما مستخدم في أنظمة إنتاج كبيرة عليها مال حقيقي. والتطبيقات التي تفشل عند التوسع تفشل بسبب مخطط، أو طابور لم يراقبه أحد، أو غياب اختبارات، في الإطارين.

نوافذ الدعم الطويل. إصدارات LTS في Symfony تدوم أطول، وذلك فرق تخطيطي حقيقي. وهو يهم إن كانت مؤسستك لا تستطيع الترقية سنويًا - وإن كان ذلك صحيحًا، فالشيء الذي يجب إصلاحه هو السبب الذي يمنعك، لأن ذلك القيد سيكلّفك أكثر مما قد يكلّفه اختيار الإطار يومًا.

إن كان لديك أحدهما بالفعل

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

إن لم تكن القائمة القصيرة فعلًا Laravel وSymfony بل Laravel وشيئًا خارج PHP، فـ Rails هو أقرب نظير للحجة. وإن كان الشك في ملاءمة إطار بهذا الشكل للمشروع أصلًا، فتلك الصفحة الأعم.