Since I have not found major references to this topic or a guide to good practices, I have not been able to form an opinion.
I am just entering the MVVM world with WPF and I see that there are several references where it is mentioned that within an MVVM project the three standard folders Model, View and ViewModel must exist, however I wanted to know if it is good practice to combine that standard with the form layered programming, that is, create a project for data access, another for business logic and in a third have MVVM with their respective folders.
My question is, is it good practice to combine the MVVM standard with layered programming?
The project that I am putting together is going to be all in C#.
The way I see it, MVVM separates VIEW and CODE, being the code the one that is divided into Model and ViewModel, now, with that clear, the Models -which would be something like the typical classes, person, ticket, etc- they must be updated from the ViewModel and in turn the ViewModel must read the changes in the Model, so I deduce that the data access goes in the ViewModel, now this is where I come to the same question, is it good to put access by layers? And my answer is Absolutely YES.
Because? Because it helps to order the code even more, I've been a C# developer for 2 years and in WPF I always use MVVM mixed with layers, BUT when it comes to Models I also apply the principle that they are self-managed, for example when updating data from a person in the DB, the logical thing for me would be to call it as Person.Update() or something like that;
Then I centralize the controllers and create a connector for each type of connection that the software makes... like so:
Naturally I am not the owner of the truth and there must be someone who has a more accurate approach, but at least for my part I think that working like this is a very good way of keeping each module organized, MVVM is very general but flexible at the same time and there is no nothing wrong with taking the best of each pattern and adapting it to what you require, remember that technology is made to adapt to you and not the other way around.
All the best.
It all depends on how you want to structure your project. Remember that the design patterns are just that, they are a guide but it depends on you and the needs of the project to implement them in one way or another.
You can use layers, even mvc/mvvm/mvp can be just the presentation layer and you have your business layer and then the data layer, or you can implement the business layer in the model.
What I do is that depending on the complexity of the project, I separate the business logic or not, also if the business logic is going to be reused or not, I separate it and leave the model cleaner and with less load.