I have read plenty of questions on here, which appear to confuse the MVP/MVC Model with the Domain Model. In my mind the MVP Model calls the Service, which then calls a rich Domain Model i.e. the MVC/MVP model is a view model..

I have seen a lot of code, which does this (this is the MVC Model):

public class Model : IModel
    private IService service;

    public PersonModel GetPerson(int id)
        PersonDTO personDTO = service.GetPerson(int id);
        PersonModel personModel = Mapper.Map<PersonModel>(personDTO);
        return personModel;

The model calls the service and the service calls a rich domain model i.e. a domain model where the classes contain both state and behaviour.

Notice in the above code that there is a class called Model (which contains behaviour and calls the service) and a class called PersonModel. Should there be one class called PersonModel, which contains both state and behaviour if a rich Domain Model is by the business layer/domain layer? I am talking about best practice here. I know both approaches work.

  • 2
    In MVP it's the presenter that calls the service, not the model. I don't know why you're mixing asp.net-mvc with mvp in the same question since the M is different from one another.
    – devnull
    Jun 7 '17 at 9:09

From an mvc perspective the two separate classes in your example is desirable over a single class. This gives you proper separation of concerns which helps your code be maintained more easily. If your PersonModel contained Service in it then you would exposing that to the view which is against the mvc pattern, if it had a non-functioning Service so you are isolating the view from data access then you have a partially functioning object which is probably worse and will cause headaches. Furthermore, by having the separate classes you give PersonModel only one reason to change, which is what a person is has changed. Service is also unaffected by changes to what a person is as its only concerned with how to get that person. Keeping this separation helps keep you business layer from leaking into your model and duplicating logic or coupling them to the point they can't be cleanly separated any more.

  • What should call the service in an MVP app? The model or the Presenter?
    – w0051977
    Jun 7 '17 at 12:24

MVP & MVC are UI design patterns I don't see how business logic would sit anywhere within it's bounds.

IMO the model in these patterns are simply view models that contain the data the view displays. The presenter/controller would query services/domain models and populate the view model with the result of these queries.

  • MVP is indeed for UI but MVC is an architectural pattern. The M part of it comprises the entire logic that manages what's being displayed/edited in the view.
    – devnull
    Jun 7 '17 at 13:23
  • 1
    @devnull according to wikipedia Model–view–controller (MVC) is a software architectural pattern for implementing user interfaces on computers Jun 7 '17 at 13:43
  • What I meant was that MVP is mostly used to implement user interfaces while MVC can be used to develop things than span outside the concept of a user interface. That is, the V part can represent a JSON object, a stylesheet, a javascript file etc.
    – devnull
    Jun 7 '17 at 13:55
  • @devnull MVC is for UI. The M is View-Model, not business model. The microsoft framework implementation muddles this, but they are not the end all of good software development practices. Jun 7 '17 at 16:35
  • 1
    @devnull OK, good luck trying to bind a view directly to a domain model. Jun 7 '17 at 16:48

No. The controller or presenter should ideally contain all of your behavior.

The purpose of using an MVC/MVP framework is to separate code/data into a model (typically your database), a view (what the user will be interacting with), and a controller/presenter, which is your middle-man between the model and view. If a developer were to join your team, they would immediately look to the controller/presenter if behavior change is the desired result.

You can, of course, add behavior in the view. It's just pointless and will lead to complications down the line, so I say avoid it.


Independently of the pattern, we should keep in mind that design patterns are a tool/language for communication among developers.

A different implementation of the pattern lead to confusion, to false assumptions and distort the communication.

So, regarding to the question

Should there be one class called PersonModel, which contains both state and behaviour if a rich Domain Model is by the business layer/domain layer?

I would say no, it should not.

In both cases (MVC and MVP), should be the controller/presenter who does the call to the service. In the abscence of the service layer, these two components do the call to the higher level components of the domain model. For instance, to the Repositories.

Additionally, two more reasons could be that, the example above, breaks the cohesion and violates the SRP.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.