Classic ASP เป็น ASP.net หรือ ASP.net MVC

เรามีเว็บแอพพลิเคชั่นที่พัฒนาใน ASP คลาสสิกและมันพัฒนามานานกว่า 5 ปีในรูปแบบปัจจุบันซึ่งมี 100 หน้า, ฐานข้อมูลขนาดใหญ่และผู้ใช้งานมากกว่า 10,000 คนที่ต้องผ่านอย่างน้อย 10 หน้าต่อวัน

ตอนนี้เราต้องการอัพเกรดเป็น. net รุ่นล่าสุด เริ่มแรกเราคิดว่าการเขียนแอพใหม่ทั้งหมด แต่หลังจากวิเคราะห์สถานการณ์แล้วเราพบว่าไม่ใช่ตัวเลือกที่ใช้การได้และผู้เชี่ยวชาญหลายคนยังไม่แนะนำ เรายังไม่ได้ตัดสินใจว่าจะทำในสิ่งอื่นอย่างไร แต่มีความคิดบางอย่างเกี่ยวกับวิธีการเขียนใหม่บนใบหน้า

ตัวเลือกที่ 1: เราคิดว่าจะระบุโมดูลหลักในแอปพลิเคชันนี้และเขียนใหม่ทีละรายการโดยแยกแอปพลิเคชันออกเป็นเลเยอร์ต่าง ๆ เช่นฐานข้อมูล (ปัจจุบัน) จากนั้นตรรกะทางธุรกิจและมุมมอง วิธีนี้โมดูลที่พัฒนาขึ้นใหม่จะถูกเพิ่มไปยังระบบที่มีอยู่และหน้าใหม่จะแทนที่หน้าเก่าในโมดูลนั้น ในเวลาเดียวกันเราสามารถทดสอบเลเยอร์ใหม่พร้อมกับระบบเก่าและปล่อยพวกเขาเมื่อเรารู้สึกมั่นใจ นอกจากนี้เรายังคิดถึงการพัฒนาโครงสร้าง API สำหรับตรรกะทางธุรกิจซึ่งจะสามารถเข้าถึงได้โดยดูเป็นแอปพลิเคชันภายนอก

ตัวเลือกที่ 2: ในขณะนี้เราได้ทำโมดูลอย่างง่ายและใช้มันในหน้า ASP คลาสสิกผ่าน IFrame แม้ว่ามันจะค่อนข้างลำบากในการส่งข้อมูลระหว่าง ASP คลาสสิกและหน้าใหม่ใน IFrame

นี่เป็นเพียงในขั้นตอนการวางแผนว่าเราควรบรรลุการเขียนใหม่ของแอปพลิเคชันทั้งหมดโดยไม่รบกวนฐานผู้ใช้อย่างไร

ฉันต้องการรับมุมมองโปรแกรมเมอร์ความคิดเห็นและข้อเสนอแนะอื่น ๆ ที่เราควรเข้าใกล้ในสถานการณ์ดังกล่าว? หากใครประสบสถานการณ์เช่นนี้กรุณาแบ่งปันความคิดเห็นของคุณด้วย

อยากทราบว่าการใช้ ASP.net MVC จะช่วยฉันได้อย่างไร

อัปเดต : ขอบคุณสำหรับคำตอบทั้งสองสำหรับการเพิ่มมุมมองของคุณ ต้องการรับอินพุตเพิ่มเติมจากตัวเลือกทั้งสองที่ฉันระบุไว้ข้างต้นในการย้ายแอปพลิเคชันจาก classic asp ไปยัง asp.net หรือ asp.net mvc มันจะเป็นความช่วยเหลือที่ดีสำหรับฉันถ้าคุณสามารถผ่านมุมมองจุดและความคิดของคุณในส่วนการโยกย้ายมากกว่าที่จะเลือก asp.net หรือ asp.net mvc

ให้ฉันเริ่มต้นด้วยการพูดว่า "ฉันรู้สึกถึงความเจ็บปวดของคุณ brutha" ฉันผ่านช่วง 3 ปีที่ผ่านมาและฉันหวังว่า MVC จะเติบโตเต็มที่เนื่องจากโซลูชัน WebForms ที่ฉันออกแบบค่อนข้างคล้ายกับรูปแบบ MVC โดยไม่ต้องมีห้องสมุด Microsoft ที่สร้างขึ้นสำหรับฉัน (แน่นอนมีการจ้องมองหลายอย่าง " ฉันทำอย่างนั้น "แตกต่าง)

ฉันลงเอยด้วยการใช้ iFrames เพื่อจัดการความแตกต่างของเนื้อหาโดยใช้. Net เป็นแอปพลิเคชันหลักและคลาสสิก asp เป็นทาส ฉันพัฒนาสถาปัตยกรรมเฟรมเวิร์กใน. Net และนำไปใช้ หน้า asp แบบคลาสสิกนั้นถูก "คัดสรร" ของชิ้นงานนำเสนอที่ไม่จำเป็น (รวมถึงและอะไรก็ตาม) และโหลดลงใน iFrames ข้อมูลถูกส่งผ่านเข้าไปใน url โดยใช้การเข้ารหัสที่กำหนดเอง เพื่อให้แน่ใจว่าการรับรองความถูกต้องไม่สามารถปลอมแปลงได้ง่ายและหน้าเว็บที่เข้าถึงได้โดยถอดรหัสสตริงการสืบค้นเรายังใช้ตัวจัดการ Wildcard ใน IIS ที่บังคับให้. Net ตรวจสอบความถูกต้องก่อนที่จะแยกหน้าคลาสสิก asp

ระบุว่าคำแนะนำของฉันจะมุ่งหน้าไปที่ MVC ทันที

1. MVC จะช่วยให้คุณเข้าถึงเส้นทางในระดับ global.asax ด้วยการควบคุมอย่างชาญฉลาดของคอนโทรลเลอร์คุณสามารถพัฒนาแบบจำลองของคุณในแบบที่เหมาะสมและมีตัวควบคุมทั่วไปที่จัดการคำขอ asp แบบคลาสสิคทั้งหมดตามความจำเป็น
2. MVC จะทำให้ง่ายมากในการเพิ่มโครงการทดสอบและอนุญาตให้คุณปรับโครงสร้างแอปพลิเคชันแต่ละชิ้นตามโครงสร้างโมเดลใหม่ในขณะที่ให้การครอบคลุมการทดสอบที่เพียงพอเพื่อให้แน่ใจว่าคุณได้รับสิ่งที่ถูกต้องทั้งหมด คุณค่าของสิ่งนี้ไม่สามารถคำนวณได้อย่างแน่นอนเพราะในการครอบคลุมรหัส refactor ใด ๆ เป็นเรื่องที่น่ากังวลอย่างมาก
3. MVC เป็นไปตามแนวทางของสคริปต์เพื่อนำเสนอมากกว่า WebForms WebForms พยายามที่จะผสมผสานมันทั้งหมดเหมือนมันเป็นแอปพลิเคชั่นที่เป็นรัฐ (ซึ่งไม่ใช่) และนั่นอาจเป็นเรื่องที่น่าตกใจสำหรับผู้ที่คุ้นเคยกับแอปคลาสสิค อย่าเข้าใจฉันผิดนักพัฒนาของคุณจะต้องตกตะลึงกับวัฒนธรรมไม่ว่าคุณจะไปทางไหน แต่ถ้าคุณสามารถทำให้ความตกตะลึงนั้นออกมาจากเลเยอร์การนำเสนอคุณอาจประสบความสำเร็จมากขึ้น

ฉันชอบทั้ง WebForms และ MVC (แม้ว่าฉันจะยอมรับด้วยการเปิดตัวมีดโกนฉันกำลังลำเอียงเล็กน้อยต่อ MVC) พวกเขาทั้งสองมีสถานที่ของพวกเขาและฉันคิดว่าแอปพลิเคชันเช่นที่คุณอธิบายอาจเหมาะอย่างยิ่งสำหรับการใช้งาน MVC โดยเฉพาะอย่างยิ่งในลักษณะ "เซ" คุณจะต้องนำมาใช้ในการนำชิ้นส่วน refactored

ไม่ว่าคุณจะไปทางไหนฉันคิดว่าคุณจำเป็นต้องตรวจสอบให้แน่ใจว่าแอปพลิเคชั่น. Net นั้นเป็นแอปพลิเคชันหลักเสมอเมื่อมีการตรวจสอบสิทธิ์ / การอนุญาต / การกำหนดเส้นทาง / ฯลฯ เพื่อนร่วมงานของฉันใช้การย้ายถิ่นของเขาในแอปพลิเคชันที่คล้ายกันกับ asp งูคลาสสิกในฐานะผู้ปกครองและเขามีปัญหาจำนวนมากในที่สุดเมื่อมันมาถึงการรวมทุกอย่างเข้าด้วยกัน

การใช้ ASP.NET MVC จะไม่ทำให้การเปลี่ยนแปลงง่ายขึ้นตามความเป็นจริงและในความเป็นจริงอาจทำให้ยากขึ้น อย่างไรก็ตามเมื่อคุณได้เลือกที่จะทำภารกิจที่ยิ่งใหญ่นี้ทำไมไม่ลองใช้เวลาในการเดินหน้าต่อและย้ายไปที่แพลตฟอร์มที่เหมาะกับแผนของคุณที่สุด

การย้ายไปยัง ASP.NET (sans MVC) จะเป็น "ง่ายขึ้น" ในแง่ที่ว่าคุณสามารถทำพอร์ตที่ตรงของตรรกะที่มีอยู่ของคุณได้โดยไม่ต้องทำการปรับเปลี่ยนที่ยิ่งใหญ่อีกต่อไปหากคุณไม่ได้ทำสิ่งแปลกใหม่มากมาย ASP แบบคลาสสิก ผลลัพธ์จะเป็นที่น่าพอใจและค่อนข้างคุ้นเคยกับผู้ที่คุ้นเคยกับแอปพลิเคชันอยู่แล้ว คุณจะได้รับประโยชน์ในแง่ที่ว่าทุกโปรแกรมรังเพลิงจาก ASP คลาสสิกไป ASP.NET ได้รับผลประโยชน์

การย้ายไปยัง ASP.NET MVC จะทำงานได้มากขึ้น เป็นไปได้ว่าจะต้องมีการออกแบบโครงสร้างแอปพลิเคชันของคุณใหม่เพื่อให้พอดีกับรูปแบบMVC โดยทั่วไปเป็นสิ่งที่ดีเพราะสนับสนุนพฤติกรรมที่ดีเช่นการแยกความกังวล แอปพลิเคชันที่เป็นผลลัพธ์จะไม่คล้ายกับสิ่งที่คุณมีอยู่อย่างใกล้ชิดยกเว้นชิ้นส่วนตรรกะหลัก คุณจะได้รับผลประโยชน์อื่น ๆ ได้เป็นอย่างดี มันจะเป็นการเปลี่ยนแปลงทางวัฒนธรรมครั้งใหญ่และจะต้องใช้เวลาศึกษาเรื่องทีมพัฒนาในการทำความเข้าใจ "วิธีการเขียน MVC" อย่างถูกต้อง

โปรดทราบว่าMicrosoft ไม่ได้ละทิ้ง WebFormsตาม ScottGu (เมื่อปีที่แล้ว) แต่ฉันไม่คิดว่าเป็นการยากที่จะโทรออกหากว่า / เมื่อพวกเขาตัดสินใจที่จะแยกเฟสหนึ่งในสองเทคโนโลยีออกมามันจะเป็น WebForms

ฉันเห็นด้วยอย่างยิ่งว่า ASP.NET MVC เป็นวิธีที่จะไป มันจะไม่ง่ายมันจะไม่ง่าย แต่แน่นอนว่ามันจะเป็นหลักฐานในอนาคตมากกว่า WebForms แม้ว่า WebForms จะไม่ถูกทอดทิ้ง แต่แอปพลิเคชันที่ใช้มันจะยุ่งยากมากขึ้นเมื่อแอปพลิเคชันเติบโตขึ้นและใหญ่ขึ้น

ฉันขอแนะนำให้ใช้ WebForms กับแอปพลิเคชัน "ใหญ่" อย่างยิ่ง

ฉันชอบตัวเลือกที่ 1) (ที่มี MVC) ดีกว่าตัวเลือกที่ 2) เนื่องจากมันช่วยให้คุณพัฒนาแอปพลิเคชั่นแบบเพิ่มขึ้นในขณะที่ไม่ต้องจับคู่แอพทั้งสองมากเกินไป

ฉันเคยมีประสบการณ์เกี่ยวกับการย้ายแอพเก่าไปยัง ASP.Net และหนึ่งในความท้าทายคือการแบ่งปันทรัพยากรบางอย่างเช่นสถานะเซสชันระหว่างแอปทั้งสอง สามารถแก้ไขได้โดยให้แอปหนึ่งโทรไปที่อีกฝั่งของเซิร์ฟเวอร์ผ่านข้อมูลคุกกี้จากเบราว์เซอร์ของผู้ใช้ การแบ่งปันข้อมูลระหว่างแอพอื่น ๆ สามารถทำได้ผ่านการกำหนดเส้นทาง URL และสตริงการสืบค้นซึ่งเป็นวิธีการที่เป็นธรรมชาติด้วย MVC

นอกจากนี้การระบุโมดูลที่เหมาะสมในการโยกย้ายก่อนสามารถเป็นสิ่งที่ท้าทาย แต่คุณสามารถเริ่มต้นด้วยฟังก์ชั่นใหม่ทั้งหมดที่ได้รับการพัฒนาบน MVC เพื่อป้องกันไม่ให้สิ่งต่าง ๆ สิ้นสุดลงในโรงรถที่จะโยกย้าย จากนั้นอาจเลือกส่วนที่มีงานค้างที่มีนัยสำคัญของการทำใหม่หรือแก้ไขข้อบกพร่องที่จะทำต่อไปเนื่องจากแอป MVC จะกลายเป็นรูปแบบของการปรับโครงสร้างโดยใช้ระบบเก่าของคุณเพื่อสร้างผลลัพธ์ที่คาดหวังตามที่คุณแนะนำ อย่าลืมที่จะใช้ประโยชน์จากความสามารถในการทดสอบของ MVC ด้วยการเพิ่มการทดสอบหน่วยและการทดสอบการยอมรับอัตโนมัติ (เช่น SpecFlow / Watin) ในระหว่างการปรับสภาพนี้ ข้อดีอย่างหนึ่งของการทดสอบประเภทหลังคือคุณสามารถตรวจสอบได้ว่าระบบเหล่านั้นผ่านระบบเก่าแล้วใช้การทดสอบเดียวกันกับรหัสใหม่ของคุณสำหรับการทำ refactorings นี้และในอนาคต