ทุกคนที่อยู่ข้างฉันไม่ได้รับ ASP.NET MVC หรือไม่ [ปิด]

ฉันเล่นซอกับ ASP.NET MVC ตั้งแต่ CTP และฉันชอบสิ่งต่าง ๆ มากมายที่พวกเขาทำ แต่มีบางสิ่งที่ฉันไม่ได้รับ

ตัวอย่างเช่นฉันดาวน์โหลด beta1 และฉันได้รวบรวมเว็บไซต์ส่วนตัว / ประวัติย่อ / บล็อกไว้ด้วยกัน นี่คือตัวอย่างข้อมูลจากมุมมอง ViewSinglePost:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

น่าขยะแขยง! (นอกจากนี้ทราบว่า HTML มี HTML ยึดชั่วคราวฉันจะทำให้การออกแบบที่เกิดขึ้นจริงที่ครั้งหนึ่งเคยทำงานเป็นคนที่ทำงาน)

ฉันกำลังทำอะไรผิดหรือเปล่า? เพราะฉันใช้เวลาหลายวันใน ASP คลาสสิกและซุปแท็กนี้ทำให้ฉันนึกถึงอย่างมาก

ทุกคนบอกกล่าวว่าคุณจะทำความสะอาด HTML ได้อย่างไร เดาอะไร 1% ของคนทั้งหมดมองไปที่ HTML ที่แสดงผล สำหรับฉันฉันไม่สนใจว่า Webforms ทำให้การเยื้องของฉันใน HTML ที่เรนเดอร์ตราบใดที่ฉันมีรหัสที่ง่ายต่อการบำรุงรักษา ... นี่ไม่ใช่!

ดังนั้นแปลงให้ฉันเป็นคนที่ชอบใช้เว็บฟอร์มยากทำไมฉันควรยกเลิกเพจ ASPX ที่ได้รับการขึ้นรูปอย่างดีเพื่อสิ่งนี้

แก้ไข:ทำให้บรรทัด "temp Html / css" เป็นตัวหนาเพื่อให้ผู้คนสนใจ

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

เว็บฟอร์ม

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

MVC

MVC ให้มุมมอง "สถาปัตยกรรม" ที่มากขึ้นเกี่ยวกับการพัฒนาเว็บแอปพลิเคชัน: เสนอโครงนั่งร้านที่ได้มาตรฐานเพื่อสร้าง นอกจากนี้ยังมีเครื่องมือสำหรับสร้างโมเดลมุมมองและคลาสตัวควบคุมโดยอัตโนมัติภายในสถาปัตยกรรมที่สร้างไว้แล้ว ตัวอย่างเช่นใน Ruby on Rails (เพียงแค่ "Rails" จากที่นี่ออก) และ ASP.NET MVC คุณจะเริ่มต้นด้วยโครงสร้างไดเรกทอรีที่สะท้อนถึงรูปแบบโดยรวมของสถาปัตยกรรมเว็บแอปพลิเคชัน ในการเพิ่มมุมมองแบบจำลองและตัวควบคุมคุณจะต้องใช้คำสั่งเช่น "Rails script / create scaffold {modelname}" ของ Rails (ASP.NET MVC มีคำสั่งที่คล้ายกันใน IDE) ในคลาสคอนโทรลเลอร์ที่ได้ผลลัพธ์จะมีวิธีการ ("การกระทำ") สำหรับดัชนี (รายการแสดง), แสดง, ใหม่และแก้ไขและทำลาย (อย่างน้อยใน Rails, MVC จะคล้ายกัน) โดยค่าเริ่มต้นเหล่านี้ "

เลย์เอาต์ของไดเรกทอรีและไฟล์มีความสำคัญใน MVC ตัวอย่างเช่นใน ASP.NET MVC วิธีการทำดัชนีสำหรับวัตถุ "หนังสือ" น่าจะมีเพียงหนึ่งบรรทัด: "Return View ();" ด้วยความมหัศจรรย์ของ MVC สิ่งนี้จะส่งแบบจำลองหนังสือไปยังหน้า "/View/Books/Index.aspx" ซึ่งคุณจะพบรหัสเพื่อแสดงหนังสือ วิธีการของ Rails นั้นคล้ายคลึงกันแม้ว่าตรรกะจะค่อนข้างชัดเจนและมีเวทมนตร์น้อยกว่า ดูหน้าแอป MVC มักจะง่ายกว่าหน้าเว็บฟอร์มเพราะพวกเขาจะได้ไม่ต้องกังวลมากเกี่ยวกับการกำหนดเส้นทางตรรกะทางธุรกิจหรือการจัดการข้อมูล

การเปรียบเทียบ

ข้อดีของ MVC คือการแยกข้อกังวลออกมาให้สะอาดและโมเดล HTML / CSS / AJAX / Javascript-centric สิ่งนี้ช่วยเพิ่มความสามารถในการทดสอบให้การออกแบบที่เป็นมาตรฐานมากขึ้นและเปิดประตูสู่เว็บไซต์ "Web 2.0" มากขึ้น

อย่างไรก็ตามมีข้อเสียที่สำคัญเช่นกัน

ครั้งแรกในขณะที่มันง่ายที่จะทำให้ไซต์ตัวอย่างดำเนินต่อไปโมเดลสถาปัตยกรรมโดยรวมมีช่วงการเรียนรู้ที่สำคัญ เมื่อพวกเขาพูดว่า "Convention Over Configuration" มันฟังดูดี - จนกว่าคุณจะรู้ว่าคุณมีหนังสือเรียนรู้ที่คุ้มค่า นอกจากนี้ก็มักจะเป็นบิตคลั่งที่จะคิดออกสิ่งที่เกิดขึ้นเพราะคุณจะอาศัยมายากลมากกว่าการโทรอย่างชัดเจน ตัวอย่างเช่น "Return View ();" โทรไปด้านบน การโทรเดียวกันนั้นสามารถพบได้ในการดำเนินการอื่น แต่ไปที่อื่น หากคุณเข้าใจอนุสัญญา MVCแล้วคุณจะรู้ว่าทำไมสิ่งนี้ถึงเกิดขึ้น อย่างไรก็ตามมันไม่ได้มีคุณสมบัติเป็นตัวอย่างของการตั้งชื่อที่ดีหรือรหัสที่เข้าใจได้ง่ายและเป็นเรื่องยากสำหรับนักพัฒนาใหม่ที่จะหยิบขึ้นมาจากเว็บฟอร์ม (นี่ไม่ใช่ความเห็น: ฉันมีฝึกงานในช่วงฤดู และ MVC ในปีนี้และความแตกต่างในการผลิตมีความเด่นชัด - ในความโปรดปรานของเว็บฟอร์ม) BTW, Rails ดีขึ้นเล็กน้อยในเรื่องนี้แม้ว่า Ruby on Rails จะมีวิธีการตั้งชื่อแบบไดนามิกที่จะทำให้เกิดความคุ้นเคยกับการใช้งานเช่นกัน

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

ประการที่สามถ้าคุณไม่สนใจ Linq (เพราะคุณกลัวว่า Linq-to-SQL กำลังจะหายไปหรือเพราะคุณพบว่า Linq-to-Entities หัวเราะเกินกำลังและอยู่ภายใต้การขับเคลื่อน) คุณก็ไม่ต้องการ ที่จะเดินเส้นทางนี้ตั้งแต่เครื่องมือ ASP.NET MVC นั่งร้านสร้างรอบ Linq (นี่คือนักฆ่าสำหรับฉัน) แบบจำลองข้อมูลของ Rails นั้นค่อนข้างงุ่มง่ามเมื่อเทียบกับสิ่งที่คุณสามารถทำได้หากคุณมีประสบการณ์ใน SQL (และโดยเฉพาะอย่างยิ่งถ้าคุณมีความรอบรู้ใน TSQL และขั้นตอนการจัดเก็บ!)

ประการที่สี่ผู้สนับสนุน MVC มักชี้ให้เห็นว่ามุมมอง MVC ใกล้เคียงกับรูปแบบ HTML / CSS / AJAX ของเว็บมากขึ้น ตัวอย่างเช่น "HTML Helpers" - การเรียกใช้โค้ดขนาดเล็กในหน้า vew ของคุณที่สลับไปมาในเนื้อหาและวางลงในการควบคุม HTML - ง่ายต่อการรวมเข้ากับ Javascript มากกว่าการควบคุมแบบฟอร์มบนเว็บ อย่างไรก็ตาม ASP.NET 4.0 แนะนำความสามารถในการตั้งชื่อการควบคุมของคุณและกำจัดข้อดีนี้เป็นส่วนใหญ่

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

สรุปผลการวิจัย

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

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

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

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

สำหรับคนที่เห็นว่านี่เป็นการต่อสู้ทางศาสนาและผู้ที่ควบคุมอุทกภัยอย่างไม่ลดละฉันไม่เข้าใจว่าทำไมคุณถึงต้องรำคาญ (20 คะแนนขึ้นไปภายในไม่กี่วินาทีในหลาย ๆ ครั้งไม่เหมือนกัน) หากคุณกำลังอ่านคำตอบนี้และสงสัยว่ามีบางสิ่งที่ "ผิด" อย่างแท้จริงเกี่ยวกับคำตอบของฉันเนื่องจากคะแนนนั้นต่ำกว่าคำตอบอื่น ๆ โปรดมั่นใจได้ว่าจะพูดถึงคนไม่กี่คนที่ไม่เห็นด้วยมากกว่าความรู้สึกทั่วไปของ ชุมชน (โดยรวมแล้วชุมชนนี้ได้รับการปรับปรุงให้ดีขึ้นมากกว่า 100 ครั้ง)

ความจริงก็คือนักพัฒนาหลายคนไม่สนใจ MVC และนี่ไม่ใช่มุมมองของชนกลุ่มน้อย (แม้แต่ใน MS เพราะบล็อกดูเหมือนจะบ่งบอก)

MVC ช่วยให้คุณควบคุมผลลัพธ์ได้มากขึ้นและด้วยการควบคุมนั้นมีความเสี่ยงมากขึ้นในการเขียน HTML ที่ออกแบบมาไม่ดีแท็กซุปแท็ก ฯลฯ

แต่ในเวลาเดียวกันคุณมีตัวเลือกใหม่มากมายที่คุณไม่เคยมีมาก่อน ...

1. ควบคุมหน้าและองค์ประกอบต่างๆในหน้าได้ดียิ่งขึ้น
2. "ขยะ" น้อยลงในผลลัพธ์ของคุณเช่น ViewState หรือ ID ที่ยาวเกินไปในองค์ประกอบ(อย่าเข้าใจฉันผิดฉันชอบ ViewState)
3. ความสามารถที่ดีกว่าในการเขียนโปรแกรมฝั่งไคลเอ็นต์ด้วย Javascript (ทุกเว็บแอปพลิเคชัน 2.0)
4. ไม่เพียงแค่ MVC แต่ JsonResult นั้นลื่น ...

ตอนนี้ไม่ได้บอกว่าคุณไม่สามารถทำสิ่งเหล่านี้กับ WebForms ได้ แต่ MVC ทำให้ง่ายขึ้น

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

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

[Update]

หากเป็นการปลอบใจใด ๆ เช่นกัน MVC เป็นเพียงเทคโนโลยีใหม่ที่กำลังพัฒนาจาก Microsoft มีการโพสต์มากมายที่ WebForms จะไม่เพียง แต่ยังคงพัฒนาต่อไป ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... และอื่น ๆ ...

สำหรับผู้ที่กังวลเกี่ยวกับเส้นทาง MVC กำลังใช้งานฉันขอแนะนำให้คุณแสดงความคิดเห็น ดูเหมือนว่าพวกเขากำลังฟังอยู่!

การคัดค้านส่วนใหญ่ของ ASP.NET MVC นั้นดูเหมือนว่าจะอยู่กึ่งกลางมุมมองซึ่งเป็นหนึ่งในบิตที่เป็นตัวเลือกและบิตแบบแยกส่วนในสถาปัตยกรรม NVelocity , NHaml , Spark , XSLT และเอ็นจิ้นการดูอื่น ๆ สามารถสลับกันได้อย่างง่ายดาย (และมันก็ง่ายขึ้นสำหรับการเปิดตัวทุกครั้ง) หลายคนมีไวยากรณ์ที่กระชับมากขึ้นสำหรับการทำตรรกะการนำเสนอและการจัดรูปแบบในขณะที่ยังคงให้การควบคุมที่สมบูรณ์เกี่ยวกับ HTML ที่ปล่อยออกมา

นอกจากนั้นการวิจารณ์เกือบทุกครั้งดูเหมือนว่าจะลงไปที่การติดแท็ก <%%> ในมุมมองเริ่มต้นและวิธีการที่ "น่าเกลียด" ความคิดเห็นนั้นมักจะถูกรูทในการใช้กับวิธีการของ WebForms ซึ่งเพิ่งย้ายความอัปลักษณ์ ASP แบบคลาสสิกส่วนใหญ่ไปยังไฟล์ code-behind

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

ปัญหาที่ใหญ่ที่สุดของ "สปาเก็ตตี้" ที่ขับเคลื่อนด้วยแท็กซุปนั้นเกี่ยวกับการผลักสิ่งต่าง ๆ เช่นการเชื่อมต่อฐานข้อมูลระหว่าง HTML

ว่ามันเกิดขึ้นกับการใช้ <%%> เป็นเพียงความสัมพันธ์กับธรรมชาติปาเก็ตตี้ของ ASP คลาสสิกไม่ใช่สาเหตุ หากคุณให้ตรรกะการดูของคุณเป็น HTML / CSS / Javascript และตรรกะขั้นต่ำที่จำเป็นในการทำการนำเสนอส่วนที่เหลือเป็นไวยากรณ์

เมื่อเปรียบเทียบการทำงานกับ WebForms ให้แน่ใจว่าได้รวม C # ทั้งหมดที่ผู้ออกแบบสร้างขึ้นและรหัสที่อยู่เบื้องหลัง C # พร้อมกับรหัส. aspx เพื่อให้แน่ใจว่าโซลูชัน MVC นั้นไม่ง่ายจริง ๆ .

เมื่อรวมกับการใช้มุมมองบางส่วนอย่างรอบคอบสำหรับบิตของการนำเสนอที่ทำซ้ำได้มันจะดีและสง่างาม

โดยส่วนตัวแล้วฉันต้องการเนื้อหาการสอนที่เน้นไปที่ส่วนท้ายของเรื่องนี้มากกว่าในการทดสอบการควบคุมการผกผัน ฯลฯ ในขณะที่เนื้อหาอื่น ๆ นั้นเป็นสิ่งที่ผู้เชี่ยวชาญคัดค้านพวกที่อยู่ในร่องลึกมีแนวโน้มมากกว่า เพื่อคัดค้าน "tag soup"

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

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

คุณสามารถโพสต์อีกครั้งโดยถามว่าทำได้อย่างไรโดยไม่รวม CSS ที่ฝังไว้

หมายเหตุ: ViewData.Model กลายเป็นรุ่นในรุ่นถัดไป

และด้วยความช่วยเหลือของการควบคุมผู้ใช้สิ่งนี้จะกลายเป็น

<% Html.RenderPartial("Pager", Model.PagerData) %>

โดยที่ PagerData ถูกเตรียมใช้งานผ่านตัวสร้างแบบไม่ระบุชื่อในตัวจัดการการดำเนินการ

แก้ไข: ฉันอยากรู้ว่าการใช้ WebForm ของคุณจะเป็นอย่างไรสำหรับปัญหานี้

ฉันไม่แน่ใจในสิ่งที่ผู้คนหยุดใส่ใจรหัสของพวกเขา

HTML เป็นงานแสดงที่เปิดเผยต่อสาธารณชนมากที่สุดมีนักพัฒนามากมายที่ใช้ Notepad, notepad ++ และเครื่องมือแก้ไขข้อความธรรมดาอื่น ๆ เพื่อสร้างเว็บไซต์จำนวนมาก

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

หากคุณต้องการการควบคุมทำความสะอาดรหัสและใช้รูปแบบการออกแบบ MVC สำหรับคุณถ้าคุณไม่ชอบทำงานกับมาร์กอัปไม่ต้องสนใจว่ามาร์กอัปของคุณมีรูปแบบไม่ถูกต้องอย่างไรให้ใช้ ASP.Net Web Forms

หากคุณไม่ชอบคุณก็จะต้องทำงานให้มากขึ้นใน markup

แก้ไข ฉันควรระบุว่าเว็บฟอร์มและ MVC มีสถานที่ของพวกเขาฉันไม่เคยระบุว่าเว็บฟอร์มใดดีกว่าอีกเว็บหนึ่งเฉพาะว่าแต่ละ MVC มีความแข็งแกร่งในการควบคุมมาร์กอัปอีกครั้ง

ฉันคิดว่าคุณขาดอะไรไป ก่อนอื่นไม่จำเป็นต้องมี Response.Write คุณสามารถใช้<%= %>แท็กได้ ประการที่สองคุณสามารถเขียนส่วนขยาย HtmlHelper ของคุณเองเพื่อดำเนินการทั่วไป ประการที่สามการฟอร์แมตเล็กน้อยช่วยได้มาก ประการที่สี่ทั้งหมดนี้อาจจะติดอยู่ในการควบคุมของผู้ใช้ที่จะแชร์ระหว่างมุมมองที่แตกต่างกันหลายมุมมองและทำให้เครื่องหมายโดยรวมในมุมมองหลักสะอาดขึ้น

ฉันจะให้คุณว่าเครื่องหมายยังไม่เรียบร้อยเท่าที่ต้องการ แต่สามารถล้างได้อย่างมากผ่านการใช้ตัวแปรชั่วคราวบางอย่าง

ตอนนี้มันไม่ได้แย่มากและมันจะดียิ่งขึ้นถ้าฉันไม่ต้องจัดรูปแบบสำหรับ SO

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

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

เรื่องใหญ่ของ Ruby on Rails คืออะไร? Rails คือ MVC นักพัฒนาได้รับการแปลงเพราะโดยคำพูดจากปากมันเป็นวิธีสำหรับโปรแกรมเมอร์ที่จะมีประสิทธิผล

มันเป็นเรื่องใหญ่ MVC และการรับรองโดยนัยของ jQuery เป็นจุดเปลี่ยนสำหรับ Microsoft ที่ยอมรับว่าแพลตฟอร์มที่เป็นกลางมีความสำคัญ และสิ่งที่เป็นกลางเกี่ยวกับเรื่องนี้คือไม่เหมือนกับเว็บฟอร์ม Microsoft ไม่สามารถล็อคคุณในเชิงแนวคิด คุณสามารถใช้รหัส C # ทั้งหมดของคุณและนำมาใช้ใหม่ในภาษาอื่นทั้งหมด (เช่น PHP หรือ java - คุณตั้งชื่อ) เพราะเป็นแนวคิด MVC ที่พกพาได้ไม่ใช่รหัสเอง (และคิดว่ามันใหญ่แค่ไหนที่คุณสามารถออกแบบและใช้มันเป็นแอพเวิร์กสเตชันที่มีการเปลี่ยนแปลงรหัสเล็กน้อยและไม่มีการเปลี่ยนแปลงการออกแบบลองใช้กับเว็บฟอร์ม)

Microsoft ได้ตัดสินใจว่าเว็บฟอร์มจะไม่ใช่ VB6 ถัดไป

โปรดดูที่โพสต์ของ Rob Conery ที่ฉัน Spose ฉันจะพูดมัน: คุณควรเรียนรู้ MVC

ข้อดีหลักสองประการของกรอบงาน ASP.NET MVC บนเว็บฟอร์มคือ:

1. ความสามารถในการทดสอบ - UI และกิจกรรมในเว็บฟอร์มนั้นไม่อาจทำการทดสอบได้ ด้วย ASP.NET MVC การกระทำของตัวควบคุมการทดสอบหน่วยและมุมมองที่แสดงนั้นง่าย สิ่งนี้มาพร้อมกับค่าใช้จ่ายในการพัฒนาค่าใช้จ่ายล่วงหน้า แต่จากการศึกษาแสดงให้เห็นว่าสิ่งนี้เป็นการตอบแทนในระยะยาวเมื่อถึงเวลาที่จะต้องปรับปรุงและบำรุงรักษาแอพ
2. ควบคุม HTML ที่แสดงผลได้ดีขึ้น - คุณระบุว่าคุณไม่สนใจ HTML ที่แสดงผลเพราะไม่มีใครมองดู นั่นเป็นข้อร้องเรียนที่ถูกต้องหากเป็นเหตุผลเดียวที่ทำให้ HTML มีรูปแบบที่ถูกต้อง มีเหตุผลมากมายที่ต้องการ HTML ที่มีการจัดรูปแบบที่ถูกต้อง ได้แก่ : SEO, ความสามารถในการใช้ตัวเลือก id บ่อยขึ้น (ใน css และ javascript), รอยเท้าของหน้าเล็กลงเนื่องจากไม่มี viewstate และรหัสยาวที่น่าขัน

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

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

เฮ้ฉันดิ้นรนกับการเปลี่ยนเป็น MVC เช่นกัน ฉันไม่ใช่แฟนตัวยงของการแสดงผล ASP และ MVC แบบคลาสสิกซึ่งทำให้ฉันนึกถึงสมัยนั้นมาก อย่างไรก็ตามยิ่งฉันใช้ MVC มากเท่าไหร่มันก็ยิ่งเพิ่มมากขึ้น ฉันเป็นคนที่ชอบใช้เว็บฟอร์ม (เป็นจำนวนมาก) และใช้เวลาหลายปีที่ผ่านมาทำให้ชินกับการทำงานกับดาต้าแกรด ฯลฯ ด้วย MVC ที่ถูกพรากไป HTML Helper class เป็นคำตอบ

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

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

มันตลกเพราะนั่นคือสิ่งที่ฉันพูดเมื่อฉันเห็นเว็บฟอร์มเป็นครั้งแรก

ฉันจะยอมรับว่าฉันยังไม่ได้รับ asp.net MVC ฉันพยายามใช้มันในโครงการด้านที่ฉันกำลังทำอยู่ แต่มันค่อนข้างช้า

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

จนถึงตอนนี้ฉันสังเกตเห็นว่าเหตุผลหลักในการใช้ MVC คือการควบคุม HTML ของคุณอย่างเต็มที่ ฉันยังอ่านว่า asp.net MVC สามารถแสดงหน้าเว็บได้เร็วกว่าเว็บฟอร์มและอาจเกี่ยวข้องกับเรื่องนี้ขนาดหน้าเว็บแต่ละหน้ามีขนาดเล็กกว่าหน้าเว็บฟอร์มทั่วไป

ฉันไม่สนใจว่า HTML ของฉันจะเป็นอย่างไรตราบใดที่มันทำงานในเบราว์เซอร์หลัก ๆ แต่ฉันจะดูแลว่าหน้าเว็บของฉันโหลดเร็วแค่ไหนและใช้แบนด์วิดท์เท่าไร

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

คำตอบอื่น ๆ ได้กล่าวถึงประโยชน์ของ MVC โดยรวมดังนั้นฉันจะมุ่งเน้นไปที่ไวยากรณ์ของมุมมอง:

การส่งเสริมให้ใช้ Html.ActionLink และวิธีอื่น ๆ ที่สร้าง HTML นั้นเป็นขั้นตอนในทิศทางที่ผิด smacks ของการควบคุมเซิร์ฟเวอร์และสำหรับฉันคือการแก้ปัญหาที่ไม่มีอยู่ หากเรากำลังจะสร้างแท็กจากโค้ดทำไมต้องใช้ HTML เลยล่ะ? เราสามารถใช้ DOM หรือรุ่นอื่นและสร้างเนื้อหาของเราในคอนโทรลเลอร์ ตกลงว่าฟังดูไม่ดีใช่มั้ย โอ้ใช่การแยกความกังวลนั่นคือสาเหตุที่เรามีมุมมอง

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

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

นี่มีข้อดีหลายประการ:

• ดูดีขึ้น
• รัดกุมมากขึ้น
• ไม่มีการสลับบริบทระหว่าง HTML และ <%%> แท็ก
• คำหลักที่เข้าใจง่ายที่อธิบายได้ด้วยตนเอง (แม้ผู้ที่ไม่ใช่โปรแกรมเมอร์ก็สามารถทำได้ - ดีสำหรับการขนาน)
• ลอจิกมากถูกย้ายกลับเข้าไปในคอนโทรลเลอร์ (หรือรุ่น) มากที่สุด
• ไม่มี HTML ที่สร้างขึ้น - อีกครั้งทำให้ผู้อื่นเข้ามาได้ง่ายและรู้ว่าจะจัดสไตล์อะไรโดยไม่ต้องยุ่งกับ Html วิธีการ
• รหัสมีข้อความตัวอย่างที่แสดงผลเมื่อคุณโหลดมุมมองเป็น HTML ธรรมดาในเบราว์เซอร์ (อีกครั้งเหมาะสำหรับผู้ใช้เลย์เอาต์)

ดังนั้นไวยากรณ์นี้ทำอะไรกันแน่?

mvc: inner = "" - อะไรก็ตามที่อยู่ในเครื่องหมายคำพูดจะได้รับการประเมินและ HTML ภายในของแท็กจะถูกแทนที่ด้วยสตริงผลลัพธ์ (ข้อความตัวอย่างของเราถูกแทนที่)

mvc: outer = "" - อะไรก็ตามที่อยู่ในเครื่องหมายคำพูดจะได้รับการประเมินและ HTML ด้านนอกของแท็กจะถูกแทนที่ด้วยสตริงผลลัพธ์ (อีกครั้งข้อความตัวอย่างจะถูกแทนที่)

{} - ใช้สำหรับแทรกเอาต์พุตภายในแอททริบิวต์คล้ายกับ <% =%>

mvc: if = "" - insde qoutes คือนิพจน์บูลีนที่ต้องถูกตัดออก ระยะใกล้ของ if คือตำแหน่งที่แท็ก HTML ถูกปิด

MVC: อื่น

mcv: elseif = "" - ...

MVC: foreach

ตอนนี้ฉันพูดได้ด้วยตัวเองเท่านั้นที่นี่:

IMO ถ้าคุณเป็นคนตาย (อะไรก็ตาม) การแปลงไม่ใช่เรื่องสำหรับคุณ หากคุณรัก WebForms นั่นเป็นเพราะคุณสามารถบรรลุสิ่งที่คุณต้องการและนั่นก็เป็นเป้าหมายของสิ่งใดสิ่งหนึ่งเช่นกัน

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

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

จากทั้งหมดที่กล่าวมานี่คือที่ ASP.NET ส่องแสง: - TDD รหัสไม่สามารถทดสอบได้

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

• มาจากที่อื่น: พื้นหลังของฉันคือ CakePHP และ Ruby on Rails ดังนั้นมันชัดเจนว่าอคติของฉันอยู่ตรงไหน มันเกี่ยวกับสิ่งที่คุณพอใจ

• โค้งการเรียนรู้: เพื่อขยายในจุดสุดท้าย; ฉันเกลียดความคิดที่ว่า "เทมเพลต" เพื่อเปลี่ยนการทำงานขององค์ประกอบต่าง ๆ ฉันไม่ชอบความจริงที่ว่าการออกแบบจำนวนมากสำเร็จในโค้ดที่อยู่เบื้องหลังไฟล์ มันเป็นอีกเรื่องหนึ่งที่ต้องเรียนรู้เมื่อฉันคุ้นเคยกับ HTML และ CSS อยู่แล้ว ถ้าฉันต้องการทำอะไรบางอย่างใน "องค์ประกอบ" บนหน้าฉันติดใน "div" หรือ "span", ตบ ID มันและฉันไป ในเว็บฟอร์มฉันจะต้องค้นคว้าวิธีการทำสิ่งนี้

• สถานะปัจจุบันของเว็บ "การออกแบบ": ไลบรารี Javascript เช่น jQuery กำลังเป็นเรื่องธรรมดามากขึ้น วิธีที่แบบฟอร์มบนเว็บทำให้ ID ของคุณยุ่งเหยิงทำให้การนำไปใช้งาน (นอก Visual Studio) นั้นยากขึ้น

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

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

หากคุณกำลังทำงานเป็นตัวเอกในเว็บฟอร์มแสดงว่าคุณมีประสิทธิภาพและเหมาะกับคุณนั่นคือที่ที่คุณควรอยู่

โดยทั่วไปให้ทำการตรวจสอบอย่างรวดเร็วทั้งสองอย่าง (ลองค้นหาแหล่งที่มาที่ไม่ลำเอียง [โชคดี]) พร้อมรายการข้อดีข้อเสียประเมินว่าอันไหนเหมาะสมกับเป้าหมายของคุณและเลือกตามแหล่งนั้น

บรรทัดล่างเลือกเส้นทางที่มีแนวต้านน้อยที่สุดและได้ประโยชน์มากที่สุดเพื่อให้บรรลุเป้าหมายของคุณ เว็บฟอร์มเป็นกรอบที่สมบูรณ์มากและจะดีขึ้นในอนาคตเท่านั้น ASP.NET MVC เป็นอีกทางเลือกหนึ่ง (เพื่อวาดใน Ruby on Rails และนักพัฒนา CakePHP เช่นตัวฉันเอง: P)

JSPs ของ Java EE มีลักษณะเช่นนี้เมื่อมีการเสนอครั้งแรก - โค้ดสคริปต์น่าเกลียด

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

ฉันคิดว่าทางออกที่ดีที่สุดคือ JSP Standard Tag Library (JSTL) มันคือ "มาตรฐาน" แท็ก HTML-ish และช่วยป้องกันไม่ให้คนใส่ตรรกะในหน้าเว็บ

ประโยชน์เพิ่มเติมคือมันจะรักษาเส้นแบ่งระหว่างผู้ออกแบบเว็บและนักพัฒนา เว็บไซต์ที่ดีที่ฉันเห็นถูกออกแบบโดยคนที่มีความสวยงามและการออกแบบเพื่อการใช้งาน พวกเขาวางหน้าและ CSS และส่งต่อไปยังนักพัฒนาที่เพิ่มในบิตข้อมูลแบบไดนามิก การพูดในฐานะนักพัฒนาที่ขาดของขวัญเหล่านี้ฉันคิดว่าเราให้บางสิ่งที่สำคัญเมื่อเราขอให้ผู้พัฒนาเขียนหน้าเว็บจากซุปไปจนถึงถั่ว Flex และ Silverlight จะประสบปัญหาเดียวกันเพราะไม่น่าที่นักออกแบบจะรู้จัก JavaScript และ AJAX ได้ดี

หาก. NET มีเส้นทางคล้ายกับ JSTL ฉันขอแนะนำให้พวกเขาตรวจสอบ

แค่คิดว่าฉันจะแบ่งปันว่าตัวอย่างนี้มีลักษณะอย่างไรกับเครื่องมือมีดโกนมุมมองใหม่ที่เป็นค่าเริ่มต้นตั้งแต่ ASP .NET MVC 3

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

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

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

ฉันไม่สามารถพูดกับโครงการ ASP.NET MVC ได้โดยตรง แต่โดยทั่วไปแล้วการพูดเฟรมเวิร์ค MVC มาเพื่อควบคุมการพัฒนาเว็บแอปพลิเคชันเพราะ

1. พวกเขามีการแยกอย่างเป็นทางการระหว่างการดำเนินงานฐานข้อมูล "ตรรกะทางธุรกิจ" และการนำเสนอ

2. พวกเขามีความยืดหยุ่นเพียงพอในมุมมองเพื่อให้นักพัฒนาปรับแต่ง HTML / CSS / Javascript ของพวกเขาเพื่อทำงานในหลายเบราว์เซอร์และเบราว์เซอร์เวอร์ชันในอนาคต

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

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

นั่นคือการแลกเปลี่ยน หาก Webforms ใช้งานได้สำหรับคุณและ MVC ไม่เป็นเช่นนั้นให้ใช้ Webforms ต่อไป

ส่วนใหญ่ของฉันหงุดหงิดกับมันก็แค่ไม่รู้ว่าจะทำสิ่งที่ "เหมาะสม" เนื่องจากมันเปิดตัวเป็นตัวอย่างเราทุกคนมีเวลาพอที่จะดูสิ่งต่าง ๆ แต่พวกเขาก็เปลี่ยนไปเล็กน้อย ตอนแรกฉันรู้สึกท้อแท้จริงๆ แต่กรอบงานนั้นใช้งานได้ดีพอที่จะทำให้ฉันสามารถสร้าง UI ที่ซับซ้อนมาก (อ่าน: Javascript) ได้อย่างรวดเร็ว ฉันเข้าใจว่าคุณสามารถทำสิ่งนี้กับ Webforms เหมือนที่ฉันเคยทำมาก่อน แต่มันเป็นความเจ็บปวดครั้งใหญ่ในก้นที่พยายามทำให้ทุกอย่างแสดงอย่างถูกต้อง หลายครั้งที่ฉันจะจบลงด้วยการใช้ repeater เพื่อควบคุมเอาต์พุตที่แน่นอนและจะจบลงด้วยความยุ่งเหยิงสปาเก็ตตี้ที่คุณมีอยู่ด้านบนเช่นกัน

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

ฉันอาจจะไม่ทำอย่างนี้ แต่นี่เป็นตัวอย่างของคุณ:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

นั่นค่อนข้างบำรุงรักษาได้ทดสอบและมีรสชาติอร่อยในซุปรหัสของฉัน

Takeaway คือรหัสสะอาดเป็นไปได้จริง ๆ แต่มันเป็นลาใหญ่จากวิธีที่เราทำสิ่งต่าง ๆ ฉันไม่คิดว่าทุกคนจะทำอย่างนั้น ฉันรู้ว่าฉันยังคงคิดออก ...

หนังสือที่ตีพิมพ์เมื่อเร็ว ๆ นี้ของ Steve Sanderson 'Pro ASP.NET MVC' [1] [2] จาก Apress แนะนำอีกทางเลือกหนึ่ง - การสร้างส่วนขยาย HtmlHelper ที่กำหนดเอง ตัวอย่างของเขา (จากบทที่ 4 ในหน้า 110) ใช้ตัวอย่างของรายการเพจที่สามารถปรับเปลี่ยนได้ง่ายสำหรับสถานการณ์ของคุณ

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

คุณจะเรียกมันว่าในมุมมองของคุณโดยใช้โค้ดดังนี้:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.co.th/books?id=Xb3a1xTSfZgC

ฉันหวังว่าจะเห็นโพสต์จาก Phil Haack แต่มันไม่ได้อยู่ที่นี่ดังนั้นฉันเพิ่งตัดและวางจาก http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc /ในส่วนความคิดเห็น

Haacked - 23 เมษายน 2009 - Rob คุณเป็นคนจลาจล! :) ฉันคิดว่ามันตลกเมื่อมีคนเขียนรหัสสปาเก็ตตี้ใน MVC แล้วพูดว่า "look! Spaghetti!" เฮ้ฉันสามารถเขียนรหัสสปาเก็ตตี้ในเว็บฟอร์มด้วย! ฉันสามารถเขียนใน Rails, PHP, Java, Javascript แต่ไม่ใช่ Lisp แต่เพียงเพราะฉันยังเขียนอะไรไม่ได้ใน Lisp และเมื่อฉันเขียนโค้ดสปาเก็ตตี้ฉันไม่ได้ดูจานของฉันอย่างคาดหวังว่าจะเห็นมักกะโรนี จุดที่คนมักจะทำเมื่อเปรียบเทียบกับ ASP แบบคลาสสิคคือการที่คน ASP คลาสสิกมีแนวโน้มที่จะผสมความกังวล เพจจะมีมุมมองแบบลอจิกพร้อมการจัดการอินพุตของผู้ใช้ซึ่งผสมกับรหัสรุ่นและตรรกะทางธุรกิจทั้งหมดรวมกันเป็นหนึ่ง นั่นคือสิ่งที่ปาเก็ตตี้เป็นเรื่องเกี่ยวกับ! การผสมเกี่ยวข้องกับทั้งหมดในระเบียบใหญ่หนึ่ง ด้วย ASP.NET MVC ถ้าคุณทำตามรูปแบบคุณมีโอกาสน้อยที่จะทำ ใช่, คุณยังอาจมีรหัสเล็กน้อยในมุมมองของคุณ แต่หวังว่าจะเป็นรหัสมุมมองทั้งหมด รูปแบบสนับสนุนให้คุณไม่ใส่รหัสการโต้ตอบกับผู้ใช้ วางไว้ในตัวควบคุม วางโค้ดโมเดลของคุณในคลาสโมเดล ที่นั่น ไม่มีสปาเก็ตตี้ ตอนนี้เป็น O-Toro Sushi แล้ว :)

ฉันด้วย; ฉันจะใช้เวลาของฉันกับ Silverlight มากกว่า ASP.NET MVC ฉันลองใช้ MVC 1.0 และดู 2.0 Beta 1 รุ่นล่าสุดเมื่อไม่กี่วันที่ผ่านมา

ฉัน (ไม่) รู้สึกว่า ASP.NET MVC ดีกว่า webform อย่างไร จุดขายของ MVC คือ:

1. หน่วย (ทดสอบ)
   
2. แยกการออกแบบ (มุมมอง) และตรรกะ (คอนโทรลเลอร์ + รุ่น)
   
3. ไม่มีมุมมองและการจัดการรหัสองค์ประกอบที่ดีกว่า
   
4. URL ที่สงบและอื่น ๆ ...

แต่เว็บฟอร์มโดยใช้ code-behind ชุดรูปแบบและทรัพยากรต่างก็สมบูรณ์แบบในการแยกการออกแบบและตรรกะ

Viewstate: การจัดการรหัสลูกค้ากำลังมาใน ASP.NET 4.0 ฉันกังวลเฉพาะเกี่ยวกับการทดสอบหน่วย แต่การทดสอบหน่วยไม่เพียงพอที่จะเป็นเหตุผลที่ทำให้ฉันเป็น ASP.NET MVC จากเว็บฟอร์ม

บางทีฉันสามารถพูดได้: ASP.NET MVC ไม่เลว แต่เว็บฟอร์มก็เพียงพอแล้ว

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

จุดขายที่ใหญ่ที่สุดของ ASP.Net MVC - StackOverflow ทำงานบนสแต็ก MVC

ที่ถูกกล่าวว่า ... รหัสของคุณสวยกว่าที่ฉันทำกับหน้าดูปกติ นอกจากนี้หนึ่งในผู้ที่ฉันทำงานด้วยก็คือการห่อผู้ช่วย HTML ไว้ในไลบรารีแท็ก แทน <% = Html.RandomFunctionHere ()%> มันใช้งานได้

<hh: randomfunction />

ฉันแค่หวังว่าทีม MVC จะไปถึงจุดนั้นเพราะฉันแน่ใจว่าพวกเขาจะทำงานได้ดีขึ้น

ใช้รูปแบบซุ้มเพื่อห่อตรรกะทั้งหมดสำหรับข้อมูลทั้งหมดที่คุณต้องการแสดงแล้วใช้เป็นสามัญในมุมมองของคุณแล้ว .... ไม่มีรหัสสปาเก็ตตี้อีกต่อไป http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

หากคุณต้องการความช่วยเหลือเพิ่มเติม cgardner2020@gmail.com

การใช้ ASP.NET MVC นั้นแย่มาก ผลิตภัณฑ์ธรรมดาครับ ฉันเห็นการสาธิตหลายครั้งและฉันละอายใจกับ MSFT ... ฉันแน่ใจว่าคนที่เขียนมันฉลาดกว่าฉัน แต่เกือบราวกับว่าพวกเขาไม่รู้ว่า Model-View-Controller คืออะไร .

คนเดียวที่ฉันรู้ว่าใครกำลังพยายามใช้ MVC คือคนที่ชอบลองสิ่งใหม่ ๆ จาก MSFT ในการสาธิตที่ฉันเคยเห็นผู้นำเสนอมีเสียงขอโทษ ...

ฉันเป็นแฟนตัวยงของ MSFT แต่ฉันต้องบอกว่าฉันไม่เห็นเหตุผลที่จะต้องใส่ใจกับการใช้ MVC ใช้เว็บฟอร์มหรือใช้ jquery เพื่อการพัฒนาเว็บอย่าเลือกสิ่งที่น่ารังเกียจนี้

แก้ไข:

เจตนาของรูปแบบการออกแบบสถาปัตยกรรม Model-View-Controller คือการแยกโดเมนของคุณออกจากงานนำเสนอจากกฎทางธุรกิจ ฉันใช้รูปแบบสำเร็จแล้วในทุกโครงการของเว็บฟอร์ม ผลิตภัณฑ์ ASP.NET MVC ไม่ได้ยืมตัวเองได้ดีกับรูปแบบการออกแบบสถาปัตยกรรมที่แท้จริง