У MVC DAO слід викликати від Controller або Model


14

Я бачив різні аргументи проти того, щоб DAO викликався безпосередньо з класу Controller, а також DAO з класу Model.Infact Я особисто вважаю, що якщо ми слідуємо за схемою MVC, контролер повинен поєднуватися не з DAO, а з класом Model слід викликати DAO зсередини, а контролер повинен викликати клас моделі. Чому тому, що ми можемо роз'єднати клас моделі, окрім webapplication і розкрити функціональні можливості різними способами, як для служби 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. Отже, який це?


1
Контролер повинен завантажувати все від моделі та передавати його на вигляд.
jgauffin

ти підхід №2?

1
"Контролер може надсилати команди до пов'язаного з ним перегляду, щоб змінити подання моделі у поданні (наприклад, прокручуючи документ). Він може надсилати команди моделі для оновлення стану моделі (наприклад, редагування документа)." .. Емм .. де це говорить, що контролер повинен видобувати дані або передавати їх навколо?
mefisto

Відповіді:


31

На мою думку, ви повинні розрізняти модель MVC та 3-рівневу архітектуру. Підсумовуючи:

3-ярусна архітектура:

  • дані: збережені дані;
  • сервіс: логічна частина програми;
  • презентація: hmi, веб-сервіс ...

Шаблон MVC має місце в ярусі представлення вищезгаданої архітектури (для веб-сайту):

  • дані: ...;
  • сервіс: ...;
  • презентація:
    • контролер: перехоплює HTTP-запит і повертає відповідь HTTP;
    • модель: зберігає дані для відображення / обробки;
    • перегляд: організовує вихід / відображення.

Життєвий цикл типового HTTP запиту:

  1. Користувач надсилає HTTP-запит;
  2. Контролер перехоплює його;
  3. Контролер викликає відповідну службу;
  4. Служба викликає відповідне дао, яке повертає деякі збережені дані (наприклад);
  5. Служба обробляє дані та повертає дані контролеру;
  6. Контролер зберігає дані у відповідній моделі та викликає відповідний вигляд;
  7. Подання отримати екземпляр з даними моделі, і отримати повертається в якості відповіді HTTP.

1
Те, що ви називаєте "життєвим циклом типового запиту HTTP", - це не MVC. І DAO - це просто об'єкт, який полегшує взаємодію / переклад між логікою домену та стійкістю. Це НЕ інша назва для активного запису. Також .. з тих пір, коли модель стала частиною презентації ?!
mefisto

1
@teresko 1) Так, це MVC, але в межах 3-х рівневої архітектури. Якщо ні, то чому? 2) Ви мали рацію, я редагував. 3) Оскільки весь шаблон MVC відбувається в ярусі презентації. Типовий приклад: Spring MVC, моделями якого є лише Карти, що містять пари ключ-значення. SpringFuse також зробив цей вибір.
sp00m

2
Я маю згоду з @ sp00m тут ... Його опис типового HTTP-запиту є точним для веб-додатків MVC, і його позиціонування Моделі (як 'M' у MVC) як частини шару презентації також правильне . У n-ярусних програмах MVC 'Модель', як правило, є фасадом ярусу презентації на інших рівнях нижче.
Ерік Кінг

8

З шару моделі.

Якщо бути точнішим: від служб, які містяться в шарі моделі , оскільки вони регулюють взаємодію між об'єктами домену та абстракціями логіки зберігання.

Контролер повинен відповідати лише за зміну стану шару моделі. DAO є частиною механізму стійкості. Це є складовою логіки бізнесу та домену. Якщо ви почнете взаємодію з DAO в контролері, ви будете просочувати логіку домену в шарі презентації .


Щоб використовувати сервісний рівень, це повинен бути шаблон DDD? виправте мене, якщо я помиляюся. Чи є у нас сервісний рівень у MVC?

Ти можеш мати. Служби використовуються для відділення логіки домену від логіки програми. Це стає необхідним, тоді ви переходите від чистої структури домену CRUD (активний запис) до чогось, що відокремлює логіку зберігання від доменної логіки. У повністю реалізованому шарі моделі у вас є 3 логічні розділення: стійкість, домен та додаток.
mefisto

3

Я не впевнений, до чого вимагає офіційний шаблон MVC, але я, як правило, люблю мати "сервісний" шар між контролерами та DAO. Контролер витягує дані із запиту та передає їх у відповідний клас обслуговування. Клас обслуговування відповідає за виклик одного або декількох DAO, які передають назад моделі класів. Ці класи моделей потім надсилаються назад до контролера для того, щоб бути надісланим до рівня перегляду. Введення сервісного рівня допомагає при повторному використанні, оскільки кілька контролерів можуть використовувати однакові методи рівня обслуговування.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.