سؤال

عادةً ما يتم تعريف الجهل الثبات على أنه القدرة على الاستمرار واسترداد كائنات .NET القياسية (أو pocos إذا كنت تصر حقًا على منحهم اسمًا). و تعريف مقبول جيدًا لكائن .NET قياسي هو:

"... الفصول العادية حيث تركز على مشكلة العمل في متناول اليد دون إضافة أشياء لأسباب تتعلق بالبنية التحتية ..."

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

  • جميع الفئات يجب لديك مُنشئ افتراضي
  • بعض الميزات لا تعمل ما لم يتم وضع الفصول الدراسية وجميع الأعضاء افتراضية
  • هوية الكائن لا تعمل بشكل صحيح إلا إذا كنت تعطي تساوي/gethashcode

(جانبا: قبل أن ينزعج أي شخص ، لا أقصد اختيار nhibernate هنا ، إنه مجرد مثال مقتبس بشكل متكرر على الإطار الذي يفترض أنه يجهل الثبات. أنا متأكد .)

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

حيث أواجه مشكلة في تعريف "جهل الثبات"/"Poco" هو أنني لا أرى كيف ، من الناحية المفاهيمية ، يختلف هذا حقًا عن إضافة سمات مثل [Serializable] أو [DataContract] أو [XmlType] أو أي تعليقات أخرى خاصة بالثبات يسهل استمرار واسترجاع الكيان باستخدام هذا الإطار.

إذن ، ما هو بالضبط "الجهل الثابت"؟

من الواضح أن تعريفها على أنها قادرة على الاستمرار في "الطبقات العادية" هي مغالطة لأن nhibernate هي فقط عادية فقط لأنها لا تشير -أعضاء ومتساويون/تطبيقات GethashCode على أنواع قابلة للتغيير.

هل من المعقول أن نقول أن "الجهل الثابت" صحيح عندما تسهل الأشياء استخدام إطار الثبات (إما في التصميم والبنية أو باستخدام التعليقات التوضيحية الخاصة بالإطار) ولكن لا تؤدي أي منطق ثبات بأنفسهم؟

هل كانت مفيدة؟

المحلول

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

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

نصائح أخرى

لا أعتقد أن فهمك (أو تعريفك) من "دخول الثبات" خاطئ.

ال حقا القضية هي تلك التجريدات المتسربة. بكل بساطة ، فإن التكنولوجيا الحالية تجعلها جداً من الصعب تنفيذ PI الحقيقي.

وأنا أتفق مع MikeB - "الجهل المثالي" هو مقياس انزلاق ، وليس خاصية حقيقية/خاطئة من ORM معين.

سيكون تعريفي لـ True 100 ٪ PI هو أنه يمكنك استمرار أي فئة محتملة POCO ، بغض النظر عن مدى تعادلها وترتبطها بفئات أخرى ، دون تغيير الفصل بأي طريقة.

إضافة حقول الهوية ، تزيين السمات ، وراثيا من فصول ORM ، واضطرار إلى تصميم فصولك حتى تتخلى عن الجداول الأساسية في RDB - كلها تقلل من "درجة PI" أقل من 100 ٪.

ومع ذلك ، فقد اخترت استخدام Automabing Nhibernate بطلاقة لأنه يبدو أنه يحتوي على أعلى درجة PI في أي من خيارات ORM التي بحثت عنها.

أتفق مع تعريفك:

هل من المعقول أن نقول أن "الجهل الثابت" صحيح عندما تسهل الأشياء استخدام إطار الثبات ، ولكن لا تؤدي أي منطق ثبات بأنفسهم؟

لا يحتوي الكود (على عكس atributes) في فصولك على ميزات جوهرية للاستمرار. قد تكون هناك حاجة إلى المُنشئين الافتراضيين للمثابرة ، ولكن ليس لديهم رمز لا يثابر بالفعل. يمكن تغيير طبقة الثبات بشكل كبير ، ويمكن استخدام قواعد بيانات مختلفة وسيظل منطق العمل دون تغيير.

الطبقة الجهلة المستمرة ، هي فئة غير مرتبطة بإطار المثابرة.

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

على الرغم من أنه قد يكون هناك بعض القيود الطفيفة التي يتطلبها أي إطار عمل معين للثبات ، إلا أنه لا يزال في مكانه.

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

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

يمكنك تنفيذ جهل persisrtence باستخدام فئة للمجال أو تطبيقك وفئة POCO في الثبات ، عندما ستستمر

يجب أن تتجاهل فئة المجال الخاصة بك كيفية استمرار المعلومات ، لذلك يجب ألا تتضمن أي قواعد لإطار الثبات مثل (مُنشئ فارغ ، خصائص افتراضية ، إلخ)

يمكن أن تكون قواعد إطار الثبات هذه في فصل الثبات الخاص بك.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top