MVVM distinguish between Model and View-Model and Models relashionships on reactive architecture

Question

This should be a simple MVVM - reactive architecture question, something that I miss probably.

I'll start with a context example:

I have a Music Tracks Player application with 2 models Player and Track. The relation between player and track is pretty obvious: the player contains tracks (multiple track can be played simultaneously), so in an Object Orient architecture I would store (or reference I should say) a list of tracks objects inside a player instance.

How should I reflect this relation On my MVVM reactive app? should I create player model that holds a list of tracks? or should I have handle them separately on my View-Model? If I store only the Player model then how do I detect changes on each Track (for example progress of a track)? Or maybe each View part (Player, and list of tracks) should have its own view-model, but then how would they know about each other for example a player need to know how much tracks it has for some logic calculations for view representation?

On my View side I have to show both of them, for example the player state (name, status, metadata) and for every track I should display the current position in track etc.

Thanks :)

Answer 1

Your model should be designed according to the business rules, without regard to any view or views it may eventually be displayed on. If it makes the most sense to have a Player hold multiple Tracks, then it makes sense no matter what your view(s) look like.

Your View Model's job is to adapt the model to whatever format makes the most sense for the view. You should end up with a view model for every view, but it's up to you how granular you want to get with that.

For example, maybe you have a single view that represents the an entire window (and therefore only have one view model per window,) or maybe you break the window up into several components (in which case you would have a view model for every component.) A more component-ized system can promote reuse across windows but the extra abstraction might make the code harder to read. You have to balance the good with the bad.