In the old days, creating a project in programming languages meant coding on a plain page. Later on, with the emergence of extensions and structures, certain methods started to be used in coding. Of course, there were those who tried to hold on to the old model before this usage. But after a while, they gave up as well. Because the spaghetti code model had made projects increasingly difficult to understand.
Spaghetti code, as the name suggests, is code that is hard to understand, deeply lock like spaghetti, and nearly impossible to test. It deviated from SOLID principles and caused fatal errors with even minor changes.
Some people still write this kind of code today, but it is not possible for projects created this way to go anywhere or for those who continue to write such code to find any "opportunities." (There are exceptions, of course, but that's my personal opinion...)
After this complex period, some patterns emerged. One of the most well-known is MVC, which generally consists of the Model-View-Controller structure. It is perfectly understandable and testable and can be used in personal projects.
However, if you want to work as a team or build a powerful system, there are other alternatives. I want to focus on the most well-known one. That is MVVM.
Although it's called MVVM, it stands for Model-View-ViewModel. With this component change, we interact with other interfaces using a technology called binding. It fully adheres to the principles of Test-Driven Development (TDD). Unlike the independent model in MVC, it provides full access. It is also highly compatible with team collaboration.
Anyway, after these basic details, let's provide more detailed information about the MVVM pattern:
As you know, whether it's programming or any other field, if you want to work on a project and make it easier, you need to break down the large system in front of you into smaller pieces, as small as possible.
Imagine a movie application where movie cover images are displayed in two columns on the screen. When you tap on these cover images, you should go to a details page where you can see information about the movie, such as its title and plot, and from there, you should be able to go to a video playback page with another button.
In this structure, even though we have planned through three pages (list-detail-watch), we are actually talking about dozens of small components. What are these?
For example, the small section that contains the cover image and name of each movie on the list page is a component. Let's call it the movie component. Then, you will have as many instances of this component as the number of movies you want to list, but you will create it once and call it 20 times. This way, you can deal only with the movie component in case of any issues or enhancements.
Again, on the details page, the movie's cover image and name will be a component. The player on the watching page is also a component.
The toolbar at the top of the pages is another component. The hamburger menu that opens in the upper right is another component. This way, you will break down the code, increase readability, and test these components individually. You will find errors quickly and make additions easily.
That's exactly where the MVVM pattern comes in handy. The model controls the data coming from the API, the view controls the interfaces where this data is displayed, such as the list, detail, and player pages. The view model is responsible for all the logic happening here. There is no logic in the model or view; there are only connections in the view model. In other words, the view model communicates with both the model and the view, serving as a maestro or orchestra conductor between them.
Who wouldn't want that?
As a conclusion, let me provide an image of this mechanism.
With warm regards, until we meet again...