MVP เทียบกับ MVC เทียบกับ MVVM เทียบกับ VIPER อะไรจะดีไปกว่าการพัฒนา iOS

เช่นเดียวกับบ้านทุกหลังที่มีชั้นใต้ดินที่มั่นคง ทุกโครงการซอฟต์แวร์ มีสถาปัตยกรรมซอฟต์แวร์ที่สร้างขึ้น และแต่ละโครงการมีโครงสร้างแอปของตัวเอง ประเภทของรูปแบบสถาปัตยกรรมอาจแตกต่างกัน แต่มี 4 รูปแบบที่ใช้บ่อยที่สุด - โลกไอทีทั้งโลกวิพากษ์วิจารณ์อย่างต่อเนื่อง แต่ยังคงใช้ในเวลาเดียวกัน: MVC, MVP, MVVM และ Viper (อันสุดท้ายเป็นรูปแบบสถาปัตยกรรม iOS ส่วนใหญ่) . การเปรียบเทียบรูปแบบเหล่านี้และการเลือกรูปแบบที่ดีกว่าสำหรับกรณีของโครงการที่เขียนโดย Swift แต่ละกรณีจะมีการค้นพบเพิ่มเติมในบทความนี้

ตามลำดับเวลาของสิ่งต่าง ๆ เมื่อรูปแบบการออกแบบซอฟต์แวร์แรกปรากฏขึ้น ปัญหาทั่วไปของรูปแบบสถาปัตยกรรมการพัฒนา iOS เหล่านั้นใช้เวลาไม่นานกว่าจะมาถึง

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

- แพทเทิร์นดีไซน์ซิงเกิลตัน

รูปแบบนี้อนุญาตให้ใช้คลาสหนึ่งกับวัตถุเดียวเท่านั้น และตัวเลือกนี้จะใช้เมื่อระบบอนุมัติจำนวนอินสแตนซ์ที่จำกัด (หรืออินสแตนซ์เดียวเท่านั้น)

- ลวดลายการออกแบบมัณฑนากร

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

- แพทเทิร์นดีไซน์สะพาน

รูปแบบสถาปัตยกรรมนี้เปิดตัวครั้งแรกโดย Gang of Four ที่โด่งดัง - ผู้แต่งหนังสือ "Design Patterns" รูปแบบสถาปัตยกรรมนี้ "ใช้การห่อหุ้ม การรวมกลุ่ม และสามารถใช้มรดกเพื่อแยกความรับผิดชอบออกเป็นชั้นเรียนต่างๆ เมื่อชั้นเรียนเกิดขึ้นบ่อยครั้ง คุณสมบัติของวัตถุเชิงวัตถุ การเขียนโปรแกรมมีประโยชน์มากเพราะการเปลี่ยนแปลงรหัสของโปรแกรมสามารถทำได้ง่ายโดยมีความรู้เบื้องต้นเกี่ยวกับโปรแกรมน้อยที่สุด [ที่มา: Wiki]

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

รูปแบบที่ใช้บ่อยที่สุด 4 รูปแบบ ได้แก่ MVC, MVP, MVVM และ VIPER (สำหรับ iOS เป็นหลัก)

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

รูปแบบ MVC

รุ่นปู่ของรูปแบบซอฟต์แวร์ทั้งหมด ซึ่งเปิดตัวครั้งแรกในต้นปี 1970 โดยนักวิทยาศาสตร์คอมพิวเตอร์ชาวนอร์เวย์ Trygve Reenskaug, Module - View - Controller หรือที่รู้จักกันอย่างแพร่หลายในชื่อ MVC เป็นหนึ่งในแนวทางรูปแบบแรกของ Object - Oriented Programming

ส่วนมุมมองมีหน้าที่แสดงทุกอย่างสำหรับผู้ใช้ระบบ (อินเทอร์เฟซของมือถือหรือเว็บแอป ฯลฯ ) โดยทั่วไป โมเดลจะรับผิดชอบฐานข้อมูล หน่วยงานธุรกิจ และข้อมูลที่เหลือ ในทางกลับกัน Controller จะควบคุมงานของ Model ข้อมูลที่จัดให้กับฐานข้อมูล แสดงจากฐานข้อมูลที่กล่าวถึงไปยังส่วน View และในทางกลับกัน

อย่างไรก็ตาม โมเดล MVC อาจเป็นแบบสากล คู่แข่งที่ใหญ่ที่สุดสองราย - Apple และ Google มีรูปแบบของตนเองซึ่งแสดงถึง Model - View - Controller system ปัญหาที่ระบบของ Apple มีอยู่ในการเชื่อมต่อที่แน่นแฟ้นระหว่างส่วน View และ Controller แน่นจนเกือบถึงจุดที่มี View & Controller รวมกันและแยกส่วน Model ออกจากกัน

ส่งผลให้กระบวนการทดสอบไม่ดี - สามารถตรวจสอบเฉพาะแบบจำลองเท่านั้น ไม่สามารถทดสอบ V&C (เนื่องจากมีการเชื่อมต่อที่แน่นหนา) เลย

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

รูปแบบ MVP

พวกเราหลายคนเคยได้ยินทางลัดนี้ในบริบทของผลิตภัณฑ์ที่ทำงานได้ขั้นต่ำ แต่ในแง่ของวิศวกรรมซอฟต์แวร์ มันมีความหมายที่แตกต่างออกไป รูปแบบ Model View Presenter มีประเด็นสำคัญสองสามประการ ทำให้เกิดช่องว่างขนาดใหญ่ระหว่างมันกับ MVC:

นางแบบ MVP

• มุมมองจะแนบชิดกับโมเดลมากขึ้น ผู้นำเสนอมีหน้าที่ผูกมัดโมเดลกับมุมมอง

• ง่ายต่อการทดสอบหน่วยเนื่องจากการโต้ตอบกับมุมมองผ่านอินเทอร์เฟซ

• โดยปกติแล้ว View to Presenter = แมปแบบตัวต่อตัว มุมมองที่ซับซ้อนอาจมีผู้นำเสนอหลายคน

รูปแบบ MVC

• ตัวควบคุมขึ้นอยู่กับพฤติกรรมและสามารถแชร์ข้ามมุมมองได้

• สามารถรับผิดชอบในการกำหนดมุมมองที่จะแสดง
  [ที่มา: Infragistics]

ในการจัดเตรียมนี้ ฟังก์ชันของ Model ยังคงเหมือนเดิม ผู้นำเสนอมีหน้าที่รับผิดชอบตรรกะทางธุรกิจตามลำดับ ส่วน V เป็นส่วนที่น่าสนใจโดยเฉพาะ - เนื่องจากแบ่งออกเป็นสองส่วน View และ View Controller ซึ่งมีอำนาจในการโต้ตอบ เมื่อมีคำถาม MVVM เทียบกับ MVC ระบบประเภทนี้จะแก้ปัญหาโหมดมุมมอง "การเสพติดอย่างหนัก" และโหมดตัวควบคุมที่เคยมีในรูปแบบ MVC

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

รูปแบบ MVVM

รูปแบบสถาปัตยกรรมซอฟต์แวร์ Model-View-ViewModel ถูกสร้างขึ้นในปี 2548 โดย John Gossman หนึ่งในสถาปนิกของ Microsoft องค์ประกอบหลักสามประการของโมเดล MVVM ตามลำดับคือ:
โมเดลคือ "การนำโมเดลโดเมนของแอปพลิเคชันไปใช้ซึ่งรวมถึงโมเดลข้อมูลพร้อมกับตรรกะทางธุรกิจและการตรวจสอบ ตัวอย่างของออบเจ็กต์โมเดล ได้แก่ ที่เก็บ ออบเจ็กต์ธุรกิจ ออบเจ็กต์การถ่ายโอนข้อมูล (DTO) ออบเจ็กต์ CLR แบบธรรมดา (POCO) และเอนทิตีที่สร้างขึ้นและอ็อบเจ็กต์พร็อกซี” [ที่มา: ไมโครซอฟท์]

มุมมองคือทุกสิ่งที่ผู้ใช้มองเห็นได้อีกครั้ง - เลย์เอาต์ โครงสร้าง และรูปลักษณ์ของทุกสิ่งบนหน้าจอ โดยทั่วไปภายในแอปพลิเคชันจะเป็นหน้าของแอป View ได้รับและส่งการอัปเดตไปยัง ViewModel เท่านั้น ไม่รวมการสื่อสารทั้งหมดระหว่างส่วนนี้และตัวโมเดลเอง

ViewModel ควรจะเป็น "สายโซ่ที่เชื่อมต่อถึงกัน" ระหว่างส่วนประกอบของระบบ View และ Model และหน้าที่หลักคือการจัดการตรรกะของ View โดยทั่วไป โมเดลมุมมองโต้ตอบกับโมเดลโดยเรียกใช้เมธอดในคลาสโมเดล จากนั้นโมเดลมุมมองจะให้ข้อมูลจากแบบจำลองในรูปแบบที่มุมมองสามารถใช้งานได้ง่าย ตามที่ Microsoft ระบุไว้

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

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

สถาปัตยกรรม iOS VIPER

ค้นหาโซลูชันสถาปัตยกรรมที่ดีที่สุดเพื่อส่งมอบ นักพัฒนา iOS ทั่วโลกพบกับแนวทางที่เรียกว่า "สถาปัตยกรรมสะอาด" ซึ่งนำโดยลุงบ๊อบใน Clean Coders ซึ่งเป็นแพลตฟอร์มที่รู้จักกันดีซึ่งจัดเซสชันการฝึกอบรมสำหรับมืออาชีพด้านซอฟต์แวร์ทั่วโลก

Clean Architecture แบ่งโครงสร้างตรรกะของแอปพลิเคชันออกเป็นระดับความรับผิดชอบหลายระดับ ในทางกลับกัน "การแยก" นี้จะแก้ไขปัญหาการพึ่งพาที่แน่นแฟ้นและเพิ่มความพร้อมในการทดสอบในทุกระดับ

VIPER สำหรับการพัฒนา ios

VIPER คือการสร้างสถาปัตยกรรมที่สะอาดสำหรับแอปพลิเคชันที่สร้างบน iOS ตามกฎทั่วไปสำหรับชื่อรูปแบบทั้งหมด มันคือ backronym เช่นกันสำหรับ View, Interactor, Presenter, Entity และ Routing ชิ้นส่วนของ VIPER แต่ละส่วนมีหน้าที่ในองค์ประกอบบางอย่าง โดยเฉพาะอย่างยิ่ง:

1. มุมมองมีหน้าที่สะท้อนการกระทำที่ผู้ใช้ทำกับอินเทอร์เฟซ

2. ความรับผิดชอบของผู้นำเสนอในรูปแบบ VIPER ค่อนข้างจำกัด - ได้รับการอัปเดตจากเอนทิตี แต่ไม่ได้ส่งข้อมูลใดๆ ไป

3. Interactor เป็นส่วนหนึ่งของระบบที่สอดคล้องกับเอนทิตี แบบแผนนี้ทำงานในทิศทางต่อไปนี้: Presenter แจ้ง Interactor เกี่ยวกับการเปลี่ยนแปลงในรูปแบบ View จากนั้น Interactor จะติดต่อส่วน Entity และด้วยข้อมูลที่ได้รับจาก Entity Interactor จะกลับไปที่ Presenter ซึ่งคำสั่ง View เพื่อมิเรอร์สำหรับผู้ใช้ ตัวแบบข้อมูลทั้งหมด เอนทิตีทั้งหมด และเว็บไซต์ทั้งหมดเชื่อมต่อกับส่วนตัวโต้ตอบ

4. เอนทิตีประกอบด้วยอ็อบเจ็กต์ที่ควบคุมโดยตัวโต้ตอบ (ชื่อ เนื้อหา ฯลฯ) โดยจะไม่โต้ตอบกับ Presenter โดยตรง ผ่านทางส่วน I เท่านั้น

5. การกำหนดเส้นทาง (หรือ Wireframe ตามที่บางครั้งเรียกว่า) มีหน้าที่ในการนำทางระหว่างหน้าจอทั้งหมด และสำหรับการกำหนดเส้นทาง Wireframe ควบคุมวัตถุของ UIWindow, UINavigationController และอื่นๆ

โดยเฉพาะอย่างยิ่งภายในระบบสถาปัตยกรรม iOS ทั้งหมดนี้สร้างขึ้นบนเฟรมเวิร์กที่เรียกว่า UIkit ซึ่งรวมถึงส่วนประกอบทั้งหมดของ Apple MVC แต่ไม่มีการเชื่อมต่อที่แน่นหนาซึ่งเคยทำให้คนเขียนโค้ดคลั่งไคล้มาก่อน

โมดูล VIPER ก็มีประโยชน์เช่นกันเมื่อเป็นการทดสอบหน่วย เนื่องจากการแจกแจงรูปแบบที่ยอดเยี่ยมทำให้คุณสามารถทดสอบการทำงานทั้งหมดที่มีได้ ในหลาย ๆ ด้าน นี่เป็นปัญหาหลักที่นักพัฒนาต้องเผชิญกับรูปแบบซอฟต์แวร์ MVC, MVP และ MVVM ก่อนหน้านี้

เพื่อมงกุฎมันทั้งหมด

รูปแบบการออกแบบซอฟต์แวร์ทั้ง 4 แบบนี้มักถูกเรียกว่ารูปแบบสถาปัตยกรรมที่ดีที่สุดรูปแบบหนึ่งสำหรับการพัฒนา iOS แม้ว่ารูปแบบเหล่านี้ทั้งหมดจะน้อยกว่าอุดมคติและไม่ได้นำไปใช้อย่างแพร่หลายในทุกโครงการที่คุณพัฒนา ด้านที่มืดมน ต่อไปนี้คือรายการปัญหาสั้นๆ ที่แต่ละรูปแบบมี:

• MVC, MVP, MVVM - ทั้งหมดมีปัญหา "การเชื่อมต่อที่แน่นหนา" ซึ่งทำให้การแนะนำการอัปเดตในการพัฒนาและการทดสอบในภายหลังเป็นงานที่ยากลำบากมาก

• VIPER vs MVVM, MVC หรือ MVP ถือเป็นกรณีที่ชนะ แม้ว่าความยืดหยุ่นสูงและความสามารถในการทดสอบที่ยอดเยี่ยมก็มีความแตกต่างหลายอย่างที่สร้างได้ยาก

มีสารละลายที่เป็นของแข็ง 100% หรือไม่? ไม่ได้จริงๆ แต่สำหรับแต่ละโครงการของคุณ รูปแบบแอป iOS 4 รูปแบบนี้อาจเป็นสิ่งที่คุณต้องการ และถ้าไม่ใช่ก็จะเป็นส่วนผสมของทั้งสอง หรืออาจจะสาม ฟอร์จูนบอกว่าชอบตัวหนา ดังนั้นทำไมคุณไม่ลองเล่นกับรูปแบบการออกแบบซอฟต์แวร์อย่างกล้าหาญล่ะ

เขียนโดย Max Mashkov และ Elina Bessarabova