📭 🍀 💙 VIPER के विकल्प के रूप में स्वच्छ स्विफ्ट आर्किटेक्चर 🎅🏿 🏷️ 🛌🏼

परिचय

फिलहाल, VIPER के बारे में कई लेख हैं - स्वच्छ वास्तुकला, जिनमें से विभिन्न विविधताएं एक समय में iOS परियोजनाओं के लिए लोकप्रिय हो गईं। यदि आप वाइपर से परिचित नहीं हैं, तो आप इसे यहाँ , यहाँ या यहाँ पढ़ सकते हैं।

मैं VIPER विकल्प के बारे में बात करना चाहूंगा - क्लीन स्विफ्ट। पहली नज़र में क्लीन स्विफ्ट VIPER की तरह दिखती है, हालांकि, मॉड्यूल के बीच बातचीत के सिद्धांत का अध्ययन करने के बाद अंतर दिखाई देते हैं। VIPER में, इंटरैक्शन प्रस्तुतकर्ता पर आधारित है, यह उपयोगकर्ता से अनुरोधों को प्रसंस्करण के लिए हस्तांतरित करता है और दृश्य नियंत्रक पर प्रदर्शन के लिए इससे प्राप्त डेटा को वापस स्वरूपित करता है:

क्लीन स्विफ्ट में, VIPER की तरह मुख्य मॉड्यूल, व्यू कंट्रोलर, इंटरेक्टर, प्रस्तुतकर्ता हैं।

उनके बीच बातचीत चक्रों में होती है। डेटा ट्रांसफर प्रोटोकॉल पर आधारित है (फिर से, VIPER के समान), जो सिस्टम घटकों में से एक में भविष्य में बदलाव के लिए इसे दूसरे के साथ बदलने की अनुमति देता है। सामान्य रूप से बातचीत की प्रक्रिया इस तरह दिखाई देती है: उपयोगकर्ता बटन पर क्लिक करता है, देखें नियंत्रक एक विवरण के साथ एक वस्तु बनाता है और इसे इंटरैक्टर को भेजता है। बदले में, व्यापार तर्क के अनुसार एक विशिष्ट परिदृश्य को लागू करता है, इंटरेक्टर, एक परिणाम वस्तु बनाता है और इसे प्रस्तुतकर्ता को भेजता है। प्रस्तुतकर्ता उपयोगकर्ता के लिए प्रदर्शित स्वरूपित डेटा के साथ एक ऑब्जेक्ट बनाता है और इसे व्यू कंट्रोलर को भेजता है। आइए प्रत्येक स्वच्छ स्विफ्ट मॉड्यूल को अधिक विस्तार से देखें।

देखें (नियंत्रक देखें)

देखें नियंत्रक, जैसा कि VIPER में है, सभी VIew कॉन्फ़िगरेशन करता है, यह रंग, UILabel या लेआउट फ़ॉन्ट सेटिंग्स है। इसलिए, इस आर्किटेक्चर में प्रत्येक UIViewController डेटा प्रदर्शित करने या उपयोगकर्ता कार्यों का जवाब देने के लिए एक इनपुट प्रोटोकॉल को लागू करता है।

Interactor

सहभागिता में सभी व्यावसायिक तर्क शामिल हैं। यह इनपुट प्रोटोकॉल में परिभाषित पैरामीटर (उदाहरण के लिए, इनपुट फ़ील्ड के परिवर्तित पाठ, एक बटन दबाने) के साथ नियंत्रक से उपयोगकर्ता की कार्रवाइयों को स्वीकार करता है। लॉजिक को वर्कआउट करने के बाद, यदि आवश्यक हो, तो इंटरएक्टर, व्यूऑन कंट्रोलर में प्रदर्शित करने से पहले प्रस्तुतकर्ता को इसकी तैयारी के लिए डेटा ट्रांसफर करना चाहिए। हालाँकि, सहभागिताकर्ता केवल VIP के विपरीत, इनपुट के रूप में दृश्य से अनुरोध स्वीकार करता है, जहां ये अनुरोध प्रस्तुतकर्ता के माध्यम से जाते हैं।

प्रस्तुतकर्ता

प्रस्तुतकर्ता उपयोगकर्ता को प्रदर्शन के लिए डेटा संसाधित करता है। इस मामले में परिणाम ViewController के इनपुट प्रोटोकॉल है, यहां आप उदाहरण के लिए, पाठ प्रारूप को बदल सकते हैं, रंग मान को एनम से आरजीबी में अनुवाद कर सकते हैं, आदि।

मज़दूर

इंटरएक्टर को अनावश्यक रूप से जटिल न करने और व्यावसायिक तर्क के विवरणों की नकल न करने के लिए, आप अतिरिक्त वर्कर तत्व का उपयोग कर सकते हैं। सरल मॉड्यूल में, इसकी हमेशा आवश्यकता नहीं होती है, लेकिन पर्याप्त रूप से लोड किए गए मॉड्यूल में यह आपको इंटरएक्टर से कुछ कार्यों को हटाने की अनुमति देता है। उदाहरण के लिए, डेटाबेस के साथ बातचीत का तर्क कार्यकर्ता में बनाया जा सकता है, खासकर अगर एक ही डेटाबेस प्रश्नों को विभिन्न मॉड्यूल में उपयोग किया जा सकता है।

रूटर

राउटर अन्य मॉड्यूलों और उनके बीच डेटा को स्थानांतरित करने के लिए जिम्मेदार है। उसके पास नियंत्रक के लिए एक लिंक है, क्योंकि आईओएस में, दुर्भाग्यवश, नियंत्रक, अन्य चीजों के अलावा, संक्रमण के लिए ऐतिहासिक रूप से जिम्मेदार हैं। सेग का उपयोग करके तैयारी के लिए राउटर के तरीकों को सेग के लिए कॉल करके ट्रांज़िशन के इनिशियलाइज़ेशन को आसान बना सकते हैं, क्योंकि राउटर डेटा ट्रांसफर करना जानता है, और इंटरेक्टर / प्रेजेंटर से किसी भी अतिरिक्त लूप कोड के बिना ऐसा करेगा। इंटरएक्टर में लागू प्रत्येक मॉड्यूल के डेटा वेयरहाउस प्रोटोकॉल का उपयोग करके डेटा स्थानांतरित किया जाता है। ये प्रोटोकॉल राउटर से आंतरिक मॉड्यूल डेटा तक पहुंचने की क्षमता को भी सीमित करते हैं।

मॉडल

मॉडल मॉड्यूल के बीच डेटा स्थानांतरित करने के लिए डेटा संरचनाओं का वर्णन है। व्यवसाय तर्क फ़ंक्शन के प्रत्येक कार्यान्वयन में मॉडलों का अपना विवरण होता है।

अनुरोध - नियंत्रक से इंटरेक्टर तक अनुरोध भेजने के लिए।
प्रतिक्रिया - डेटा के साथ प्रस्तुतकर्ता को प्रेषित करने के लिए इंटरप्रेटर की प्रतिक्रिया।
ViewModel - नियंत्रक में प्रदर्शन के लिए तैयार एक फॉर्म में डेटा ट्रांसफर के लिए।

कार्यान्वयन का उदाहरण

आइए एक सरल उदाहरण का उपयोग करके इस वास्तुकला पर करीब से नज़र डालें। उन्हें संपर्कपुस्तिका एप्लिकेशन द्वारा सरलीकृत रूप में परोसा जाएगा, लेकिन वास्तुकला रूप के सार को समझने के लिए काफी पर्याप्त है। एप्लिकेशन में संपर्कों की एक सूची, साथ ही संपर्कों को जोड़ना और संपादित करना शामिल है।

इनपुट प्रोटोकॉल का एक उदाहरण:

protocol ContactListDisplayLogic: class { func displayContacts(viewModel: ContactList.ShowContacts.ViewModel) }

प्रत्येक नियंत्रक में एक ऑब्जेक्ट का संदर्भ होता है जो इनपुट इंटरेक्टर प्रोटोकॉल को लागू करता है

 var interactor: ContactListBusinessLogic?

साथ ही राउटर ऑब्जेक्ट, जो डेटा ट्रांसफर और मॉड्यूल स्विचिंग के तर्क को लागू करना चाहिए:

 var router: (NSObjectProtocol & ContactListRoutingLogic & ContactListDataPassing)?

आप मॉड्यूल कॉन्फ़िगरेशन को एक अलग निजी विधि में लागू कर सकते हैं:

 private func setup() { let viewController = self let interactor = ContactListInteractor() let presenter = ContactListPresenter() let router = ContactListRouter() viewController.interactor = interactor viewController.router = router interactor.presenter = presenter presenter.viewController = viewController router.viewController = viewController router.dataStore = interactor }

या नियंत्रक से इस कोड को हटाने के लिए एक विन्यासकर्ता सिंगलटन बनाएं (उन लोगों के लिए जो मानते हैं कि नियंत्रक को कॉन्फ़िगरेशन में शामिल नहीं होना चाहिए) और नियंत्रक में मॉड्यूल के कुछ हिस्सों तक पहुंच के साथ खुद को लुभाएं नहीं। अंकल बॉब के दृष्टिकोण और क्लासिक VIPER में कोई विन्यासकर्ता वर्ग नहीं है। ऐड संपर्क मॉड्यूल के लिए विन्यासकर्ता का उपयोग इस तरह दिखता है:

 override func awakeFromNib() { super.awakeFromNib() AddContactConfigurator.sharedInstance.configure(self) }

कॉन्फ़िगरेशन कोड में केवल कॉन्फ़िगरेशन विधि होती है जो नियंत्रक में सेटअप विधि के समान होती है:

 final class AddContactConfigurator { static let sharedInstance = AddContactConfigurator() private init() {} func configure(_ control: AddContactViewController) { let viewController = control let interactor = AddContactInteractor() let presenter = AddContactPresenter() let router = AddContactRouter() viewController.interactor = interactor viewController.router = router interactor.presenter = presenter presenter.viewController = viewController router.viewController = viewController router.dataStore = interactor } }

नियंत्रक के कार्यान्वयन में एक और बहुत महत्वपूर्ण बिंदु सेग विधि के लिए मानक तैयार में कोड है:

 override func prepare(for segue: UIStoryboardSegue, sender: Any?) { if let scene = segue.identifier { let selector = NSSelectorFromString("routeTo\(scene)WithSegue:") if let router = router, router.responds(to: selector) { router.perform(selector, with: segue) } } }

एक चौकस पाठक सबसे अधिक संभावना है कि राउटर भी NSObjectProtocol को लागू करने के लिए आवश्यक है। यह इसलिए किया जाता है ताकि हम इस प्रोटोकॉल के मानक तरीकों का उपयोग सेगिंग का उपयोग करते समय राउटिंग के लिए कर सकें। इस सरल पुनर्निर्देशन का समर्थन करने के लिए, सेग पहचानकर्ता का नामकरण राउटर विधि के नामों के अंत से मेल खाना चाहिए। उदाहरण के लिए, किसी संपर्क को देखने जाने के लिए, एक सेग है, जो संपर्क के साथ एक सेल की पसंद से जुड़ा हुआ है। इसकी पहचानकर्ता "ViewContact" है, यहाँ राउटर में इसी विधि है:

 func routeToViewContact(segue: UIStoryboardSegue?)

इंटरेक्टर को डेटा प्रदर्शित करने का अनुरोध भी बहुत सरल लगता है:

 private func fetchContacts() { let request = ContactList.ShowContacts.Request() interactor?.showContacts(request: request) }

आइए इंटरएक्टर पर जाएं। इंटरएक्टर ContactListDataStore प्रोटोकॉल को लागू करता है, जो डेटा को संग्रहीत / एक्सेस करने के लिए जिम्मेदार है। हमारे मामले में, यह केवल संपर्कों की एक सरणी है, जो केवल राउटर विधि द्वारा सीमित है, राउटर को अन्य मॉड्यूल से इसे बदलने की अक्षमता दिखाने के लिए। हमारी सूची के लिए व्यावसायिक तर्क को लागू करने वाला एक प्रोटोकॉल इस प्रकार है:

 func showContacts(request: ContactList.ShowContacts.Request) { let contacts = worker.getContacts() self.contacts = contacts let response = ContactList.ShowContacts.Response(contacts: contacts) presenter?.presentContacts(response: response) }

यह ContactListWorker से संपर्क डेटा प्राप्त करता है। इस स्थिति में, डेटा कैसे डाउनलोड किया जाता है, इसके लिए कार्यकर्ता जिम्मेदार है। वह तृतीय-पक्ष सेवाओं को बदल सकता है, जो उदाहरण के लिए, कैश से डेटा लेने या नेटवर्क से डाउनलोड करने का निर्णय लेते हैं। डेटा प्राप्त करने के बाद, इंटरएक्टर प्रस्तुतकर्ता को प्रदर्शन के लिए तैयार करने के लिए एक प्रतिक्रिया भेजता है, इसके लिए इंटरसेक्टर में प्रस्तुतकर्ता के लिए एक लिंक होता है:

 var presenter: ContactListPresentationLogic?

प्रस्तुतकर्ता केवल एक प्रोटोकॉल लागू करता है - ContactListPresentationLogic, हमारे मामले में, यह केवल संपर्क के पहले और अंतिम नाम के मामले को जबरन बदल देता है, डेटा मॉडल से DisplayContact प्रस्तुति मॉडल बनाता है और प्रदर्शन के लिए नियंत्रक के पास जाता है:

 func presentContacts(response: ContactList.ShowContacts.Response) { let mapped = response.contacts.map { ContactList .ShowContacts .ViewModel .DisplayedContact(firstName: $0.firstName.uppercaseFirst, lastName: $0.lastName.uppercaseFirst) } let viewModel = ContactList.ShowContacts.ViewModel(displayedContacts: mapped) viewController?.displayContacts(viewModel: viewModel) }

उसके बाद, चक्र समाप्त होता है और कंट्रोलर डेटा प्रदर्शित करता है, जिससे कॉन्टैक्टलिस्टप्लेप्लेजिक प्रोटोकॉल विधि लागू होती है:

 func displayContacts(viewModel: ContactList.ShowContacts.ViewModel) { displayedContacts = viewModel.displayedContacts tableView.reloadData() }

संपर्क प्रदर्शित करने के लिए मॉडल इस प्रकार है:

 enum ShowContacts { struct Request { } struct Response { var contacts: [Contact] } struct ViewModel { struct DisplayedContact { let firstName: String let lastName: String var fullName: String { return firstName + " " + lastName } } var displayedContacts: [DisplayedContact] } }

इस मामले में, अनुरोध में डेटा शामिल नहीं है, क्योंकि यह सिर्फ एक सामान्य संपर्क सूची है, हालांकि, यदि, उदाहरण के लिए, सूची स्क्रीन में एक फ़िल्टर होगा, तो इस अनुरोध में फ़िल्टर प्रकार शामिल किया जा सकता है। इंट्रेक्टर प्रतिक्रिया मॉडल में वांछित संपर्क सूची शामिल है, ViewModel में प्रदर्शन के लिए तैयार डेटा की एक सरणी भी शामिल है - DisplayCContact।

क्यों स्वच्छ स्विफ्ट

इस वास्तुकला के पेशेवरों और विपक्षों पर विचार करें। सबसे पहले, क्लीन स्विफ्ट में कोड टेम्प्लेट होते हैं जो मॉड्यूल को आसान बनाते हैं। ये टेम्पलेट कई आर्किटेक्चर के लिए लिखे जा सकते हैं, लेकिन जब वे बॉक्स से बाहर होते हैं - तो यह कम से कम आपके समय के कई घंटे बचाता है।

दूसरे, इस वास्तुकला, जैसे VIPER, का अच्छी तरह से परीक्षण किया जाता है, परीक्षण के उदाहरण परियोजना में उपलब्ध हैं। चूंकि मॉड्यूल जिसके साथ इंटरैक्शन होता है, स्टब से बदलना आसान है, प्रोटोकॉल का उपयोग करके प्रत्येक मॉड्यूल की कार्यक्षमता का निर्धारण करना आपको सिरदर्द के बिना इसे लागू करने की अनुमति देता है। यदि हम एक साथ व्यावसायिक तर्क और संबंधित परीक्षण (इंटरेक्टर, इंटरेक्टर परीक्षण) बनाते हैं, तो यह टीडीडी के सिद्धांत के साथ अच्छी तरह से फिट बैठता है। इस तथ्य के कारण कि प्रोटोकॉल द्वारा तर्क के प्रत्येक मामले के आउटपुट और इनपुट को परिभाषित किया गया है, यह केवल एक परीक्षण लिखने के लिए पर्याप्त है जो इसके व्यवहार को निर्धारित करता है, और फिर सीधे विधि के तर्क को लागू करता है।

तीसरा, क्लीन स्विफ्ट (VIPER के विपरीत) डेटा प्रोसेसिंग और निर्णय लेने के एक अप्रत्यक्ष प्रवाह को लागू करता है। केवल एक चक्र को हमेशा क्रियान्वित किया जाता है - देखें - इंटरेक्टर - प्रस्तुतकर्ता - देखें, जो रीफैक्टरिंग को भी सरल करता है, क्योंकि कम संस्थाओं को बदलने के लिए अक्सर आवश्यक होता है। इसके कारण, लॉजिक वाली परियोजनाएं जो अक्सर बदलती हैं या पूरक होती हैं, स्वच्छ स्विफ्ट पद्धति का उपयोग करके रिफ्लेक्टर के लिए अधिक सुविधाजनक होती हैं। क्लीन स्विफ्ट का उपयोग करते हुए, आप दो तरीकों से संस्थाओं को अलग करते हैं:

इनपुट और आउटपुट प्रोटोकॉल घोषित करके घटकों को अलग करें
अलग-अलग अनुरोधों / प्रतिक्रियाओं / यूआई मॉडल में संरचनाओं और एनकैप्सुलेटिंग डेटा का उपयोग करके सुविधाओं को अलग करें। प्रत्येक विशेषता का अपना तर्क होता है और एक प्रक्रिया के ढांचे के भीतर नियंत्रित किया जाता है, अन्य विशेषताओं के साथ एक मॉड्यूल में प्रतिच्छेद किए बिना।

प्रोटोटाइप परियोजनाओं में लंबी अवधि के परिप्रेक्ष्य के बिना छोटी परियोजनाओं में स्वच्छ स्विफ्ट का उपयोग नहीं किया जाना चाहिए। उदाहरण के लिए, इस वास्तुकला का उपयोग करके डेवलपर सम्मेलन की अनुसूची के लिए एक आवेदन को लागू करना बहुत महंगा है। लंबी अवधि की परियोजनाएं, कई व्यावसायिक तर्क वाली परियोजनाएं, इसके विपरीत, इस वास्तुकला के ढांचे में अच्छी तरह से फिट होती हैं। क्लीन स्विफ्ट का उपयोग करना बहुत सुविधाजनक है जब परियोजना दो प्लेटफार्मों - मैक ओएस और आईओएस के लिए कार्यान्वित की जाती है, या इसे भविष्य में पोर्ट करने की योजना है।

VIPER के विकल्प के रूप में स्वच्छ स्विफ्ट आर्किटेक्चर