Шаблон mvvm в этом стиле кодирования бессмысленен?

Question

Я разработал свой собственный проект с шаблоном MVC и пытаюсь преобразовать его в шаблон MVVM, но иногда я думаю, что он становится все хуже и бессмысленным.

Это часть моего кода.У меня есть контроллер, модель и одна модель представления, как показано ниже:

struct FAQ: Mappable {        
    var id: String?
    var question: String?
    var answer: String?
    var datalist: [FAQ]?
    //var datalist: [Any]?

    mutating func mapping(map: Map) {
        id <- map["id"]
        question <- map["question"]
        answer <- map["answer"]
        datalist <- map["data"]
    }
}

class learningViewController: UIViewController, UITableViewDelegate, UITableViewDataSource {
    @IBOutlet weak var faqLable: UILabel!
    @IBOutlet weak var learningLable: UILabel!
    @IBOutlet weak var uiviewHeader: UIView!
    @IBOutlet weak var barRight: UILabel!
    @IBOutlet weak var barLeft: UILabel!
    @IBOutlet weak var tableView: UITableView!
    @IBOutlet weak var backImage: UIImageView!

    var learningRequestSession: URLSessionDataTask?
    let address = Domains.address
    var objectData = faqViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()
        objectData.faqFunc {
            self.setup()
        }
        setup()

    }

    override func viewWillAppear(_ animated: Bool) {
        tableView.reloadData()
    }

    func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        return objectData.objectData.count
    }

    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "faqCell", for: indexPath) as! customViewCellTableViewCell

        //cell.faqIcon.image = UIImage(named: "question")
        cell.faqTitle.text = objectData.objectData[indexPath.row].question
        cell.faqBody.text = objectData.objectData[indexPath.row].answer

        return cell            
    }
...
}

, и это класс модели представления:

class faqViewModel {
    var objectData = [FAQ]()

    init(faq: [FAQ]) {
        self.objectData = faq
    }

    init() {}

    func faqFunc(complition: @escaping () -> () ) {        
        let url = URL(string: "\(address)faq/getdata")
        print(url!)

        URLSession.shared.dataTask(with: url!) { (data, response, err) in
            if let content = data {
                do {
                    let json = try! JSONSerialization.jsonObject(with: content, options: .mutableContainers) as Any

                    let mapper = Mapper<FAQ>().map(JSONObject: json)

                    self.objectData = (mapper?.datalist.map({ $0}))!
                } catch {
                    print(err)
                }
            }
        }.resume()
    }
}

Функция faqFunc используется в классе контроллера в шаблоне MVC.

Я переместил его в модель представления в этом шаблоне.Поэтому я чувствую, что делаю это неправильно или MVC был лучше ...!

Answer 1

Некоторые из проблем MVC хорошо описаны в блоге Дейва ДеЛонга .

Я согласен с ним, что MVC, , в некоторых случаях может привести к:

1. M assive V iew C контроллеры (Просмотр логики, бизнес-логики и сетей часто размещается в *ViewController классах, которые растут, иногда чрезвычайно.

2. Нарушение инкапсуляции (например, передача данных в ViewController в следующем порядке и т. д.)

3. Тестируемость. Обычно MVC требует написания интеграционных тестов, которые сложно поддерживать и которые требуют очень хороших знаний UIKit

MVVM

Стоит сказать, что MVVM - это в основном модный MVC.

MVVM - это попытка устранить некоторые недостатки паттерна MVC.Это улучшает разделение проблем , делает логику как-то более ясной. Больше нет массовых контроллеров представления (при правильном использовании). ИМХО, лучшее преимущество MVVM - Testable . Теперь у нас есть ViewModel, объект, который содержит все данные, относящиеся к представлению, поэтому для написания тестов не требуется интеграциятестирование больше.Но использование MVVM обычно связано с каким-то реактивным программированием.Что само по себе имеет скрытые подводные камни и крутой кривой обучения.

MVVM Pros

1. Лучшая тестируемость
2. Лучшее разделение интересов
3. Избавление отКонтроллеры Massive View
4. Это как бы соответствует парадигме CocoaTouch MVC

Есть и другие, я думаю,

Против MVVM

1. Использование реактивных сред требуетизменение "мышления" и, как следствие, крутая кривая обучения
2. Легко получить модель и представление несинхронно
3. Легко допустить ошибку при наблюдении логики

И еще

Выводы

MVVM - это хороший инструмент, который при правильном использовании исправляет некоторые недостатки MVC и дает производственные преимущества.MVVM требует определенных усилий и изучения лучших практик.Но, прежде чем углубляться в это, я предлагаю прочитать серию блога Дэйва ДеЛонга "Лучший MVC" и помнить, что MVC - это нативный шаблон Apple, и, реализуя его, вы остаетесь "в безопасности" от больших сюрпризов, когда SDKобновлен.

PS Я большой поклонник правильного использования MVVM, но неправильное использование иногда пугает меня.

Answer 2

Модель представления - это своего рода мини-модель, используемая в представлении.Таким образом, вы привязываете к нему атрибуты вида и управляете изменениями в каждом из них:

Вид изменен -> Обновления модели вида

Вид-модель изменен -> Обновления вида

faqViewModel класс, который вы написали, является разновидностью APIRequestLoader и не относится к view-модели.Для получения дополнительной информации я предлагаю вам провести исследование о Clean Swift Architecture и Swift Viper Architecture, а если вы хотите узнать больше о том, как отделить сетевой запрос от других частей приложения, Этот сеанс WWDC 2018 хороший вариант для просмотра.