mvvm-delegates is not MVVM, actually that is MVP.

[marty-suzuki]

Hi, @tailec

ViewModel has a reference of abstracted ViewController as Delegate in mvvm-delegation.
It means that is not MVVM, actually that is MVP.
@amadeu01 mentioned in #2 (comment) , too.

I have a doubt about #2 (comment) .

I think in MVP, presenter can have access to view (imports UIKit) but view models in MVVM are forbidden to do that.

I think differences between MVP and MVVM are those have references of View directly or not.

Presenter in MVP

Presenter has a reference of View (or ViewController) that is abstracted as protocol in almost cases.
To reflect state of Presenter, it calls method of abstructed View.

protocol CounterView {
    func didChangeCount(_ presenter: CounterPresenter, count: Int)
}

class CounterViewController: UIViewController, CounterView {
    let presenter: CounterPresenter
    let countLabel: UILabel

    override func viewDidLoad() {
        super.viewDidLoad()

        presenter.view = self
    }

    func countUp() {
        presenter.countUp()
    }
}

extension CounterViewController: CounterView {
    func didChangeCount(_ presenter: CounterPresenter, count: Int) {
        countLabel?.text = "\(count)"
    }
}

class CounterPresenter {
    private(set) var count: Int = 0 {
        didSet {
             view?.didChangeCount(self, count: count)
        }
    }

    weak var view: CounterView?

    func countUp() {
        count += 1
    }
}

ViewModel in MVVM

ViewModel must not depend on View (or ViewController).
Even if View is abstracted as Protocol, ViewModel must not depend on them.
To reflect state of ViewModel, it notifies changes of state with closure (or RxSwift.Observable and so on).
Closure is implemented outside of ViewModel, therefore ViewModel does not depend on View directly.

class CounterViewController: UIViewController {
    let viewModel: CounterViewModel
    let countLabel: UILabel

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.countChanged = { [weak countLabel] count in
            countLabel?.text = "\(count)"
        }
    }

    func countUp() {
        viewModel.countUp()
    }
}

class CounterViewModel {
    private(set) var count: Int = 0 {
        didSet {
             countChanged?(count)
        }
    }

    var countChanged: ((Int) -> Void)?

    func countUp() {
        count += 1
    }
}

[eleev]

Those were the good arguments @marty-suzuki

The point of ViewModel is to be reusable, which means it has no coupling to particular View components. On the other hand, Presenter is an entity that presents something and has some coupling to View. Basically Presenter is a decoupled logic from View layer into separate object. Whereas ViewModel is a “transformation” layer, that converts models to viewable format and the other way around.

By no means these are the absolute rules, I wanted to share my thoughts related to this topic 😉

[tailec]

@marty-suzuki @jVirus amazing input, thanks for that!

I totally agree with your explanation and I'll make a PR to fix it.
I always thought that in MVVM you can have bindings between VM and VC represented by whatever binding mechanism you want to use - observables, delegation, notifications, closures, KVO etc.

You said:

To reflect state of ViewModel, it notifies changes of state with closure (or RxSwift.Observable and so on).
Closure is implemented outside of ViewModel, therefore ViewModel does not depend on View directly.

Can you explain why delegation cannot be used as notification mechanism for MVVM? Lots of people were doing that in Obj-C times etc. Also, Closure is implemented outside of ViewModel - I don't quite get that :)

[marty-suzuki]

@tailec
Thank you for replying!
I’ll explain why delegation cannot be used as notification mechanism for MVVM 👍

Notification mechanism for MVVM notifies without considering whatever objects receive notifications.
Observables, NotificationCenter, closures, KVO satisfy above conditions.

On the other hand, notification mechanism with delegation pattern depends on anything object that outside of itself.
If delegation pattern is used in MVVM, ViewModel depends on View.
In other words, it is same as Presenter depends on View.
Therefore I think the concept of MVVM with delegation pattern does not exist because it is actually MVP.

Lots of people were doing that in Obj-C times etc.

I think people used delegation pattern with MVC or MVP, not MVVM.

Also, Closure is implemented outside of ViewModel - I don't quite get that :)

I'm sorry I didn't explain it enough 😅
Closure as notification mechanism for MVVM is implemented outside of ViewModel, therefore implementation of closure is independent from ViewModel because ViewModel does not know implementation details of closure.
On the other hand, delegation as notification mechanism for MVVM has reference of View (View is almost abstracted as Protocol) to call delegate methods.
It means ViewModel knows what methods view does have.

By the way, what do you think differences between MVP and MVVM with delegation pattern? 👀

[tailec]

@marty-suzuki Replaced mvvm-delegates with mvp.

[VineFiner]

@tailec
谢谢你的回复！
我将解释为什么委托不能用作MVVM的通知机制👍

MVVM的通知机制在不考虑任何接收通知的对象的情况下通知。
Observables，NotificationCenter，closures，KVO满足上述条件。

另一方面，具有委托模式的通知机制取决于其自身之外的任何对象。
如果在MVVM中使用委托模式，则ViewModel依赖于View。
换句话说，它与Presenter依赖于View相同。
因此我认为具有委托模式的MVVM的概念不存在，因为它实际上是MVP。

很多人都在Obj-C时代这样做过。

我认为人们使用委托模式与MVC或MVP，而不是MVVM。

另外，Closure is implemented outside of ViewModel- 我不太明白:)

对不起，我没有解释得够 😅
作为MVVM的通知机制的Closure是在ViewModel之外实现的，因此闭包的实现独立于ViewModel，因为ViewModel不知道闭包的实现细节。
另一方面，作为MVVM的通知机制的委托引用View（View几乎被抽象为Protocol）来调用委托方法。
这意味着ViewModel知道视图有哪些方法。

那么，您认为MVP和MVVM之间的区别与委托模式有什么关系？ 👀

Hello, the delegate does not need to know the specific implementation method. For ViewModel, I don't know what methods the view has. He just exposes some methods. What is the difference between a delegate and a closure?

[marty-suzuki]

Hi, @VineFiner

What is the difference between a delegate and a closure?

Closures are one of Swift function that self-contained blocks of functionality.
On the other hand, Delegations are one of design pattern that delegating some prosessing to other object.
Therefore, meaning of implementations are different, even if prosessing results are same.
Those are sample implementations.

protocol SampleDelegate: AnyObject {
    func sampleModel(_ sampleModel: SampleModel, didChange isEnabled: Bool)
}

class SampleModel {
    private(set) var isEnabled: Bool = true
    weak var delegate: SampleDelegate?

    func toggle() {
        isEnabled = !isEnabled

        // Focus point①
        // Calls a delegate method, therefore this model knows owner of delegate method
        // even if a delegate object is abstracted.
        delegate?.sampleModel(self, didChange: isEnabled)
    }
}

class SampleViewController: UIViewController, SampleDelegate {

    let button = UIButton()
    let model = SampleModel()

    func buttonHandler(_ button: UIButton) {
        model.toggle()
    }

    func sampleModel(_ sampleModel: SampleModel, didChange isEnabled: Bool) {
        button.isEnabled = isEnabled
    } 
}

class SampleModel {
    private(set) var isEnabled: Bool = true
    var didChangeIsEnabled: ((Bool) -> Void)?

    func toggle() {
        isEnabled = !isEnabled

        // Focus point②
        // `didChangeIsEnabled` is owned by this model.
        // Therefore, it only knows arguments and return values.
        didChangeIsEnabled?(isEnabled)
    }
}

class SampleViewController: UIViewController, SampleDelegate {

    let button = UIButton()
    let model = SampleModel()

    func viewDidLoad() {
        super.viewDidLoad()
        
        // Focus point③
        // Sets a closure with capturing self instance.
        // But SampleModel don't know what instances captured (or not)
        // when it calls.
        model.didChangeIsEnabled = { [weak self] isEnabled in
            self?.button.isEnabled = isEnabled
        }
    }

    func buttonHandler(_ button: UIButton) {
        model.toggle()
    }
}

[tvvkcodehub]

"mvvm-delegates is not MVVM, actually that is MVP" - I think this explains the exact fundamental difference between MVP and MVVM.