The MVVM and other ideas in the issue are, at the core, about broadening what the definition of "model" means in an app. The authors seem to think "model" currently is just the data store of an app. But that's never been correct.
The model in MVC is the aspect of the real world that's being reflected in the app. This can and should include network communications and business logic. The architectural issues here are that people are mis-using the idea of a model.
That's just the fat model approach. It suffers from similar issues as fat controllers, whereby unrelated functionality tends to accumulate.
Why do models know how to persist themselves? Or send themselves over the network? What does that have to do with the concept they represent? It conflates technical concerns ("how do I serialize myself?") with business concerns ("am I valid?").
Hi there – I wrote the MVVM article, and I see your point. There is a line to be drawn somewhere, but that's often up to the developer. However, on iOS, models tend to be very thin, through convention (typically, they're only a Core Data "managed object" and have no logic at all in them). I hope that helps clarify where the article is coming from.
Hmm... If I may say so I find that the MVVM pattern in iOS to be very cumbersome when compared to how it can be done in WPF. You essentially need another layer of indirection in iOS where you need none in WPF. That's probably why I personally haven't heard about it before in CocoaTouch land.
Comments
The MVVM and other ideas in the issue are, at the core, about broadening what the definition of "model" means in an app. The authors seem to think "model" currently is just the data store of an app. But that's never been correct.
The model in MVC is the aspect of the real world that's being reflected in the app. This can and should include network communications and business logic. The architectural issues here are that people are mis-using the idea of a model.
That's just the fat model approach. It suffers from similar issues as fat controllers, whereby unrelated functionality tends to accumulate.
Why do models know how to persist themselves? Or send themselves over the network? What does that have to do with the concept they represent? It conflates technical concerns ("how do I serialize myself?") with business concerns ("am I valid?").
It doesn't help that Core Data forces you into the framework superclass antipattern: http://michaelfeathers.typepad.com/michael_feathers_blog/201...
Hi there – I wrote the MVVM article, and I see your point. There is a line to be drawn somewhere, but that's often up to the developer. However, on iOS, models tend to be very thin, through convention (typically, they're only a Core Data "managed object" and have no logic at all in them). I hope that helps clarify where the article is coming from.
Hmm... If I may say so I find that the MVVM pattern in iOS to be very cumbersome when compared to how it can be done in WPF. You essentially need another layer of indirection in iOS where you need none in WPF. That's probably why I personally haven't heard about it before in CocoaTouch land.
And I guess technically it's MVVCVM.