MVVM - Why are the businesses stored in the ViewController

In the MVVM diagram the ViewController dosent know the model.
In are case the model is an array of businesses.

So why is the example is the array stored in the ViewController and not in the ViewModel?
Or am i getting this all wrong?


@jstrawn Can you please help with this when you get a chance? Thank you - much appreciated! :]

Thanks for your question, @ilandbt ! :]

ViewController receives the businesses from its client, which is an instance of YLPClient and is used to get search results from Yelp.

Each BusinessViewModel knows about only one YLPBusiness. The purpose of BusinessViewModel (like all view models) is transforming model information into values that can be displayed on a view. Hence, one BusinessViewModel transforms one YLPBusiness into values that can be displayed. It’s not required (and doesn’t make sense) for BusinessViewModel to know about all YLPBusiness objects, as it only deals with just one.

However, you’re right that technically the ViewController doesn’t need to hold onto businesses! Rather, it could have immediately converted the businesses into businessViewModels after it receives them from Yelp.

This makes sense for this chapter here, but in a later chapter, you’ll add a Filter to only show certain businesses, based on their star rating.

This Filter uses businesses directly, instead of the view models.

Taking another look at the code, however, this too could have used view models instead of the models directly!

I’ll talk with @jstrawn about updating these chapters to have the view controller hold onto the view models only, instead of the models, in the next iteration of this book. :]

1 Like

Thanks so much for the answer @jrg.developer .

So does it make any sense to have a ViewControllerViewModel to handle manipulating the list of business for the map view?
Like filtering?

A ViewControllerViewModel (if I understand what you mean correctly) might be overkill. View Models are for transforming data into something that can be shown on a screen (a Date into a String for example). While it’s a good idea to have as many View Models as you need, making View Models for setting up your view controller could get confusing, since the logic would be more spread out.

If you have a large ViewController that could benefit from abstraction, instead of making a View Model for it, you could split it up into parts. For example, if you have a large View Controller containing a detailed view object (a custom button, a popup, etc), instead of doing logic for that view inside the View Controller, you could make that view its own class and do setup in the view class, then display that view in the View Controller.

I hope that helps! And thanks for the suggestion, you’re right that the View Controller doesn’t need to hold on to businesses!

As @jstrawn mentions, this isn’t exactly a “view model,” which by definition is used for converting model data into view displayable forms… that is, a view controller isn’t a model.

However, you’re on the right track that it seems “wrong” to have the view controller do this filtering – view controllers are often the most overloaded classes in apps!

Thereby, it does make sense to pull this into another class; it’s just not a “view model” per se.

You’ll actually do this later in the book: See chapter 13 wherein you create Filter for this purpose.

This goes right along with @jstrawn 's suggestion:

I’d add that you don’t have to just create child views or child view controllers, though. You can create whatever classes make sense to manage the work that needs to be done. :]