الهجرة من ASP Classic إلى .NET وتخفيف الألم

Question

نحن بصدد إعادة تصميم القسم الذي يتعامل مع العملاء في موقعنا في .NET 3.5.لقد سار الأمر على ما يرام حتى الآن، ونحن نستخدم نفس سير العمل والإجراءات المخزنة، في معظم الأحيان، أكبر التغييرات هي واجهة المستخدم، وORM (من القواميس إلى LINQ)، ومن الواضح أن اللغة.كانت معظم الصفحات حتى هذه اللحظة تافهة، ولكننا الآن نعمل على صفحات سير العمل الأكثر كثافة.

الصفحة الرئيسية لقسم قبول العرض لدينا هي 1500 سطر، حوالي 90% منها عبارة عن ASP، مع احتمال وجود 1000 سطر آخر في استدعاءات الوظائف المراد تضمينها.أعتقد أن السطور الـ 1500 خادعة بعض الشيء أيضًا نظرًا لأننا نعمل مع أحجار كريمة كهذه

function GetDealText(sUSCurASCII, sUSCurName, sTemplateOptionID, sSellerCompany, sOfferAmount, sSellerPremPercent, sTotalOfferToSeller, sSellerPremium, sMode, sSellerCurASCII, sSellerCurName, sTotalOfferToSeller_SellerCurr, sOfferAmount_SellerCurr, sSellerPremium_SellerCurr, sConditions, sListID,  sDescription, sSKU, sInv_tag, sFasc_loc, sSerialNoandModel, sQTY, iLoopCount, iBidCount, sHTMLConditions, sBidStatus, sBidID, byRef bAlreadyAccepted, sFasc_Address1, sFasc_City, sFasc_State_id, sFasc_Country_id, sFasc_Company_name, sListingCustID, sAskPrice_SellerCurr, sMinPrice_SellerCurr, sListingCur, sOrigLocation)

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

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

Answer 1

صدقني، أنا أعلم بالضبط من أين أتيت ..أقوم حاليًا بترحيل تطبيق كبير من ASP classic إلى .NET..وما زلت أتعلم ASP.NET!:S (نعم، أنا مرعوب!).

أهم الأشياء التي احتفظت بها في ذهني هي:

• أنا لا أضل أيضاً بعيدًا عن التصميم الحالي (أيلا يوجد ضخم "دعونا نمزق كل هذا ونجعل ASP.NET سحريًا!) نظرًا للقدر الكبير بشكل لا يصدق من أدوات الاقتران التي يميل إليها ASP الكلاسيكي، سيكون هذا خطيرًا للغاية.بالطبع، إذا كنت واثقًا من ذلك، املأ حذاءك :) يمكن دائمًا إعادة هيكلة هذا لاحقًا.
• قم بعمل نسخة احتياطية من كل شيء مع الاختبارات والاختبارات والمزيد من الاختبارات!أنا حقًا أحاول جاهدة الدخول إلى TDD، ولكن من الصعب جدًا اختبار التطبيقات الحالية، لذلك في كل مرة أقوم فيها بإزالة جزء من التطبيقات الكلاسيكية واستبدالها بـ .NET، أضمن حصولي على أكبر قدر ممكن من اختبارات الضوء الأخضر التي تدعمني.
• بحث كثيرًا، هناك بعض التغييرات الرئيسية بين Classic و.NET وفي بعض الأحيان يمكن تحقيق ما يمكن أن يكون عدة أسطر من التعليمات البرمجية ويتضمنها الكلاسيكي في بضعة أسطر من التعليمات البرمجية، يفكر قبل التشفير..لقد تعلمت هذا بالطريقة الصعبة عدة مرات:D

إنه يشبه اللعب إلى حد كبير جينجا مع الكود الخاص بك :)

حظا موفقا في المشروع، أي أسئلة أخرى، يرجى طرحها :)

Answer 2

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

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

اكتب بعض الاختبارات أولًا والتي تتحقق مما تفعله القطعة التي تنظر إليها بالفعل.ثم إعادة البناء.وهذا أكثر موثوقية بكثير من مجرد "يبدو أنه لا يزال يعمل".

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

Answer 3

هل ستنتقل من ASP الكلاسيكي إلى ASP مع 3.5 دون إعادة الكتابة فقط؟سكيلز.لقد اضطررت إلى التعامل مع بعض أعمال ASP القديمة وأعتقد أنه من الأسهل تحليلها وإعادة كتابتها.

Answer 4

صفحة ASP مكونة من 1500 سطر؟مع وجود الكثير من المكالمات لتضمين الملفات؟لا تخبرني - لا تحتوي الوظائف على أي اصطلاح تسمية يخبرك بملف التضمين الذي تم تنفيذه ...وهذا يعيد الذكريات (الارتعاش) ...

يبدو لي أن لديك نهجًا قويًا جدًا - لست متأكدًا مما إذا كانت هناك أي طريقة سحرية لتخفيف الألم.بعد جهود التحويل، ستظل بنية تطبيقك فوضوية ومثقلة بواجهة المستخدم (على سبيل المثال:التعليمات البرمجية خلف سير العمل قيد التشغيل)، ومن المحتمل أن تظل المحافظة عليه مؤلمة إلى حد ما، ولكن إعادة البناء التي تقوم بها يجب أن تساعد بالتأكيد.

أتمنى أن تكون قد قمت بموازنة الترقية التي تقوم بها مقابل مجرد إعادة الكتابة من الصفر - طالما أنك لا تنوي توسيع التطبيق أكثر من اللازم ولست مسؤولاً بشكل أساسي عن صيانة التطبيق، وترقية تطبيق معقد يعتمد على سير العمل مثلك قد يكون ما نقوم به أرخص وخيارًا أفضل من إعادة كتابته من الصفر.من المفترض أن يمنحك ASP.NET فرصًا أفضل لتحسين الأداء وقابلية التوسع، على الأقل، مقارنة بـ Classic ASP.من سؤالك أتصور أن الوقت قد فات في عملية تلك المناقشة على أي حال.

حظ سعيد!

Answer 5

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

بالنسبة للملفات الأكبر حجمًا، سأحاول الحصول على عرض بمستوى أعلى أولاً.على سبيل المثال، أحد الأشياء التي لاحظتها هو أن Classic ASP كان سيئًا فيما يتعلق باستدعاءات الوظائف.ستقرأ بعض التعليمات البرمجية وتجد استدعاءً لوظيفة دون أي دليل حول المكان الذي يمكن تنفيذه فيه.ونتيجة لذلك، تميل أكواد ASP الكلاسيكية إلى أن تحتوي على وظائف ونصوص طويلة لتجنب تلك القفزات السيئة.أتذكر رؤية وظيفة تمت طباعتها إلى 40 صفحة!إن التحليل مباشرة عبر هذا القدر من التعليمات البرمجية ليس أمرًا ممتعًا.

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

Answer 6

لا تخبرني - لا تملك الوظائف أي اتفاقية تسمية تخبرك والتي تشمل الملف لها تنفيذها ...هذا يعيد الذكريات (ارتجف) ...

كيف حزرت؟;)

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

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

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

لقد شعرت بالفعل بهذا الاستياء من العمل مع الكود القديم إلى حد ما، لذا لدي فهم جيد وعالي المستوى للنظام.أنت على حق بشأن طول الوظيفة، هناك بعض الإجراءات (معظمها قمت بإعادة هيكلتها إلى إجراءات أصغر بكثير) والتي يبلغ طولها 3-4x طالما أي من صفحات aspx/فئات المساعدة/ORMs على الموقع الجديد.

Answer 7

لقد عثرت ذات مرة على تطبيق .Net تم نقله من ASP.كانت صفحات .aspx فارغة تمامًا.لعرض واجهة المستخدم، استخدم المطورون StringBuilders في الكود الموجود خلفهم ثم قاموا بإجراء استجابة.ستكون هذه الطريقة الخاطئة للقيام بذلك!

Answer 8

لقد عثرت ذات مرة على تطبيق .Net تم نقله من ASP.كانت صفحات .aspx فارغة تمامًا.لعرض واجهة المستخدم، استخدم المطورون StringBuilders في الكود الموجود خلفهم ثم قاموا بإجراء استجابة.ستكون هذه الطريقة الخاطئة للقيام بذلك!

لقد رأيت الأمر يتم بالطريقة الأخرى، حيث كان الكود الموجود خلف الصفحة فارغًا، باستثناء إعلان العوالم، ثم تم ترك VBScript في ASPX.