В простейшем виде можно сказать, что модель отвечает за представление данных.Определение самого шаблона MVC не делает различий относительно того, должна ли модель действовать только как структура данных или также должен содержать алгоритм / логику для извлечения / обновления / создания этого представления данных в хранилище данных (например,база данных).
Определенная неопределенность в определении Model между различными источниками определенно существует.Например, если вы посмотрите википедию [1] для шаблона проектирования MVC, вы увидите ниже определение модели:
Центральный компонент шаблона.Это динамическая структура данных приложения, независимая от пользовательского интерфейса. Она напрямую управляет данными, логикой и правилами приложения.
Тогда, если вы посмотрите на другой источник, такой как этот , это в некоторой степени противоречит определению из Википедии, говоря, что в нем нет логики, а является просто представлением данных.
Хотя я не собираюсь комментировать, какое определение является правильным, исходя из моего опытаЧто касается работы с корпоративными приложениями, я могу вам сказать, что почти всегда, когда мы говорим Model, когда говорим об архитектуре MVC, люди обычно называют ее представлением данных.Другими словами, они говорят о структуре данных.И я считаю, что это правильный подход к объекту Model.
С вашим примером модели Patient это будет POJO, который имеет private fields и getters и settersв простейшем виде.
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;
}
Поскольку вы упомянули, что извлекаете данные с сервера, я предполагаю, что данные хранятся в некоторой базе данных.Таким образом, в зависимости от технологии, которую вы используете для подключения / сопоставления моделей вашего домена (также называемых объектами моделей) с тем, как они представлены в базе данных, например, Hibernate / Open JPA , вы добавитеаннотации к вашему классу модели, чтобы сообщить объектному реляционному сопоставителю (ORM), что определенное поле в объекте модели отображается на определенный столбец в таблице в базе данных.Или, в зависимости от библиотеки, вы также можете использовать XML-конфигурации для отображения.После этого вы создали Model в своем приложении MVC.
Итак, куда вы помещаете всю ту логику / алгоритм, который вам необходим для выполнения операций CRUD на этой модели?Как получить Pateint с идентификатором 453 в вашем примере?Добро пожаловать в репозиторий Pattern [1] , [2] .Таким образом, Repository Pattern содержит логику, используемую для получения данных.В вашем примере поиск пациента (синоним поиска данных пациента из базы данных) будет осуществляться на уровне хранилища или более широко известен как Уровень доступа к данным .
В мире Java (по крайней мере,в отношении веб-технологий) API персистентности Java определяет модель запросов, которая реализуется несколькими провайдерами, такими как Hibernate, OpenJPA.Это то, что используется в слое хранилища.Именно на этом уровне вы добавляете логику поиска.
Большинство реализаций спецификации JPA уже поставляются с некоторыми API по умолчанию для выполнения простых операций CRUD над объектами модели.Я работал с Spring, и в вашем примере с Patient хранилище будет выглядеть примерно так:
public interface PatientRepository extends JpaRepository<Patient, Long> {
}
Вот и все.Если вы посмотрите на javadoc для SimpleJPARespoitory, у вас уже есть доступ к реализациям по умолчанию таких методов, как findById.Теперь вы можете внедрить / ссылаться на экземпляр PatientRepository в вашем Controller и получить доступ к данным.Мы вернемся к этому в следующей части.
Так что же собирается делать контроллер?Controller в самых общих чертах - это точка входа в ваше приложение. На самом деле это не так. Потому что это сервлет из Java Servelet API (в случае веб-приложения), который фактически передает управление контроллеру. Но с точки зрения высокого уровня понимания вы можете рассматривать контроллер как тот, который получает ваш запрос. Как только он получает запрос, он вызывает следующие слои, такие как ваш репозиторий, который использует логику, необходимую для получения данных из источника данных, построения объекта Model и передачи его контроллеру.
Так что в вашем примере PatientController будет выглядеть примерно так (в контексте среды Spring)
@RestController
@RequestMapping("/patients")
public interface PatientController {
@GetMapping("/{id}")
Pateint getPatient(@PathVariable int id);
}
и реализация вашего контроллера REST:
@Component
public class PatientControllerImpl implements PatientController {
@Autowired
PatientRepository pateintRepository;
@Override
public Patient getPatient(int id) {
Patient patient = patientRepository.findById(id);
return pateint;
}
}
Так что, если вы позвоните в приложение, запущенное на сервере, чтобы получить сведения о пациенте для ID 453 пациента, это будет что-то вроде:
http://localhost:8080/patients/453.
Затем он принимается контроллером, и вызывается метод getPatient. Затем он вызывает findById метод PateintRepository, который будет взаимодействовать с базой данных, получит сведения о пациенте с ID = 453, создаст объект модели Patient и вернется в контроллер.
Контроллер затем связывает этот объект Model с представлением и передает его обратно клиенту в любой форме, в которой он был запрошен.
Это, конечно, не показывает все лучшие практики. Но должен дать вам хороший обзор того, где и как все части будут соответствовать друг другу.
Существует множество статей по созданию приложения MVC. Я бы предложил вам начать с демонстрационного приложения Spring MVC.
Я также рекомендовал бы ознакомиться с классической 3-уровневой архитектурой для создания веб-приложений. Как только вы поймете это, вы сможете понять больше о MVC.