Я видел различные аргументы против прямого вызова DAO из класса Controller, а также DAO из класса Model. Фактически я лично чувствую, что если мы следуем шаблону MVC, контроллер должен быть связан не с DAO, а с классом Model. должен вызывать DAO изнутри, а контроллер должен вызывать класс модели. Почему мы можем отделить класс модели от веб-приложения и предоставить различные функции, например, для службы REST, чтобы использовать наш класс модели.
Если мы запишем вызов DAO в контроллере, для службы REST не будет возможности повторно использовать функциональность, верно? Я суммировал оба подхода ниже.
Подход № 1
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
new CustomerDAO().save(customer);
}
}Подход № 2
public class CustomerController extends HttpServlet {
proctected void doPost(....) {
Customer customer = new Customer("xxxxx","23",1);
customer.save(customer);
}
}
public class Customer {
...........
private void save(Customer customer){
new CustomerDAO().save(customer);
}
}Примечание -
Вот что такое определение модели:
Модель: модель управляет поведением и данными домена приложения, отвечает на запросы информации о его состоянии (обычно из представления) и отвечает на инструкции по изменению состояния (обычно от контроллера).
В управляемых событиями системах модель уведомляет наблюдателей (обычно просмотров), когда информация изменяется, чтобы они могли реагировать.
Мне нужно мнение эксперта по этому вопросу, потому что я нахожу, что многие используют №1 или №2. Так что же это?
Ответы:
На мой взгляд, вы должны различать шаблон MVC и 3-уровневую архитектуру. Подводить итоги:
3-х уровневая архитектура:
Шаблон MVC имеет место на уровне представления вышеупомянутой архитектуры (для веб-приложения):
Жизненный цикл типичного HTTP-запроса:
источник
С модельного слоя.
Точнее, из сервисов, которые содержатся на уровне модели , поскольку они управляют взаимодействием между объектами домена и логическими абстракциями хранилища.
Контроллер должен отвечать только за изменение состояния уровня модели. DAOs являются частью постоянного механизма. Это составляет часть бизнес-логики и прикладной логики. Если вы начнете взаимодействовать с DAO в контроллере, у вас будет утечка логики домена на уровне представления .
источник
Я не уверен, к чему призывает официальный шаблон MVC, но обычно мне нравится иметь «служебный» слой между контроллерами и DAO. Контроллер извлекает данные из запроса и передает их в соответствующий класс обслуживания. Класс обслуживания отвечает за вызов одного или нескольких DAO, которые возвращают класс (ы) модели. Эти классы моделей затем отправляются обратно в контроллер для отправки на уровень представления. Помещение уровня обслуживания помогает с повторным использованием, поскольку несколько контроллеров могут использовать одни и те же методы уровня обслуживания.
источник