تدهش تقنيات المعلومات الحديثة بقوتها ، فهي تغمرها الفرص التي تفتحها ، وتثبطها المثالية الفنية الكامنة فيها ، ولكن هناك نقطة واحدة مثيرة للسخرية حول تكنولوجيا المعلومات التي تكسر أسنانها مرارًا وتكرارًا. عرض بيانات المستخدم من قاعدة البيانات ، والحصول على مدخلات منه ، ووضعها مرة أخرى في قاعدة البيانات ، وإظهار النتيجة. حقول الإدخال ، والأزرار ، وعلامات الاختيار ، والنقوش - يبدو أنها يمكن أن تكون معقدة للغاية بحيث يتطلب الأمر بناء هياكل الألغاز مثل الأُطُر التي تعمل على أعلى محركات templating في أعلى الأطر على رأس transpilers؟ ولماذا ، على الرغم من كل الجهود الهائلة ، لدينا حقيقة أن أمثلة الألعاب في البرنامج التعليمي ، بالطبع ، مصنوعة بسهولة وبكل سرور ، ولكن بمجرد أن تواجه مجموعة الأدوات المهام الحقيقية للحياة الحقيقية ... كيف نقول ليونة ... مع التعقيد المتزايد للمهام التي يتعين حلها ، هناك عدم خطية قوية لزيادة صعوبات التنفيذ. حسنًا ، سيكون الأمر يتعلق بشيء محير حقًا على مستوى الفيزياء النظرية أو تكنولوجيا الفضاء ، لأنه لا يوجد على أي حال - أزرار وعلامات اختيار. لماذا يستمر هذا الهراء في تسميم حياة المواطنين والعمل الجماعي لعدة عقود؟
الأسباب ، على الأرجح ، كما هو الحال دائمًا ، كثيرة. ربما يستحق كل منهم النظر بطريقة أو بأخرى ، ولكن هنا والآن سنتحدث عن مهمة تعيين الكائنات (ORM) ، والتي دائمًا ما تقف وراء بعض "الأزرار وعلامات الاختيار" هذه بشكل ما.
ماذا نعرف عن ORM
- لا يعني تخزين البيانات في الجداول العلائقية أنها مسألة بسيطة للغاية ، ولكن بشكل عام فإن فكرة وطرق تطبيقها واضحة تمامًا ومدروسة جيدًا.
- مع برمجة الكائنات ، ليس كل شيء جيدًا (هناك العديد من الأساليب المتنافسة) ، ولكن بشكل عام ، مع تطبيق التقنيات وتطبيقها ، يصبح كل شيء أكثر وضوحًا أيضًا.
- كل ذلك ، وآخر - حول البيانات وتخزينها ومعالجتها. هذا هو ، في الواقع ، عن الشيء نفسه.
- يبدو من المنطقي لنا أنه ينبغي أن يكون هناك جسر بسيط ومفهوم ومريح ويمكن التنبؤ به وعالمي بين العالمين.
- وفي كل مرة نجد هذا الجسر بسهولة ، إلا أن المصيبة وبساطته وشموليته وراحته وإمكانية التنبؤ به وبراعته لا تعمل بأكثر من الأمثلة البسيطة من البرامج التعليمية.
- الجميع يعانون: المطورين ، الذين يتعين عليهم القيام بالكثير من العمل الممل للغاية ، والمستخدمين الذين يتعين عليهم القتال مع البرامج الخرقاء ، والأعمال التجارية ، وتحقيق احتياجاتهم التي تبين فجأة أن تكون طويلة ومكلفة للغاية ، والصناعة ككل.
- لقد رأيت العديد من ORMs المختلفة ، ولكن لم أر أي منها جيدًا. وهذا هو ، واحد ، إلى جانب الأمثلة البسيطة ، لا يتحول إلى عبء وسرير Procrustean.
لماذا كل شيء غريب جدا
الأساس الأيديولوجي لنظرية وممارسة قواعد البيانات العلائقية هو حساب التفاضل والتكامل الأصلي ، أي فرع من الرياضيات. بالنسبة إلى OOP ، لا يوجد أساس أيديولوجي مماثل. يمكن للمرء أن يحاول صياغة الفكرة الأساسية لـ OOP مثل هذه: بما أن العالم يتكون من كائنات ، فسيكون من المناسب تصميمها ، هذا العالم ، من خلال إنشاء كائنات داخل نظام برنامج. في هذا المعنى ، خطأين في وقت واحد. أولاً ، العالم نفسه لا يتكون ولا يتكون أبدًا من أشياء. ثانياً ، أنا آسف ، ولكن لماذا يتعين على البرنامج محاكاة العالم؟ وهذا هو ، لدينا بيان غير صحيح من الناحية المفاهيمية ، يكمله تماما بيان بلا معنى للمشكلة.
كل ORM هي محاولة لتوسيع نطاق المراسلات الموحدة بوضوح ، في الواقع ، فرع الرياضيات ومجموعة فضفاضة من الممارسات المتنوعة ، استنادًا إلى اعتبارات الملاءمة والمناهج الثابتة تاريخًا ، وكذلك غالبًا على الأساطير وآراء السلطات والمفاهيم الخاطئة. في المختبر ، يمكن صنعه للعمل ، لكن في الجسم الحي محكوم عليه أن يبدو مثيرًا للشفقة وجلب المزيد من الحزن أكثر من الفرح.
على حتمية اتجاه الكائن
ومع ذلك ، فإن الحاجة إلى التوجه الكائن لبرنامجنا هو واقعنا لا مفر منه. تعتمد هذه الحتمية بشكل أساسي على حقيقة أن العمل بالكائنات هو جوهر وأساس أي من أنشطتنا. العالم نفسه لا يتكون من كائنات ، ولكن من أجل فهم شيء ما في هذا العالم والقيام بشيء ما مع هذا العالم ، نعلن أنفسنا أجزائه كأشياء ، نسميها أسماء ، نحاول فهم سلوكهم ، نطبق جهوده للحصول على النتائج المرجوة. هذه هي طريقتنا في العمل ، ومن المستحيل تركها ، وهي ليست ضرورية. كل شيء كائن ، ليس لأنه حقًا ، ولكن لأنه لا يمكننا فعل شيء آخر. إن ما لا يمكن أن يكون كائنًا بأي حال من الأحوال يقع خارج حدود قدرتنا على الفهم ولا يمكن أن يكون موضوعًا لجهودنا.
حتى إذا كان البرنامج مكتوبًا دون استخدام تقنيات OOP ، فهو حتميًا يحتوي على كائنات (بالمعنى الواسع للكلمة) ، من خلال معالجة أي مطور يحل مشكلته - المتغيرات وأنواع البيانات والمشغلين والخوارزميات والمنشآت النحوية والوظائف والوحدات النمطية. من وجهة نظر المستخدم ، يحتوي البرنامج أيضًا على مجموعة من الكائنات التي يتفاعل معها - الأزرار والملصقات وحقول الإدخال والصفحات والمواقع والنظام بأكمله.
ما نقوم بتخزينها في قواعد البيانات لدينا
كما ذكر أعلاه ، تستند قواعد البيانات العلائقية إلى حساب التفاضل والتكامل الأصلي. المسند عبارة عن حقيقة تم وضعها ، وفي حالتنا ، يتم تخزينها على وسيط. فقط في حالة ، لاحظت أن قاعدة البيانات العلائقية ليست فقط وليس الكثير عن العلاقات بين الجداول بواسطة مفاتيح خارجية. في المصطلحات المناسبة ، والعلاقات هي ما نسميه ببساطة الجداول. أي أنه حتى لو كانت قاعدة البيانات الخاصة بك تحتوي على جدول واحد فقط به عمودين (على سبيل المثال ، اسم ورقم الهاتف) ، لديك بالفعل قاعدة بيانات علائقية تنشئ العلاقة بين مجموعتين ، في هذه الحالة ، مجموعات من الأسماء وأرقام الهواتف.
قاعدة البيانات العلائقية لا تخزن الأشياء ؛ إنها تخزن الحقائق. للوقائع المخزنة ، بطبيعة الحال ، كائن ("ماذا تعني هذه الحقيقة؟") ، وعندما نحاول تعليم النظام للإجابة على هذا السؤال ، لدينا كيانات ، أي كائنات مرتبطة بالحقائق. إذا كنت تعمل بشكل صحيح ، فإن هيكل قاعدتنا ينتج عن سلسلة من الإجابات على السؤال "ما نوع الوقائع التي نعتزم الاحتفاظ بها؟" ، وفقط في المرحلة التالية ، نحصل على شيء يشبه الأشياء التي تعطي الحقائق للموضوعية. يمكنك بالطبع تصميم "من الأشياء" ، لكنني لا أوصي بذلك إلا في الأعمال المختبرية في مواضيع لا تتعلق مباشرة بتصميم قاعدة البيانات. خطر سوء الحسابات المعمارية الثقيلة كبير جدا. بالإضافة إلى ذلك ، على الأقل غير مريح.
استطرادا صغيرا حول قواعد بيانات الكائنات. فكرة بسيطة للغاية: إذا سئمنا مشاكل مع ORM ، فربما يتعين علينا فعل شيء مع الجزء "R"؟ دع قاعدة البيانات الخاصة بنا لا تكون وحشًا صعبًا ومتطلبًا ، بل شيء عصري من الشباب مصمم خصيصًا لتخزين الأشياء. نوع من قاعدة NoSQL التخطيطي ، على سبيل المثال. ولكن في النهاية اتضح فجأة أن ORMs التي تشبه NoSQL أكثر حرجًا وغير طبيعية من SQL القديمة الجيدة. على أي حال ، يمكننا أن نحصل وبكل سرور على تشغيل نظم إدارة قواعد البيانات الخالية من الدارات ، ولكن لا توجد بيانات خالية من الدارات في الطبيعة. لا يوجد شيء لا حيلة له ، غير مسؤول وغير أخلاقي من ORM لقواعد البيانات بدون دوائر.
جيد ORM
ORM الجيد هو ORM المفقود. حسنا ، بجدية. انظر إلى أي من أنظمة ORM الخاصة بك وحاول بصراحة الإجابة على سؤالك: ما هي فوائد هذا الوحش؟ ما هو سبب استخدامه باستثناء الوعود غير المنجزة بالسعادة والوعود التي تحطمت مراراً وتكراراً؟ بالطبع ، هناك بعض الأشياء المفيدة المفيدة ، ولكن ما هي هذه الأشياء على خلفية التشوهات المعمارية المقدمة ومشاكل الأداء التي تنشأ باستمرار عن اللون الأزرق؟
كقاعدة عامة ، واجهة برمجة تطبيقات قاعدة البيانات "المنخفضة المستوى" بسيطة ومريحة وكاملة ومتسقة. عادة ما يكفي من الأصابع لسرد جميع الميزات. لتعلمهم ليس خبرا إله ما مهمة.
سأحاول رسم مجموعة من المبادئ المعمارية التي تسمح لك بتعيين كائنات إلى قاعدة بيانات دون استخدام ORM:
- نحن تخزين الحقائق ، تعمل على الأشياء. تذكر أن قاعدة البيانات تخزن الحقائق ، وأن نماذج الكائنات المتضمنة في معالجة البيانات هي إسقاطات لمجموعات من الحقائق من وجهات نظر مختلفة. على سبيل المثال ، على سبيل المثال المعطى بالأسماء وأرقام الهواتف ، يمكننا الحصول على فئة Abonent ، والتي يمكن تخزين العديد من الأرقام ، وكذلك فئة PhoneNumber ، والتي يمكن تعيين العديد من المشتركين فيها (لا تنس أنه بالإضافة إلى أرقام الهواتف المحمولة الشخصية ، لدينا حيث لا تزال هناك شقة والهواتف المكتبية). والجدول في قاعدة البيانات هو مجرد جدول يحدد العلاقة بين أطراف كثيرة بين العديد من الأسماء وأرقام الهواتف. مجرد اثنين من التوقعات المختلفة. هذا النهج ، بالمناسبة ، يتناسب مع الحالات الأكثر تعقيدًا ، مما يتيح لك الحصول على فئات مفيدة في النظام مثل "متوسط المبيعات لفترة محددة وفقًا لمجموعة من المعايير".
- يتم عرض الحقائق في الكائنات والعكس بالعكس من خلال واجهة برمجة تطبيقات موجهة للمشاكل. بدون تطبيق حل يدعي أنه عالمي. إذا كنت لا تزال لا تعرف كيفية إنشاء واجهات برمجة تطبيقات ملائمة ، فتعلم كيف. والأهم من ذلك ، علم نفسك لتوثيقها على الفور.
- النظام قبل كل شيء. إذا كنت تستخدم الإصدار الكلاسيكي من نظام إدارة قواعد البيانات (DBMS) مع نظام بيانات جامد ، فإن هذا النظام في حد ذاته يجلب العمل إلى حد كبير مع البيانات. الهيكل الإضافي المشفر بواسطة هيكل الكائنات ببساطة زائدة. إذا كنت تستخدم نظام إدارة قواعد البيانات الخالية من المخططات ، فسيتعين عليك بالطبع بذل بعض الجهود للتأكد من أن قاعدة البيانات الخاصة بك لا تتحول إلى جبل من القمامة بسبب حقيقة أن المطورين المختلفين لديهم أفكار مختلفة حول ما يتم تخزينه.
- استقلالية نظم إدارة قواعد البيانات (إذا لزم الأمر). إذا كانت الخاصية الأكثر إثارة للاهتمام في ORM بالنسبة لك هي استقلالية نظم إدارة قواعد البيانات ، فاستخدم أدوات خاصة مثل ODBC أو JDBC أو ADO ، أو إذا كان ذلك غير ممكن ، فجرِّب مستوى التجريد الخاص بك. الأمر ليس صعباً كما قد يبدو في البداية. أنت لا تحتاج إلى دعم لكل إمكانات جميع نظم إدارة قواعد البيانات على الإطلاق لمهمتك ، أليس كذلك؟
- لا تنس الجوانب الإضافية للعمل مع البيانات. على سبيل المثال ، على سبيل المثال ، مشاركة الوصول إلى البيانات (التي يمكن أن تكون معقدة بشكل تعسفي) ، والرصد ، والتكرار ، وأكثر من ذلك. ولكن لدي هنا أخبار جيدة لك: لأنه في ORM المفضلة لديك ، الإضافة. لا يزال الجانب يتم تنفيذه وفقًا لمبدأ "لن ترضي الجميع ، وتناول ما تقدمه" ، ورفض الخدمة المشبوهة التي يتعين عليك التعامل معها أكثر من التعاون معها سيثبت في النهاية أنه قرار استراتيجي صحيح.
في المجموع
ORM هو موضوع مؤلم جدا لصناعتنا. في عصر يسلب فيه الذكاء الاصطناعي السحابي blockchain الكمي ، فإن الغالبية العظمى من القوى العاملة مشغولة بهدوء منطق الأعمال وواجهة مستخدم لقواعد البيانات. الملايين من خطوط الشفرة الرهيبة ، تسمير مع المجاهر والألم واليأس في كل مكان ترافق هذه العملية الإبداعية. واحدة من جذور هذا الوضع المحزن هو الاعتقاد الخاطئ للغاية أن ORM العالمي هو ممكن من حيث المبدأ. لكن هذا مستحيل ، وهناك سبب أساسي لذلك ، لا يمكن القضاء عليه. الوعي بهذه الحقيقة هو الخطوة الأولى نحو الخروج من هذا الكابوس. هناك طريقة للخروج ، فهناك بدائل ، لكن عليك أولاً أن تدرك وتشعر وتتعلم للحفاظ على بؤرة الاهتمام.
ملحوظة: أعتذر بصدق لأولئك الإخوة في المهنة الذين استثمروا الكثير من الوقت والجهد في إنشاء أفضل عدد عالمي في عالم ORM. انا اسف حقا