MVCS - รุ่น Store View Controller

ฉันเพิ่งตัดสินใจที่จะเริ่มต้นเรียนรู้การพัฒนา iOS และเพื่อการนี้ฉันได้อ่านการเขียนโปรแกรม iOS: บิ๊กไร่ Nerd คู่มือ ในหนังสือเล่มนี้ผู้เขียนอธิบายรูปแบบการออกแบบMVCS - Model-View-Controller-Storeแนวคิดพื้นฐานว่าเนื่องจากแอปพลิเคชันจำนวนมากใช้ประโยชน์จากแหล่งข้อมูลภายนอกหลายแหล่งที่ทำให้ตรรกะคำขอในตัวควบคุมนั้นยุ่งเหยิงมากแทนที่จะเป็นผู้เขียน เสนอว่าการย้ายตรรกะคำขอทั้งหมดออกจากตัวควบคุมและไปยังวัตถุที่แยกต่างหาก

ในระยะสั้นเพื่ออ้างหนังสือ

Model-View-Controller-Store ทำให้ตรรกะคำขอเป็นวัตถุแยกต่างหากและเราเรียกวัตถุนี้ว่าร้านค้า (รูปที่ 28.4) การใช้ออบเจกต์ร้านค้าลดรหัสที่ซ้ำซ้อนให้น้อยที่สุดและลดความซับซ้อนของรหัสที่ดึงและบันทึกข้อมูล สิ่งสำคัญที่สุดคือมันย้ายตรรกะในการจัดการกับแหล่งข้อมูลภายนอกเป็นชั้นเรียนที่เป็นระเบียบเรียบร้อยด้วยเป้าหมายที่ชัดเจนและมุ่งเน้น รหัสนี้ทำให้เข้าใจง่ายยิ่งขึ้นซึ่งทำให้ง่ายต่อการบำรุงรักษาและตรวจแก้จุดบกพร่องรวมถึงแบ่งปันกับโปรแกรมเมอร์คนอื่น ๆ ในทีมของคุณ

และ

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

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

สำหรับฉันแล้วตรรกะของผู้เขียนดูเหมือนจะสมเหตุสมผลและดูเหมือนว่าเป็นการขยายตรรกะของรูปแบบ MVC ปกติ แต่อาจเป็นเพราะฉันไม่มีประสบการณ์มากกับรูปแบบ MVC ในทางปฏิบัติ (นอกเหนือจากการจู่โจมสู่การพัฒนา iOS ที่ฉันมี ประเภท MVV ที่ใช้แล้วที่มีbackbone.js (นั่นคือถ้าคุณพิจารณาว่าเป็น MVC )

ฉันหวังว่าอาจมีบางคนที่มีประสบการณ์มากกว่านั้นสามารถบอกได้ว่ามีข้อบกพร่อง / ปัญหาที่ชัดเจนเกี่ยวกับรูปแบบMVCSที่ฉันพลาดไปหรือไม่

"Store" ในกรณีของรูปแบบการออกแบบ MVCS มีแนวโน้มที่จะพึ่งพาตรรกะการจัดเก็บ ในกรณีของ iOS นี่มักเป็นการนำ Core Data ไปใช้ หากคุณสร้างเทมเพลตที่สนับสนุนข้อมูลหลักใน Xcode คุณจะเห็นลักษณะ "Store" ของรูปแบบการออกแบบนี้ซ่อนตัวอยู่ในคลาส AppDelegate

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

อย่างไรก็ตามกระบวนทัศน์ "ร้านค้า" ไม่ได้ จำกัด อยู่ที่ Core Data ร้านค้าของคุณอาจเป็นบริการเว็บ บางทีคุณอาจมีคลาสที่โต้ตอบกับ Facebook, Twitter, Yelp หรือ API แบบอิง REST อื่น ๆ ฉันได้พบ (และทำตามแนวโน้มในทำนองเดียวกัน) ว่าคลาสเหล่านี้มีชื่อผู้จัดการด้วย พวกเขาจัดการรายละเอียดภายในทั้งหมดอย่างแท้จริงเพื่อให้ชั้นเรียนอื่น ๆ ของคุณสามารถใส่หรือรับสิ่งที่ต้องการ

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

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

ในระดับทั่วไปดูเหมือนว่าหนังสือจะใช้ 'Store' เพื่อแสดงระดับตรรกะทางธุรกิจ + ระดับของการดึงข้อมูลตรรกะที่จัดการชุดข้อมูลที่อาจเป็นส่วนหนึ่งของแอปพลิเคชันของคุณหรือไม่ก็ได้

ตัวอย่างเช่นการตัด twitter api ใน 'Store' เป็นวิธีที่ดีในการแยกตรรกะออกจากกัน

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

บรรทัดล่างฉันคิดว่าคุณจะสบายดีตามคำแนะนำที่พวกเขาแนะนำ (ดูเหมือนเสียงโดยรวม)