IOS एप्लिकेशन में वास्तुशिल्प दृष्टिकोण

आज हम iOS विकास में वास्तु दृष्टिकोण के बारे में, कुछ चीजों के कार्यान्वयन में कुछ बारीकियों और विकास के बारे में बात करेंगे। मैं आपको बताता हूं कि हम किन दृष्टिकोणों का पालन करते हैं और विवरण में थोड़ा गहराई से जाते हैं।

सभी कार्डों को तुरंत प्रकट करें। हम MVVM-R (MVVM + Router) का उपयोग करते हैं।

वास्तव में, यह एक नियमित एमवीवीएम है, जिसमें स्क्रीन के बीच नेविगेशन को एक अलग परत में रखा गया है - राउटर, और डेटा प्राप्त करने के लिए तर्क - सेवाओं में। अगला, हम प्रत्येक परत के कार्यान्वयन में हमारी उपलब्धियों पर विचार करेंगे।

MVVM, VIPER या MVC क्यों नहीं?

एमवीसी के विपरीत, MVVM की परतों के बीच काफी विभाजित जिम्मेदारी है। यह VIPER की तरह कई "सेवारत" कोड नहीं है, हालांकि स्क्रीनमैडल फॉर स्क्रीन भी प्रोटोकॉल द्वारा बंद है। यह वास्तुकला कुछ हद तक VIPER के समान है, केवल प्रस्तुतकर्ता और इंटरेक्टर ViewModel में संयुक्त हैं, और परतों के बीच कनेक्शन को प्रतिक्रियाशील प्रोग्रामिंग और बाइंडरों के उपयोग के माध्यम से सरल किया गया है (हम ReactiveSwift का उपयोग करते हैं)।

सत्ता

हम डेटा मॉडल की दो परतों का उपयोग करते हैं: पहला एक डेटाबेस से जुड़ा हुआ है (बाद में प्रबंधित ऑब्जेक्ट के रूप में संदर्भित), दूसरा तथाकथित प्लेन ऑब्जेक्ट है , जिसका डेटाबेस से कोई लेना-देना नहीं है।

प्रत्येक सादा इकाई ट्रांसलेटेबल प्रोटोकॉल को लागू करती है, जिसे एक प्रबंधित ऑब्जेक्ट से आरंभ किया जा सकता है और जिससे एक प्रबंधित ऑब्जेक्ट बनाया जा सकता है। हम Realm का उपयोग डेटाबेस के रूप में करते हैं, हमारे मामले में ManagedObject RealmSwift.Object । मानचित्रण Codable माध्यम से होता है: उन्हें सादे वस्तुओं के रूप में मैप किया जाता है और प्रबंधित वस्तुओं के रूप में सहेजा जाता है। इसके अलावा सेवाएं और ViewModel केवल सादे वस्तुओं के साथ काम करते हैं।

 protocol Translatable { associatedtype ManagedObject: Object init(object: ManagedObject) func toManagedObject() -> ManagedObject } 

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

 protocol StorageProtocol { func cachedObjects<T: Translatable>() -> [T] func object<T: Translatable>(byPrimaryKey key: AnyHashable) -> T? func save<T: Translatable>(objects: [T]) throws func save<T: Translatable>(object: T) throws func delete<T: Translatable>(objects: [T]) throws func delete<T: Translatable>(object: T) throws func deleteAll<T: Translatable>(ofType type: T.Type) throws } 

इस दृष्टिकोण के पेशेवरों और विपक्ष क्या हैं?

प्रत्येक डेटाबेस की अपनी विशेषताएं हैं। उदाहरण के लिए, डेटाबेस में पहले से संग्रहीत एक रियल ऑब्जेक्ट का उपयोग केवल उस स्ट्रीम के ढांचे के भीतर किया जा सकता है जिसमें इसे बनाया गया था। यह असुविधाजनक है।

इसके अलावा, एक ऑब्जेक्ट को डेटाबेस से हटा दिया जा सकता है, जबकि यह रैम में है, और इसे एक्सेस करने से क्रैश हो जाएगा। कोर डेटा में समान विशेषताएं हैं। इसलिए, हम डेटाबेस से ऑब्जेक्ट प्राप्त करते हैं, उन्हें सादे ऑब्जेक्ट में परिवर्तित करते हैं, और फिर उनके साथ काम करते हैं।

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

कोर घटक

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

प्रोटोकॉल

हम सक्रिय रूप से प्रोटोकॉल का उपयोग करते हैं। सभी मुख्य घटक प्रोटोकॉल द्वारा बंद कर दिए गए हैं, और यूनिट परीक्षणों के लिए एक नकली या परीक्षण कार्यान्वयन करना संभव है। इस प्रकार, हम एक निश्चित कार्यान्वयन लचीलापन प्राप्त करते हैं। सभी निर्भरता init में पारित कर रहे हैं। प्रत्येक ऑब्जेक्ट को इनिशियलाइज़ करते समय, हम समझते हैं कि किस तरह की निर्भरताएँ हैं, यह अपने अंदर क्या उपयोग करता है।

HTTP क्लाइंट

एक नेटवर्क अनुरोध NetworkRequestParams प्रोटोकॉल द्वारा वर्णित है।

 protocol NetworkRequestParams { var path: String { get } var method: HTTPMethod { get } var parameters: Parameters { get } var encoding: ParameterEncoding { get } var headers: [String: String]? { get } var defaultHeaders: [String: String]? { get } } 

हम नेटवर्क अनुरोधों का वर्णन करने के लिए enum का उपयोग करते हैं। यह इस तरह दिखता है:

 enum UserNetworkRouter: URLRequestConvertible { case info case update(userJson:[String : Any]) } extension UserNetworkRouter: NetworkRequestParams { var path: String { switch self { case .info: return "/users/profile" case .update: return "/users/update_profile" } } var method: HTTPMethod { switch self { case .info: return .get case .update: return .post } } var encoding: ParameterEncoding { switch self { case .info: return URLEncoding() case .update: return JSONEncoding() } } var parameters: Parameters { switch self { case .info: return [:] case .update(let userJson): return userJson } } } 

प्रत्येक NetworkRouter URLRequestConvertible प्रोटोकॉल को लागू URLRequestConvertible है। हम इसे नेटवर्क क्लाइंट को देते हैं, जो इसे URLRequest कनवर्ट URLRequest और अपने इच्छित उद्देश्य के लिए इसका उपयोग करता है।

नेटवर्क क्लाइंट इस प्रकार है:

 protocol HTTPClientProtocol { func load(request: NetworkRequestParams & URLRequestConvertible) -> SignalProducer<Data, Error> } 

मैपर

हम डेटा मैपिंग के लिए Codable उपयोग करते हैं।

 protocol MapperProtocol { func map<MappingResult: Codable>(data: Data, dateDecodingStrategy: JSONDecoder.DateDecodingStrategy) -> SignalProducer<MappingResult, Error> } 

सूचनाएं पुश करें

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

सेवाएं

मोटे तौर पर, एक इकाई के लिए एक सेवा जिम्मेदार है। एक सामाजिक नेटवर्क एप्लिकेशन के उदाहरण के साथ इस पर विचार करें। उपयोगकर्ता का एक सर्वर है जो उपयोगकर्ता को प्राप्त करता है - स्वयं, और यदि हम इसे संपादित करते हैं, तो परिवर्तित संस्थाएं देता है। एक पोस्ट सेवा है जो पदों की एक सूची, एक विस्तृत पोस्ट, एक भुगतान सेवा आदि प्राप्त करती है। आदि

सभी सेवाओं में मुख्य घटक होते हैं। जब हम किसी सेवा पर एक विधि कहते हैं, तो यह मुख्य घटकों के विभिन्न तरीकों को छोड़ना शुरू कर देती है और अंततः परिणाम देती है।

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

सेवाएं स्टेटलेस हैं। चूंकि सेवाएँ एकल नहीं हैं, इसलिए हमारे पास एक ही सेवा के कई उदाहरण हो सकते हैं, जिसमें राज्य एक दूसरे से भिन्न हो सकते हैं। इससे गलत व्यवहार हो सकता है।

सेवाओं में से एक की एक विधि का एक उदाहरण:

 func currentUser() -> SignalProducer<User, Error> { let request = UserNetworkRouter.info return httpClient.load(request: request) .flatMap(.latest, mapUser) .flatMap(.latest, save) } 

ViewModel

हम ViewModel को 2 प्रकारों में विभाजित करेंगे:

• स्क्रीन के लिए ViewModel (ViewController)
• UIView के लिए ViewModel (तालिका कोशिकाओं या UICollectionView सहित)

ViewController के लिए ViewModel स्क्रीन के तर्क के लिए जिम्मेदार है। एक नियम के रूप में, यह नेटवर्क अनुरोध भेज रहा है, डेटा तैयार कर रहा है, यूआई घटनाओं का जवाब दे रहा है।

ViewModel सेवा से आए दृश्य के लिए सभी डेटा तैयार करता है। यदि संस्थाओं की सूची आती है, तो ViewModel इसे ViewModel की सूची में बदल देता है और उन्हें देखने के लिए बाध्य करता है। यदि राज्य हैं (कोई चेकमार्क / कोई चेकमार्क नहीं है), तो यह भी प्रबंधित और ViewModel को पारित कर दिया गया है।

ViewModel नेविगेशन लॉजिक को भी नियंत्रित करता है। नेविगेशन के लिए एक अलग राउटर परत है, लेकिन व्यूमॉडल कमांड देता है।

दृश्य मॉडल के विशिष्ट कार्य: उपयोगकर्ता प्राप्त करें, उपयोगकर्ता सेवा से संपर्क करें, प्राप्त मूल्य से ViewModel बनाएं। जब सब कुछ लोड होता है, तो ViewModel लेता है और व्यू सेल खींचता है।

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

ViewModel इस प्रोटोकॉल द्वारा बंद किया गया है:

 protocol CodeInputViewModelProtocol { ///    func send(code: String) -> SignalProducer<Void, Error> ///    func resendCode() -> SignalProducer<Void, Error> } 

ViewController में, इसे निम्न रूप में संग्रहीत किया जाता है:

 var viewModel: CodeInputViewModelProtocol? 

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

ViewModel व्यू और कोशिकाओं के लिए आमतौर पर डेटा स्वरूपण और उपयोगकर्ता इनपुट प्रसंस्करण से संबंधित है। उदाहरण के लिए, चयनित / चयनित राज्य का भंडारण नहीं करना चाहिए।

 final class FeedCellViewModel { let url: URL? let title: String let subtitle: String init(feed: FeedItem) { url = URL(string: feed.imageUrl) title = feed.title subtitle = DateFormatter.feed.string(from feed.publishDate) } } 

नेविगेशन

राउटर द्वारा स्क्रीन के बीच संक्रमण किया जाता है।

 class BaseRouter { init(sourceViewController: UIViewController) { self.sourceViewController = sourceViewController } weak var sourceViewController: UIViewController? } 

प्रत्येक स्क्रीन का अपना राउटर होता है, जो आधार से विरासत में मिला है। इसमें विशिष्ट स्क्रीन के लिए संक्रमण के तरीके हैं।

 final class FeedRouter : BaseRouter { func showDetail(viewModel: FeedDetailViewModelProtocol) { let vc = FeedDetailViewController() vc.viewModel = viewModel sourceViewController?.navigationController?.pushViewController(vc, animated: true) } } 

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

कई बार अलग-अलग राउटर में एक ही विधि की आवश्यकता होती है। इसे कई बार नहीं लिखने के लिए, हम एक प्रोटोकॉल बनाते हैं जिसमें सामान्य तरीके होंगे, और हम इसे extension लागू करेंगे। अब इस प्रोटोकॉल के लिए वांछित राउटर पर हस्ताक्षर करना पर्याप्त है, और इसमें आवश्यक तरीके होंगे।

 protocol FeedRouterProtocol { func showDetail(viewModel: FeedDetailViewModelProtocol) } extension FeedRouterProtocol where Self: BaseRouter { func showDetail(viewModel: FeedDetailViewModelProtocol) { let vc = FeedDetailViewController() vc.viewModel = viewModel sourceViewController?.navigationController?.pushViewController(vc, animated: true) } } 

राय

उपयोगकर्ता को जानकारी प्रदर्शित करने और उपयोगकर्ता कार्यों को संसाधित करने के लिए पारंपरिक रूप से दृश्य पारंपरिक रूप से जिम्मेदार है। MVVM में, हमें लगता है कि ViewController एक दृश्य है। यह महत्वपूर्ण है कि कोई भी जटिल तर्क न हो जिसे व्यूमॉडल में जगह मिले। किसी भी मामले में, यहां तक ​​कि एमवीसी में, आपको व्यूकंट्रोलर को भारी रूप से लोड नहीं करना चाहिए, हालांकि ऐसा करना मुश्किल है।

ViewModel को कमांड देखें। यदि ViewController लोड किया गया है, तो हम ViewModel कमांड देते हैं: नेटवर्क से या कैश से डेटा लोड करें। व्यू भी ViewModel से संकेतों को स्वीकार करता है। यदि ViewModel कहता है कि कुछ बदल गया है (उदाहरण के लिए, बहुत डेटा लोड किया गया है), तो View इस पर प्रतिक्रिया करता है और फिर से बताता है।

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

आगे क्या करना है?

आप मॉडल (ट्रांसलेटेबल) के लिए कोड जनरेशन का उपयोग कर सकते हैं, क्योंकि डेटाबेस ऑब्जेक्ट से प्लान ऑब्जेक्ट तक सभी इनिशियलाइज़ेशन और इसके विपरीत अब मैन्युअल रूप से पंजीकृत हैं।

आप एक अधिक सार्वभौमिक क्वेरी योजना का भी उपयोग कर सकते हैं, क्योंकि सेवाओं के कई तरीके इस तरह दिखते हैं: नेटवर्क पर जाएं, मैपिंग लागू करें, डेटाबेस पर सहेजें। यह एक सामान्य कंकाल सेट करने के लिए, सार्वभौमिक भी हो सकता है।

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