tags:

views:

168

answers:

4

I just cannot seem to get my head around what exactly is the MODEL in MVP.

If I have a layered architecture PRESENTATION / APPLICATION / DOMAIN / INFRASTRUCTURE, what exactly is the MODEL?

  1. DOMAIN objects accessed through lower layers?
  2. A separate object defined in the PRESENTATION layer that maps to the UI and uses data obtained from a lower layer?

If someone could clear my understanding on what is the MODEL it would be greatly appreciated.

+3  A: 

In any of the Model-View-* architectures, the Model is what describes the data in your application (and, if they fit the need, are passed in to the View for rendering).

If your application already has Domain objects, it very well may be the case that you could use them for your Model.

Justin Niessner
Justin what do you mean by if they fit the need?
David
By "fit the need" I meant if they express the data you need to render in your views. If not, the problem could easily be solved by using View Models...which are pretty much Models meant specifically for expressing data to render in Views.
Justin Niessner
Who would be responsible for creating these View Models? Are View Models the same as what I've seen referred to as screen DTOs?
David
I would assume the View Model would be a functional equivalent to a screen DTO. As for who should be responsible for creating them...it all depends on your team structure. I'd say whoever is creating the View should be responsible for creating the View Model since they're the ones who are going to use/consume it.
Justin Niessner
Appologies for not being clear on my last comment. By responsible I was meaning in terms of what would be responsible. Would it be the presenters responsibilty to put together the View Model.
David
Sorry for the confusion...and yes, it would be the Presenter's responsibility for constructing the View Model.
Justin Niessner
+1  A: 

The model is the data. This might just be data out of a database in DataSets, or it might be a complete domain model with objects representing your field of business.

The view is the UI, whether web pages or a Windows application or a mobile device application.

The presenter is the glue between the two and the brains of the whole outfit. Actions initiated by the view take place in the presenter. Generally in a WinForms application, for instance, a Button.Click event in my View simply calls a method on the Presenter, which then takes whatever action is necessary (and it may just be doing something back in the View).

The presenter holds a reference to the view (through an interface), and to the model. The view has a reference to the presenter (usually I strongly-type this, but it can be an interface as well). The model doesn't know about the presenter or the view.

Kyralessa
Is it the presenter that would then determine for example if a button was enabled/disabled based upon some logic surrounding the state of the model
David
In general, yes. I'm not above doing things all in the view on occasion where there are two interdependent parts of the view that have no connection with the presenter or the model. I think the best rule of thumb on that is whether the thing being done would need to be done in *any* UI (in which case it should be done from the presenter) or whether it's specific to the particular type of UI you're using (e.g. something you'd do in WinForms but not in WPF).
Kyralessa
+1  A: 

It doesn't matter what architectural guidelines you're following, M is always going to be the same thing. The Model is the piece that is specific to your domain. It's the part that really is what you're application is trying to do. The Model is supposed to represent your business domain. This goes for MVP, MVC, MVVM, etc.

If you were making a inventory system, then an Inventory class would most likely be in your Model, a Product would probably be there, an Order, you get the idea. These are the things that compose your domain logic.

Joseph
+2  A: 

The Model is normally the group of classes/types/components that represent the core domain (business or otherwise) that your application operates within. These are the classes that perform the key logic required, often in the form of business rules, and also consume/manipulate data.

In your layered example, the Model would mostly be found in the Domain layer but could also be in the Application layer.

I think you're having difficulty understanding it because you are trying to combine two separate architectural patterns, or ways of looking at the application, being n-tier/n-layer versus MVP.

It's completely reasonable (and quite common) to use some sort of Model/View approach while at the same time applying layering in your application.

Maybe you should focus on them one at a time to start with and then overlay them when you are more familiar with both.

Ash
Are you saying that these two architectural patterns are distinct and should not be combined?
David
Models are all about data. Any logic they contain pertains to the data and its integrity. They shouldn't contain view or controller logic (how to display model contents or what models should be presented to the view in response to user input).
Will
@David, No, to be honest i have misread MVP for the more general MVC. MVP is all about your UI as far as I am aware. I actually find the reuse of Model in these various patterns annoying. For the most widely agreed definiton of Model you should have a look at Patterns of Enterpise Applkication Architecture by Martin Fowler.
Ash
@Will, in MVP it appears that's correct, definitely not in the broader sense of Model View Controller. But this is exactly why David why asked the question. Eveyone and their dog has come up with a definition of Model these days. I usually go by Martin Fowlers book (see previous comemnt).
Ash