เมื่อใดที่จะชอบ ASP.NET WebForms มากกว่า MVC

ฉันรู้ว่า Microsoft ได้กล่าว

ASP.NET MVC ไม่ใช่การแทนที่สำหรับ WebForms

และนักพัฒนาบางคนบอกว่า WebForms นั้นพัฒนาได้เร็วกว่า MVC แต่ฉันเชื่อว่าความเร็วในการเขียนรหัสลงมาถึงระดับความสะดวกสบายด้วยเทคโนโลยีดังนั้นฉันไม่ต้องการคำตอบใด ๆ ในหลอดเลือดดำนั้น

เนื่องจาก ASP.NET MVC ให้นักพัฒนาสามารถควบคุมแอปพลิเคชันของตนได้มากขึ้นเหตุใด WebForm จึงไม่ถือว่าล้าสมัย อีกทางเลือกหนึ่งเมื่อใดที่ฉันควรสนับสนุน WebForms ผ่าน MVC สำหรับการพัฒนาใหม่

Webforms vs. MVC ดูเหมือนจะเป็นประเด็นร้อนแรงในตอนนี้ ทุกคนที่ฉันรู้จัก TVC MVC จะเป็นสิ่งที่ดีต่อไป จากการตบเบา ๆ เล็กน้อยของฉันในมันดูเหมือนว่าตกลง แต่ไม่มีฉันไม่คิดว่ามันจะเป็นจุดสิ้นสุดของเว็บฟอร์ม

เหตุผลของฉันและเหตุผลว่าทำไมเว็บฟอร์มจึงถูกเลือกผ่าน MVC นั้นมีส่วนเกี่ยวข้องกับมุมมองทางธุรกิจมากกว่าสิ่งที่ดีกว่าอีกด้านหนึ่ง

เวลา / เงินเป็นสาเหตุที่ยิ่งใหญ่ที่สุดที่เว็บฟอร์มจะถูกเลือกผ่าน MVC

หากทีมส่วนใหญ่ของคุณรู้จัก webforms และคุณไม่มีเวลาที่จะเพิ่มความเร็วให้กับ MVC รหัสที่จะใช้อาจไม่ได้คุณภาพ การเรียนรู้พื้นฐานของ MVC จากนั้นกระโดดเข้ามาและทำหน้าที่ซับซ้อนที่คุณต้องทำมีความแตกต่างกันมาก เส้นโค้งการเรียนรู้สูงดังนั้นคุณต้องคำนึงถึงปัจจัยที่เป็นงบประมาณของคุณ

หากคุณมีเว็บไซต์ขนาดใหญ่เขียนทั้งหมดในเว็บฟอร์มคุณอาจมีแนวโน้มที่จะสร้างหน้าใหม่ในเว็บฟอร์มเพื่อให้คุณไม่มีหน้าเว็บสองประเภทที่แตกต่างกันมากในเว็บไซต์ของคุณ

ฉันไม่ได้บอกว่ามันเป็นวิธีการทั้งหมดหรือไม่มีอะไรที่นี่ แต่มันจะทำให้รหัสของคุณยากขึ้นหากมีการแยกของทั้งสองโดยเฉพาะอย่างยิ่งถ้าไม่ใช่ทุกคนในทีมจะคุ้นเคยกับ MVC

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

เราจำเป็นต้องสร้างโครงสร้างโฟลเดอร์ใหม่ทั้งหมดสำหรับหน้าเหล่านี้เพื่อให้เป็นไปตามการแยก MVC ที่เหมาะสม

ฉันรู้สึกว่ามีไฟล์มากเกินไปสำหรับ 3 หน้า แต่นั่นเป็นความเห็นส่วนตัวของฉัน

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

ฉันได้พัฒนาแอปพลิเคชั่น ASP .Net WebForms เป็นเวลา 3 ปีและหลังจากวันหนึ่งในการสอน MVC ฉันถูกขาย MVC เกือบจะเป็นทางออกที่ดีกว่าเสมอ ทำไม?

• lifecylce หน้าง่ายและมีประสิทธิภาพมากขึ้น
• ไม่มีสิ่งนั้นเป็นตัวควบคุมนอกเหนือจากการควบคุม HTML คุณไม่จำเป็นต้องทำการดีบั๊กเอาต์พุตของคุณเพื่อดูว่า ASP .Net กำลังสร้างอะไร
• ViewModels ให้พลังอันยิ่งใหญ่และขจัดความจำเป็นที่จะต้องทำการควบคุมด้วยตนเองและกำจัดข้อผิดพลาดมากมายที่เกี่ยวข้องกับการรวม
• คุณสามารถมีหลายรูปแบบในหน้า นี่เป็นข้อ จำกัด ที่ร้ายแรงของ WebForms
• เว็บไร้สัญชาติและ MVC ตรงกับสถาปัตยกรรมของเว็บอย่างใกล้ชิดยิ่งขึ้น Webforms แนะนำสถานะและข้อบกพร่องที่คุณมีด้วยการแนะนำ ViewState ViewState เป็นไปโดยอัตโนมัติและทำงานในพื้นหลังจึงไม่ทำงานตามที่คุณต้องการ
• แอปพลิเคชันบนเว็บต้องทำงานกับ ajax ในทุกวันนี้ ไม่สามารถโหลดแบบเต็มหน้าได้อีกต่อไป MVC ทำให้อาแจ็กซ์ดีขึ้นง่ายขึ้นและมีประสิทธิภาพมากขึ้นด้วย JQuery
• เนื่องจากคุณสามารถมีหลายรูปแบบในหน้าและเนื่องจากสถาปัตยกรรมถูกขับเคลื่อนโดยการโทรไปยัง URL คุณสามารถทำสิ่งที่สนุก ๆ เช่น ajax โหลดรูปแบบที่แตกต่างกันเช่นรูปแบบการแก้ไขในหน้าปัจจุบันของคุณโดยใช้ JQuery เมื่อคุณตระหนักถึงสิ่งนี้จะช่วยให้คุณสามารถทำสิ่งที่น่าอัศจรรย์ได้อย่างง่ายดาย
• ASP. Net WebForms ไม่เพียง แต่เป็นนามธรรมมากกว่า html เท่านั้น แต่ยังเป็นสิ่งที่ซับซ้อนอย่างยิ่ง บางครั้งคุณจะได้รับข้อผิดพลาดที่แปลกและต่อสู้กับมันนานกว่าที่ต้องการ ในหลายกรณีคุณสามารถเห็นสิ่งที่เกิดขึ้นจริง แต่คุณไม่สามารถทำอะไรกับมันได้ คุณจบลงด้วยการทำวิธีแก้ปัญหาแปลก
• WebForms ไม่ได้สร้างเทคโนโลยีที่ดีสำหรับนักออกแบบ นักออกแบบมักจะชอบทำงานกับ html โดยตรง ใน MVC เป็นมุมมองใน WebForms เป็นเวลาครึ่งวัน
• ในฐานะที่เป็นแพลตฟอร์มเว็บที่มีการพัฒนาอย่างรวดเร็ว WebForms จะไม่รักษา ไม่ทราบว่ามีแท็กหรือคุณสมบัติใหม่ของ HTML5 แต่จะยังคงแสดงผลเหมือนเดิมเว้นแต่คุณจะได้รับการควบคุมจากบุคคลที่สามที่มีราคาแพง (หรือบ่อยครั้ง) หรือรอให้ Microsoft ออกการอัปเดต
• การควบคุมใน WebForms จำกัด คุณในหลาย ๆ ด้าน ใน MVC คุณสามารถคว้าไลบรารี JQuery และรวมเข้ากับเทมเพลตของคุณ

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

ฉันส่งอีเมลScott Guthrieเป็นผู้เชี่ยวชาญ MVCไมโครซอฟท์ และอาจเป็นคนที่มีคุณสมบัติเหมาะสมที่สุดในการตอบคำถามนี้ เขาใจดีพอที่จะตอบ:

"ลูกค้าที่แตกต่างกันมองหาวิธีการเขียนโปรแกรมที่แตกต่างกันและชอบ WebForms มากและคิดว่ามันยอดเยี่ยมคนอื่น ๆ ชอบ MVC และคิดว่ามันยอดเยี่ยมนั่นคือเหตุผลที่เราลงทุนทั้งสองอย่าง"

ดังนั้นสำหรับฉันนี่บอกว่ามันไม่ใช่ปัญหาทางเทคนิค มันเป็นมากกว่า "ปัญหาที่อ่อนนุ่ม" ถ้าคุณจะ หนึ่งในความชอบส่วนตัว นี่คือสิ่งที่คุณหลายคนพูด

ขอบคุณสำหรับคำตอบทั้งหมด

นี่เป็นคำถามเก่าที่มีคำตอบมากมาย แต่ไม่มีคำตอบที่ฉันคาดว่าจะปรากฏ

คำตอบสั้น ๆ คือ:

• ใช้ ASP.NET MVC หากคุณตั้งใจจะสร้างเว็บแอปพลิเคชั่นอย่างเหมาะสมด้วยรูปแบบการเขียนโปรแกรมที่ทันสมัยและรูปแบบการกอดอุตสาหกรรมสำหรับแพลตฟอร์ม ASP.NET ในด้านลงคุณจะต้องรู้ว่า HTML และทรัพยากรฝั่งไคลเอ็นต์ (Javascript, CSS) ทำงานอย่างไรและเพิ่มความคิดการเขียนโปรแกรม MVC ซึ่งมีช่วงการเรียนรู้ที่สูงชัน
• ใช้ ASP.NET Web Forms หากคุณกำลังใช้หรือต้องการใช้GUI -centric, RAD (การพัฒนาแอปพลิเคชันอย่างรวดเร็ว) , วิธีการลากแล้วปล่อยเพื่อทำต้นแบบอย่างรวดเร็วเช่นการกดปุ่ม / กริดข้อมูลที่มีสายภายใน 15 นาทีและโซลูชันไม่ได้ตั้งใจให้เป็นสิ่งที่นักพัฒนาสนับสนุน หรือใช้ ASP.NET Web Forms ถ้าคุณมีพื้นหลังในการพัฒนาGUIหรือ Windows Forms และคุณต้องการถ่ายโอนความรู้ของคุณไปยังเว็บ

แต่ถ้าจะดูอย่างนี้คุณต้องเข้าใจประวัติศาสตร์ของแต่ละคน

ASP.NET Web Forms คือคำตอบของ Microsoft สำหรับผู้ที่สร้างแอปพลิเคชันเว็บแบบไดนามิกโดยใช้ตัวควบคุม ActiveX 6 ของ Visual Basic, VB6 DLLs บนเซิร์ฟเวอร์และ ASP Classic ในขณะนั้นการพัฒนาเว็บโดยใช้เครื่องมือของ Microsoft เหล่านี้เป็นเรื่องยุ่งเหยิงจริง พร้อมด้วยความสมบูรณ์ของ. NET Framework ซึ่งเป็นผลลัพธ์ของ Microsoft โดยพื้นฐานแล้วจะกลับไปที่กระดานวาดภาพเกี่ยวกับวิธีการเขียนโปรแกรมทางธุรกิจที่มีประสิทธิภาพบนสแต็ก Windows, ASP.NET Web Forms เป็นในวันที่น่าตื่นตาตื่นใจและสวยงาม

แนวทางทั้งหมดคือการให้นักพัฒนาที่ดีที่สุดของโลกทั้งสองของสิ่งที่คล้ายกับการพัฒนาโปรแกรม Windows แต่ด้วยพลังของบริการอินเทอร์เน็ต แนวคิดก็คือเช่นเดียวกับ VB6 / WinForms "แบบฟอร์ม" (หน้าต่าง) เช่นเดียวกันกับหน้าเว็บที่เป็นรูปแบบ (เช่นเดียวกับหน้าต่างดู)และในแบบฟอร์มนั้นคุณสามารถลากและวางฉลากกล่องข้อความ กริดข้อมูล, ปุ่ม, และสิ่งอื่น ๆ ที่นักพัฒนา GUI ของ VB / WinForms คุ้นเคย

ในการทำปุ่มให้ทำอะไรบางอย่างหลังจากลากแล้วปล่อยคุณเพียงคลิกสองครั้งในตัวออกแบบและบูมคุณอยู่ในโปรแกรมแก้ไขโค้ดบอกรูปแบบว่าจะทำอย่างไรเมื่อเหตุการณ์ "คลิก" เกิดขึ้น นี่คือสิ่งที่นักพัฒนา Windows GUI สร้างซอฟต์แวร์โดยใช้เครื่องมือGUIของ VB6 และเครื่องมือการแข่งขันยกเว้นตอนนี้รหัสกำลังทำงานบนเซิร์ฟเวอร์! ว้าว!

นี่คือเทคโนโลยีปี 2002 ที่น่าตื่นตาตื่นใจและสวยงามในเวลานั้นเป็นคำตอบสำหรับโซลูชั่นGUI ที่เปิดใช้งานอินเทอร์เน็ตสำหรับการพัฒนาRADมันทำให้รู้สึกถึงพลังในโลกที่ยุ่งเหยิงของนักพัฒนาซอฟต์แวร์ที่มีวัตถุประสงค์ทางธุรกิจที่พวกเขาต้องการเพื่อให้บรรลุ

โชคไม่ดีที่รูปแบบการเขียนโปรแกรมนี้เน้นการเปรียบเทียบของการเขียนโปรแกรม Windows GUI ที่มีภาระในรายละเอียดการใช้งานที่จำเป็นกระเป๋าสัมภาระที่จำเป็นทั้งหมดเพื่อรองรับวงจรชีวิตเหตุการณ์และซ่อนรายละเอียดที่น่าเกลียดของ HTML แบบง่ายและ สคริปต์ที่คอมโพเนนต์การลากและวางเหล่านี้จะแสดงผล และในตอนท้ายของวันนักพัฒนาที่สนับสนุนแอปพลิเคชันจริงอย่างหลีกเลี่ยงไม่ได้ต้องเจาะลึกลงไปในส่วนประกอบเหล่านี้หรือเขียนของตัวเองและดังนั้นพวกเขาจะต่อสู้กับการต่อสู้กับโครงสร้างพื้นฐานนี้การต่อสู้ที่จะทิ้งกองไว้บนกอง cruft ดึงผมและ น้ำตา.

สำรองข้อมูล ล้างมือของคุณ. ลองดูที่ปัญหาทางธุรกิจอีกครั้ง วัตถุประสงค์ทางธุรกิจของเราคืออะไร

เราจำเป็นต้องสร้างและจัดการการใช้งานเว็บ ข้อ จำกัด ของเราคือเรามีเวิลด์ไวด์เว็บซึ่งตั้งอยู่บน HTTP, HTML, Javascript และ CSS และบนเซิร์ฟเวอร์เรามีกฎเกณฑ์ทางธุรกิจฐานข้อมูลและภาษาการเขียนโปรแกรมที่ยอดเยี่ยมเล็กน้อย (เช่น C #) เราต้องการคำอุปมา Windows GUI นี้เพื่อผลักดันวิธีการพัฒนาของเราหรือไม่? เหตุใดเราไม่สามารถมุ่งเน้นที่ปัญหาของแอปพลิเคชันและทำสิ่งที่เป็นอุปมาอุปมัย GUI ได้?

นี่คือที่มาของ ASP.NET MVC โดยเริ่มต้นจากการก่อจลาจลของนักพัฒนาที่เรียกตัวเองว่า "Alt.Net" ซึ่งต้องการกลับไปใช้หลักการพัฒนาซอฟต์แวร์ที่เหมาะสมและบริสุทธิ์ ไม่ต้องยุ่งยากและยุ่งยากอีกต่อไปเพียงแค่มุ่งเน้นไปที่วัตถุประสงค์ทางธุรกิจและแนวทางปฏิบัติที่ดีที่สุดของซอฟต์แวร์

สิ่งนี้แปลจริง ๆ ในกรณีนี้คือ:

1. แยกของความกังวล ตัวอย่างเช่นองค์ประกอบของข้อมูลไม่จำเป็นต้องทราบว่าข้อมูลจะแสดงผลอย่างไรและไม่ควรดูมาร์กอัปที่ถูกกำหนดด้วยรายละเอียดการกำหนดค่าการเชื่อมต่อฐานข้อมูล รหัสการทดสอบ
2. การเปิดรับและสนับสนุนอย่างเต็มที่สำหรับการสัมผัสกับ nitty ทรายของ HTML และทรัพยากรที่เกี่ยวข้อง ในเว็บฟอร์ม HTML จะถูกเก็บซ่อนไว้นักพัฒนาจะไม่สนับสนุนให้ยุ่งยาก ใน ASP.NET MVC ผู้พัฒนาได้รับการสนับสนุนให้จัดการรายละเอียดเหล่านั้น ในความเป็นจริงมันเป็นสิ่งจำเป็น ข้อได้เปรียบที่นี่คือผู้พัฒนาสามารถเรียนรู้อีกครั้งเพื่อชื่นชมความหมายที่ชัดเจนของ HTML, CSS และสคริปต์และทำงานร่วมกับมันแทนที่จะต่อต้าน
3. การตรวจสอบของวัตถุธุรกิจ ตัวควบคุมและแบบจำลองนั้นเหมาะสำหรับการทดสอบหน่วยการเขียนโปรแกรมเพื่อให้สามารถตรวจสอบการใช้งานเพื่อให้บรรลุตามวัตถุประสงค์ทางธุรกิจและการเปลี่ยนแปลงสามารถตรวจสอบได้ว่าจะไม่เกิดการแตกหัก ด้วยเว็บฟอร์มมันเป็นการยากที่จะทดสอบเนื่องจากส่วนประกอบไม่ได้ถูกออกแบบมาเพื่อทดสอบเป็นรายบุคคลและผลลัพธ์การพัฒนาทั้งหมดจะหมุนรอบรูปแบบหน้าและรอบอายุเหตุการณ์ของพวกเขาด้วยโคลนทางธุรกิจและตรรกะการนำเสนอที่เชื่อมโยงกันอย่างลึกซึ้ง

โปรดทราบว่า HTML เป็นภาษามาร์กอัประดับสูงอยู่แล้วเช่นเดียวกับ Javascript เป็นภาษาโปรแกรมระดับสูง เรื่องราวทั้งหมดจะแตกต่างกันไปถ้าเราติดต่อกับแอสเซมบลีภาษาและซี

จากการขยายไปสู่อันดับที่ 2 ดังนั้นวัตถุประสงค์อื่นของ ASP.NET MVC ก็คือช่วยให้นักพัฒนาสามารถจัดระเบียบรายละเอียดส่วนหน้าของส่วน 'มุมมอง' ของโซลูชันและใช้ประโยชน์จากรากฐานที่สมบูรณ์ซึ่งส่วนที่เหลือของอุตสาหกรรมได้สร้างขึ้น แพลตฟอร์มไคลเอ็นต์ส่วนหน้า

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

ฉันเป็นตัวแปลงที่สมบูรณ์และรวมเป็น ASP.NET MVC และไม่ได้มองย้อนกลับไปที่กล่าวว่าฉันยังคงต้องดูแลแอป WebForms ที่มีขนาดใหญ่มากหลายแห่ง นี่คือสิ่งที่ฉันจะทำ:

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

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

สรุปแล้วสำหรับฉันมันลงมาที่กริดและ! กริด :)

ประสบการณ์ของฉัน:

• เขียนโครงการ CakePHP เป็นเวลาหนึ่งปี
• เสร็จสิ้นโครงการ Webforms ขนาดกลางในระยะเวลาหกเดือน
• ทำงานในโครงการ Windows Forms เป็นเวลาสามปี

หลังจากประสบการณ์นั้นฉันพยายามเขียนแอปอื่นโดยใช้เว็บฟอร์มและรู้สึกท้อแท้หลังจากดิ้นรนมาประมาณหนึ่งวันว่าเว็บฟอร์มพยายามปกป้องนักพัฒนาจากความจริงที่ว่าพวกเขากำลังพัฒนาแอปพลิเคชันที่ใช้ html, javascript และ css

ฉันลองใช้ MVC และควบคุมการแสดงผลได้โดยตรง (และประสบการณ์บางอย่างกับกระบวนทัศน์ MVC จาก CakePHP) ฉันสามารถทำแอพพลิเคชั่นที่เรียบง่ายอย่างที่ฉันต้องการในเวลาประมาณ 1/2 วัน

ความพร้อมใช้งานของเฟรมเวิร์ก UI ที่ทรงพลังเช่น jQuery ช่วยลดความน่าสนใจในการยกเลิกการควบคุมโดยตรงของเอาต์พุตเพื่อสนับสนุนการใช้ส่วนประกอบ UI ที่สร้างไว้ล่วงหน้าที่มีขนาดใหญ่

ฉันชอบเว็บฟอร์มเพราะพื้นหลังของฉันคือการพัฒนาหน้าต่าง

Speed ​​of developmnt เป็นปัญหาสำคัญและฉันสามารถส่งปัญหาไปยังคนในอินเดียเพื่อแก้ไขข้ามคืนได้อย่างง่ายดายด้วยฟอร์มหากฉันมีปัญหาเกี่ยวกับความเร็วบนหน้าหนังสือที่ดีมากเกี่ยวกับความเร็ว asp.net นั้นมีประโยชน์ (Rick Kiessig เป็นผู้ชาย)

webforms สำหรับ ex windows people mvc สำหรับ web คน

แต่ในโลกสมัยใหม่ที่ริคเขียนหนังสือยอดเยี่ยมด้วยเซิร์ฟเวอร์ที่เพิ่มความเร็วในการเขียนโค้ดรายวันและราคาถูกในอินเดียเว็บฟอร์มมีความได้เปรียบ

2 เซ็นต์ของฉันคือการใช้ ASP.NET MVC สำหรับโครงการใหม่เสมอหากคุณมีตัวเลือก ในความคิดของฉัน webforms ไม่ใช่วิธีที่ดีในการพัฒนาเว็บแอพ

ฉันคิดว่าการสรุป REST พื้นฐานไม่ดีโมเดล postback ทั้งหมดไม่ดีวิธีที่ html / css มอบให้กับการพึ่งพาโปรแกรมแก้ไข GUI ไม่ดีการเน้นสิ่งต่าง ๆ เช่นพ่อมดและ GUI ในการตั้งค่าสิ่งต่าง ๆ แย่ URL ไม่ดี

ฉันได้อ่านคำตอบทั้งหมดและรู้สึกว่าประสบการณ์ส่วนตัวของฉันจะเพิ่มสิ่งที่คำตอบข้างต้น

3-4 ปีก่อนฉันพัฒนาโครงการเว็บไซต์ 2-3 รายการโดยใช้ Webforms ประมาณช่วงเวลานั้น MVC ไม่อยู่หรือไม่ได้ยินเลย การพัฒนาเป็นไปตามธรรมชาติ (ฉันมาจากการพัฒนารูปแบบวินโดยไม่ต้องมีประสบการณ์การพัฒนาเว็บมาก่อน) รวดเร็วสำหรับฉันเนื่องจากฉันไม่ต้องการเรียนรู้ HTML ในรายละเอียดและการควบคุมเว็บช่วยได้มาก .

ตอนนี้หลังจากนั้นฉันก็ไม่ได้ทำงานกับโปรเจ็กต์เว็บใด ๆ จนกระทั่งเมื่อเร็ว ๆ นี้

ไม่กี่วันก่อนฉันมีความคิดเกี่ยวกับเว็บไซต์และคิดว่าจะพัฒนามัน: คราวนี้เป็น MVC (ตั้งแต่พูดถึงทุกที่นอกจากฉันต้องเรียนด้วยเช่นกันดังนั้นฉันจึงเลือก MVC) โครงการยังอยู่ในช่วงการพัฒนาเนื่องจากฉันยังคงเรียนรู้และสร้างด้วยกัน

ดังนั้นความแตกต่างที่สำคัญฉันพบ b / w ทั้งสองมีดังนี้: -

• สำหรับคนที่มาจากการพัฒนา windows เว็บฟอร์มจะเป็นที่นิยมเสมอ Asp.net ช่วงการเรียนรู้สำหรับนักพัฒนา windows ค่อนข้างสูงชัน

• สำหรับคนที่มาจากการพัฒนาเว็บในเทคโนโลยีอื่น ๆ MVC จะได้รับความนิยมเพราะมันล้อเลียนล่าสุดของพวกเขาทั้งหมด

• การพัฒนานั้นง่ายขึ้นและสะอาดขึ้นใน MVC ถ้าคุณมีความรู้ HTML และ CSS เป็นอย่างดี

• การปรับใช้ยังคงเป็นปัญหา ในเว็บฟอร์มเราเพียงต้องการคัดลอกและวาง แต่นี่ต้องมีบางสิ่งที่จะต้องทำ

ในระยะสั้นพวกเขาทั้งสองจะอยู่ที่นี่สักพัก

ฉันยังไม่เห็นการพิจารณานี้หยิบยกอยู่ใน 15 คำตอบของกระทู้นี้ แต่ฉันคิดว่ามันคุ้มค่าที่จะพิจารณา

จากประสบการณ์เว็บฟอร์มของฉันคล้ายกับ Win Forms และ WPF มากกว่า MVC เมื่อพิจารณาสิ่งนี้ฉันคิดว่าอาจพิจารณาเลือกแบบฟอร์มเว็บเมื่อทีมมีประสบการณ์มากที่สุดในเทคโนโลยีประเภทนั้นหรือเมื่อโครงการเว็บฟอร์มจะส่งมอบอินเทอร์เฟซไปยังชุดข้อมูลเดียวกันกับแบบฟอร์มที่ชนะ (หรือพัฒนาพร้อมกัน) โครงการ WPF การทำเช่นนี้ช่วยให้นักพัฒนาสามารถข้ามระหว่างโครงการได้ง่ายขึ้นเนื่องจากตรรกะของแอปพลิเคชันอาจจะค่อนข้างคล้ายกันระหว่างทั้งสอง

ดังที่คำตอบอื่น ๆ ได้ชี้ให้เห็นการพัฒนาในกรอบ MVC นั้นคล้ายคลึงกับการพัฒนาเว็บใน Ruby, PHP, Python และอื่น ๆ มากกว่า Microsoft ดังนั้นทางเลือกของ MVC จะได้รับอิทธิพลจากประสบการณ์ของทีมในพื้นที่เหล่านั้นพร้อมกับปัจจัยที่ส่งมาในคำตอบอื่น ๆ

เหตุผลของเราที่จะไม่ไปที่ MVC เมื่อสองสามปีก่อนนั้นเป็นเทคโนโลยีที่ยังไม่บรรลุนิติภาวะจาก Microsoft ในช่วงไม่กี่ปีที่ผ่านมาเราได้กลายเป็นเวอร์ชันที่เป็นผู้ใหญ่มากขึ้น (4) และ MS ดูเหมือนจะได้ผลออกมาแล้ว อย่างไรก็ตามเรายังคงลังเลที่จะพัฒนาแอพ LOB หลัก ๆ โดยใช้ MVC เนื่องจากคุณสมบัติที่เราต้องการใช้ในเวอร์ชั่น 4 ต้องใช้เซิร์ฟเวอร์ windows 2012 (เว็บเบราเซอร์ใหม่ผ่าน IIS8) ฉันคิดว่าอีก 1 ปีเราจะรับ MVC ได้มากขึ้นเพราะหวังว่าจะมีการควบคุมจากบุคคลที่สามมากขึ้นเทคโนโลยีจะมีการตัดสินและเราจะมีโครงสร้างพื้นฐานเพื่อรองรับ

การตัดสินใจนี้ขึ้นอยู่กับความชอบของคุณตามความต้องการของคุณหรือแม้กระทั่งความรู้และประสบการณ์ของคุณ

เวลาในการฝึกอบรมการเรียนรู้ MVC หรือเวลาในการรับสินค้า ทุกสิ่งนี้มีความสำคัญในการเลือกโปรแกรมหนึ่งโปรแกรม

ไม่ว่าอย่างใดอย่างหนึ่งจะดีกว่าอีกเพียงทั้ง aproach หรือกรอบมีข้อดีและข้อเสีย

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

ความนับถือ,

เหตุผลเดียวที่ฉันจะเลือก WebForms แทน MVC คือเพราะคุณมีการควบคุม UI บุคคลที่สามสำหรับ WebForms มากกว่า MVC ฉันเลือก MVC เพราะฉันทำงานกับ WebForms มากเกินไปและฉันต้องการทำงานกับสิ่งใหม่ / ใหม่ แต่ยังคงมาจาก MS shop :)

โดยพื้นฐานแล้วไม่มีสิ่งใดที่จะป้องกันไม่ให้คุณปิด viewstate ใน WebForms และใช้ ViewModels และ if / for loops แทนการเชื่อมโยงโมเดลและการควบคุมฝั่งเซิร์ฟเวอร์

นี่คือ WebForms หรือรหัส MVC:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

ข้อ จำกัด เดียวที่ฉันพบใน WebForms คือถ้าคุณใช้ Dependency Injection / Inversion of Control คุณไม่สามารถสร้าง Constructor ได้เนื่องจากหน้า WebForms ต้องมี Constructor แบบไม่มีพารามิเตอร์ดังนั้นคุณต้องใช้การฉีดคุณสมบัติ นี่เป็นเรื่องใหญ่จริง ๆ หรือ

ASP.NET MVC เป็นคำตอบสำหรับ Ruby และเป็นวิธีที่ดีกว่าใหม่ยอดนิยมและ (IMO) ในการแยกเบราว์เซอร์ (ไคลเอนต์) ออกจากเซิร์ฟเวอร์ให้มากที่สุด

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

ASP.NET MVCแยกมุมมองและตัวควบคุมโดยการแยกการเชื่อมต่อแบบแน่นของไฟล์. aspx และไฟล์. aspx.cs ซึ่งมาพร้อมกับพวกเขาในเว็บฟอร์ม

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

ในความคิดของฉันพวกเขามีความเกี่ยวข้องมากพอและมีความสามารถในระดับเดียวกับที่ควรจะเป็น

นักพัฒนา WebForms ที่ยอดเยี่ยมสามารถผลิตผลิตภัณฑ์ที่มีประสิทธิภาพเท่าเทียมกันในฐานะนักพัฒนา MVC ที่ยอดเยี่ยม แต่นักพัฒนา WebForms ที่ยอดเยี่ยมที่พยายามบังคับตัวเองให้ยอมรับ MVC จะเกิดขึ้นในระยะสั้น เช่นเดียวกันสำหรับนักพัฒนา MVC ที่ยอดเยี่ยมที่ให้ WebForms ยิง

พวกเขาไม่ได้แยกจากกันอย่างสมบูรณ์และตราบใดที่ Microsoft ยังคงให้การสนับสนุนทั้งคู่ฉันเชื่อว่าคุณจะเห็นกลุ่มนักพัฒนาที่โดดเด่นสำหรับแต่ละคน

นี่คือทั้งหมดที่เกี่ยวกับการเลือกส่วนบุคคลโดยสมมติว่าเราทุกคนมีความเชี่ยวชาญในเทคโนโลยีที่เราใช้ ฉันใช้ WebForms ในการออกแบบมาหลายปีและต้องบอกว่าข้อเสียเพียงอย่างเดียวคือมันเป็นวิธีการที่เรียบง่ายทำให้หลายคนไม่ต้องใช้เวลาในการค้นพบความสามารถมากมาย

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

ขณะนี้ฉันรู้สึกสะดวกสบายที่จะใช้ทั้งเทคโนโลยีและฉันเลือกและเลือกตามสถานการณ์ การพูดอย่างตรงไปตรงมานั้นขึ้นอยู่กับคุณ แต่ความจริงยังคงอยู่ที่ทุกคนไม่ต้องใช้เวลาในการเรียนรู้อย่างลึกซึ้งว่าเทคโนโลยีเฉพาะใดที่มีความสามารถ

เมื่อประสบปัญหาการเขียนโปรแกรมฉันมักจะมองหาคำตอบที่เว็บ เว็บฟอร์มมีข้อมูล / ส่วนประกอบมากมายเกี่ยวกับการทำอะไรก็ได้ ใน MVC เนื่องจากแหล่งที่มาออนไลน์น้อยลงและเลเยอร์ของ abstractions ที่จำเป็นในการทำให้บางสิ่งบางอย่างทำงานได้ทำให้มีข้อ จำกัด ในสิ่งที่ฉันสามารถทำได้ MVC รวมฆ่าประสิทธิภาพการทำงานของฉันในฐานะนักพัฒนาในขณะที่มี Webforms ไม่เป็นเช่นนั้น ดังนั้นสำหรับตอนนี้ฉันติดอยู่กับเว็บฟอร์มจนกระทั่ง MVC ได้ครบกำหนดพอที่จะแทนที่

WebForms มีแหล่งข้อมูลการเรียนรู้เพิ่มเติม (เพียงเพราะมันเก่ากว่า) และทำให้โปรแกรมเมอร์ใหม่ที่ไม่ "รู้" จะมีแนวโน้มที่จะค้นหาข้อมูลเกี่ยวกับเทคโนโลยีเก่านี้มากกว่าที่จะเป็นสิ่งใหม่กว่าเช่น MVC .

โปรแกรมเมอร์อาวุโส / มีประสบการณ์นั้นมีอายุมากกว่าและจะมีความเชี่ยวชาญในเทคโนโลยีรุ่นเก่ามากขึ้นเนื่องจากพวกเขาได้ตั้งโปรแกรมไว้นานกว่ารุ่นใหม่กว่า

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

ดังนั้นจึงมีปัญหาด้านลอจิสติกส์หลายประการ: ประโยชน์ของ MVC มีมากกว่าค่าใช้จ่ายในแง่ของคุณภาพและเวลาในการติดตั้งที่น้อยลงหรือไม่ หากฉันมีเว็บไซต์ที่เขียนทั้งหมดใน WebForms มันจะคุ้มค่ากับความพยายามและเงินที่จะรวม MVC เข้ากับมันหรือไม่?

ตามที่ระบุไว้โดยผู้แสดงความคิดเห็นก่อนหน้านี้ MVC ยังป้องกันไม่ให้คุณได้รับอินเทอร์เฟซในระดับเดียวกันกับคอนโทรลเลอร์เช่นเดียวกับที่คุณสามารถใช้กับ WebForms ในขณะที่ฉันทุกคนสำหรับ "ป้องกันผู้ใช้จากการบรรจุสิ่งต่าง ๆ / การเรียนรู้" ของสิ่งต่าง ๆ มันยังคงเป็นปัญหาอย่างไม่มีเหตุผลสำหรับทีมในการปรับใช้ / ใช้โปรแกรมที่ติดอยู่กับกระบวนทัศน์ที่คลั่งไคล้สำหรับทุกสิ่งที่พวกเขาเขียน

ฉันคิดว่าช่องว่างระหว่างเทคโนโลยีทั้งสองนี้ไม่กว้างเท่าที่เคยเป็นมา

• เว็บฟอร์มสามารถใช้เอ็นจิ้นการกำหนดเส้นทางที่ MVC ใช้ (หรือสิ่งที่คล้ายกันมาก)
• ตัวจัดการสคริปต์สามารถรวมสคริปต์โหลดจาก CDN และแม้กระทั่งชะลอการโหลดสคริปต์

เพื่อตอบคำถามของคุณโดยตรงฉันคิดว่ามันขึ้นอยู่กับความชอบและ / หรือโครงการคืออะไร พวกเขาทั้งสองใช้แนวทางที่แตกต่างกันอย่างมีนัยสำคัญในการพัฒนา โดยส่วนตัวแล้วฉันกำลังทำงานเพื่อมุ่งสู่ MVC แต่ก็ยังสนุกกับการทำงานกับ Webforms ฉันคิดว่าคำตอบสำหรับคุณที่ควรใช้ MVC หรือ Webforms นั้นเพื่อให้คุณตัดสินใจผ่านการสัมผัสกับเทคโนโลยีทั้งสอง