MVP and DAL Operations

[Jeff S]

I'm designing an implementation of the Model View Presenter (MVP) pattern
for a Windows Forms MDI application.

Question: From where would it generally make sense to *initiate* data access
(e.g, CRUD) operations - the Model or the Presenter?

Please note that I'm *not combining* the data access layer with the MVP
objects. Rather, I have a completely separate DAL. Even so, the DAL methods
must be called/initiated from somewhere within the MVP objects. My tendency
is to put DAL calls into the Model (e.g., DAL.UpdateThisThing(thingID)), but
doing that would seem to have the model doing much more than the MVP pattern
intends for it to be doing. So this leaves the Presenter as the apparently
reasonable place in which to place calls to the DAL.

Thoughts? Opinions? Perspective?

Thanks!

 

[Ravi Ambros Wallau]

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...

 

[Rudderius]

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.