In its simplest form you could say that model is responsible for the representation of data. The definition of the MVC pattern itself doesn't make a distinction as to whether the model should only act as a data structure or should also house the algorithm/logic to retrieve/update/create this representation of the data in the datastore (for example a database).
There definitely is ambiguity in the definition of a Model between various sources. For example if you look up wikipedia [1] for MVC design pattern, you will come across below definition of model:
The central component of the pattern. It is the application's dynamic data structure, independent of the user interface It directly manages the data, logic and rules of the application.
Then if you look at a different source like this one, it contradicts the definition from wikipedia to some extent by saying that it houses no logic but is purely a representation of the data.
While I am not going to comment on which definition is right, from my experience of working on enterprise applications, I can tell you that almost always, when we say Model while talking about MVC architecture, people are mostly referring to it as a representation of data. In other words they are talking about the structure of the data. And I believe this is the right way to think of a Model object.
With your example of a Patient model, this would be a POJO which has the private fields and getters and setters in its simplest form.
public class Patient {
private int id;
private String name;
...
// more properties
public int getId() {
return this.id;
}
public String getName() {
return this.name;
}
public void setId(int id) {
this.id = id;
}
public void setName(String name) {
this.name = name;
}
Since you mentioned you are retrieving data from a server, I will assume the data is stored in some database. So depending on the technology you are using to connect/map your domain models (aka Model Objects) to how they are represented in the database, for example Hibernate / Open JPA you will add annotations to your model class to tell the Object Relational Mapper (ORM) that a specific field in the model object maps to a specific column in the table, in a database. Or depending on the library you may also end up using XML configurations to do the mapping.
With that you have created your Model in your MVC application.
So where do you put all that logic/algorithm you need to perform CRUD operations on this Model? Like retrieving Pateint with ID 453 in your example? Welcome to Repository Pattern [1], [2]. So it is the Repository Pattern that houses the logic used to retrieve the data. In your example the searching of patient (synonymous to retrieving the patient data from database) will live in the repository layer or more commonly known as Data Access Layer.
In Java world (at least w.r.t web technologies) the Java Persistence API defines the query model that is implemented by several providers like Hibernate, OpenJPA. This is what gets used in the repository layer. It is in this layer, you add the search logic.
Most implementations of the JPA specification already come with some default API's to perform simple CRUD operations on your model objects. I have worked with Spring and In your Patient example the repository would be something like below:
public interface PatientRepository extends JpaRepository<Patient, Long> {
}
Thats it. If you look at the javadoc for SimpleJPARespoitory, you already have access to default implementations of methods like findById. Now you can inject / reference an instance of the PatientRepository in your Controller and access the data. We will get to that in the next part.
So what is the controller going to do?
The Controller in the most general terms is like an entry point into your application. In reality its not. Because its the servlet from Java Servelet API (in case of a web application) that actually passes the control to the Controller. But from a high level understanding view point, you can treat the controller as the one that receives your request. Once it receive sthe request, it calls the below layers like your Repository which uses the logic it has to get data from data source and build the Model object and give it to the Controller.
So in your example the PatientController would look something like this (in the context of Spring framework)
@RestController
@RequestMapping("/patients")
public interface PatientController {
@GetMapping("/{id}")
Pateint getPatient(@PathVariable int id);
}
and the implementation of your REST controller:
@Component
public class PatientControllerImpl implements PatientController {
@Autowired
PatientRepository pateintRepository;
@Override
public Patient getPatient(int id) {
Patient patient = patientRepository.findById(id);
return pateint;
}
}
So if you make a call to your application running on the server to get the Patient details for patient ID 453, it would be something like:
http://localhost:8080/patients/453.
This is then received by the controller and the getPatient method gets invoked. It then invokes the findById method of the PateintRepository which will talk to the database, get the Patient details with ID = 453, construct the Patient model object and return to Controller.
The Controller then binds this Model object to a view and passes it back to the client in whatever form it was requested.
This of course doesn't show all the best practices. But should give you a good overview of where and how all the pieces would fit together.
There are ton of articles on building MVC application. I would suggest you start with a demo Spring MVC application.
I would also suggest reading up on classic 3-tier architecture for building web applications. Once you understand this, you will be able to understand more on MVC.
