التحول إلى ORMs

Question

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

هل هذا صحيح مع تجاربك؟
هل من الممكن أو حتى فكرة جيدة أن يتم تنفيذها على مراحل؟
ما هي سلبيات ORM؟

Answer 1

أوصي بشدة بالحصول على نسخة من كتاب مايكل فيذر العمل بفعالية مع الكود القديم (بمصطلح "Legacy Code" تعني الريش أي نظام لا تغطيه اختبارات الوحدة بشكل كافٍ).إنه مليء بالأفكار الجيدة التي من شأنها أن تساعدك في إعادة البناء والتنفيذ التدريجي لأفضل الممارسات.

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

سلبيات ORM - من التجربة، هناك حتماً القليل من منحنى التعلم في التعامل مع المفاهيم والتكوين والخصوصيات الخاصة بحل ORM المختار.

يحرر:تصحيح اسم المؤلف

Answer 2

كتاب "Robert C Martin"، الذي كتبه مايكل فيذرز ("العم بوب"، على ما يبدو، اسم علامة تجارية هذه الأيام!) أمر لا بد منه.

يكاد يكون من المستحيل - ناهيك عن استهلاك الوقت بجنون - وضع اختبارات الوحدة في تطبيق لم يتم تطويره باستخدامها.الرمز لن يكون قابلاً للتنفيذ.

لكن هذه ليست مشكلة.تتعلق إعادة البناء بتغيير التصميم دون تغيير الوظيفة (آمل ألا أكون قد أفسدت المعنى بشكل سيء هناك) حتى تتمكن من العمل بطريقة أوسع بكثير.

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

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

سأفكر أيضًا في النظر إلى مارتن فاولر إعادة بناء التعليمات البرمجية, ، وهو، من الواضح بما فيه الكفاية، العمل النهائي في هذه العملية.

Answer 3

أنا أعمل على تطبيق ASP.net كبير حيث بدأنا مؤخرًا في استخدام NHibernate.لقد قمنا بنقل عدد كبير من كائنات المجال التي كنا نحتفظ بها يدويًا إلى Sql Server إلى NHibernate بدلاً من ذلك.لقد بسّط الأمور إلى حد ما وجعل من السهل تغيير الأشياء بمرور الوقت.يسعدنا أننا أجرينا التغييرات ونستخدم NHibernate حيثما كان ذلك مناسبًا للكثير من أعمالنا الجديدة.

Answer 4

سمعت أن TypeMock غالبًا ما يُستخدم لإعادة معالجة التعليمات البرمجية القديمة.

Answer 5

أعتقد جديًا أن إدخال ORM في تطبيق قديم يستدعي حدوث مشكلة (وقد يكون بنفس القدر من المتاعب مثل إعادة الكتابة الكاملة).

بخلاف ذلك، تعد ORM طريقة رائعة ويجب أخذها في الاعتبار بالتأكيد.

Answer 6

القاعدة لإعادة البناء هي.قم بإجراء اختبارات الوحدة.

لذلك ربما يجب عليك أولاً إجراء بعض اختبارات الوحدات على الأقل للأشياء الأساسية/الرئيسية.

يجب تصميم ORM لتقليل التعليمات البرمجية المعيارية.الوقت / المتاعب مقابل.عائد الاستثمار ليكون مشروعًا متروك لك لتقديره :)

Answer 7

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

إن محاولة بناء شبكة أمان من اختبارات الوحدات على تعليمات برمجية سيئة التصميم لن تضمن النجاح، بل ستجعلك تشعر بأمان أكبر بشأن تغييرها.

لذا، ما لم يكن لديك حجة تجارية قوية لتحمل المخاطر التي ينطوي عليها الأمر، فمن الأفضل أن تترك الأمر بمفردك بشكل كافٍ.