MVC vs. MVVM. Dlaczego młodszy brat zyskuje na popularności?
Przed rozpoczęciem części zasadniczej artykułu chciałbym na wstępie zaprosić Was na cykl, który rozpoczyna ten tekst. Poświęcę w nim trochę czasu na zaznajomienie Was z kilkoma dobrymi praktykami, które według mnie warto stosować podczas developowania aplikacji mobilnych (i nie tylko mobilnych) oraz przydatnymi bibliotekami wartymi uwagi, gdy zabieramy się za programowanie mobilków pod systemem z Cupertino.
Adam Włodarczyk. Właściciel firmy Hindbrain tworzącej oprogramowanie na urządzenia mobilne oraz systemy CRM w różnych technologiach. Jego ulubionymi językami są Java i Objective-C, chociaż próbuje też sił w językach takich jak Kotlin czy Swift. Zdarza się, że nawet czasem pokoduje w PHP’ie. Żeby dać ujście ekstrawertycznej części swojej osobowości, uczy i jest mentorem kolejnego pokolenia programistów w Coderslab. Po godzinach stara się dbać o kręgosłup pływając i ćwicząc na siłowni.
Spis treści
Wprowadzenie
Rozpocznijmy zatem od podstaw, każdy programista powinien znać pojęcie wzorców projektowych. Są one bardzo pomocne podczas tworzenia rozwiązań dla klientów, przyspieszają znacząco pracę, gdyż podążamy przez wcześniej utarte i ugruntowane w wielu projektach ścieżki (zmniejszamy tym samym prawdopodobieństwo popełnienia błędu i porażki). Wzorce pozwalają także koleżankom i kolegom po fachu zrozumieć tok myślenia oraz koncepcje jakie staraliśmy się upakować w danej technologii. Teraz trochę faktografii dla zaznajomienia tych, którzy może rozpoczynają swoją przygodę z programowaniem lub w ogóle są zieloni w temacie wzorców projektowych, czyli czym te wzorce są, jak się je grupuje i gdzie szukać informacji o nich.
Wzorce projektowe (ang. design patterns) jak sama nazwa wskazuje to ugruntowane, uniwersalne, sprawdzone w wielu przypadkach i środowiskach, przetestowane schematy postępowania podczas rozwiązywania różnych problemów projektowych. Przedstawiają sposób powiązania i zależności między klasami oraz obiektami, a także ułatwia tworzenie, zarządzanie i utrzymywanie kodu źródłowego. Wzorce projektowe są opisem rozwiązania, czyli takim cook bookiem, a nie implementacją.
Podstawowy podział jaki wykorzystywany jest do ustrukturyzowania wzorców projektowych to podział na trzy kategorie:
- Kreacyjne – opisują w jaki sposób obiekty są tworzone;
- Strukturalne – opisują struktury powiązanych ze sobą obiektów;
- Behawioralne – opisują zachowania i odpowiedzialności współpracujących ze sobą obiektów.
W dzisiejszym materiale skupimy się na wzorcach strukturalnych, które zawarte zostały w tytule tego artykułu, czyli MVC i MVVM. Zarówno jeden, jak i drugi wzorzec wykorzystywany jest do podziału aplikacji na spójnie logicznie elementy zgodnie z pewnymi normami i zasadami jakie zostały przyjęte w tych podejściach.
Wzorzec MVC
MVC, czyli Model-View-Controller jest wzorcem, który dzieli aplikacje na trzy warstwy. Pierwszą jest model danych wraz z logiką biznesową oraz dostępem do danych. W tej warstwie następuje wymiana danych, ich mutacje, filtrowanie. Następną warstwą jest widok, czyli warstwa prezentacji danych oraz interakcji z użytkownikiem. Ostatnia warstwa to kontroler, który zarządza połączeniem widoku z modelem oraz innymi elementami wykorzystywanymi w aplikacji (sesją, serwer api, powiadomienia itd.). Ten sposób tworzenia kodu wykorzystywany jest podczas programowania aplikacji mobilnych na urządzenia spod znaku nadgryzionego jabłka (do dziś). Ma to jednak swoje konsekwencje, gdyż kod źródłowy (szczególnie w kontrolerze) staje się mało czytelny. Agreguje w sobie połączenie modelu z widokiem, dodatkowo posiada często metody do pobierania czy wysyłania danych do serwera RESTowego, zarządza powiadomieniami, nasłuchuje zdarzeń, generalnie robi bardzo dużo.
Podczas tworzenia aplikacji zgodnie z tym wzorcem można dojść do pewnej wprawy, która przeradza się czasem w ekwilibrystykę skakania między różnymi klasami w celu podzielenia kodu z kontrolera na mniejsze elementy, ale chyba nie chodzi nam w programowaniu o utrudnianie sobie życia tylko o jego ułatwianie.
Rysunek 1. Wzorzec MVC
Wzorzec MVVM
Z pomocą przyszedł kolejny wzorzec strukturalny, czyli MVVM. Rozwinięcie skrótu oznacza ModelView-View-Model. Jest to wzorzec, który stał się niejako rozwinięciem wzorca MVC i implementuje w sobie zasady clean architecture, czyli odseparowania od siebie elementów tak, aby kod był jak najbardziej niezależny od platformy. Dobra, czyli co ten wzorzec tak naprawdę robi? Tak naprawdę oprócz standardowego widoku (warstwy prezentacji, która w tym wypadku jest trochę połączeniem prezentera z kontrolerem) oraz modelu, który odpowiada nam za wymianę danych oraz enkapsuluje nam je w odpowiedniej formie, mamy również nowy byt pt. ViewModel.
Jest to połączenie warstwy modelowej z elementem przejściowym, który z danych wyciąga nam jedynie niezbędne dla widoku informacje, zawiera metody konieczne do prawidłowego wyfiltrowania czy zmapowania danych oraz zarządza logiką biznesową. Jest powoływany do życia wtedy, gdy warstwa prezentacji będzie gotowa i odseparowuje od niej logikę biznesową. Wzorzec ten pozwala zachować przepływ zgodny z zasadami czystej architektury (czyli od prezentera do warstwy danych).
Rysunek 2. Clean architecture
Krótko mówiąc dostajemy dodatkową warstwę, która spina dane z warstwą prezentacji, a dodatkowo dostajemy miejsce, gdzie możemy zaimplementować wszystkie metody zarządzające logiką biznesową. Dodatkowo możemy się w niej komunikować z innymi serwisami, co zdecydowanie odchudza warstwę kontrolera. Teraz w niej możemy skupić się na komunikacji z widokiem oraz zarządzaniu akcjami z użytkownikiem.
Rysunek 3. MVVM
Case study
Po takim krótkim i treściwym wstępie czas przejść do jakiegoś przykładu. Przygotowałem małą aplikację na iOS’a (do pobrania tutaj). Jest to bardzo prosta aplikacja pozwalająca zapisywać, odznaczać i usuwać zadania, które przed sobą postawimy. Dodatkowo mamy możliwość zmiany ich priorytetów. Aplikacja posiada w sobie kontroler, który ma widok dodawania zadania oraz listę tych zadań. Lista ma zaimplementowany system sortowania elementów od najnowszego do najstarszego oraz według priorytetów. Zadania oznaczone jako zakończone, są wyświetlane na samym końcu listy.
Aplikacja będzie rozwijana w kolejnych artykułach także zachęcam do lektury.
Pierwszym podejściem jakie przygotowałem dla Was, to wykorzystanie wzorca MVC w aplikacji. Struktura projektu wygląda następująco.
Rysunek 4. Struktura projektu MVC
TodoItem zawiera strukturę danych z jakiej będę korzystał. Nie jest ona jakoś mocno rozwinięta bo też projekt nie jest duży.
enum Priority: Int, Codable{
case normal
case important
case urgent
}
struct TodoItem: Codable {
let id: Int
let name: String
var done: Bool
var priority : Priority
let createdAt: Date
}
Wykorzystałem tu implementacje interfejsu Codable tak, aby dostać automatycznie generowany konstruktor oraz móc później bez zbędnego problemu skonwertować obiekt do JSONa i z powrotem. Atrybut priority jest zdefiniowany jako enum, który reprezentowany jest poprzez liczbę całkowitą (Int).
Za przechowywanie i wymianę danych odpowiedzialny jest DataManagerService. Jest to klasa typu Singleton, zapisuje dane do lokalnego storage’a (UserDefaults). Żeby uzyskać efekt loose coupling’u, czyli luźnego powiązania między implementacją a wywołaniem, wykorzystuje protokoły, które pozwolą mi bez najmniejszego problemu zastosować wstrzykiwanie zależności (ang. Dependency Injection). Oznacza to, że klasa wykorzystująca dany protokół nie wie, jak zaimplementowana jest logika biznesowa, ale za zna sygnatury metod, więc istnieje możliwość wstrzyknięcia konkretnej implementacji.
protocol DataManagerService {
static var shared: DataManagerService! {get}
var toDoItems: [TodoItem]! {get}
func getNextId() -> Int
func addItem(item: TodoItem) -> Void
func changePriority(priority: Priority, at index: Int) -> Void
func changeDoneStatus(at index: Int) -> Void
func removeItem(at index: Int) -> Void
}
Powyższy protokół definiuje zestaw funkcji oraz atrybutów, które będą zdefiniowane w klasie implementacyjnej, a w kontrolerze podczas jego tworzenia będzie wykorzystywana jako pole trzymające implementację, co pozwoli w przyszłości w łatwy sposób zmienić ewentualną implementację na bazę danych lub zewnętrzne RESTful API.
W implementacji serwisu zaszyta jest zmienna toDoItems, która podczas pobierania listy od razu ją sortuje. Najpierw sprawdzane jest czy elementy są oznaczone jako nie zrobione, następnie sprawdzany jest priorytet od najważniejszego do najmniej ważnego, jako ostatnia sprawdzana jest data utworzenia zadania w kolejności malejącej (od najnowszej do najstarszej).
var toDoItems: [TodoItem]! {
get{
items.sort {
if !$0.done && $1.done {
return true
}
if $0.priority.rawValue > $1.priority.rawValue && ($0.done == $1.done){
return true
}
if $0.priority == $1.priority && $0.done == $1.done {
return $0.createdAt.compare($1.createdAt) == .orderedDescending
}
return false
}
return items
}
}
Poniżej przedstawione są funkcje zaimplementowane zgodnie z protokołem interfejsu.
extension DataManagerServiceImpl{
func changeDoneStatus(at index: Int) {
self.items[index].done = !(self.items[index].done)
storeIntoUserDefault()
}
func changePriority(priority: Priority, at index: Int) {
self.items[index].priority = priority
storeIntoUserDefault()
}
func addItem(item: TodoItem) {
self.items.append(item)
storeIntoUserDefault()
}
func removeItem(at index: Int){
self.items.remove(at: index)
storeIntoUserDefault()
}
}
Funkcja storeIntoUserDefault koduje tablicę toDoItems do JSONa, a następnie zapisuje ją pod odpowiednim kluczem w local storage.
private func storeIntoUserDefault(){
do{
let encoder = JSONEncoder()
let encodedData = try encoder.encode(self.items)
let userDefaults = UserDefaults.standard
userDefaults.set(encodedData, forKey: TODO_KEY)
userDefaults.synchronize()
} catch {
print("err")
}
}
Czas na przygotowanie kontrolera. W nim skonfigurowany jest widok ToDoHeaderView oraz UITableView. Do prawidłowej komunikacji wykorzystywane są protokoły dla tych widoków (odpowiednik listenera/handlera w innych językach programowania).
Na wstępie musimy dodać widok, który składa się z inputa i przycisku do dodawania elementu do naszej listy. Jest on dodany jako Outlet w widoku Interface Buildera, także w samym kodzie przetrzymuję jedynie referencję do niego, a także definiuję kto będzie nasłuchiwał zdarzeń. W tym przypadku jest to kontroler właśnie, implementuje on metodę protokołu.
protocol HeaderViewDelegate {
func itemCreated(name: String)
}
W samym kontrolerze, po jej wywołaniu przez widok, tworzony jest obiekt ToDoItem, który następnie wysyłany jest do dataMangera, zapisywany jest w local storage, a po wykonaniu tych wszystkich operacji, kontroler odświeża widok.
func itemCreated(name: String) {
let item = TodoItem(id: self.manager.getNextId(), name: name, done: false, priority: .normal, createdAt: Date())
self.manager.addItem(item: item)
reload()
}
Kontroler sam w sobie musi również zaimplementować wszystkie niezbędne metody do obsługi tableView, czyli:
func tableView(_ tableView: UITableView, heightForRowAt indexPath: IndexPath) -> CGFloat {
return TableView.automaticDimension
}
func tableView(_ tableView: UITableView, estimatedHeightForRowAt indexPath: IndexPath) -> CGFloat {
return TodoItemTableViewCell.defaultCellHeight()
}
func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
return self.manager.toDoItems.count
}
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = TodoItemTableViewCell.cellFromXib()
cell.configureCell(item: self.manager.toDoItems[indexPath.row], atIndex: indexPath.row)
return cell
}
func tableView(_ tableView: UITableView, didSelectRowAt indexPath: IndexPath) {
tableView.deselectRow(at: indexPath, animated: true)
}
func tableView(_ tableView: UITableView, canEditRowAt indexPath: IndexPath) -> Bool {
return true
}
func tableView(_ tableView: UITableView, editActionsForRowAt indexPath: IndexPath) -> [UITableViewRowAction]? {
let deleteAction = UITableViewRowAction(style: .destructive, title: "Remove") { [weak self] (UITableViewRowAction, IndexPath) in
self?.showRemovePrompt(index: indexPath.row)
}
let stateName = self.manager.toDoItems[indexPath.row].done ? "Undone":"Done"
let changeStateAction = UITableViewRowAction(style: .normal, title: stateName) { [weak self] (UITableViewRowAction, IndexPath) in
self?.manager.changeDoneStatus(at: indexPath.row)
self?.reload()
}
changeStateAction.backgroundColor = self.manager.toDoItems[indexPath.row].done ? Color.orange.darken1 : Color.lightBlue.base
if self.manager.toDoItems[indexPath.row].done {
return [deleteAction,changeStateAction]
}
let changePriority = UITableViewRowAction(style: .normal, title: "Priority") { [weak self] (UITableViewRowAction, IndexPath) in
self?.showPriorityAlertView(index: indexPath.row)
}
changePriority.backgroundColor = Color.lightGreen.base
return [deleteAction,changeStateAction,changePriority]
}
Jak łatwo zauważyć, nasz kontroler stał się dość mocno rozbudowany, a to tylko dwa komponenty (header i tableView). Co by było gdybyśmy zaimplementowali jeszcze kilka dodatkowych elementów w widoku… spaghetti jak nic.
Warto jeszcze wspomnieć o klasie odpowiadającej za wyświetlanie komórki w tabeli. Przygotowałem prosty widok, który wyświetla tytuł, priorytet oraz datę utworzenia elementu. Dodatkowo w zależności od statusu, tekst jest przekreślony lub nie.
class TodoItemTableViewCell: UITableViewCell {
@IBOutlet weak var indexLabel: UILabel!
@IBOutlet weak var nameLabel: UILabel!
@IBOutlet weak var dateLabel: UILabel!
@IBOutlet weak var priorityView: UIView!
let formatter = DateFormatter()
override func awakeFromNib() {
super.awakeFromNib()
// Initialization code
formatter.dateStyle = .medium
formatter.timeStyle = .medium
self.layer.masksToBounds = false
self.layer.shadowOffset = CGSize(width: -1, height: 1)
self.layer.shadowRadius = 1
self.layer.shadowOpacity = 0.5
}
override func setSelected(_ selected: Bool, animated: Bool) {
super.setSelected(selected, animated: animated)
// Configure the view for the selected state
}
func configureCell(item: TodoItem, atIndex:Int){
indexLabel.text = "(atIndex+1)"
let date = formatter.string(from: item.createdAt as Date)
var attrNameString: NSAttributedString?
var attrDateString: NSAttributedString?
var priorityColor:UIColor?
switch item.priority {
case .urgent:
priorityColor = Color.red.base
break
case .important:
priorityColor = Color.orange.base
break
default:
priorityColor = Color.lightGreen.base
}
if item.done{
attrNameString = NSAttributedString(string: item.name, attributes: [NSAttributedString.Key.strikethroughStyle: NSUnderlineStyle.single.rawValue,NSAttributedString.Key.foregroundColor : UIColor.gray])
attrDateString = NSAttributedString(string: date, attributes: [NSAttributedString.Key.strikethroughStyle: NSUnderlineStyle.single.rawValue,NSAttributedString.Key.foregroundColor : UIColor.gray])
}else{
attrNameString = NSAttributedString(string: item.name, attributes: [NSAttributedString.Key.foregroundColor : UIColor.black])
attrDateString = NSAttributedString(string: date, attributes: [NSAttributedString.Key.foregroundColor : UIColor.black])
}
nameLabel.attributedText = attrNameString
dateLabel.attributedText = attrDateString
priorityView.backgroundColor = priorityColor
}
static func cellFromXib() -> TodoItemTableViewCell{
let nib = Bundle.main.loadNibNamed(defaultReuseIdentifier(), owner: self, options: nil)! as NSArray
let cell = nib.object(at: 0) as! TodoItemTableViewCell
return cell
}
static func defaultReuseIdentifier() -> String{
return "TodoItemTableViewCell"
}
static func defaultCellHeight() -> CGFloat{
return 88.0
}
}
TableViewCell, musi sam zająć się sprawdzeniem wszystkich warunków, dobraniem odpowiednich kolorów, sprawdzeniem statusu i przekonwertowaniem daty na odpowiedni tekst. Trochę dużo pracy jak na prostą komórkę.
Z opanowaniem tego chaosu przychodzi wzorzec MVVM. Przejmuje on kilka odpowiedzialności, którymi musi teraz zajmować się ViewController. Dzięki nowej warstwie (viewModel) znajdującej się pomiędzy prezenterem a modelem danych, jesteśmy w stanie przenieść część (nawet większą) logiki biznesowej i tym samym odciążyć i odchudzić ViewController, co za tym idzie, kod stanie się bardziej modułowy, będzie o wiele bardziej przejrzysty i łatwiejszy w zarządzaniu. Dodatkowo zyskamy warstwę, która odpowiedzialna będzie za kontrolę, co faktycznie ma zostać wyświetlone w widoku. Warstwa danych zostanie zatem odseparowana od samego prezentera.
Rysunek 5. Struktura projektu MVVM
W tym celu niezbędna jest nowy plik, który nazwałem ToDoViewModel. Będzie on odpowiedzialny za przechowywanie elementów w odpowiedniej kolejności (zdejmuje tym samym odpowiedzialność z dataManagera) i tym zajmie się klasa o tej samej nazwie. Dodatkowo muszę stworzyć nową klasę dla elementu Todo, która będzie jej reprezentantem na froncie oraz będzie odpowiedzialna za przygotowanie elementów w prawidłowym formacie, tzn. sprawdzeniu warunków takich jak status elementu, jego priorytet i zamiana daty na tekst.
class TodoViewModel {
var delegate: TodoViewModelDelegate?
private let manager: DataManagerService?
private var items:[ToDoItemViewModel] = []
Tworzę listę elementów gotowych do wyświetlenia, posortowanych według założeń biznesowych.
var toDoItems:[ToDoItemViewModel]{
get{
items.sort {
if !$0.item.done && $1.item.done {
return true
}
if $0.item.priority.rawValue > $1.item.priority.rawValue && ($0.item.done == $1.item.done){
return true
}
if $0.item.priority == $1.item.priority && $0.item.done == $1.item.done {
return $0.item.createdAt.compare($1.item.createdAt) == .orderedDescending
}
return false
}
return items
}
}
init(manager: DataManagerService){
self.manager = manager
self.loadData()
}
private func loadData(){
if let _items: [TodoItem] = self.manager?.toDoItems{
self.items = _items.map{ ToDoItemViewModel(item: $0) }
}else{
self.items = []
}
delegate?.itemsChanged()
}
}
Tworzę metody do zarządzania elementami listy (dodawanie, odejmowanie, modyfikacja).
extension TodoViewModel{
func insert(name:String){
let item = TodoItem(id: self.manager?.getNextId() ?? 0, name: name, done: false, priority: .normal, createdAt: Date())
self.manager?.addItem(item: item)
self.loadData()
}
func remove(at index:Int) {
self.manager?.removeItem(at: self.toDoItems[index].item.id)
self.loadData()
}
func changePriority(priority: Priority,at index:Int){
self.manager?.changePriority(priority: priority,at: self.toDoItems[index].item.id)
self.loadData()
}
func changeDoneStatus(at index:Int) {
self.manager?.changeDoneStatus(at: self.toDoItems[index].item.id)
self.loadData()
}
}
Tworzę obiekt przechowujący wszystkie niezbędne elementy, które będą prezentowane w widoku (tj. sformatowany tekst, kolor priorytetu, data w formacie tekstowym).
struct ToDoItemViewModel{
let nameText:NSAttributedString
let createdAtText: NSAttributedString
let priorityColor: UIColor
let removeText: String
let priorityText: String
let item:TodoItem
init(item:TodoItem){
self.item = item
let formatter = DateFormatter()
formatter.dateStyle = .medium
formatter.timeStyle = .medium
let date = formatter.string(from: item.createdAt as Date)
var priorityColor:UIColor
switch item.priority {
case .urgent:
priorityColor = Color.red.base
break
case .important:
priorityColor = Color.orange.base
break
default:
priorityColor = Color.lightGreen.base
}
self.priorityColor = priorityColor
var attrNameString: NSAttributedString?
var attrDateString: NSAttributedString?
if item.done{
attrNameString = NSAttributedString(string: item.name, attributes: [NSAttributedString.Key.strikethroughStyle: NSUnderlineStyle.single.rawValue,NSAttributedString.Key.foregroundColor : UIColor.gray])
attrDateString = NSAttributedString(string: date, attributes: [NSAttributedString.Key.strikethroughStyle: NSUnderlineStyle.single.rawValue,NSAttributedString.Key.foregroundColor : UIColor.gray])
}else{
attrNameString = NSAttributedString(string: item.name, attributes: [NSAttributedString.Key.foregroundColor : UIColor.black])
attrDateString = NSAttributedString(string: date, attributes: [NSAttributedString.Key.foregroundColor : UIColor.black])
}
self.nameText = attrNameString!
self.createdAtText = attrDateString!
self.removeText = "You want to remove item:nn(item.name)nnAre You sure, You want to do this?"
self.priorityText = "You want to change priority for:nn(item.name)n"
}
}
W samym kontrolerze zbyt dużo się nie zmienia (przynajmniej na tym etapie), ale zyskujemy odseparowanie od dataManagera, co w przyszłości pozwoli nam bez ingerencji w warstwę prezentacji zmieniać implementację warstwy zarządzania danymi.
Tworzę referencję do viewModel w kontrolerze.
var viewModel: TodoViewModel = TodoViewModel(manager: DataManagerServiceImpl.shared)
Wykorzystanie viewModel’u na przykładzie wyświetlania komórki w tableView.
func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
let cell = TodoItemTableViewCell.cellFromXib()
cell.configureCell(item: self.viewModel.toDoItems[indexPath.row], atIndex: indexPath.row)
return cell
}
Funkcja konfigurująca komórkę w TodoItemTableViewCell.
func configureCell(item: ToDoItemViewModel, atIndex:Int){
indexLabel.text = "(atIndex+1)"
nameLabel.attributedText = item.nameText
dateLabel.attributedText = item.createdAtText
priorityView.backgroundColor = item.priorityColor
}
Porównując zatem te dwie funkcję we wzorcu MVVM z wzorcem MVC zyskaliśmy większą przejrzystość kodu, odseparowanie widoku od modelu danych, a tym samym możliwość zarządzania formą prezentacji bez konieczności ingerencji w dane.
Podsumowanie
Przyszedł czas na krótkie podsumowanie. W programowaniu aplikacji mobilnych, klasy obsługujące dane widoki w modelu MVC w bardzo szybkim tempie zwiększają swój rozmiar co stwarza problemy w późniejszym utrzymaniu takiego kodu i jednocześnie zaciera obraz logiki biznesowej. O wiele lepszym rozwiązaniem dla aplikacji mobilnych (i nie tylko) staje się zastosowanie wzorców projektowych, które w większym stopniu rozbijają kod na mniejsze, logicznie spójne elementy, jednocześnie separując warstwy od siebie nową warstwą abstrakcji.
Oczywiście każdy wzorzec ma swoje plusy i minusy, więc do danego projektu należy podchodzić indywidualnie i przed rozpoczęciem prac rozważyć czy to rozwiązanie jest najlepszym z możliwych. Niemniej, wzorzec MVVM coraz bardziej zyskuje na popularności i warto zapoznać się z nim nieco bliżej, a na pewno w przyszłości odwdzięczy się nam skróceniem czasu przy dorabianiu nowego ficzera do naszej aplikacji. Dodatkowo zyskujemy o wiele większy procent pokrycia kodu testami w porównaniu do MVC.
Tymczasem już teraz zapraszam Was do przeczytania kolejnego artykułu z tej serii, który już niebawem powinien się ukazać na tym portalu. Poruszę w nim temat reaktywności aplikacji oraz na przykładzie pokaże w jak można wykorzystać bibliotekę RxSwift.
Poniżej możecie przeanalizować sobie cały projekt na moim githubie:
Link do projektu MVC.
Lind do projektu MVVM.
Zdjęcie główne artykułu pochodzi z unsplash.com.
Podobne artykuły
Nie komplikuj swojego kodu. Dependency Injection w iOS
Czy w IT największe szanse będą mieć najlepsi oraz prawdziwi pasjonaci? Wywiad z Joanną Kocik
10 lat temu użytkownicy aplikacji byli mniej wymagający. Wywiad z Maciejem Galosem
Jak zarządzać feature flags w aplikacjach ASP.NET Core przy użyciu Azure?
Computer Vision - rozpoznawanie treści na obrazach tak, jak robi to ludzki mózg
Modularna (r)evolucja w krakowskim oddziale StoneX
wAIste: wykorzystanie AI do walki z marnowaniem żywności i promowania zrównoważonego rozwoju
