What is the best way to implement MVC/MVP architecture?

Question

OOP

I am doing a project. I use MVP architecture. The view is divided into components.

First question. I get all the information about the change in the components, perform all the necessary calculations, and pass the ready-made values ​​to the model. Is it possible to do this in MVC/MVP? Or should the view only receive data, and perform calculations in another layer?

Second question. When calculating, "service data" is needed, such as coordinates, position, and so on. That is, this is data that should not be in the model. That is, it is logical to transfer this data only between components. With any change, this data must change for all components. The solution that I implemented: when initializing the components, I pass an object that stores this data in itself. Components in calculations refer to this object and change it if necessary. In this way, the components have access to up-to-date data. Is it possible to do so?

Answer 1

The first step is to refer to the description [ T ] MVP from Martin Fowler.
Fowler immediately operates on top of the GUI based on the form and element model, i.e. considering your specific case.
The form and element model operates on element events to interpret user input. According to Fowler, the handling of these events should be left to the presenter. The presenter in this case processes the user input, passes it to the model, and collects updated data from the model to pass to the view. The internal data of the view, which is not intended for the model, must also be processed by the presenter, after which everything should be passed to the view in the same way.
The view should only display model data and signal user input to the presenter.
What happens if you do it differently. For example, as described in your question. Now you have lost your flexibility and literally destroyed the abstraction of the presenter. If the presenter suddenly needs to be made composite (for example, to select visible and inputable view elements), you will run into refactoring of both the view and the presenter. This will delay the compositing implementation of the presenter logic. If you need to keep several views for one model at the same time, you will have to somehow implement Change Propagation. In an ordinary MVP, the presenter is responsible for this, and it will turn out that the view must subscribe to the notification, which is no longer typical for MVP, but for MVC.
MVP, like MVC, is an architectural pattern. Such patterns are at the topmost level of the pattern relationship pyramid. This suggests that just the implementation of MVC / MVP in the forehead in the code is undesirable. MVC/MVP imposes a strict separation of functionality on UI code: data entry, processing, and data output. This is what should be explicitly present in your code, this is what should be implemented using design patterns and development idioms. For example, a presenter or controller can be formed on the basis of Rx and be completely decentralized, but at the same time perform its functions with high quality. And the view can even be a data-driven object, i.e. not have even a minimal personal logic.
Each architectural pattern, in addition to easy support, is formed based on initial simplicity, interoperability with other architectural patterns, and potential extensibility.
As a result, having initially laid down a weak implementation of MVP, with further actions you risk blurring the boundaries of architectural elements, reducing the transparency of the implementation for understanding by other people, and complicating the support of this code.

Answer 2

The purpose of the View is to display data and pass it to another layer. By definition, there can be no calculations and business logic in the View.

That is, this is data that should not be in the model.

And where should they be if not in the model?
I advise you to read the theory again.
As an option - choose another architecture other than MVC / MVP