How to organize an MVP for the table editor?

Question

.NET

Good afternoon.
I am engaged in independent study of C #, for this I write a program for work. The purpose of the program is to take data from the OPC server by enumeration (20 pieces each) and transfer them to the SQL server.
I conditionally divided the program into three parts:
- the simplest table editor (with validation)
- OPC client
- SQL client I
almost completed the program prototype. I tried all the main functions, but the program turned out to be very discordant and confusing. I decided to use MVP to remake the program. I seem to understand the basic principle of MVP:
View - simply displays data and responds to user actions
Presenter - changes both the model and the view
Model - contacts the data
I looked and repeated a few simple examples, but I still don’t understand how to organize the work of a simple table editor. It is not clear to me what the model should be and how exactly to store the data for display on the View.
For example, the user decided to create a new table. Selected in the menu File-> New. By clicking on the New button, an event is triggered, to which the Presenter is subscribed, which in turn requests a new (empty) table from the Model with a predefined schema, and then I have a stupor. What should happen next? The model should pass a link to the new table to the Presenter, which in turn, through the IView interface, will put it in the dataSource of the DataGridView component? Or should the table be created in the Model and a copy sent to the View? Or somehow else?
So far I can't figure these out.
PS I rummaged around and realized that I needed to dig towards the virtual datagridview mode.

Answer 1

MVP only makes sense for WinForms.
WinForms really makes no sense to take now. Better than WPF with MVVM.
There is a good example from this guy :
markheath.net/downloads/podcastmvp.zip
Presenter is usually either Passive or Observing. You seem to be passive.
Passive is a tin, because you do everything with the look of your hands through Set / Get. It works, but it turns out a lot of code just to check the box.
Therefore, they use the "observer", those bind (Bindings.Add) view to the presenter.
For bindings to work, you need to bind the table to either ObservingCollection<table columns> (WPF/Winforms) or BindingList(winforms).
The presenter must then implement INotifyPropertyChanged like the class you give ObservingCollection.
Here the paths of M and P diverge because in the model you have some kind of ORM thread for the database and you need to convert the object that is in the database to the object that is in the table. Either you pass the object from the presenter to the model, which cleans it up and repopulates it, or the presenter calls a model method that gives a new object.
"F * pa" will start when there is a lot of data and you decide to read them in a task or asynchronously. There is a DB session in the model, and they don’t really like when they are used from another thread (our grit is not supposed to).