I use the MVC pattern, but I thing it's the same thing...
I believe that the "C" (controller) or "P" (presenter) should process the
workflow of your application, making the navigation between your forms,
checking if some page can be open, etc...
But all persistence should be made by the model. The model is light,
anyway... The model should call another class to persist your data, a BLL or
something like that.
I made two MVC implementations, one in java and another in C# (ASP.NET). On
both, the model was responsable for data persistance. The BLL class was
configured in my "task" (when using Microsoft UIPAB), and other things were
also configured on this class.

You should have in mind that the model does not change - the presenter and
the view can change... The model is aware of what the view and the presenter
are, but the view and the presenter knows about the model (have references
to it). I use the model to persist data, and I also keep other things on the
model (even navigation values - I have a "free" hashtable to store this
stuff)...

In a phare, use the model...

I've seen implementations of the MVC/MVP pattern which are, in my humble
opinion, not exactly correct. The thing I often see is the following:
there is a presenter class (e.g. a windows form) and a model class (a
custom object). very often, people have the presenter class intantiated
first en it is the presenter class that keeps a reference to the model
class.

I think this is wrong. What i do is the following.

I make classes which I call controlers. They control the user interface.
Let me give an example: I want to show some information on a customer. I
will create an instance of a CustomerController class (the model class)
which will get the information about the customer from the DAL and
create a form to show all the information. It is the controller that
sets the date on the form and that handles the events.
The reason I do it this way is the following. My winforms are completely
independent from any other class! They have properties to set the data
en they fire event when the user clicks on a button or changes a field
etc. This makes the winform like a blackbox: i put some data in it, en
when the user does something, the form returns me something. This means
that I have for kinds of classes: forms or webpages, controllers,
business objects and DAL objects.

In most implementations of the mvc/mvp pattern i've seen, the
presentation layer components (forms/webpage...) are not completely
independent form the model classes, in my opinion, this is a shortcoming...

So, espacially for you, I would say, the access to the DAL is something
for the process classes. For you, it depends on what you understand as
the 'model', if it are your business objects: do not put any code to
access the DAL in there! If you model controls the flow of the program:
this is the place to be!

Hope this gives you some ideas.