როგორ ავირჩიოთ შესაბამისი iOS არქიტექტურა (ნაწილი 2)

MVC, MVP, MVVM, VIPER ან VIP

შეგიძლიათ პირველი ნაწილის კონსულტაცია აქ.

IOS ყველაზე მნიშვნელოვანი არქიტექტურა

მოკლე მიმოხილვა.

MVC

MVC ფენები შემდეგია:

M: ბიზნეს ლოგიკა, ქსელის ფენა და მონაცემთა წვდომის ფენა

V: UI დონის (UIKit ობიექტები, storyboards, Xibs)

C: კოორდინაციას უწევს შუამავლობას მოდელსა და შეხედულებას შორის.

MVC– ს გასაგებად უნდა გვესმოდეს ის კონტექსტი, რომელშიც ის გამოიგონეს. MVC გამოიგონეს ვებ – გვერდების შექმნის ძველ დღეებში, როდესაც Views– ს სტატუსი არ ჰქონდა. ძველად, ბრაუზერი ატვირთავს ყველა HTML– ს, როცა ვებ – გვერდზე ვიზუალური ცვლილება დაგვჭირდება. იმ დროისთვის წარმოდგენა არ არსებობდა, რომ ხედვის მდგომარეობა შენარჩუნებული და შენახული იყო.

მაგალითად, იყო რამდენიმე დეველოპერი, რომლებიც იყენებდნენ ერთსა და იმავე HTML ფაილებს, PHP- ს და მონაცემთა ბაზასთან წვდომას. ასე რომ, MVC– ის მთავარი მოტივაცია იყო ხედვის დონის გამოყოფა მოდელის დონისგან. ამან გაზარდა მოდელის დონის ტესტირება. სავარაუდოდ MVC– ში ხედმა და მოდელის ფენებმა არ უნდა იცოდნენ ერთმანეთის შესახებ. ამის შესაძენად გამოიგონეს შუალედური შრე, რომელსაც ეწოდება კონტროლერი. ეს იყო SRP, რომელიც გამოიყენეს.

MVC ციკლის მაგალითი:

  1. ხვდება მომხმარებლის მოქმედება / მომხმარებლის მოვლენა ხედვის დონეზე (მაგ. "განახლების მოქმედება") და ეს ქმედება ეცნობება კონტროლერს
  2. კონტროლერი, რომელიც აგზავნის მონაცემებს მოდელის დონეზე
  3. დააბრუნეთ მონაცემები კონტროლერისთვის
  4. კონტროლერი ამბობს, რომ ხედი განაახლებს სტატუსს ახალი მონაცემებით
  5. იხილეთ მისი მდგომარეობის განახლება

Apple MVC

IOS- ში ხედვის კონტროლერი დაერთებულია UIKit და სიცოცხლის ციკლის ხედთან, ამიტომ ეს არ არის სუფთა MVC. ამასთან, MVC განსაზღვრებაში არაფერია სათქმელი, რომ მაკონტროლებელს არ შეუძლია იცოდეს ხედი ან მოდელის სპეციფიკური განხორციელება. მისი მთავარი მიზანია გამოყოს მოდელის დონის პასუხისმგებლობები ხედვის დონისაგან, რათა მათ განმეორებით გამოვიყენოთ და მოდელის დონე განვასხვაოთ.

ViewController შეიცავს ხედვას და ეკუთვნის მოდელს. პრობლემა ისაა, რომ ჩვენ ვწერთ როგორც კონტროლერის კოდს, ისე ხედვის კოდს ViewController- ში.

MVC ხშირად იწვევს მასივის ხედვის კონტროლერის პრობლემას, მაგრამ ეს მხოლოდ საკმარის სირთულის მქონე აპებში ხდება და სერიოზულ საქმიანობად იქცევა.

არსებობს რამდენიმე მეთოდი, რომელთა გამოყენება დეველოპერს შეუძლია View Controller- ის უფრო გასაგებად. Რამდენიმე მაგალითი:

  • ამოიღეთ VC ლოგიკა სხვა კლასებისთვის, მაგალითად, ცხრილის ნახვის მეთოდების მონაცემთა წყარო და დელეგირება სხვა ფაილებისთვის, დელეგატის დიზაინის ნიმუშის გამოყენებით.
  • შექმენით კომპოზიციის პასუხისმგებლობის უფრო მკაფიო გადანაწილება (მაგ., VC გაყოფა ბავშვთა ხედვის მართვის საშუალებებად)
  • გამოიყენეთ კოორდინატორის დიზაინის ნიმუში ვირტუალურ კონტროლერში ნავიგაციის ლოგიკის განხორციელების პასუხისმგებლობის მოსაშორებლად
  • გამოიყენეთ DataPresenter შეფუთვის კლასი, რომელიც ათავსებს ლოგიკას და გარდაქმნის მონაცემთა მოდელს მონაცემების გამომუშავებაში, რომელიც წარმოადგენს საბოლოო მომხმარებლისთვის წარმოდგენილ მონაცემებს.

MVC წინააღმდეგ MVP

როგორც ხედავთ MVP დიაგრამას, MVC ძალიან ჰგავს

MVC იყო წინ გადადგმული ნაბიჯი, მაგრამ მას მაინც ახასიათებდა არარსებობა ან დუმილი ზოგიერთ საკითხთან დაკავშირებით.

ამასობაში მსოფლიო ქსელი გაიზარდა და დეველოპერთა საზოგადოებაში ბევრი რამ განვითარდა. მაგალითად, პროგრამისტებმა დაიწყეს Ajax- ის გამოყენება და ერთდროულად მთლიანი HTML გვერდის ნაცვლად იტვირთებენ გვერდების ნაწილებს.

MVC– ში, ჩემი აზრით, არ არსებობს მითითება, რომ კონტროლერმა არ უნდა იცოდეს View– ს (არყოფნის) კონკრეტული განხორციელება.

HTML ხედვის ფენის ნაწილი იყო და ბევრი შემთხვევა სულელური იყო. ზოგიერთ შემთხვევაში, ის უბრალოდ იღებს მოვლენებს მომხმარებლისგან და აჩვენებს GUI- ს ვიზუალურ შინაარსს.

ვინაიდან ვებ – გვერდების ნაწილები ნაწილებად იტვირთებოდა, ამ სეგმენტაციამ განაპირობა ხედვის მდგომარეობის შენარჩუნება და პრეზენტაციის ლოგიკის პასუხისმგებლობის გამიჯვნა.

პრეზენტაციის ლოგიკა არის ლოგიკა, რომელიც აკონტროლებს მომხმარებლის ინტერფეისის ჩვენების და მომხმარებლის ინტერფეისის ელემენტების ურთიერთქმედებას. მაგალითად, არის კონტროლის ლოგიკა, თუ როდის უნდა დაიწყოს დატვირთვის ინდიკატორი ჩვენება / ანიმაცია და როდის უნდა შეწყდეს ჩვენება / ანიმაცია.

MVP და MVVM– ში ხედვის ფენა ისეთი სისულელე უნდა იყოს, რომ არ შეიცავს ლოგიკასა და ინტელექტს, ხოლო iOS– ში ხედვის კონტროლერი უნდა იყოს ხედვის ფენის ნაწილი. ის ფაქტი, რომ View არის დუმლი, ნიშნავს, რომ პრეზენტაციის ლოგიკაც კი რჩება View თვითმფრინავის გარეთ.

MVC– ს ერთ – ერთი პრობლემა ის არის, რომ გაუგებარია, სად უნდა წარიმართოს პრეზენტაციის ლოგიკა. ამის შესახებ ის უბრალოდ დუმს. პრეზენტაციის ლოგიკა უნდა იყოს ხედვის სიბრტყეზე თუ სამოდელო სიბრტყეში?

თუ მოდელის როლი მხოლოდ "ნედლი მონაცემების" მოწოდებაა, ეს ნიშნავს, რომ ხედიდან კოდი შემდეგია:

განვიხილოთ შემდეგი მაგალითი: ჩვენ გვყავს მომხმარებელი სახელით და გვარით. თვალსაზრისით, ჩვენ უნდა ვაჩვენოთ მომხმარებლის სახელი, როგორც "გვარი, სახელი" (მაგ. "ფლორესი, ტიაგო").

თუ მოდელის როლი არის "ნედლი" მონაცემების მიწოდება, ეს ნიშნავს, რომ ხედიდან კოდი შემდეგია:

ნება firstName = userModel.getFirstName () ნება lastName = userModel.getLastName () nameLabel.text = გვარი + “,“ + სახელი

ეს ნიშნავს, რომ View- ს პასუხისმგებლობაა მომხმარებლის ინტერფეისის ლოგიკის გატარება. ამასთან, ეს შეუძლებელს ხდის მომხმარებლის ინტერფეისის ლოგიკის ტესტირებას.

სხვა მიდგომაა, რომ მოდელმა აჩვენოს მხოლოდ ის მონაცემები, რომლებიც უნდა აჩვენოს და ბიზნესის ლოგიკა არ დაათვალიეროს. შემდეგ ჩვენ გვაქვს მოდელები, რომლებიც ამუშავებენ როგორც ბიზნეს ლოგიკას, ასევე მომხმარებლის ინტერფეისის ლოგიკას. ეს იქნება ტესტირებადი სუბიექტი, მაგრამ შემდეგ მოდელი აშკარად დამოკიდებულია დამოკიდებულებაზე.

მოდით name = userModel.getDisplayName () nameLabel.text = სახელი

ეს MVP- სთვის გასაგებია და პრეზენტაციის ლოგიკა რჩება წამყვან დონეზე. ეს ზრდის პრეზენტატორის დონის ტესტირებადობას. ახლა მოდელისა და წამყვანის ფენის ტესტირება უპრობლემოდ შეიძლება.

ჩვეულებრივ MVP დანერგვებში ხედი იმალება ინტერფეისის / პროტოკოლის მიღმა და წამყვანში არ უნდა იყოს მითითებული UIKit– ზე.

კიდევ ერთი რამ უნდა აღინიშნოს არის გარდამავალი დამოკიდებულებები.

თუ კონტროლერს აქვს ბიზნეს შრე, როგორც დამოკიდებულება, ხოლო ბიზნეს ფენას აქვს მონაცემთა წვდომის ფენა, როგორც დამოკიდებულება, კონტროლერს აქვს ტრანზიტული დამოკიდებულება მონაცემთა წვდომის ფენისთვის. მას შემდეგ, რაც MVP დანერგვები ჩვეულებრივ იყენებს კონტრაქტს (პროტოკოლს) ყველა დონეს შორის, გარდამავალი დამოკიდებულებები არ არსებობს.

სხვადასხვა ფენა ასევე იცვლება სხვადასხვა მიზეზით და განსხვავებული ტემპებით. ასე რომ, თუ ერთ დონეს შეცვლით, ეს არ გამოიწვევს სხვა დონის მეორად ეფექტებს / პრობლემებს.

პროტოკოლები უფრო სტაბილურია, ვიდრე კლასები. ჟურნალები არ შეიცავს განხორციელების დეტალებს და არ უკავშირდება კონტრაქტებს. ამრიგად, შესაძლებელია განხორციელდეს ერთი დონის შესრულების დეტალების შეცვლა, სხვა დონეზე ზემოქმედების გარეშე.

კონტრაქტები (პროტოკოლები) ქმნის შრეებს შორის განშორებას.

MVP vs MVVM

MVVM დიაგრამა

MVP- სა და MVVM- ს შორის ერთ-ერთი მთავარი განსხვავება ის არის, რომ MVP- ში პრეზენტატორი ინტერფეისს ხედთან, ხოლო MVVM- ში ხედი მიმართულია მონაცემებისა და მოვლენების ცვლილებებისკენ.

MVP– ში ჩვენ ვქმნით სახელმძღვანელოს კავშირს წამყვანსა და ხედს შორის ინტერფეისების / პროტოკოლების გამოყენებით. MVVM– ში ჩვენ ვატარებთ მონაცემთა ავტომატურ სავალდებულოობას RxSwift, KVO ან მექანიზმს გენერიკებით და დახურვებით.

MVVM– ში ჩვენ ViewModel– სა და View– ს შორის ხელშეკრულებაც კი არ გვჭირდება (მაგ. Java ინტერფეისი / iOS პროტოკოლი), რადგან ჩვეულებრივ ვსაუბრობთ Observer Design Pattern– ის საშუალებით.

MVP იყენებს დელეგირებულ შაბლონს, რადგან წამყვანის შრე ბრძანებებს გადასცემს ხედვის ფენას. ასე რომ, მან უნდა იცოდეს ხედი, თუნდაც ეს მხოლოდ ინტერფეისი / პროტოკოლის ხელმოწერაა. გაიხსენეთ განსხვავება შეტყობინებების ცენტრსა და TableView დელეგატებს შორის. შეტყობინების ცენტრს არ სჭირდება რაიმე ინტერფეისი საკომუნიკაციო არხის შესაქმნელად. ამასთან, TableView Delegates იყენებს ოქმს, რომელიც კლასებმა უნდა განახორციელონ.

დაფიქრდით დატენვის ინდიკატორის პრეზენტაციის ლოგიკაზე. MVP– ში წამყვანი აწარმოებს ViewProtocol.showLoadingIndicator– ს. MVVM– ში ViewModel– ში შეიძლება იყოს isLoading თვისება. ხედვის ფენა იყენებს მონაცემთა ავტომატურ სავალდებულოობას, რომ აღიაროს, როდესაც ეს თვისება იცვლება და განახლდება. MVP უფრო მყარია, ვიდრე MVVM, რადგან წამყვანი გასცემს ბრძანებებს.

MVVM უფრო მეტია, ვიდრე მონაცემების ცვლილებები, ვიდრე პირდაპირი შეკვეთები, და მონაცემთა ცვლილებებს ვუკავშირებთ განახლებების სანახავად. როდესაც ჩვენ ვიყენებთ RxSwift- ს და ფუნქციონალური რეაქტიული პროგრამირების პარადიგმას MVVM- სთან ერთად, ჩვენ კოდი კიდევ უფრო ნაკლებად დამაჯერებელი და უფრო დეკლარაციული გავხდით.

MVVM უფრო ადვილია, ვიდრე MVP, რადგან MVVM იყენებს დამკვირვებლის დიზაინის ნიმუშს, რომელიც მონაცემებს კომპონენტებს შორის გაწყვეტილი გზით გადასცემს. ასე რომ, ჩვენ შეგვიძლია შეამოწმოთ მონაცემების ცვლილების მხოლოდ ორი ობიექტის შედარების ნაცვლად, ვიდრე მეთოდის ზარის დაცინვა, რომ შეამოწმოთ კომუნიკაცია ხედსა და წამყვანს შორის.

პ.ს .: რამდენიმე განახლება გავაკეთე იმ ნივთზე, რამაც ის ძალიან გაზარდა. ამიტომ საჭირო იყო მისი სამ ნაწილად დაყოფა. მესამე ნაწილის წაკითხვა შეგიძლიათ აქ.

მეორე ნაწილი აქ მთავრდება. ყველა კავშირი მისასალმებელია. მესამე ნაწილი არის VIPER, VIP, რეაქტიული პროგრამირება, ვაჭრობა, შეზღუდვები და კონტექსტუალური გრძნობა.

მადლობას გიხდით კითხვისთვის! თუ მოგეწონათ ეს სტატია, გთხოვთ ტაში დაუკაროთ სხვებმაც წაიკითხონ იგი :)