مرحبا بالجميع. أريد أن أعترف بك وأخبرك قليلاً عن شعوري عندما أتطور في لارافيل. لا ، لا تفكر في ذلك ، أنا معجب بهذا الإطار وأنا ممتن للغاية للفريق الذي أنشأه ويدعمه ، فهم يقومون بعمل رائع للغاية ، وفي رأيي ، فإن Laravel هو أفضل استمرارية لـ Symfony ، ولا تقل حبيبي عن ذلك.
أنا أحب رمز غبية. غبية بمعنى أنه حتى بعد 10 سنوات ، إذا طلب منك العميل إجراء تغييرات عليه ، يمكنك القيام بذلك دون الخوض في المنطق بأكمله ، حتى بعد أن يكون بعد حفلة شركة يوم الجمعة ، دون كسر أي شيء في الكود القديم. وغبي بمعنى أنك لست بحاجة إلى بذل أي جهد إدراكي لفهم ذلك. ولكن هناك حل معماري واحد في Laravel Eloquent ORM يجعلني أبكي. مثيرة للاهتمام؟ تعال تحت القط.
لقد توصل الأشخاص الأذكياء إلى كل شيء من أجلك منذ فترة طويلة: OOP وأنماط التصميم و SOLID و DDD وكلمات مخيفة أخرى تخيفك كثيرًا في البداية ، ثم يتم تطبيقها على حدس.
هذه أحب لارافيل و Symfony. أنها تسمح لك لكتابة رمز الأكثر أمانا والبكم من خارج منطقة الجزاء. نعم كل واحد منهم لديه عيوبه ... ولكن في لارافيل هناك واحد يزعجني أكثر. هذا يستخدم نمط السجل النشط (AR) للعمل مع الطرز.
بالنسبة للمبتدئين ، قليلا عن هذا النمط. ما هذا كله؟ لفهم ، يجب أن تذهب إلى الأصل من التأليف من تصميم التطبيق - نمط السجل. هذا النمط هو مجموعة. مجموعة من الكيانات (الكيان) التي يمكنها استرجاعها أو تعديلها أو حفظها أو حذفها ، بشكل عام ، إدارتها في موقع تخزين تجريدي. في 90 من 100 في المائة من الحالات ، يعد موقع التخزين هذا مجموعة متنوعة من قواعد البيانات. ولكن قد يكون هناك نظام ملفات ، ونوع من ذاكرة التخزين المؤقت ، وحتى واجهة برمجة تطبيقات خارجية.
يتوافق هذا النهج تمامًا مع مبدأ المسؤولية المشتركة ونهج DDD. بالإضافة إلى ذلك ، وبفضل هذا النهج ، يتم تنفيذ ضعف الاتصال - نحن لا نهتم بكيفية تخزين التطبيق بالضبط ، فنحن نعمل مع Entity عندما نريد العمل مباشرة مع تمثيل الكائن للبيانات والعمل مع المستودع عندما نحتاج إلى التفاعل مع المستودع.
لكن Laravel قررت المضي قدماً في استخدام AR ، وهو أمر لا يمكن إنكاره ومريح بشكل لا يصدق عندما تحتاج إلى إنشاء نموذج أولي سريع ، لكنه يصبح صداعًا لا يصدق عندما تحتاج إلى التفاعل مع عدة مصادر للبيانات والعمل معها داخل النظام.
AR هو نمط يخطط الكيان والمستودع في نموذج واحد. وهذا هو ، يصبح كائن تمثيل لسجل معين في قاعدة البيانات. و ... ماذا؟ ما الذي يؤدي إلى هذا ولماذا هو مزعج للغاية؟
أولاً ، ننتهك نفس مبدأ المسؤولية المشتركة - منطق العمل مع المستودع في مكان ما ، ومنطق العمل مع كيان في مكان آخر. هذا أمر مهم ، لأنه في إطار نظامي لا أريد نقل خط من قاعدة البيانات في تمثيل الكائن من خلال سلسلة الاتصال. أريد تمرير النموذج. لا ينبغي لي أن أعطي كيف تبين ، والتغييرات استمرت. أحتاج إلى تلك الأساليب التي تسمح لك بالتفاعل فقط مع النموذج ، وليس مع الصفوف الموجودة في قاعدة البيانات.
ثانياً ، لا يمكننا (نتيجة لحقيقة أن الطبقة الثابتة - طبقة التخزين - متصلة بطبقة الكيان) ، ما عليك سوى تغيير موقع تخزين النموذج. نعم ، يمكننا القيام بذلك في التكوين ، وتغييره على الفور للجميع ، داخل قواعد البيانات المدعومة. أو قم بالتغيير فقط لطراز معين (مع كل هذا ، لا نقوم بإزالة أي أساليب منشئ الاستعلام ، لأنه لا يمكنك التخلص من أساليب الطبقة الأساسية) وتواجه الكثير من الأخطاء المحتملة في الكود أو لا سمح الله ، إذا كان شخص آخر سوف تدعم (وهذا يحدث في كل وقت).
ثالثا. أريد اختبار كياناتي. أريد أن أتأكد من أن التغييرات التي أجريها لن تؤدي إلى كسر منطق عملي. وكما تبين الممارسة ، في حالة AR ، لا يمكنك القيام بذلك ، لأن المبدأ الشيطاني الخاص بالمسؤولية الفردية قد انتهك! على الرغم من أنني هنا مخادع بعض الشيء. نماذج الاختبار ممكنة ، فقط ... معقدة بعض الشيء.
ومع ذلك ، فمن المستحيل عدم الحديث عن مزايا هذا النمط. على الرغم من أن كل شيء زائد هو أنه "سريع وبسيط ، دون تردد". من خلال دمج نموذجين قريبين من المنطق واستخدامهما معًا بشكل مستمر ، حصلنا على أداة ملائمة تقلل بشكل طفيف مقدار الشفرة (في اتجاه التعقيد ، هل نتذكر "الرمز الغبي"؟). كما يسمح لك بالتخلص من المشكلات غير الضرورية في مرحلة تشكيل MVP ، وهو أمر إلزامي (تدل الممارسة على أن هذا نادرًا ما يحدث ، لكن لا يزال) يتم التخطيط لإعادة كتابته. يسمح لك هذا بنقل الأفكار من السؤال "كيف نفعل" إلى السؤال "ماذا نفعل" ، أي التخلص من الأسئلة غير الضرورية حول التقنيات والانتقال إلى منطق العمل.
ما هي الخاتمة التي توصلت إليها على مر السنين باستخدام Laravel Eloquent ORM؟ نشط سجل الشر في الجسد؟ لا ، هذه هي الأداة الأكثر روعة في بعض المواقف ، خاصة بالنسبة للمرحلة التي تكتب فيها تطبيقًا بسيطًا أو نموذجًا أوليًا لهذا التطبيق. ولكن هذا أمر مستحيل العمل عندما يكبر التطبيق الخاص بك ويجب عليك العمل مع عدد كبير من مصادر البيانات ، وكتابة التعليمات البرمجية مع تغطية اختبار 100 ٪ ، وتبدأ المشاكل الكبيرة.
نعم ، يتم اختراع شرائح جديدة ( Trucker ؟) ، لكن لنذهب إلى الحيل. لكن ما زلت أريد المزيد من التحرر من الإطار ، خاصةً لأنه جيد جدًا للكثيرين!