MVC
ModelViewController (MVC) เป็นรูปแบบการพัฒนาส่วนต่อประสานผู้ใช้คอมพิวเตอร์ที่แยกตรรกะการนำเสนอข้อมูลและการโต้ตอบของผู้ใช้ รูปแบบมีข้อมูลแอปพลิเคชันและตรรกะทางธุรกิจ คอนโทรลเลอร์รับผิดชอบในการแปลงอินพุตของผู้ใช้เป็นคำสั่งและส่งผ่านไปยังรูปแบบและมุมมอง นี่คือคำอธิบายของวิกิพีเดีย
รุ่นนี้ได้รับการออกแบบโดย Trygve Reenskaug เมื่อทำงานกับ SmallTalk-80 (1979) และเป็นครั้งแรกที่เรียกว่า Model-View-Controller-Editor; ต่อมาผ่านการแนะนำในเชิงลึกของหนังสือ "รูปแบบการออกแบบ: องค์ประกอบของซอฟต์แวร์เชิงวัตถุที่นำกลับมาใช้ใหม่ได้" MVC ได้รับความนิยมอย่างสมบูรณ์
ทำความเข้าใจกับความรับผิดชอบในการสร้างสามส่วนของ MVC และสิ่งที่กรอบ JavaScript ที่มีอยู่ให้เราเพื่อให้เราสามารถใช้เฟรมเวิร์กเหล่านี้ได้ดีขึ้น ต่อไปเราจะผ่านสามส่วนที่ประกอบขึ้นเป็น MVC เพื่อเรียนรู้ว่าความรับผิดชอบของแต่ละส่วนคือ [ได้รับรหัสสาธิตที่มีกระดูกสันหลังเป็นตัวอย่าง]
แบบอย่าง
โมเดลจัดการข้อมูลแอปพลิเคชัน เมื่อข้อมูลโมเดลเปลี่ยนแปลงผู้ฟังจะได้รับแจ้ง [อาจเป็นมุมมอง] หลังจากได้รับการแจ้งเตือนผู้ฟังจะทำการเปลี่ยนแปลงที่สอดคล้องกัน
ดู
มุมมองคือการแสดงภาพของโมเดลสถานะปัจจุบัน มุมมองจะสังเกตการเปลี่ยนแปลงของโมเดลและได้รับแจ้งเมื่อโมเดลเปลี่ยนแปลงและอนุญาตให้มุมมองอัปเดตตัวเอง โดยทั่วไปเราจะใช้เอ็นจิ้นเทมเพลตเพื่อแสดงรุ่นในมุมมอง
ผู้ควบคุม
คอนโทรลเลอร์เป็นสื่อกลางระหว่างแบบจำลองและมุมมอง งานของมันคือการอัปเดตมุมมองเมื่อโมเดลเปลี่ยนแปลงและอัปเดตรุ่นเมื่อผู้ใช้ทำงานมุมมอง
การเปรียบเทียบเฟรมเวิร์ก Javascipt MVC
คนที่แตกต่างกันมีวิธีการเปรียบเทียบที่แตกต่างกันคีย์ขึ้นอยู่กับสิ่งที่คุณให้ความสนใจกับ:
1. หากคุณให้ความสำคัญกับรายละเอียดของการกำหนดเส้นทาง URL ของเฟรมเวิร์กการจัดเก็บข้อมูลการใช้งานการใช้งาน ฯลฯ คุณสามารถมุ่งเน้นไปที่สิ่งนี้บัลลังก์ JavaScript: Framework Sword;
2. หากคุณให้ความสนใจกับตัวอย่างเฉพาะของเฟรมเวิร์กจะมีโครงการโอเพนซอร์สที่นี่ที่ใช้เฟรมเวิร์ก JavaScript MVC ที่แตกต่างกันสำหรับการสาธิตเดียวกัน คุณสามารถเห็นความแตกต่างอย่างชัดเจนในแอปพลิเคชันเฉพาะของแต่ละเฟรมเวิร์ก นี่คือเว็บไซต์อย่างเป็นทางการของ TODOMVC
ประโยชน์ของ MVC นำมาให้เรา:
1. ง่ายต่อการบำรุงรักษา
2. การแยกมุมมองแบบจำลองหมายความว่าตรรกะทางธุรกิจสามารถทดสอบได้ดีขึ้น
3. รหัสสามารถนำกลับมาใช้ใหม่ได้ดีขึ้น
4. การพัฒนาแบบแยกส่วนสามารถทำให้การแบ่งงานชัดเจนขึ้นบางคนมุ่งเน้นไปที่ตรรกะทางธุรกิจและบางคนมุ่งเน้นไปที่ส่วนต่อประสานผู้ใช้
5. หลังจากตรวจสอบโมเดล MVC แบบคลาสสิกเราเข้าใจแนวคิดของการจัดเรียงในแอปพลิเคชันและความรับผิดชอบของแต่ละชั้น ในเวลาเดียวกันเราควรจะสามารถระบุความแตกต่างระหว่างกรอบ JavaScript MVC ทั้งหมดและโมเดล MVC แบบคลาสสิกที่เราอธิบาย ด้วยวิธีนี้เมื่อเลือกเฟรมเวิร์ก MVC เราควรมุ่งเน้นไปที่วิธีการใช้แบบจำลองมุมมองตัวควบคุมจะถูกนำไปใช้และแม้แต่วิธีการใช้รหัสเฉพาะเพื่อช่วยให้เราเลือกกรอบ JavaScript MVC ที่เหมาะสมที่สุด
MVVM
ชื่อเต็มของ MVVM คือ Model View ViewModel แบบจำลองสถาปัตยกรรมนี้ถูกเสนอโดย Martinfowler ของ Microsoft เป็นข้อมูลจำเพาะของรูปแบบการออกแบบเลเยอร์การนำเสนอของ Microsoft มันเป็นอนุพันธ์ของโมเดล MVC จุดสนใจของโมเดล MVVM อยู่บนแพลตฟอร์มการพัฒนา UI ที่สามารถรองรับเหตุการณ์ที่ขับเคลื่อนด้วยเหตุการณ์เช่น HTML5, [2] [3] มูลนิธิ Windowspresentation (WPF), Silverlight และ T ZK Framework, Adobe Flex
การใช้งานส่วนใหญ่ของโมเดลนี้ถูกแยกออกจากเลเยอร์อื่น ๆ โดยการประกาศข้อมูลที่มีผลผูกพันที่เลเยอร์มุมมองซึ่งอำนวยความสะดวกในการแบ่งงานระหว่างนักพัฒนาส่วนหน้าและนักพัฒนาแบ็คเอนด์ นักพัฒนาส่วนหน้าเขียนข้อมูลที่ถูกผูกไว้กับ ViewModel ในแท็ก HTML โมเดลและ ViewModel เป็นนักพัฒนาแบ็คเอนด์ที่รักษาสองเลเยอร์นี้ผ่านตรรกะของการพัฒนาแอปพลิเคชัน
ในช่วงไม่กี่ปีที่ผ่านมาโมเดล MVVM ได้เริ่มดำเนินการใน JavaScript ปัจจุบันเฟรมเวิร์กที่ค่อนข้างครบกำหนด ได้แก่ Knockoutjs, Kendo MVVM และ Knockback.js ลองใช้ความผิดพลาดเป็นตัวอย่างเพื่อดูความรับผิดชอบเฉพาะและรหัสตัวอย่างของแต่ละส่วนของโมเดล MVVM และในขณะเดียวกันก็เข้าใจข้อดีและข้อเสียของการใช้โมเดลนี้เพื่อพัฒนา
แบบอย่าง
เช่นเดียวกับสมาชิกในครอบครัว MV* อื่น ๆ โมเดลแสดงถึงข้อมูลในฟิลด์หรือข้อมูลเฉพาะที่จำเป็นสำหรับแอปพลิเคชันข้อมูลเฉพาะฟิลด์ทั่วไปเช่นข้อมูลผู้ใช้ [ชื่อผู้ใช้, อวตาร, อีเมล, หมายเลขโทรศัพท์] หรือข้อมูลดนตรี [ชื่อเพลง, ปีที่วางจำหน่าย, อัลบั้ม];
แบบจำลองมุ่งเน้นเฉพาะข้อมูลข้อมูลและไม่สนใจพฤติกรรมใด ๆ มันไม่ได้จัดรูปแบบข้อมูลหรือส่งผลกระทบต่อการแสดงข้อมูลในเบราว์เซอร์ซึ่งไม่ใช่ความรับผิดชอบของเขา การจัดรูปแบบข้อมูลเป็นหน้าที่ของเลเยอร์มุมมองและเลเยอร์ตรรกะทางธุรกิจถูกห่อหุ้มในรูปแบบมุมมองเพื่อโต้ตอบกับโมเดล
พฤติกรรมที่ไม่คาดคิดมากขึ้นในเลเยอร์โมเดลคือการตรวจสอบข้อมูล ตัวอย่างเช่นเมื่อผู้ใช้ป้อนอีเมลให้ตรวจสอบว่ารูปแบบอีเมลถูกต้องหรือไม่
ใน KnockoutJS โมเดลจะถูกนำไปใช้ตามคำจำกัดความข้างต้น แต่จะมีบริการเซิร์ฟเวอร์การโทร AJAX เพื่ออ่านและเขียนข้อมูลรุ่น
ดู
ดูหมายถึงส่วนของแอปพลิเคชันที่โต้ตอบโดยตรงกับผู้ใช้ มันเป็น UI แบบโต้ตอบเพื่อแสดงถึงสถานะของ ViewModel มุมมองถือว่าใช้งานมากกว่าที่จะแฝงอยู่? ประโยคนี้หมายความว่ามุมมองแบบพาสซีฟไม่สนใจโดเมนของโมเดลในแอปพลิเคชันและโดเมนของโมเดลจะถูกเก็บรักษาไว้ในคอนโทรลเลอร์ มุมมองที่ใช้งานอยู่ของ MVVM รวมถึงการเชื่อมโยงข้อมูลเหตุการณ์และพฤติกรรมของโมเดลและ ViewModel จำเป็นต้องเข้าใจ แม้ว่าพฤติกรรมเหล่านี้สามารถสอดคล้องกับคุณลักษณะ แต่มุมมองยังคงต้องตอบสนองต่อเหตุการณ์ของ ViewModel และมุมมองจะไม่รับผิดชอบในการควบคุมสถานะ
เลเยอร์มุมมองของ KnockoutJS เป็นเอกสาร HTML ง่าย ๆ ซึ่งจะเชื่อมโยงกับการประกาศข้อมูลของ ViewModel ในเวลาเดียวกันเลเยอร์มุมมองของ KnockoutJS จะแสดงข้อมูลที่ได้จาก ViewModel ส่งคำสั่งไปยัง ViewModel และอัปเดตสถานะการเปลี่ยนแปลงของ ViewModel
ViewModel
สามารถพิจารณาได้ว่า ViewModel เป็นคอนโทรลเลอร์ที่ใช้เป็นพิเศษสำหรับการแปลงข้อมูล มันสามารถแปลงข้อมูลในโมเดลเป็นข้อมูลในมุมมองและในเวลาเดียวกันคำสั่งส่งผ่านจากมุมมองเป็นโมเดล
ในแง่นี้ ViewModel ดูเหมือนโมเดลมากขึ้น แต่มันควบคุมตรรกะการแสดงผลจำนวนมากของมุมมอง ในเวลาเดียวกัน ViewModel ยังเปิดเผยวิธีการบางอย่างเพื่อรักษาสถานะของมุมมองและอัปเดตโมเดลตามพฤติกรรมและเหตุการณ์ของมุมมอง
โดยสรุป ViewModel ตั้งอยู่ด้านหลังเลเยอร์ UI และการเปิดเผยข้อมูลไปยังมุมมองถือเป็นแหล่งข้อมูลและพฤติกรรมของเลเยอร์มุมมอง
KnockoutJS ตีความ ViewModels เป็นการแสดงข้อมูลและพฤติกรรมที่แสดงบน UI ไม่ใช่รูปแบบข้อมูลที่ต้องมีการคงอยู่ แต่สามารถเก็บข้อมูลที่ผู้ใช้เก็บไว้ได้ ViewModels ของ Knockout ถูกนำมาใช้โดยใช้วัตถุ JavaScript และไม่จำเป็นต้องใส่ใจเกี่ยวกับแท็ก HTML วิธีนามธรรมนี้สามารถทำให้การใช้งานง่ายขึ้น
ข้อได้เปรียบ:
1.MVVM ทำให้การพัฒนาแบบขนานง่ายขึ้นดังนั้นการพัฒนาส่วนหน้าและนักพัฒนาแบ็คเอนด์จะไม่ส่งผลกระทบต่อกันและกัน
2. บทคัดย่อเลเยอร์มุมมองลดตรรกะทางธุรกิจในรหัส
3. viewModel นั้นง่ายต่อการทดสอบมากกว่าการขับเคลื่อนเหตุการณ์
4. การทดสอบของ ViewModel ไม่จำเป็นต้องใส่ใจเกี่ยวกับระบบอัตโนมัติและการโต้ตอบ UI
ข้อบกพร่อง:
1. สำหรับ UI ง่าย ๆ การใช้ MVVM นั้นหนักเกินไปเล็กน้อย
2. การเชื่อมโยงข้อมูลที่ประกาศไม่เอื้อต่อการดีบักเนื่องจากรหัสที่จำเป็นสามารถตั้งค่าจุดพักได้อย่างง่ายดายและโหมดนี้ไม่เอื้อต่อการตั้งค่าจุดพักดังกล่าว
3. การเชื่อมโยงข้อมูลสามารถสร้างการเก็บหนังสือจำนวนมากในแอปพลิเคชันที่ไม่สำคัญ คุณไม่ต้องการที่จะจบลงด้วยสถานการณ์ที่ซับซ้อนมากขึ้นซึ่งการผูกมัดนั้นซับซ้อนกว่าวัตถุที่ถูกผูกไว้
4. ในแอพพลิเคชั่นขนาดใหญ่มันเป็นเรื่องยากที่จะออกแบบเลเยอร์มุมมองแบบจำลองก่อนที่จะได้รับการสรุปจำนวนมาก