Is it ok to have MVVM without model for temporary things?

Question

Do you think it is alright from architectural stand-point to have ViewModel - View without model for temporary things?

Eg: I want users to input some paths so I can open some files later on. It doesn't make sense for me to store the paths anywhere just ViewModel and when the user clicks "Show all files" I then construct models of the files and ViewModels for View that represent them somehow. So really my only model is the model of the file.

Answer 1

I think sometimes people mistake design and architectural patterns as hard and fast rules. We need to understand that these are just guidelines. One example of this could be the way different programming languages implement singleton pattern.

So I would say if you need the functionality of View Model to be bound to View but really don't require a model, there shouldn't be any problem in ignoring the model. I would suggest use these patterns as guidelines and not as hard and fast rules. Feel free to make minor adjustments wherever applicable.

But at the same time keep in mind that you are not violating the purpose with which these layers are created. It should not happen like we bypass the model and start querying the backend database directly from the View Model. As long as the basic principle of separation of concerns is adhered to everything should be fine.

Answer 2

Of course. If it suits your business process, why not.
But you could probably still use a model to have some sort of in-memory persistence of the entered paths.

Answer 3

Sure. There's no sense in moving the file-opening logic to a separate object just so that you can say you've done it.