لماذا لا ينبغي أن يكون ORM أفضل رهان لك

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

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

بدأت أفكر في المشكلات التي أدخلها ORM:

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

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

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

حتى الآن ، عملت مع Hibernate (Java) ، و Mongoose (إطار ORM في Node for MongoDB). عندما جئت إلى مشروع Node الذي كان يستخدم بالفعل Mongoose باعتباره ORM ، كانت لدي مهمة هائلة لإعادة بناء المشروع بأكمله تقريبًا. في البداية فكرت في إزالة إطار ORM تمامًا. لكن زملائي في العمل لن يكونوا راضين دون أن تدعمني الأرقام. لذلك قمت بتقييم وقت الاستعلام مع Mongoose وبدونه. وهنا النتائج.

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

تخمين أي مكتبة ذهب قدما.

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

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