Model classes vs Model in MVC

Question

Does the model in MVC contain both business logic (algorithms and stuff) and the classes that are mapped to entity tables in databases? Those mapped classes are called model as well, specifically, because they model some data. My confusion is this: Does model contain the business logic? or is it just entities? It turns out that it contains, from Mozilla docs: Model: Manages data and business logic.

I got confused by how Java Spring projects are structured. There are controllers, service (business logic), repository(connection to database, aka DAOs) and model classes (Classes of objects that are received by controller and often mapped to database entities). Let's map this to MVC "components":

View - Not in a spring app;

Controller - Rest controller (or just Controller, depending on how you want to structure your app);

Model - Services, Repositories, Model classes (???).

I am confused here, that we have model in both left and right sides.

Thanks.

Edit: Adding a snippet of code, and the structure of app.

This is how spring application looks usually. What most of people do.

.
├── BasicSpringAppApplication.java
├── controller
│   └── CustomerController.java
├── model
│   └── Customer.java
├── repository
│   └── CustomerRepository.java
└── service
    └── CustomerService.java

This is how model/entity looks in a java file:

package com.example.basicspringapp.model;

public class Customer {
    private String id;
    private String name;
    private String surname;
    private int age;

    //constructors, getters, setters
}

Look what I called (and what they call usually) a model, only a specific thing, an entity. But in MVC it's more than that! Model includes not only entities, but services and repositories as well, anything which is not a view and a controller.

Why MVC pattern is messed up in usual spring applications? It seems messed up for me, at least. Why people doesn't call those classes an entity or something like that? Since the model is more than that, for MVC.

Answer 1

The model in MVC-based applications:

In an MVC-based application, the domain model (or, short, the model) mirrors a certain business. It is programmed as a layer - the model layer, or the business layer - and is composed of multiple objects of various types:

• Data mappers: transfer data between entities and the chosen persistence space (database, session, remote repository accessible through SOAP, etc).
• Repositories: transfer data between entities and the chosen persistence space, too, though by using data mappers from the data mapers layer. They build a layer additional to the data mappers layer, in order to hide the type of persistence space from their users. Each repository object is coded as a collection of entities of a certain type, accessible in a collection-like manner. So, for example, a collection of Book entities could be named BookCollection, or Library, or BooksRepository and would contain methods used to handle a collection of objects of type Book, like: "find/get/remove/update/store/exists/count/etc the book(s) in the book collection".
• Entities, or domain objects: to hold the data and the behavior requested by the specific business. These components contain the business logic which is independent of the application in which they are used. In other words, they can be reused by multiple applications.
• Value objects.
• Services, as part of the service layer. These objects contain business logic as well, but, in comparison to entities, their business rules are dependent of the application in which they are used. Because of this fact, it is debatable if the service classes should be defined as part of the domain model, or of the delivery mechanism (see the first two resources below).

So, in MVC-based applications:

• the model is not a class, but a layer of objects with different responsibilities;
• the model contains business logic in both entities and services;
• the domain objects contain both data and behavior.

By themselves, the entities are NOT mapped in any way to any persistence system (like a database). Their properties and methods mirror the specific business, by using a business-specific vocabulary, therefore beeing completely independent of the structure of the chosen persistence system. It is the responsibility of the data mappers - and theirs only! - to know about and map between the properties of the domain objects and the structure of the database records, for example.

In the first two resources below, at least, you'll discover that, in MVC-based applications, the persistence system (database, etc) does NOT determine the structure of the application. The persistence system is "just a detail".

Notes:

• Injecting other components of the model layer beside services into controllers results in wrongly having business logic in them. The sole purpose of the controllers should be to delegate the processing of the user request to the service layer.
• The advantages and disadvantages of the object-relational mapping systems (ORMs) are debatable.

Resources:

• Keynote: Architecture the Lost Years by Robert C. Martin
• Sandro Mancuso : Crafted Design
• How should a model be structured in MVC?
• Unbreakable Domain Models with slides
• DDD Building Blocks: Value Object
• Validating Value Objects
• A definition of the Ubiquitous Language
• The tutorials of Alejandro Gervasio, with PHP code: Building a Domain Model – An Introduction to Persistence Agnosticism, Building a Domain Model – Integrating Data Mappers, Handling Collections of Aggregate Roots – the Repository Pattern, An Introduction to Services
• Challenges of object–relational mapping, Object–relational impedance mismatch